Memecahkan masalah TensorFlow - TPU

Panduan ini, bersama dengan FAQ, memberikan bantuan pemecahan masalah bagi pengguna yang melatih model TensorFlow di Cloud TPU. Jika Anda memecahkan masalah pelatihan PyTorch atau JAX, Anda dapat melihat dokumen pemecahan masalah untuk framework tersebut:

Untuk panduan umum lainnya tentang cara menggunakan Cloud TPU, lihat:

Ringkasan

Masalah umum yang dialami dengan Cloud TPU termasuk dalam kategori berikut:

  1. Masalah saat menghubungkan ke TPU

  2. Melakukan proses debug pada error umum

  3. Mengurangi penggunaan memori

  4. Meningkatkan kecepatan pelatihan

  5. Men-debug penurunan akurasi model

Masalah saat menghubungkan ke server TPU

Bagian ini menjelaskan cara memecahkan masalah situasi saat TensorFlow berhenti merespons atau mencetak error saat terhubung ke TPU. Langkah kompilasi grafik TPU dapat memerlukan waktu lama untuk model besar, jadi biarkan skrip dieksekusi setidaknya selama 5 menit sebelum menyimpulkan bahwa skrip telah berhenti merespons.

Langkah pertama adalah memverifikasi apakah masalahnya ada pada server itu sendiri, atau pada pipeline pelatihan TensorFlow Anda. Untuk melakukannya, jalankan tutorial MNIST menggunakan URL server TPU Anda dan pastikan tutorial tersebut berfungsi dengan benar. Jika masih ada masalah koneksi dengan tutorial MNIST, ini mengonfirmasi bahwa masalahnya terletak pada server TPU. Dalam kasus ini:

  1. Jalankan perintah berikut untuk menampilkan TPU yang tersedia. Mengganti zone dan project-id dengan zona dan project ID Anda.

    (vm)$ gcloud compute tpus tpu-vm list --zone zone --project project-id

    Tindakan ini akan mencetak output seperti: 

    NAME       ZONE           ACCELERATOR_TYPE  NETWORK_ENDPOINT   NETWORK  RANGE          STATUS
demo-tpu   us-central1-b  v2-8              10.240.1.2:8470    default  10.240.1.0  READY

  2. Pastikan Anda meneruskan nilai yang benar ke --tpu (demo-tpu dalam contoh sebelumnya), dan bahwa TPU ini tercantum sebagai READY.

  3. Jika TPU Anda tidak tercantum sebagai READY atau Anda masih mengalami masalah saat terhubung, mulai ulang server secara manual dengan:

    (vm)$ gcloud compute tpus tpu-vm stop $TPU_SERVER_NAME && gcloud compute tpus tpu-vm start $TPU_SERVER_NAME

    Dalam contoh sebelumnya, $TPU_SERVER_NAME adalah demo-tpu. Mungkin perlu waktu beberapa menit untuk menyelesaikan prosesnya.

  4. Jalankan kembali perintah ... tpus list dan tunggu hingga TPU berada dalam status READY. Proses ini mungkin perlu waktu beberapa menit.

  5. Coba jalankan tutorial MNIST lagi.

  6. Jika Anda masih mengalami masalah saat menjalankan tutorial MNIST, minta bantuan menggunakan salah satu mekanisme yang dijelaskan dalam Mendapatkan Dukungan.

Jika contoh MNIST berjalan dengan benar, tetapi model Anda masih berhenti merespons, masalahnya mungkin ada pada pipeline pelatihan Anda. Untuk men-debug ini, mulailah dengan mengganti TPUStrategy dalam kode Anda dengan strategi default. Saat Anda menggunakan strategi default, di mana pun Anda menggunakan strategy.scope() atau strategy.run(), model akan berjalan di CPU (atau GPU jika ada), bukan di TPU. Jika model berjalan di CPU, bukan TPU, pasti ada masalah khusus TPU. Jika masih tidak berjalan, praktik terbaiknya adalah men-debug masalah di CPU.

Koneksi ssh terputus selama pelatihan

