アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

※この投稿は米国時間 2026 年 7 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模言語モデル（LLM）のトレーニング後の強化学習（RL）において、その背後にある数学は妥協が許されないことで知られています。最先端の AI ラボでは、Group Relative Policy Optimization（GRPO）などの RL のトレーニング後のアルゴリズムを使用して推論モデルやコーディング モデルの限界を押し広げるなか、アーキテクチャやインフラストラクチャの厳しい制約に日常的に直面しています。業界の関心の多くは、依然としてアクセラレータの物理容量の獲得に集中していますが、複数の RL ジョブを実行し、モデルをより高いレベルのインテリジェンスに引き上げるために必要な高速性を実現するには、インフラストラクチャの効率も同様に重要です。大規模な分散 RL では、同期サンプリングとトレーニングが厳密に順次フェーズとして実行されるため、トレーナーとサンプラーのリソースが交互にアイドル状態になるため、深刻なリソース ボトルネックが発生します。一方、非同期アーキテクチャではこれらのフェーズを重複させようとしますが、トレーナーは、次のサイクルを開始する前に特定の軌跡バッチが完了するのを待つ間、頻繁にアイドル状態になります。

本日は、この構造的な無駄を解消するソリューションとして、llm-d プロジェクトによる協調型タイムスライスをご紹介します。ロールアウトのサンプリングや勾配トレーニングといった個別の RL ステップを、スケジュール可能な動的エンティティとして扱うことで、独立した RL ジョブを共有物理ハードウェアにインターリーブできます。初期ベンチマークでは、このプラットフォーム レベルの多重化により、モデルの収束や精度に影響を与えることなく、アクセラレータの集計デューティ サイクルがベースラインの約 40% から最大 70% まで向上することが示されています。これにより、時間の経過とともに発生するコンピューティングの無駄がなくなるため、コスト パフォーマンスが向上し、TCO の大幅な削減が実現します。

同期設定の場合、プラットフォームはサンプラーとトレーナーの両方をインターリーブして、交互に生じるアイドル時間を最小限に抑えます。一方、非同期ワークロードはタイムスライスを利用して、RL トレーナーのイテレーション間に生じる断片的なアイドル時間を動的に回収して再利用します。

このブログ記事では、このタイムスライス ソリューションについて、技術フロー、現在のリリース、今後のロードマップを詳しく説明します。

RL インフラストラクチャの効率化のための llm-d（全体像）

Google は当初から、大規模な RL のトレーニング後にインフラストラクチャに深刻なボトルネックが生じることを予測し、RL ワークロードにおけるインフラストラクチャの非効率性を解消することに取り組んできました。

そのなかで、アクセラレータのアイドル時間をなくすことを重視し、推論、エージェント、RL ワークロード向けの高度にコンポーズ可能なインフラストラクチャ スタックに llm-d を組み込みました。RL 向け  llm-d スタックには、次のような特徴があります。

1. スループット重視の推論 （llm-d-router）: RL ワークロード全体にデプロイされ、成熟した、本番環境でテスト済みのエンジンです。ロールアウト生成スループットを最大化してパイプライン常にフル稼働させることに重点を置いています。

2. 高ベロシティの Agent Sandbox （レシピ）: 大規模かつ高密度な環境での検証済みで、ロールアウトの生成と評価中に、安全な 1 秒未満でのツール使用と分離されたコード実行を実現します。Agent Sandbox は、報酬シグナルの生成のための高速インテーク マニホールドとして機能し、タイムスライスされた NVIDIA GPU がリソース不足になるような、サンドボックスがレイテンシのボトルネックにならないように設計されています。

3. コア パイプライン プリミティブ: 重み転送の信頼性と速度の問題に対処するため、Google は Weight Propagation Interface（WPI）を構築するとともに、RL の全体的なオブザーバビリティと信頼性の向上に注力しています。

RL ループにおける効率性の課題

分散型 RL トレーニングの後の運用は、生成（ロールアウトのサンプリング）と最適化（勾配の更新）を交互に繰り返す、断片的で継続的なサイクルとして機能します。従来のクラウド インフラストラクチャは、継続的で安定した状態のワークロード向けに設計されているため、標準の Kubernetes クラスタでは、この交互のリズムに適応できません。

この構造的なケイデンスは、運用が大規模になると、次の 2 つのような大きなシステム上の非効率性を生み出します。

• アイドル状態のアクセラレータ: 各フェーズは順次発生するため、GPU クラスタはライフサイクルの 40～60% の間にわたって、完全にアイドル状態（使用率 0%）になります。トレーナーはサンプリング ロールアウトが完了するまでアイドル状態で待機し、サンプラーは勾配の更新と重みの分散中にアイドル状態で待機します。これは、年間で数百万ドル規模の資本の無駄につながる可能性があります。

