GPU boşta bekliyor çünkü sandbox geç açılıyor: ısıtılmış havuz ve pod geri dönüşümü
Accelerate agentic RL with GKE Agent Sandbox
Agent'ları pekiştirmeli öğrenmeyle (RL) eğitmek ve değerlendirmek için büyük ölçekli paralel rollout'lar çalıştırınca öncü laboratuvarlar hep aynı darboğaza çarpıyor: pahalı GPU kümeleri, CPU sandbox'ların soğuk başlangıcını dakikalarca bekliyor. Üstüne binlerce, her biri çok gigabaytlık SWE-bench tarzı imaj çekimi ve zamanlama birikimleri geliyor.
Tipik bir agentic RL döngüsünde GPU'daki LLM politikası kod parçası gibi eylemler üretiyor ve bunlar yalıtılmış CPU sandbox'larda çalıştırılıp bir ödül sinyali gözleniyor. On binlerce paralel rollout'a ölçeklenince üç darboğaz çıkıyor. Kuyruk gecikmesi tuzağı: RL adımı senkron, yani eğitim batch'teki en yavaş sandbox hazır olana kadar ilerlemiyor. İmaj kardinalitesi: klasik konteyner önbelleği birkaç statik temel imaj varsayar, oysa her görev (örneğin her GitHub deposu) başka bir imaj gerektirebiliyor. Kontrol düzlemi doygunluğu: her eğitim adımı, aynı anda binlerce sandbox isteyen bir rollout patlaması tetikliyor.
Google'ın çözümü RL için optimize edilmiş GKE Agent Sandbox, bir orkestrasyon SDK'sı ve popüler RL ortamlarına yerel entegrasyonlar. Sonuçlar: ilk komuta kadar süre 10-45 kat daha kısa (sandbox 45-85 saniye yerine 1-9 saniyede açılıyor), en kötü durum bekleme 7,5 dakikadan 10 saniyenin altına iniyor ve kontrol düzlemi yükü 3 kat azalıyor. Anahtar teknikler: gVisor sandbox havuzu ve GKE imaj akışı (image streaming); SandboxWarmPool, önceden başlatılmış ve sağlıklı ortamları hazır tutarak soğuk başlangıcı ortadan kaldırıyor; ve SDK'nın yerinde geri dönüştürme stratejisi, pod'ları her rollout'ta silip yeniden yaratmak yerine yeniden kullanıyor (üç kat az pod yaratımı, Kubernetes API sunucusu kararlı kalıyor). Test küme boyutu mütevazı: 10 düğümlük bir havuz. Bu ilke Mistral AI'ın RL eğitim altyapısında kullanılıyor.
Öne çıkanlar
- Senkron toplu işte toplam süreyi ortalama değil en yavaş eleman belirler (tail latency).
- Isıtılmış havuz (warm pool): başlatma maliyetini istek anından hazırlık zamanına kaydırır.
- Nesne silip yeniden yaratmak yerine geri dönüştürmek kontrol düzlemi yükünü düşürür.
- Darboğazları bulmak için kendi altyapılarını SWE-bench ile kasten zorlamışlar: ölçüm güdümlü iyileştirme.
Neden önemli?
Pahalı kaynağın verimi, ucuz kaynağın gecikmesine bağlı olabilir. Bu desen (ısıtılmış havuz, yeniden kullanım, kuyruk gecikmesine odaklanma) yalnızca RL için değil, bağlantı havuzlarından sunucusuz fonksiyonlara kadar her yerde geçerli.
Sende karşılığı
Aynı fikir senin dünyanda üç yerde var. Bağlantı havuzu: HikariCP’nin ‘her istekte yeni bağlantı açma’ maliyetini ısıtılmış havuzla çözmesi. Spring Boot soğuk başlangıcı: bir konteyner ilk istekte yavaşsa ısınma (warm-up) isteği ya da minimum örnek sayısı. Bu gazetenin pipeline’ı: fetch her koşuda sıfırdan indiriyor, ama .cache/raw klasörü tam olarak bu ısıtma mantığı. Daha genel alışkanlık: bir işlemin ortalama süresine değil p99 süresine bak, çünkü toplu bir iş her zaman en yavaşı bekler.
Sözlük
- cold start soğuk başlangıç
- Bir ortamın ilk kez ya da uzun bekleme sonrası başlatılırken yaşadığı ek gecikme.
- warm pool ısıtılmış havuz
- Önceden başlatılıp hazır tutulan, istek gelince hemen kullanılan kaynak havuzu.
- time-to-first-command (TTFC) ilk komuta kadar süre
- Bir sandbox’ın istenmesinden ilk komutu çalıştırabilecek hâle gelmesine kadar geçen süre.
- rollout rollout
- RL’de bir politikanın ortamda adım adım eylem yapıp ödül topladığı tek bir deneme.