Koneksi ssh Anda ke Cloud TPU mungkin habis waktunya selama pelatihan yang berjalan lama (terutama jika Anda menggunakan Cloud Shell). Pada saat itu, tidak ada output ke konsol TPU dan mungkin terlihat seolah-olah TPU telah berhenti melakukan pelatihan. Untuk menghindari hal ini, jalankan sesi pelatihan dengan multiplexer terminal atau alat pengelolaan sesi seperti tmux atau screen. Tindakan ini akan membuat koneksi ssh tetap aktif, berapa pun durasi pelatihannya.

Men-debug error umum

Bagian ini menjelaskan cara memecahkan masalah error umum yang mungkin Anda alami saat melatih model di Cloud TPU.

Tidak dapat membuat TPU

Saat membuat Cloud TPU, Anda mungkin melihat error berikut:

googleapiclient.errors.HttpError: < HttpError 403 when requesting https://content-tpu.googleapis.com/v1/projects/{PROJECT}/locations/{ZONE}/nodes/{TPU_NAME}?alt=json returned "Request had insufficient authentication scopes."

Ini adalah masalah izin dan dapat diatasi dengan menjalankan perintah berikut:

gcloud auth login --update-adc

Perintah ini akan memperbarui Kredensial Default Aplikasi (ADC) dan akan menyelesaikan masalah. Untuk mengetahui informasi selengkapnya, lihat gcloud auth login.

Bentuk dinamis tidak didukung

Pesan Error

ValueError: shape [Shape] must have a fixed size for dimension
d that is known at graph construction time.

Framework dan Konfigurasi yang Terpengaruh

Pesan ini hanya terjadi selama kompilasi XLA dengan TensorFlow.

Detail

Untuk menjalankan model di TPU, Cloud TPU mengompilasi model menggunakan compiler XLA. Meskipun langkah kompilasi ini secara signifikan meningkatkan kecepatan pelatihan dan penggunaan memori, bentuk (ukuran dimensi) semua tensor dalam grafik harus diketahui pada waktu kompilasi grafik. Jika bentuk apa pun tidak dapat ditentukan pada waktu kompilasi, kompilasi TPU akan gagal dengan error seperti yang ditampilkan sebelumnya.

Salah satu operasi umum yang menampilkan bentuk dinamis adalah dataset.batch(batch_size), karena jumlah sampel yang tersisa dalam streaming mungkin kurang dari ukuran batch. Oleh karena itu, saat melakukan pelatihan di TPU, tetapkan drop remainder=True untuk dataset.batch. Tindakan ini berpotensi menghapus beberapa sampel terakhir dari file untuk memastikan bahwa setiap batch memiliki bentuk batch_size yang statis. Contoh:

dataset = tf.data.Dataset.range(8)
dataset = dataset.batch(3, drop_remainder=True)

Operasi TensorFlow tidak tersedia

Pesan Error

NotFoundError: No registered 'OpName' OpKernel for XLA_TPU_JIT
devices compatible with node

Framework dan Konfigurasi yang Terpengaruh

Pesan ini dapat muncul saat melakukan pelatihan dengan TensorFlow.

Detail

Model menggunakan operasi TensorFlow yang tidak tersedia di TPU.

Untuk daftar operasi yang tersedia di TPU, beserta rencana dukungan di masa mendatang dan saran untuk solusi, lihat panduan untuk Ops TensorFlow yang tersedia.

Pesan error kehabisan memori

Pesan Error

ResourceExhaustedError: Ran out of memory in memory space hbm; used:
YYY; limit: 7.48G.

Framework dan Konfigurasi yang Terpengaruh

Pesan ini dapat muncul saat melakukan pelatihan dengan TensorFlow, PyTorch, atau JAX.

Detail

Setiap Cloud TPU terdiri dari delapan core TPU, TPU v2 memiliki RAM sebesar 8 GB, dan TPU v3 memiliki RAM sebesar 16 GB (atau HBM, High-Bandwidth Memory). Memori ini digunakan untuk menyimpan tensor (variabel) bobot, serta tensor hasil perantara yang diperlukan untuk komputasi gradien. Jika model terlalu besar untuk dimuat ke dalam RAM TPU, inisialisasi akan gagal dan pesan error akan dicetak. Lihat bagian tentang mengurangi penggunaan memori untuk mendapatkan bantuan lebih lanjut.