• コンテキストのロックイン: RL トレーニングとサンプラーは、NVIDIA CUDA コンテキストとすべてのデバイスメモリを常駐させておく必要があるため、アイドル状態のフェーズでも、ランタイム全体にわたってアクセラレータの割り当てを保持し続けます。標準的なスケジューラでは、これらの Pod を稼働中の RL ループのフェーズレベルでの状態が交互に変化することに合わせるのではなく、静的でサイロ化された割り当てとして扱います。そのため、非アクティブなフェーズでも貴重なハードウェアがロックされたままになります。

重要なのは、これが単なる同期 RL の問題ではないということです。非同期バリアントでは生成とトレーニングが重複して行われますが、アイドル時間を完全に軽減するわけではありません。生成は RL ループ固有のボトルネックであり、ロールアウト データが蓄積されるのを待っている間、トレーナー アクセラレータは依然としてリソース不足に陥ります。非同期ジョブがポリシーに沿って実行されるほど、こうしたアイドル状態の時間は増大します。生成とトレーニングのずれを制限するバウンド ステイルネスにより、新しいロールアウトの準備が整っていない場合はパイプラインが停止するからです。

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

RL ジョブ中にアクセラレータがアイドル状態になるのを防ぐために、llm-d プロジェクトの協調型タイムスライスでは、ハードウェアがアップストリーム フェーズを待機するのではなく、インフラストラクチャが独立した RL ジョブを共有ハードウェア ブロックに動的にインターリーブできます。これにより、基盤となるモデルの収束や精度を変更することなく、アクセラレータの総使用率を向上させることができます。

同期 RL のフェーズ境界でジョブ A がアイドル状態になると（または非同期 RL で新しいロールアウト データ待ちでジョブ A が停止すると）、インフラストラクチャは物理アクセラレータをタイムスライスし、ジョブ B のアクティブなサンプリング フェーズまたはトレーニング フェーズに切り替えます。内部的にこの切り替えは、チェックポイント / 復元として扱われます。ジョブ A のデバイス状態全体がアクセラレータ メモリからホスト DRAM にチェックポイントされ、代わりにジョブ B の以前に保存された状態が復元されます。アクセラレータを占有するジョブの状態は常に 1 つだけであるため、フレームワーク レベルの干渉やメモリ不足（OOM）障害を発生させることなく、ステップを安全に切り替えることができます。

タイムスライス: アーキテクチャの概要

タイムスライス システム アーキテクチャは、ワークロード スコープ（アプリケーション ロジック）、クラスタ スコープ（調整）、ノードスコープ（ハードウェア管理）の 3 つのレイヤで構成されています。

ワークロード スコープのレイヤ（アプリケーション ランタイム）ユーザーのコードが実行される場所で、トレーニング ループ、推論サーバー、RL フレームワークなどがあります。新たに追加されたのは、タイムスライス クライアント ライブラリで、タイムスライス オーケストレーターで 2 つの gRPC API を公開します。1 つはアクセラレータへの排他的アクセスをリクエストする acquire() で、もう 1 つはそれを解放する yield() です。ユーザーは、アクセラレータに触れるフェーズをこれらの呼び出しでラップし、オーケストレータにフェーズの境界を通知します。ML フレームワーク（PyTorch FSDP、vLLM など）や、CUDA コンテキスト、アクセラレータ メモリ割り当てなど、他はすべて変更なしで実行されます。

クラスタ スコープのレイヤ（制御およびオーケストレーション プレーン）このレイヤは、どのジョブがいつアクセラレータにアクセスできるかを決定します。同じ物理アクセラレータを共有するジョブ（例: 同じ GPU ノードセットでインターリーブする 2 つの RL ジョブ）は、1 つのグループに配置されます。タイムスライス オーケストレーターは、グループごとにロックキューを維持します。ロックキューは、そのグループのアクセラレータへの排他的アクセスを待機しているジョブの順序付きリストです。キューの先頭のジョブのみがロックを保持してハードウェア上で実行され、他のすべてのジョブは acquire() 呼び出しでブロックされた状態で待機します。実行中のジョブが yield() を呼び出すと、オーケストレーターはロックをキュー内の次のジョブに渡し、グループ内のすべてのノードで協調的なコンテキスト切り替えをトリガーします。将来的には、ワークロード配置オプティマイザーがワークロード フェーズ パターンをプロファイリングし、互いに補完的なアイドル フェーズのジョブを自動的にペアリングできるようになるため、ユーザーがジョブのグループ化を明示的に指定する必要はなくなります。

