TPU待ち時間を削るGoogle Tunix、agentic RLの訓練基盤へ

multi-turn agentの訓練コストは、モデルが計算している時間だけで決まらない。tool呼び出し、コード実行、データベース照会、web search、reward計算、環境stepを待つ間に、高価なacceleratorが空く。Google Tunixはこの問題を狙うJAX-native post-training libraryだ。最新releaseの焦点は、reasoning agentが遅く不均一な環境とやり取りしている間もTPUを動かし続けることにある。

Googleは、LLM alignmentの焦点が静的なchatbotから動的なagent workflowへ移ったと位置づける。従来のsynchronous rolloutでは、環境の初期化やstate、rewardの返却を待つたびに処理が止まり、accelerator側にも空白が生まれる。batch生成では、ひとつの長いtrajectoryが全体のlatencyを決めるstraggler effectも起きる。TunixはPython asyncioベースのRolloutOrchestratorで多数のagent-environment interactionを並行管理する。ひとつのagentがhost-side tool実行を待つ間、inference engineは別のtrajectoryのtoken生成へ回れる。async vLLM-TPUとSGLang-Jaxの統合も含まれる。

もうひとつの軸はrolloutとtrainingの分離だ。単純なpipelineではbatch全体が完了するまでtrainerが待つ。Tunixは完了したtrajectoryをhigh-throughput queueへ流し、AgenticRLLearnerがそれを消費する。GRPOのようにpromptごとに複数のreasoning pathが必要なアルゴリズムでは、asynchronous trajectoryを動的にまとめ、post-processingとscoringを経てtrainerへ送る。狙いはsynchronous trainerを途切れさせず、end-to-end throughputを上げることだ。

開発者向けには、ModelAgent、ToolAgent、TaskEnvironment、ToolEnvironmentなどの標準部品が用意される。SWE-bench、WebArena、game engine、社内simulatorのような環境も、訓練ループを書き換えずに接続しやすい。観測面では、rollout、training、weight sync、tool latency、environment latencyなどのRL-specific metricを軽量に追跡する。次の確認点は、coding agent、math、game向けrecipeがGemmaやQwenなどのopen model familyで実測benchmark改善につながるかだ。