Tips untuk mengurangi penggunaan memori:

Masalah saat menghentikan eksekusi

Jika TensorFlow mengalami error selama eksekusi TPU, skrip terkadang tampaknya berhenti merespons, bukan keluar ke shell. Jika hal ini terjadi, tekan CTRL+C di keyboard untuk memicu SIGQUIT, yang menyebabkan Python segera keluar.

Demikian pula, menekan CTRL+C selama eksekusi TPU tidak langsung menonaktifkan TensorFlow, tetapi menunggu hingga akhir loop iterasi saat ini untuk keluar dengan bersih.

Jika Anda mengalami error baru saat terhubung kembali ke TPU setelah keluar dengan cara ini, reset server TPU secara manual dengan perintah: 

gcloud compute tpus tpu-vm stop tpu-name --zone=zone
gcloud compute tpus tpu-vm start tpu-name --zone=zone

dengan tpu-name diambil dari kolom pertama yang ditampilkan oleh perintah gcloud compute tpus tpu-vm list dan zone adalah zona yang ditampilkan di kolom kedua.

Padding tensor yang berlebihan

Kemungkinan Penyebab Masalah Memori

Tensor di memori TPU ditambahkan padding, yaitu, TPU membulatkan ukuran tensor yang disimpan dalam memori untuk melakukan komputasi secara lebih efisien. Padding ini terjadi secara transparan di tingkat hardware dan tidak memengaruhi hasil. Namun, dalam kasus tertentu, padding dapat menyebabkan peningkatan penggunaan memori dan waktu eksekusi secara signifikan.

Cara Mengurangi Penggunaan Memori

Software TPU mencoba menata tensor dalam memori untuk memaksimalkan efisiensi komputasi dan meminimalkan padding. Proses tata letak memori ini rumit, tetapi untuk hasil terbaik, model harus mematuhi aturan praktis berikut. Untuk meminimalkan overhead memori dan memaksimalkan efisiensi komputasi, salah satu hal berikut harus terpenuhi:

  • Total ukuran batch harus kelipatan 64 (8 per core TPU), dan dimensi fitur harus kelipatan 128,

    atau

  • Total ukuran batch harus kelipatan 1024 (128 per core TPU), dan dimensi fitur harus kelipatan 8.

Menggunakan ukuran batch 1024 dan dimensi fitur yang merupakan kelipatan dari 128 akan menghasilkan efisiensi terbaik, meskipun hal ini mungkin tidak dapat dilakukan untuk semua model. Untuk memperjelas, "dimensi fitur" mengacu pada ukuran tersembunyi lapisan sepenuhnya terkoneksi atau jumlah saluran output dalam konvolusi. Tidak semua lapisan dapat mematuhi aturan ini, terutama lapisan pertama dan terakhir jaringan. Hal ini tidak masalah, dan diperkirakan sebagian besar model memerlukan sejumlah padding.

Mengurangi penggunaan memori

Jika mengalami error kehabisan memori saat menjalankan model di TPU, Anda harus melakukan langkah-langkah untuk mengurangi penggunaan memori model.

Cara paling efektif untuk mengurangi penggunaan memori adalah dengan:

  • Mengurangi padding tensor yang berlebihan
  • Mengurangi ukuran batch

Ukuran batch atau model terlalu besar

Kemungkinan Penyebab Masalah Memori

Saat melatih jaringan saraf di CPU, GPU, atau TPU, penggunaan memori berasal dari dua tempat:

  1. Penggunaan memori sebanding dengan jumlah bobot dalam model.
  2. Menyimpan aktivasi perantara dari penerusan maju yang diperlukan untuk menghitung penerusan mundur. Penggunaan memori secara langsung sebanding dengan ukuran batch, ukuran lapisan, dan jumlah lapisan.

Oleh karena itu, memori yang diperlukan oleh model sebagian besar bergantung pada ukuran batch.

Memori yang diperlukan oleh model bergantung pada jumlah lapisan dalam jaringan.

Runtime TPU mencoba mengoptimalkan operator agar cocok dengan model dalam memori (disebut rematerialisasi, mirip dengan checkpoint gradien), tetapi tidak selalu dapat melakukannya.

