Saya telah berbicara dengan banyak orang yang mengerjakan RL akhir-akhir ini, dan saya telah melihat sesuatu yang menarik — setiap kali percakapan beralih ke RL Infra, hampir selalu tertarik pada satu topik: penyelarasan pelatih-inferensi. Cara menjaga kebijakan pelatihan dan inferensi tetap konsisten. Cara mengontrol gelar di luar kebijakan. Cara menangani log prob diff setelah memperkenalkan async. Ini semua adalah pertanyaan penting, tidak diragukan lagi. Tetapi saya semakin yakin bahwa RL Infra menderita kesalahan alokasi perhatian yang signifikan. Meminjam pembingkaian dari diskusi baru-baru ini dengan seorang kolega, saya menyebutnya Efek Barel RL Infra. Satu tong hanya menampung air sebanyak tongkat terpendeknya. Throughput dan kebenaran sistem pelatihan RL bekerja dengan cara yang sama — mereka tidak ditentukan oleh modul yang paling Anda optimalkan, tetapi oleh modul yang paling Anda abaikan. Penyelarasan inferensi kereta mungkin merupakan tongkat yang telah Anda ampelas dan poles dengan sempurna. Tetapi jika stabilitas kotak pasir Anda adalah bencana, pipa hadiah Anda terhenti terus-menerus, dan observabilitas end-to-end Anda hampir tidak ada — apa gunanya penyelarasan sempurna? Kapasitas sistem sudah dibatasi oleh setiap mata rantai lemah lainnya. Ini pada dasarnya berbeda dari cara kerja pengoptimalan sistem inferensi. Sebagai mesin inferensi, SGLang memiliki ruang strategi yang sangat besar untuk pengoptimalan, tetapi pipelinenya relatif linier — permintaan proses, prefill, decode. Anda dapat mengisolasi kemacetan modul demi modul, dan kopling antar komponen dapat dikelola. Pelatihan RL adalah binatang buas yang sama sekali berbeda — perulangan multi-sistem yang sangat kompleks: pembuatan peluncuran bergantung pada mesin inferensi, komputasi hadiah mungkin bergantung pada lingkungan eksternal, pembaruan kebijakan bergantung pada kerangka kerja pelatihan, dan putaran peluncuran berikutnya bergantung pada kebijakan yang diperbarui. Jika ada satu tautan yang putus, seluruh loop runtuh. Sayangnya, dari apa yang saya lihat selama setahun terakhir, masih banyak titik lemah yang sangat diremehkan: Keandalan Kotak Pasir Agen. Ini mungkin karya paling kotor, paling melelahkan, dan paling tidak glamor secara akademis di RL Infra saat ini. RL berbasis agen membutuhkan kotak pasir eksekusi yang andal untuk peluncuran — terdengar sederhana, ternyata mimpi buruk. Stabilitas kontainer, latensi start dingin, keandalan isolasi sumber daya, manajemen status kotak pasir — hal-hal ini tampak dipisahkan di atas kertas, tetapi produk kotak pasir yang tersedia di pasaran secara konsisten berkinerja buruk di bawah ekspektasi. Sandboxing agen bukanlah masalah algoritme, tetapi secara langsung menentukan efisiensi pembuatan data Anda, yang pada gilirannya menentukan kecepatan pelatihan Anda. Observabilitas. Debugging prapelatihan relatif mudah — perhatikan kurva kerugian, periksa norma gradien, dan Anda biasanya dapat menentukan masalahnya. Tetapi debugging RL memerlukan kemampuan pelacakan end-to-end: distribusi kualitas peluncuran, statistik hadiah, tingkat di luar kebijakan, besarnya pembaruan kebijakan, dan bahkan atribusi perbedaan logprob (apakah perbedaan berasal dari sisi inferensi, atau dari kelambatan versi pelatihan asinkron?). Sayangnya, sebagian besar tim yang saya temui pada dasarnya terbang buta pada dimensi ini. Hal ini mengarah pada situasi yang canggung — ketika hasil pelatihan buruk, Anda bahkan tidak tahu modul mana yang harus disalahkan. Dilema Skala. Banyak pengoptimalan RL Infra hanya menunjukkan dampak terukur pada skala yang memadai. Eksperimen skala kecil sering kali tidak mengungkapkan perbedaan yang berarti - bukan karena pengoptimalan tidak berguna, tetapi karena kebisingan terlalu tinggi dan jumlah langkah terlalu rendah untuk sinyal muncul. Namun eksperimen skala besar sangat mahal. Ini menciptakan lingkaran setan: Anda tidak dapat membuktikan pengoptimalan Anda bekerja dalam skala kecil, sehingga Anda tidak dapat mengamankan sumber daya untuk eksperimen skala besar; Dan tanpa validasi skala besar, pengoptimalan Anda selamanya terjebak pada "secara teoritis itu harus membantu." Investasi industri di RL Infra sangat tidak sesuai dengan kompleksitasnya yang sebenarnya. Sebagian besar tim memperlakukannya sebagai pekerjaan tambalan di atas infra prapelatihan — ambil kerangka kerja pelatihan siap pakai, pasang mesin inferensi, rekatkan dengan skrip, dan sebut saja RL Infra. Tetapi kompleksitas sistem pelatihan RL dan prapelatihan bahkan tidak berada di liga yang sama. Alur prapelatihan linier, homogen, dan hampir tidak memiliki dependensi eksternal. Pipeline pelatihan RL bersifat siklus, heterogen, dan sangat bergantung pada lingkungan eksternal. Menerapkan pola pikir arsitektur yang pertama pada yang terakhir dijamin akan menabrak dinding dalam skala besar. Kesulitan sebenarnya dalam rekayasa sistem bukanlah tentang mendorong modul tunggal ke ekstremnya — ini tentang memahami kopling antara modul dan ruang pertukaran global. Ini berlaku untuk sistem inferensi, dan terlebih lagi untuk RL Infra, di mana dimensi kopling lebih besar, loop umpan balik lebih panjang, dan kepadatan informasi untuk debugging jauh lebih rendah. Saya ingin menutup dengan dua pertanyaan yang telah saya pikirkan, dan saya ingin mendengar dari orang lain yang bekerja di ruang ini: Di mana tepatnya pengembalian marjinal dari penyelarasan train-inferensi mulai berkurang? Setelah asinkron diperkenalkan, tingkat di luar kebijakan sudah substansial. Pada dasar itu, apakah keuntungan tambahan dari penyelarasan lebih lanjut benar-benar ROI yang lebih tinggi daripada menginvestasikan upaya rekayasa yang sama ke dalam stabilitas kotak pasir, pengoptimalan pipa hadiah, atau infrastruktur observabilitas? Saya memiliki jawaban tentatif saya sendiri, tetapi saya pikir pertanyaan ini layak dipikirkan secara serius dari lebih banyak orang - daripada default ke penyelarasan sebagai prioritas utama hanya karena itu adalah topik yang paling terlihat. Dan ada alasan mengapa itu yang paling terlihat: penyelarasan inferensi kereta api memiliki formalisasi matematis yang bersih dan menghasilkan ablasi yang elegan - itu cocok untuk makalah. Tapi bagaimana Anda menulis makalah tentang stabilitas kotak pasir? Bagaimana Anda membingkai keandalan orkestrasi kontainer sebagai cerita akademis? Anda tidak bisa, sungguh. Jadi masalah-masalah ini diabaikan secara kolektif. Bahkan jika sistem RL Infra mencapai penyelarasan inferensi kereta tingkat bit, efisiensi keseluruhan masih bisa suram — karena kemacetan pindah ke tempat lain sejak lama. Sejauh mana RL Infra dapat distandarisasi? Sistem inferensi memiliki metrik tolok ukur yang relatif terdefinisi dengan baik — TTFT, TBT, Throughput. Indikator objektif ini memungkinkan kita mengevaluasi dengan jelas dampak pengoptimalan. Tapi apa standar evaluasi untuk RL Infra? Throughput pelatihan? Efisiensi sampel? Waktu jam dinding ujung ke ujung? Arsitektur optimal mungkin bervariasi secara dramatis di seluruh skenario (pembuatan kode vs. agen vs. penalaran). Jika kita bahkan tidak memiliki konsensus tentang seperti apa "RL Infra yang bagus", maka pengetahuan teknik di bidang ini akan sangat sulit untuk dikumpulkan dan digunakan kembali. Apakah RL adalah jalur penting untuk meningkatkan kemampuan model — penilaian itu masih berkembang. Tetapi jika jawabannya adalah ya, maka Infra adalah hambatan yang paling diremehkan di jalur itu. Bukan karena tidak ada yang mengerjakannya, tetapi karena perhatian kolektif salah dialokasikan. Kekejaman Efek Barel adalah ini: tidak peduli seberapa tinggi tongkat tertinggi Anda, itu tidak dapat menyelamatkan sistem. RL Infra bukanlah masalah sekunder. Ini adalah domain rekayasa sistem independen dengan kompleksitas tinggi. Hanya dengan memperlakukannya sebagai warga negara kelas satu kita akan memiliki kesempatan untuk membuat skala RL.