ノードスコープ レイヤ（ハードウェアとデータプレーンの分離）このレイヤは、各アクセラレータ ノードでチェックポイントと復元の切り替えを実行します。特権 DaemonSet であるスナップショット エージェントは、オーケストレーターから指示を受け取り、それをハードウェア レベルのオペレーションに変換します。具体的には、アクセラレータ プロセスを一時停止し、デバイスの状態をホスト DRAM にシリアル化して、ジョブがアクセスを再開したときに復元します。このエージェントは、プラグイン可能なバックエンド インターフェースを中心に構築されており、最初の実装として cuda-checkpoint が使用されています（今後さらに追加される予定です）。今後のバックエンドでは、より高速なスナップショット メカニズムや、デバイスの状態全体ではなく LoRA アダプタなどの特定のメモリアドレスをオフロードするなどの、より選択的なアプローチが導入される見込みです。エージェント自体は、ベアメタル環境と Slurm 環境向けに Kubernetes の外部でスタンドアロンで動作するように設計されています。

フロー: 全体像

ワークロードが現在のアクセラレータ フェーズを終了すると、そのタイムスライス クライアント ライブラリはタイムスライス オーケストレーターに対して yield() を呼び出し、アクセスを解放します。オーケストレーターは、グループ内の各ノードのスナップショット エージェントに指示を送信して、コンテキストの切り替えを開始します。エージェントは、譲歩するワークロードのプロセスをフリーズし、そのデバイスの状態をアクセラレータ メモリからホスト DRAM に移動します。

アクセラレータが解放されると、オーケストレーターはキューで待機している次のワークロードにグループロックを付与します。それらのノード上のスナップショット エージェントに対して、そのワークロードの以前に保存された状態をホスト DRAM からアクセラレータ メモリに復元するよう指示し、その後、ワークロードの保留中の acquire() 呼び出しのブロックを解除します。ワークロードは、コンテナの再起動やフレームワークの再初期化、ストレージからのモデル再読み込みを行うことなく、中断したところから正確に実行を再開します。

譲歩したワークロードは、ホスト DRAM でウォーム状態を維持します。オーケストレータが再びロックを許可すると、スナップショット エージェントは同じ切り替えを逆方向に実行します。

開発者エクスペリエンス（クライアントサイド）研究者は、低レベルの CUDA コンテキスト切り替えやカスタム スケジューリング ループに煩わされることなく、コア モデリング ロジックに集中したいと考えています。RL ジョブのオーケストレーションに Ray や同様のプラットフォームを使用している場合、タイムスライスを使用してもクライアント側への影響は最小限に抑えられます。実際、プラットフォーム レベルでトレーニング ジョブとサンプリング ジョブを別々にキューイングしている場合は、クライアント側にはまったく影響が及ばない可能性があります。

現在のリリースと今後の見通し

このたび、タイムスライスのフルスタック（スナップショット エージェント、アクセラレータ オーケストレーター、Python クライアント ライブラリ）をリリースいたしました。各スタックには、RL ワークロードにタイムスライスを統合するためのユーザーガイドが付属しています。

ロードマップの主なハイライトは次のとおりです。

• レイテンシと状態の最適化: より高速なチェックポイント / 復元バックエンドでスナップショット エージェントを拡張し、コンテキスト切り替えのオーバーヘッドを最小限に抑えます。また、アプリケーション対応のバックエンドを使用して、特定のメモリ領域をスナップショットします（例: モデルの重み全体ではなく、LoRA アダプタを切り替え）。

• 自動スケジューリングとオンボーディング: 実行中のプロセスをプロファイリングし、タイムスライス可能な構造を特定して、ジョブの配置を動的に処理する自動スケジューラを導入します。

• ハードウェア間の互換性: データプレーンのサポートを GPU から TPU やカスタム アクセラレータ アーキテクチャに拡張します。

使ってみる

堅牢で高度に最適化された RL インフラストラクチャを構築するには、これらのワークロードを大規模に実行するエンジニアや研究者との緊密な連携が不可欠です。

現在課題となっている、トレーニング後のパイプラインでの GPU 使用率の低さ、同期による停止、複雑なスケジューリング ロジックは、タイムスライスで解決できます。まずは以下のリソースをご確認いただき、ぜひフィードバックをお寄せください。

• これらのユーザーガイドを使用して、RL の実行中にタイムスライスをお試しください。

• RL 生成フェーズ中のサンプリング スループットを向上させるには、llm-d-router（Kubernetes ネイティブ）または RL スケジューラ（Python ライブラリ）のユーザーガイドをお試しください。

• Weight Propagation Interface のリポジトリをご覧ください。

• llm-d Slack の #sig-rl チャンネルでディスカッションにご参加ください。

• リファレンス実装、ベンチマーク、エッジケースを共有して、この手法の改善にご協力ください。

このブログ投稿の執筆に協力してくれた Dolev Ish Am と Bogdan Berce に感謝します。

- シニア プロダクト マネージャー、Poonam Lamba

- ソフトウェア エンジニア、Aishu Kamal