Cara Mengurangi Penggunaan Memori

Kurangi ukuran batch secara perlahan hingga sesuai dengan memori, pastikan total ukuran batch adalah kelipatan 64 (ukuran batch per core harus merupakan kelipatan 8). Perlu diingat bahwa ukuran batch yang lebih besar lebih efisien di TPU. Total ukuran batch 1024 (128 per core) umumnya merupakan titik awal yang baik.

Jika model tidak dapat dijalankan di TPU meskipun dengan ukuran batch kecil (misalnya, 64), coba kurangi jumlah lapisan atau ukuran lapisan.

Meningkatkan kecepatan pelatihan

Jika model Anda berhasil berjalan di TPU, tetapi kecepatan pelatihannya kurang dari yang diharapkan, bagian ini menguraikan beberapa kemungkinan cara untuk meningkatkan kecepatan. Lihat Panduan performa untuk saran lain tentang cara meningkatkan performa pelatihan.

Terlalu sedikit langkah per eksekusi per loop pelatihan

Deskripsi Masalah Performa

Meneruskan argumen steps_per_execution ke Model.compile akan mengontrol jumlah langkah pelatihan yang dijalankan di antara callback host. Setiap callback host memerlukan komunikasi yang signifikan antara CPU host server TPU dan perangkat TPU, sehingga jika steps_per_execution terlalu kecil, hal ini dapat memperlambat pelatihan.

Cara Mengetahui Apakah Model Anda Terpengaruh

Jika profil TPU mengungkapkan callback CPU host yang sering terjadi di antara langkah perangkat TPU, pelatihan Anda dapat memanfaatkan nilai steps_per_execution yang lebih besar.

Cara Mitigasi

Tetapkan steps_per_execution ke nilai yang lebih besar. Perhatikan bahwa steps_per_execution dapat ditetapkan ke nilai besar, tetapi perlu diingat bahwa logging pesan dan menyimpan titik pemeriksaan hanya dapat dilakukan setelah jumlah langkah yang ditentukan telah dijalankan.

Bottleneck pemrosesan input

Deskripsi Masalah Performa

Saat TPU dilatih pada bagian data tertentu, fungsi pemrosesan input akan menyiapkan bagian data berikutnya di CPU. Jika fungsi input Anda memerlukan waktu lebih lama daripada fungsi model, TPU akan dibiarkan tidak ada aktivitas saat fungsi input mengambil data.

Cara Mengetahui Apakah Model Anda Terpengaruh

Ikuti petunjuk di Alat Cloud TPU: Input Pipeline Analyzer untuk melihat analisis pipeline input di TensorBoard:

gambar

Halaman analisis pipeline input menampilkan ringkasan yang jelas yang menunjukkan apakah model Anda mengalami bottleneck oleh pemrosesan input. Halaman yang sama juga menampilkan waktu eksekusi per operasi, yang memungkinkan Anda menentukan operasi yang bermasalah.

Cara Mitigasi

Ada beberapa kemungkinan mitigasi saat memuat data dengan Dataset API:

  1. Simpan data Anda sebagai kumpulan struktur tf.train.Example dalam file TFRecord, dan muat dengan TFRecordDataset. Lihat tutorial Dataset API atau tutorial ResNet untuk mengetahui contohnya.
  2. Gunakan dataset.cache() atau dataset.prefetch() untuk melakukan buffering data input. Hal ini mencegah pelambatan sporadis dalam akses file sehingga tidak menimbulkan bottleneck.
  3. Tentukan parameter num_parallel_calls dari fungsi dataset.map() untuk mengaktifkan operasi map() multi-thread. Heuristik untuk nilai num_parallel_calls adalah menggunakan jumlah core CPU yang tersedia.
  4. Lakukan prapemrosesan data yang mahal secara offline sebagai biaya satu kali, bukan menanggung biaya melalui setiap epoch dari setiap pelatihan.

Semua pemrosesan input dilakukan pada CPU yang berada di server TPU, bukan di komputer lokal, sehingga kecepatan komputer lokal tidak menjadi faktor.

Waktu langkah lambat dan penggunaan MXU rendah

Deskripsi Masalah Performa

