powered by TechFeed
表示モード
Deep Dive

同じハードウェアでLLMエージェントを最大2.39倍速く動かす「ThunderAgent」— KVキャッシュ競合を「プログラム」単位のスケジューリングで解消、ICML 2026 Spotlight採択

7月29日、Together AIが「ThunderAgent: 2x Faster Agentic Inference for Synthetic Data Generation at Scale」と題した記事を公開した。エージェント型LLM推論において構造的に発生する「KVキャッシュスラッシング」問題を解決するシステム「ThunderAgent」を紹介するもので、シングルノードで約2.06倍、64GPU(8ノード)構成では2.39倍のスループット改善を実測で示している。本研究はジョージア工科大学・イリノイ大学アーバナシャンペーン校・カーネギーメロン大学・Together AIの共同研究としてICML 2026にSpotlight採択されており、すでにオープンソースとして公開済みだ。

7月29日、Together AIが「ThunderAgent: 2x Faster Agentic Inference for Synthetic Data Generation at Scale」と題した記事を公開した。エージェント型LLM推論において構造的に発生する「KVキャッシュスラッシング」問題を解決するシステム「ThunderAgent」を紹介するもので、シングルノードで約2.06倍、64GPU(8ノード)構成では2.39倍のスループット改善を実測で示している。本研究はジョージア工科大学・イリノイ大学アーバナシャンペーン校・カーネギーメロン大学・Together AIの共同研究としてICML 2026にSpotlight採択されており、すでにオープンソースとして公開済みだ。


KVキャッシュスラッシングとは何か

Claude CodeやCodexのようなLLMエージェントは、ツールを呼び出しながら何十ターンもの推論を繰り返す。こうしたエージェントを大量に同時実行するには、スケールするエージェント推論基盤が不可欠だ。ところが既存の推論エンジン(vLLM、SGLang、TensorRT-LLM)には構造的な欠陥がある。

エージェントのワークフローは「推論フェーズ(GPU稼働)」と「ツール呼び出しフェーズ(GPU待機)」を交互に繰り返す。ツール呼び出し中、エージェントのKVキャッシュ(モデルが過去のトークンを再計算しないために保持するメモリ)はGPUメモリ上で空間を占有し続ける。既存エンジンはこれを「最近未使用(LRU)」ポリシーで退避させる。

結果として連鎖的な問題が起きる:

  1. エージェントAがツール呼び出しで待機 → KVキャッシュが退避される
  2. エージェントBのプリフィルのためにメモリが使われる
  3. エージェントAが再開 → 会話履歴全体をゼロから再計算
  4. その再計算がエージェントCのキャッシュを押し出す

この連鎖をThunderAgentチームは「KVキャッシュスラッシング」と呼ぶ。バッチサイズ192の条件でSGLangのスループットが390 token/sまで落ち込み、平均レイテンシが65秒に達するのはこのためだ。

KVキャッシュオフローディングLMCacheHiCacheでCPUメモリやディスクにキャッシュを逃がす手法)は問題を先送りするだけで、同時実行エージェントのワーキングセットが全ストレージ階層を超えれば同じ悪循環に戻る。マルチノード分散SGLang Gatewayのセッション単位の固定ノード割り当て)も、コンテキスト長が予測不能に伸びるエージェントの特性と相性が悪く、一部ノードがメモリ枯渇する一方で他ノードが遊ぶ事態になる。


ThunderAgentの解法:「プログラム」抽象化

ThunderAgentの本質は一つの抽象化の追加だ。既存エンジンが個々のLLMリクエストを独立した単位として扱うのに対し、ThunderAgentはエージェントワークフロー全体を「スケジューリング可能なプログラム」として捉える。

ThunderAgentはエージェントクライアントと推論バックエンドの間に置くスケジューリング層として機能し、各プログラムの実行フェーズ・KVキャッシュのフットプリント・ノード配置を「プログラムテーブル」で追跡する。

スラッシング対策の核心はプログラムレベルのアドミッション制御だ。ノードのメモリ圧力を監視し、低優先度のワークフローを一時停止することでKVキャッシュを競合するプログラム数を減らす。再開時はグローバル待機キューを通じて空き容量の最も多いノードへルーティングする。これによりキャッシュの局所性とクラスタ全体の負荷分散を両立する。

採用に必要なクライアント側の変更は**program_idフィールドの追加のみ**。OpenAI互換エンドポイントで動作し、既存の量子化やスペキュラティブデコーディングとも共存できる。


実測値

Together AIの社内合成データ生成パイプライン(CoderForge等のデータセット生成に使用)でSGLangと比較した結果:

シングルノード(8×H100、HiCacheオフローディング使用)

SGLang ThunderAgent
スループット(バッチ192) 390 token/s 803 token/s(約2.06倍)
平均レイテンシ 65秒 10.6秒

マルチノード(H100、SGLang Gateway比較)

規模 倍率 スループット(steps/min)
16 GPU(2ノード) 1.79倍
64 GPU(8ノード) 2.39倍 671→2,248

マルチノード構成では、GPUノード数の増加に対してスループットがほぼ線形にスケールしている点が重要だ。SGLang Gatewayはセッションを特定ノードに固定するため、コンテキスト長が伸びるにつれて一部ノードのメモリが枯渇し、クラスタ全体の利用効率が低下する。ThunderAgentはグローバル待機キューで空きメモリの多いノードへ動的にルーティングするため、この不均衡が生じにくく、671 steps/minから2,248 steps/minへの約3.4倍という線形に近いスケーリングを実現している。

なお、タイトルにある「最大2.39倍」はこの64GPU構成時の数値であり、シングルノード実測の約2.06倍とは測定条件が異なる。


オープンソースで利用可能

ThunderAgentはすでにオープンソースとして公開されており、SkyRLNVIDIA Dynamoといったフレームワークにも採用されている。

詳細はThunderAgent: 2x Faster Agentic Inference for Synthetic Data Generation at Scaleを参照していただきたい。