Google’s Tunix system mengangkat titik hambat yang selama ini menghalangi reinforcement learning (RL) berbasis agen skala besar untuk menggunakan TPU secara efisien. Dengan memisahkan pekerjaan pembuatan data interaksi dari pekerjaan pembaruan kebijakan, Tunix mendorong utilisasi TPU dari persentase satu digit hingga mendekati kapasitas penuh, sehingga memangkas pemborosan komputasi secara drastis.

Bottleneck dalam agentic RL

Agentic RL berbeda dari pelatihan model bahasa "next-token" yang lebih umum. Sebuah agen harus mengirim panggilan API, mengeksekusi kode, atau melangkah melalui lingkungan simulasi, lalu bereaksi terhadap hasilnya. Oleh karena itu, loop pelatihan bersifat sinkron: model menghasilkan tindakan, lingkungan berjalan, hasil dikembalikan, dan baru setelah itu model menerima pembaruan gradien. Ketika satu langkah lingkungan memakan waktu beberapa detik, perangkat keras TPU yang mahal akan menganggur, dan utilisasi yang dilaporkan dapat turun di bawah 10%. Ketidakefisienan ini berdampak langsung pada tagihan cloud yang lebih tinggi dan siklus penelitian yang lebih lambat.

Arsitektur terpisah Tunix

Tunix mengatasi masalah ini dengan memisahkan dua tahap—pembuatan trajektori dan optimasi kebijakan—ke dalam kumpulan perangkat keras yang terpisah.

  • Aktor asinkron berjalan pada CPU atau GPU yang murah. Setiap aktor terus berinteraksi dengan lingkungan yang ditugaskan, mencatat tindakan dan observasi, serta mengalirkan trajektori yang dihasilkan ke dalam penyimpanan bersama.
  • Pembelajar kontinu menempati TPU Pod khusus. Pembelajar mengambil batch dari buffer pusat dan melakukan pembaruan gradien tanpa menunggu satu aktor pun menyelesaikan rollout.
  • Buffer throughput tinggi berada di tengah, bertindak sebagai area penampungan untuk trajektori. Karena pembelajar dapat membaca secepat buffer menyediakan data, TPU tidak pernah terhenti.

Efek bersihnya adalah pipeline pelatihan di mana TPU tetap sibuk hampir sepanjang waktu, mendorong utilisasi menuju 100%.

Hambatan teknis dan cara Tunix mengatasinya

Episode dengan panjang variabel dan rekompilasi XLA

Kompiler XLA pada JAX mengoptimalkan bentuk tensor tetap. Namun, tugas-tugas berbasis agen menghasilkan urutan dengan panjang yang berbeda, yang biasanya akan memicu rekompilasi yang mahal. Tunix mengemas urutan yang lebih pendek bersama-sama dan mengelompokkan episode dengan panjang serupa ke dalam bucket, menjaga bentuk tetap stabil cukup lama agar XLA dapat menggunakan kembali kernel yang telah dikompilasi. Hasilnya adalah throughput yang stabil tanpa overhead kompiler yang dapat melumpuhkan performa.

Menskalakan model masif di banyak chip TPU

Melatih agen dengan lebih dari 70 miliar parameter memerlukan penyebaran bobot dan data ke beberapa node TPU. Tunix menggunakan primitif ShardMap dari JAX untuk melakukan sharding pada parameter model dan aktivasi, memungkinkan pembelajar untuk menyimpan seluruh model di memori sambil tetap menyuapinya dengan data berkecepatan tinggi. Strategi sharding ini memungkinkan pelatihan model yang sebelumnya tidak terjangkau oleh satu TPU pod.

Gradien usang (stale) dari pipeline yang terpisah

Ketika aktor berjalan lebih cepat daripada pembelajar, data yang mereka sediakan dapat menjadi "usang" (stale) relatif terhadap kebijakan saat ini. Tunix memitigasi pergeseran ini dengan dua mekanisme: pembobotan ulang importance-sampling untuk mencerminkan relevansi sampel lama, dan ambang batas keusangan yang dapat dikonfigurasi untuk membuang trajektori yang melebihi usia yang telah ditentukan. Keduanya menjaga pembelajaran tetap stabil bahkan saat pipeline berjalan secara asinkron.

Hal yang perlu diperhatikan oleh pengguna

  • Audit latensi – Manfaat dari pemisahan ini bergantung pada waktu respons lingkungan. Tim harus mengukur latensi end-to-end dan memastikan bahwa pool aktor berukuran cukup untuk menjaga buffer tetap terisi penuh.
  • Desain pool pekerja – CPU atau GPU murah dapat menampung banyak aktor, tetapi penggunaan berlebih (oversubscribing) dapat menyebabkan kontensi pada jaringan atau penyimpanan. Pool yang seimbang yang sesuai dengan laju input buffer sangatlah penting.
  • Ketahanan buffer – Penyimpanan pusat harus menangani laju tulis dan baca yang tinggi tanpa menjadi titik hambat baru. Memilih sistem penyimpanan dengan tail latency rendah dan bandwidth yang cukup adalah bagian yang tidak bisa ditawar dari arsitektur ini.

Potensi kekurangan

Arsitektur yang terpisah memperkenalkan lebih banyak komponen yang kompleks: armada perangkat keras yang terpisah, buffer yang persisten, dan logika koordinasi untuk menegakkan batas keusangan.

Kesimpulan

Tunix menunjukkan bahwa biaya dominan dalam agentic RL bukanlah model itu sendiri, melainkan waktu menganggur yang disebabkan oleh loop interaksi sinkron. Dengan mengalihkan pekerjaan rollout ke perangkat keras murah dan menyuapi TPU pod yang belajar secara kontinu dari buffer throughput tinggi, Google telah mengubah masalah utilisasi di bawah 10% menjadi alur kerja dengan kapasitas hampir penuh.