Cloud TPU dapat melakukan perkalian dan konvolusi matriks dengan kecepatan yang sangat tinggi. Sebagian besar operasi TensorFlow lainnya memiliki implementasi yang efisien di TPU, tetapi ini bukan kekuatan utama TPU dibandingkan dengan hardware lainnya. Oleh karena itu, model harus didominasi oleh perkalian matriks atau konvolusi untuk memanfaatkan TPU sepenuhnya.

Cara Mengetahui Apakah Model Anda Terpengaruh

Gejala yang akan Anda lihat dalam kasus ini adalah waktu langkah lambat yang disertai dengan penggunaan MXU rendah yang ditampilkan saat Anda membuat profil performa.

Cara Mitigasi

Coba kurangi jumlah operasi yang bukan perkalian matriks. Setelah mengurangi jumlah perkalian matriks, lakukan benchmark ulang untuk melihat apakah performanya dapat diterima di TPU.

Padding tensor yang berlebihan

Deskripsi Masalah Performa

TPU menambahkan padding pada tensor dalam memori sehingga TPU dapat menggunakan unit komputasinya secara efisien. Padding dapat meningkatkan penggunaan memori dan bandwidth memori. Lihat bagian tentang padding tensor untuk mendapatkan bantuan dalam memahami dan memperbaiki masalah padding tensor.

Throughput lambat dan penggunaan memori rendah

Deskripsi Masalah Performa

Sebagai aturan umum, menggunakan ukuran batch yang lebih besar akan menghasilkan kecepatan pelatihan yang lebih tinggi di TPU, dalam hal sampel/detik.

Cara Mengetahui Apakah Model Anda Terpengaruh

Ukuran batch model apa pun harus selalu minimal 64 (8 per core TPU), karena TPU selalu menambahkan padding ke tensor hingga ukuran ini. Ukuran batch yang ideal saat melatih di TPU adalah 1024 (128 per core TPU), karena hal ini menghilangkan inefisiensi yang terkait dengan transfer memori dan padding.

Cara Mitigasi

Praktik terbaiknya adalah menggunakan ukuran batch terbesar yang sesuai dengan memori dan merupakan kelipatan 64. Cara termudah untuk mencapainya adalah memulai dengan 1024, dan jika hal ini menyebabkan error kehabisan memori, coba kurangi ukuran batch hingga model berhasil berjalan. Mengubah ukuran batch model mungkin memerlukan penyesuaian hyperparameter lain untuk mencapai akurasi model yang sama, seperti kecepatan pembelajaran, tetapi hal ini harus dievaluasi berdasarkan kasus per kasus.

Ukuran lapisan terlalu kecil

Deskripsi Masalah Performa

Meskipun model didominasi oleh perkalian matriks atau konvolusi, TPU mungkin tidak berjalan dengan efisiensi penuh jika tensor inputnya kecil. Jika dibandingkan dengan hardware lain, TPU berjalan paling efisien jika ukuran batch dan ukuran lapisan besar (misalnya, dimensi >= 512).

Cara Mengetahui Apakah Model Anda Terpengaruh

Sebagai aturan umum, ukuran lapisan yang lebih kecil dari 128 akan menghasilkan efisiensi yang buruk di TPU, karena 128 adalah dimensi bawaan dari unit perkalian matriks TPU. Untuk lapisan yang terhubung sepenuhnya, ukuran tersembunyi minimum 512 direkomendasikan untuk mencapai efisiensi tinggi. Perhatikan bahwa lapisan konvolusi biasanya tidak perlu sebesar lapisan terhubung sepenuhnya untuk mencapai tingkat efisiensi yang sama.

Cara Mitigasi

Jika motivasi utama untuk ukuran lapisan kecil dalam model Anda adalah kecepatan pelatihan, lakukan benchmark ulang model Anda dengan lapisan yang lebih besar di TPU. Misalnya, meningkatkan ukuran output lapisan dari 256 menjadi 512 mungkin hanya meningkatkan waktu pelatihan sebesar 20% meskipun model melakukan komputasi 2x lipat.

Pembuatan profil model tingkat operasi

Sering kali berguna untuk mengukur waktu eksekusi tingkat operasi dan penggunaan memori untuk mengidentifikasi bottleneck performa. Untuk mengetahui petunjuk cara melakukannya,
lihat panduan Alat Cloud TPU: Trace Viewer.

