Sistem Tunix Google menghapuskan titik sumbat yang menghalang pembelajaran pengukuhan (RL) ejen berskala besar daripada menggunakan TPU secara cekap. Dengan memisahkan kerja menjana data interaksi daripada kerja mengemas kini polisi, Tunix memacu penggunaan TPU daripada peratusan angka tunggal kepada hampir kapasiti penuh, sekali gus mengurangkan pembaziran pengkomputeran secara drastik.

Titik sumbat dalam RL ejen

RL ejen berbeza daripada latihan model bahasa "token seterusnya" yang lebih biasa. Seorang ejen mesti menghantar panggilan API, melaksanakan kod, atau melalui persekitaran simulasi, kemudian bertindak balas terhadap hasilnya. Oleh itu, gelung latihan adalah segerak (synchronous): model menghasilkan tindakan, persekitaran berjalan, hasil dikembalikan, dan hanya selepas itu model menerima kemas kini kecerunan (gradient update). Apabila satu langkah persekitaran mengambil masa beberapa saat, perkakasan TPU yang mahal akan terbiar tanpa kerja, dan penggunaan yang dilaporkan boleh jatuh di bawah 10%. Ketidakcekapan ini diterjemahkan secara langsung kepada bil awan yang lebih tinggi dan kitaran penyelidikan yang lebih perlahan.

Seni bina terpisah Tunix

Tunix menangani masalah ini dengan memisahkan dua peringkat—penjanaan trajektori dan pengoptimuman polisi—ke dalam kumpulan perkakasan yang berbeza.

  • Pelakon tidak segerak (Asynchronous actors) berjalan pada CPU atau GPU yang murah. Setiap pelakon berinteraksi secara berterusan dengan persekitaran yang ditetapkan, merekod tindakan dan pemerhatian, serta menyalurkan trajektori yang terhasil ke dalam storan kongsi.
  • Pembelajar berterusan (Continuous learners) menduduki TPU Pod yang dikhaskan. Pembelajar menarik kelompok (batches) daripada penimbal pusat dan melakukan kemas kini kecerunan tanpa menunggu mana-mana pelakon tunggal selesai melakukan rollout.
  • Penimbal daya pemprosesan tinggi (High-throughput buffer) terletak di tengah, bertindak sebagai kawasan persediaan untuk trajektori. Oleh kerana pembelajar boleh membaca sepantas penimbal membekalkan data, TPU tidak pernah terhenti.

Kesan keseluruhannya ialah saluran paip latihan di mana TPU sentiasa sibuk hampir sepanjang masa, memacu penggunaan ke arah 100%.

Cabaran teknikal dan cara Tunix mengatasinya

Episod panjang berubah-ubah dan kompilasi semula XLA

Kompilator XLA JAX mengoptimumkan bentuk tensor tetap. Walau bagaimanapun, tugas ejen menghasilkan urutan dengan panjang yang berbeza, yang biasanya akan mencetuskan kompilasi semula yang mahal. Tunix membungkus urutan yang lebih pendek bersama-sama dan mengelompokkan episod dengan panjang yang serupa ke dalam bakul (buckets), mengekalkan bentuk yang stabil cukup lama untuk XLA menggunakan semula kernel yang telah dikompilasi. Hasilnya ialah daya pemprosesan yang stabil tanpa beban kompilator yang boleh menjejaskan prestasi.

Menskala model besar merentasi banyak cip TPU

Melatih ejen dengan lebih daripada 70 bilion parameter memerlukan penyebaran pemberat (weights) dan data merentasi pelbagai nod TPU. Tunix menggunakan primitif ShardMap JAX untuk membahagikan (shard) kedua-dua parameter model dan pengaktifan (activations), membolehkan pembelajar menyimpan keseluruhan model dalam memori sambil tetap menyuap data kepadanya pada kelajuan tinggi. Strategi pembahagian ini membolehkan latihan model yang sebelum ini tidak dapat dicapai oleh satu TPU pod tunggal.

Kecerunan basi daripada saluran paip terpisah

Apabila pelakon berjalan lebih pantas daripada pembelajar, data yang mereka bekalkan boleh menjadi "basi" (stale) berbanding polisi semasa. Tunix mengurangkan hanyutan ini dengan dua mekanisme: pensampelan kepentingan (importance-sampling) menimbang semula sampel lama untuk mencerminkan kerelevanannya, dan ambang kebasian (staleness threshold) yang boleh dikonfigurasi membuang trajektori yang melebihi usia yang ditetapkan. Bersama-sama, ia mengekalkan kestabilan pembelajaran walaupun saluran paip berjalan secara tidak segerak.

Perkara yang perlu diperhatikan oleh pengguna

  • Audit kependaman (Latency audit) – Manfaat pemisahan bergantung pada masa tindak balas persekitaran. Pasukan harus mengukur kependaman hujung-ke-hujung dan memastikan kumpulan pelakon bersaiz mencukupi untuk memastikan penimbal sentiasa penuh.
  • Reka bentuk kumpulan pekerja (Worker pool design) – CPU atau GPU murah boleh menampung banyak pelakon, tetapi penggunaan berlebihan (oversubscribing) boleh menyebabkan persaingan pada rangkaian atau storan. Kumpulan yang seimbang yang sepadan dengan kadar kemasukan penimbal adalah penting.
  • Keteguhan penimbal (Buffer robustness) – Storan pusat mesti mengendalikan kadar tulis dan baca yang tinggi tanpa menjadi titik sumbat baharu. Memilih sistem storan dengan kependaman ekor (tail latency) yang rendah dan lebar jalur yang mencukupi adalah bahagian yang tidak boleh dirunding dalam seni bina ini.

Keburukan berpotensi

Seni bina terbahagi ini memperkenalkan lebih banyak bahagian yang bergerak: armada perkakasan berasingan, penimbal yang kekal, dan logik penyelarasan untuk menguatkuasakan had kebasian.

Kesimpulan

Tunix menunjukkan bahawa kos utama dalam RL ejen bukanlah model itu sendiri, tetapi masa terbiar yang disebabkan oleh gelung interaksi segerak. Dengan memindahkan kerja rollout ke perkakasan murah dan menyuap TPU pod yang belajar secara berterusan daripada penimbal daya pemprosesan tinggi, Google telah mengubah masalah penggunaan bawah 10% kepada aliran kerja dengan kapasiti hampir penuh.