Men-debug penurunan akurasi model

Salah satu sasaran ekosistem Cloud TPU adalah setiap model yang dilatih di CPU atau GPU akan mencapai akurasi yang sangat mirip saat dilatih di TPU, dengan mungkin penyesuaian kecil pada hyperparameter seperti ukuran batch dan kecepatan belajar. Namun, terkadang pengguna dapat mengamati menurunnya akurasi saat melatih model di TPU. Proses debug masalah tersebut dapat sangat menjengkelkan karena sifat pelatihan jaringan neural yang acak. Bagian ini memberikan panduan tentang cara menentukan akar masalah menurunnya akurasi model saat melakukan port model ke TPU.

Memahami sharding data (paralelisme data)

Salah satu sasaran utama TensorFlow adalah setiap operasi harus menghasilkan hasil yang hampir identik, baik dijalankan di CPU, GPU, maupun TPU. Ada pengecualian tertentu untuk hal ini, seperti operasi acak. Secara umum, jika Anda menemukan perbedaan yang signifikan antara output operasi non-acak di TPU dan CPU, laporkan sebagai bug.

Namun, untuk pipeline pelatihan secara keseluruhan, ada perbedaan signifikan antara pelatihan di CPU/GPU dan TPU. Saat melakukan pelatihan di TPU, TensorFlow melakukan sharding data, Setiap Cloud TPU berisi 8 core TPU yang beroperasi sebagai unit pemrosesan independen. Untuk setiap langkah dalam pelatihan, setiap core TPU menerima batch data, menghitung gradien bobot, menukar gradien dengan core TPU lainnya, lalu menghitung pembaruan bobot. Secara default, kerugian dirata-ratakan di seluruh core, tetapi dapat dijumlahkan dengan mengubah parameter CrossShardOptimizer.

Jika total kerugian model dapat dihitung sebagai rata-rata (atau jumlah) kerugian per sampel independen, prosedur ini secara matematis setara dengan pelatihan pada satu batch besar.

Operasi paling umum yang tidak independen per sampel adalah normalisasi batch, yang berjalan di setiap batch per core secara terpisah. Misalnya, jika total ukuran batch adalah 128, ukuran batch per core adalah 16, dan setiap 8 core melakukan normalisasi batch pada 16 sampelnya sendiri. Dalam beberapa kasus, melakukan normalisasi batch pada batch kecil (misalnya, kurang dari 32) telah ditemukan mengurangi akurasi. Dalam skenario ideal, total ukuran batch harus besar (misalnya, 256 hingga 1024). Jika ukuran batch terlalu besar untuk dimuat dalam memori, efek sharding harus dievaluasi berdasarkan kasus per kasus.

Pelatihan deterministik

Salah satu alasan sulitnya men-debug perbedaan akurasi model adalah di berbagai framework (TensorFlow, PyTorch, JAX), software pelatihan menggunakan inisialisasi bobot dan pengacakan data yang berbeda setiap kali model dilatih. Sebaiknya ubah prosedur pelatihan menjadi deterministik, sehingga beberapa operasi menghasilkan model yang hampir identik. Bagian ini menunjukkan cara menjalankan tutorial MNIST secara deterministik:

  1. Buat file checkpoint awal dengan menjalankan satu langkah di CPU. Langkah ini digunakan untuk mencapai inisialisasi bobot deterministik. Selain itu, pastikan Anda menggunakan seed acak tetap untuk fungsi acak apa pun dalam model. 
# Run training for 1 step to create an initial checkpoint.
python mnist_tpu.py \
  --use_tpu=False \
  --data_dir=${STORAGE_BUCKET}/data/ \
  --model_dir=${STORAGE_BUCKET}/init_output \
  --random_seed=12345 \
  --iterations=1
  --train_steps=1
  1. Ubah fungsi pengacakan data dalam fungsi input Anda untuk menggunakan seed acak. Hal ini telah dilakukan dalam tutorial MNIST. Hal ini berfungsi untuk operasi pemrosesan data input karena selalu berjalan di CPU. Operasi acak dalam fungsi model mungkin tidak deterministik antara TPU dan CPU. Setiap kali Anda memanggil operasi acak, teruskan seed tetap untuk memastikan hasil yang sama di antara operasi. Contoh: 
# In the flag definitions
tf.flags.DEFINE_integer("batch_size", None, "Random seed for training")

# In the input_fn
if FLAGS.random_seed is not None:
dataset = dataset.shuffle(seed=FLAGS.random_seed)
  1. Jalankan model yang sama dua kali di CPU untuk memverifikasi bahwa pelatihan bersifat deterministik. Perhatikan bahwa pelatihan harus dijalankan untuk jumlah langkah yang wajar (misalnya, 1.000), tetapi tidak perlu dijalankan hingga konvergensi.

    Karena pelatihan CPU dibandingkan dengan pelatihan TPU satu core, gunakan ukuran batch yang dapat muat di satu core TPU (biasanya, ukuran batch penuh dibagi 8). TensorFlow tidak menjamin determinisme bit demi bit di antara eksekusi, tetapi kerugiannya harus sangat dekat:

Menyalin bobot awal

gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_1/ --continue-on-error
gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/cpu_output_2/ --continue-on-error

Putaran 1

python mnist_tpu.py \
  --use_tpu=False \
  --data_dir=${STORAGE_BUCKET}/data/ \
  --model_dir=${STORAGE_BUCKET}/cpu_output_1 \
  --batch_size=128 \
  --random_seed=12345 \
  --train_steps=2000 \
  --eval_steps=10

Output 1

accuracy = 0.9910644, global_step = 1000, loss = 0.025323588

Run 2

python mnist_tpu.py \
  --use_tpu=False \
  --data_dir=${STORAGE_BUCKET}/data/ \
  --model_dir=${STORAGE_BUCKET}/cpu_output_1 \
  --batch_size=128 \
  --random_seed=12345 \
  --train_steps=2000 \
  --eval_steps=10

Output 2

accuracy = 0.9910644, global_step = 1000, loss = 0.025323414

Pelatihan TPU satu core

Setelah Anda dapat menjalankan tutorial MNIST secara deterministik, langkah berikutnya adalah mereplikasi hasil yang dilatih CPU di TPU, menggunakan satu core TPU untuk menentukan apakah masalahnya terkait dengan sharding data atau mesin eksekusi TPU itu sendiri.

Berikut cara menjalankan pelatihan dan evaluasi single-core di tutorial MNIST:

Menggunakan inisialisasi bobot yang sama dengan CPU

gcloud storage cp ${STORAGE_BUCKET}/init_output/* ${STORAGE_BUCKET}/tpu_output --continue-on-error

Menjalankan pelatihan selama 1.000 langkah

python mnist.py \
    --use_tpu=True \
    --master=$GRPC_SERVER \
    --train_file=${STORAGE_BUCKET}/data/train.tfrecords \
    --model_dir=${STORAGE_BUCKET}/tpu_output \
    --random_seed=12345 \
    --num_shards=1 \
    --batch_size=128 \
    --train_steps=1000 \
    --eval_steps=10

Output

  accuracy = 0.9910644, global_step = 1000, loss = 0.02514153

Kerugian tidak akan sama persis dengan model yang dilatih CPU, tetapi harus mendekati. Jika tidak mendekati untuk model Anda, hal ini mungkin menunjukkan bahwa Anda telah menemukan bug di mesin eksekusi TPU. Sebelum mengirim laporan bug, periksa kembali hal-hal berikut:

  1. Anda meneruskan num_shards=1 ke TPUConfig.

  2. Anda tidak memiliki operasi acak dalam fungsi model, dan setiap operasi acak dalam fungsi input Anda di-seed dengan benar.

  3. Anda menggunakan file checkpoint awal yang sama untuk pelatihan CPU dan TPU.

Men-debug pelatihan TPU multi-core

Jika model Anda memang mencapai kerugian yang sama pada CPU dan TPU single-core, masalahnya kemungkinan salah satu dari berikut ini:

(a) Degradasi terjadi karena varian acak alami saat melatih model neural dengan inisialisasi yang berbeda.

(b) Degradasi terjadi karena masalah yang terkait dengan sharding data di TPU.

Untuk menentukan apakah (a) adalah masalahnya, latih ulang model lengkap di CPU/GPU dan TPU multi-core menggunakan inisialisasi bobot yang sama.

Jika Anda yakin bahwa penurunan akurasi signifikan secara statistik, masalah yang paling mungkin terkait dengan sharding data adalah:

  1. Jika model Anda menggunakan normalisasi batch, total ukuran batch kurang dari 256 (misalnya, kurang dari 32 per core) dapat mengurangi akurasi.
  2. Fungsi loss per batch dipengaruhi oleh sharding. Fungsi loss tersebut biasanya cukup khusus. Misalnya, Karras et al. 2017 menggunakan diskriminator batch saat melatih jaringan adversarial generatif.

Pemecahan masalah penyiapan gcloud

Masalah
gcloud components update menampilkan pesan error berikut:
ERROR: (gcloud.components.update)
You cannot perform this action because the Cloud SDK component manager is
disabled for this installation.
Solusi
Untuk menggunakan gcloud, Anda perlu menggunakan penginstalan gcloud yang tidak dikelola melalui pengelola paket. Ikuti langkah-langkah berikut untuk menginstal gcloud dari kode sumber:
  sudo apt-get remove google-cloud-sdk
  curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-311.0.0-linux-x86_64.tar.gz
  tar -xzf google-cloud-sdk-311.0.0-linux-x86_64.tar.gz
  ./google-cloud-sdk/install.sh
  source ~/.bashrc
Masalah

Perintah gcloud compute tpus tpu-vm ssh ${TPU_NAME} --zone ${ZONE} menampilkan pesan error berikut:

Waiting for SSH key to propagate.
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ssh: connect to host 34.91.136.59 port 22: Connection timed out
ERROR: (gcloud.compute.tpus.tpu-vm.ssh) Could not SSH into the instance.  It is possible that your SSH key has not propagated to the instance yet. Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.
Solusi

Mungkin ada yang salah dengan penerapan kunci SSH. Coba pindahkan kunci yang dibuat secara otomatis ke lokasi cadangan untuk memaksa gcloud membuat ulang kunci tersebut:

mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine
mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub

Log debug

Framework Cloud TPU yang didukung, JAX, PyTorch, dan TensorFlow mengakses TPU menggunakan library bersama yang disebut libtpu yang ada di setiap VM TPU. Library ini mencakup compiler XLA yang digunakan untuk mengompilasi program TPU, runtime TPU yang digunakan untuk menjalankan program yang dikompilasi, dan driver TPU yang digunakan oleh runtime untuk akses tingkat rendah ke TPU.

Library libtpu mencatat informasi yang dapat berguna untuk proses debug. Secara default, log ini ditulis ke /tmp/tpu_logs di setiap VM Cloud TPU. Variabel lingkungan berikut dapat ditetapkan sebelum Anda memulai pelatihan untuk mengubah perilaku logging:

TPU_LOG_DIR: direktori tempat log ditulis
Lokasi direktori ditetapkan secara default ke /tmp/tpu_logs. Direktori akan dibuat jika belum ada, tetapi tidak ada direktori induk yang dibuat. Jika terjadi error saat menemukan atau membuat direktori yang ditentukan, pesan akan dicetak ke stderr, tetapi tidak akan menghentikan program dan logging dinonaktifkan. Tetapkan nama direktori ke "dinonaktifkan" untuk menonaktifkan logging ke disk sepenuhnya.
TPU_MIN_LOG_LEVEL: tingkat keparahan minimum yang akan dicatat ke disk
Pilihannya adalah 0 (INFO), 1 (WARNING), 2 (ERROR), dan 3 (FATAL). Defaultnya adalah 0.
TPU_STDERR_LOG_LEVEL: tingkat keparahan minimum yang akan dicatat ke stderr, selain disk, jika berlaku
Pilihannya sama dengan TPU_MIN_LOG_LEVEL. Nilai defaultnya adalah 3.
TPU_MAX_LOG_SIZE_MB: ukuran maksimum dalam megabyte dari setiap file log
File log baru akan otomatis dimulai saat file log sebelumnya mencapai ukuran ini. Setelan defaultnya adalah 1024.