Together AI、合成データ生成向け高速推論モデル「ThunderAgent」を発表
Together AI は、エージェント型 LLM の推論効率を飛躍的に高める「ThunderAgent」を発表し、単一ノードで処理スループットが最大2.5倍向上し、8 ノードクラスターでも 2.4 倍の高速化を実現した。
AI深層分析を開く2026年7月30日 08:02
AI深層分析
キーポイント
KV キャッシュのスラッシング解消
従来の推論エンジンが抱えていた、エージェントの待機時に KV キャッシュが不要に削除・再計算される非効率な問題を解決する新しいプログラム抽象化を導入した。
大規模クラスターでの線形スケーリング
16 から 64 GPU に至るまで、GPU ノード数に対してほぼ線形でスループットが向上し、8 ノード環境で 2.4 倍の速度改善を達成した。
既存システムとの互換性
OpenAI との互換性を維持しつつ、単一の program_id フィールドを追加するだけで、既存のオフローディングや推測的デコーディング機能と組み合わせて使用可能である。
ICML 2026 で採択
この技術は ICML 2026 の Spotlight paper として採用され、学術的にもその革新性が認められた。
KV キャッシュのスラッシング問題
従来の推論エンジンはツール呼び出し中のエージェントの KV キャッシュを不要と判断して削除し、再開時に履歴を再計算するため、高同時実行時に対処不能なスループット低下を引き起こす。
重要な引用
ThunderAgent achieves up to 2.5× higher single-node throughput in our synthetic data generation pipeline
When an agent pauses for a tool call, its KV cache can be evicted to make room for other requests, only to be recomputed from scratch when the agent resumes.
This creates fundamental inefficiencies in engines such as SGLang, vLLM, and TensorRT-LLM when serving agentic workloads at high concurrency
At high concurrency, this cascade of evictions and recomputations can lead to severe throughput and latency degradation. We refer to this problem as KV cache thrashing.
編集コメントを表示
編集コメント
エージェント型ワークロードの非効率性を特定し、KV キャッシュ管理という根本的な課題に切り込んだ点は非常に示唆に富む。特に既存エコシステムとの互換性を保ちながら性能を向上させたアプローチは、実務現場での導入障壁を下げる重要な要素となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
ThunderAgent は、高スループットなエージェント推論を実現するシステムです。エージェント LLM のリクエストスケジューリングに新たなプログラム抽象化を導入することで、合成データ生成パイプラインにおける単一ノードのスループットを最大 2.5 倍向上させました。また、8 ノード構成のクラスターでは 2.4 倍の高速化を実現し、GPU ノード数に対してほぼ線形にスケーリングする性能を示しています。
主な成果は以下の通りです。
→ 高同時実行時でも P50 レイテンシが約 1/10 に短縮され、単一ノードのスループットは 2 倍以上に向上
→ 8 ノード構成で 2.4 倍の高速化。16 から 64 GPU までほぼ線形にスケーリング
→ ドロップイン対応:program_id フィールドを 1 つ追加するだけで OpenAI 互換。既存のオフローディングやスペキュレーティブ・ディコーディングと併用可能
ThunderAgent は、ICML 2026 の Spotlight paper に採択されました。
LLM をエージェントとして活用するケースが増えています。Claude Code や Codex、OpenClaw といったシステムは、タスク完了までに数十ターンにわたって推論を行い、ツールを呼び出し、結果を読み込んで再度推論を行います。これらのエージェントを訓練するには、大規模な合成データ生成が必要です。なぜなら、自然言語のウェブコーパスには、複数ターンにわたるツール使用のエージェントの軌跡が含まれていないからです。最近公開した CoderForge のようなエージェント用データセットを生成するには、高同時実行でのエージェント推論が不可欠です。
しかし、既存の推論エンジンはリクエスト単位でスケジューリングしており、各 LLM 呼び出しが独立した単位として扱われます。そのため、長いマルチターンワークフローの一部であることを認識していません。エージェントがツール呼び出しのために一時停止すると、KV キャッシュは他のリクエストのためのスペースを確保するために退去させられます。その後、エージェントが再開する際にキャッシュは最初から再計算されることになります。
これは、SGLang や vLLM、TensorRT-LLM といったエンジンにおいて、高並行でアジェンティックなワークロードを処理する際に根本的な非効率を生み出します。具体的には KV キャッシュのスラッシング(頻繁な読み書き)、マルチノード間での負荷の偏り、ツール管理におけるリソースの浪費などが発生します。
本ブログでは、最も重要な問題である KV キャッシュのスラッシングに焦点を当てます。より包括的な議論については、論文をご参照ください。
スケールしたアジェンティック推論を阻む要因
アジェンティックなワークフローは、2 つのフェーズを交互に繰り返します。1 つ目は GPU を大量に使用する「推論フェーズ」で、モデルがトークンを生成している間です。もう 1 つは GPU がアイドル状態になる「行動フェーズ」で、コンパイラなどのツールからの応答を待っている間です。
数百のエージェントが同時に実行されると、各フェーズで KV キャッシュが増大し、限られた GPU メモリを巡って競合します。このメモリ圧力下では、vLLM といった従来の推論エンジンは「最近使われていないもの」を単純なポリシーで退去させます。そのキャッシュが数秒後に再び必要になるかどうかに関わらずです。
この状況は悪循環を生み出します。エージェント A がツール呼び出しを待機している間に、その KV キャッシュはエージェント B のプリフェッチのために退去させられます。そして、エージェント A のツールが応答した際、エンジン側はエージェント A の会話履歴を最初からすべて再計算する必要があり、それが原因でエージェント C のコンテキスト用のキャッシュも退去させられることになります。高同時実行環境では、この退去と再計算の連鎖がスループットとレイテンシの深刻な低下を引き起こします。私たちはこの問題を「KV キャッシュ・スラッシング」と呼んでいます。
単に GPU ノードを大量に投入しても、根本的な解決にはなりません。SGLang Gateway などの既存のマルチノールーターは、キャッシュの局所性を保つために各エージェントを固定されたノードに割り当てます。しかし、エージェントのコンテキスト長が予測不能に伸びるため、メモリをすべて使い果たす長いコンテキストのエージェントが割り当てられたノードと、余力を残してアイドル状態にあるノードが混在します。過負荷となったノードでは依然としてスラッシングが発生します。
KV キャッシュのオフロードを採用しても問題は解決しません。LMCache や HiCache などの戦略は、KV キャッシュを CPU メモリやディスクへオフロードすることで総キャッシュ容量を増やしますが、これはスラッシングを先送りするだけにとどまります。並行して動作するエージェントのワーキングセットが利用可能なすべてのストレージ層を超えると、退去処理が再開され、同じ悪循環に戻ってしまいます。

メモリ圧力がかかる状況では、リクエストレベルのエンジンがツール呼び出しのためにエージェントが一時停止した瞬間に KV キャッシュを削除してしまいます。その結果、再開時には会話全体を再計算する必要が生じ、次のエージェントのキャッシュも削除されるという悪循環に陥ります。
ThunderAgent がスラッシング問題を解決する方法
リクエストレベルのエンジンだけではスラッシング問題を根本的に解決できません。なぜなら、一連の LLM 呼び出しが一つの長いワークフローの一部であることを認識できないからです。ThunderAgent はこの欠落した視点を補完します。これはエージェントクライアントと推論バックエンドの間に位置する軽量なスケジューリング層であり、各エージェントワークフローをスケジューラブルなプログラムとして抽象化します。実行フェーズ、KV キャッシュの使用量、ノード配置を追跡することで管理を行います。
ThunderAgent はプログラムレベルでの入場制御を通じて KV キャッシュのスラッシングを緩和します。各ノードのメモリ圧力を監視し、優先度の低いワークフローを選択的に一時停止させることで、キャッシュを競合するプログラムの数を減らします。同時に実行されるプログラムが減るため、残りのアクティブなワークフローは KV キャッシュのヒット率が大幅に向上し、レイテンシも低下します。一時停止していたワークフローが再開準備ができたら、ThunderAgent はグローバル待機キューを通じて最も空き容量が多いノードへルーティングし、クラスター全体で負荷をバランスさせます。
マルチノード展開において、ThunderAgent はセッションベースの静的なノード割り当てを、グローバル待機キューに置き換えます。一時停止されたワークフローが再開可能な状態になると、ThunderAgent はそのリクエストを最も空き容量が多いノードへルーティングします。この戦略は KV キャッシュの局所性とマルチノード上の負荷分散というトレードオフを最適化し、キャッシュ利用効率とクラスター全体での均等な負荷配分の両立を実現します。
マルチノードのスケーラビリティを超えて、ThunderAgent は KV キャッシュのオフロードにも対応しています。GPU の HBM、CPU メモリ、ディスクストレージにまたがる KV キャパシティを統一されたプールとして扱います。オフロード単体ではスラッシング(頻繁なページング)を遅らせるだけで完全には解消できませんが、ThunderAgent の一時停止と再開の戦略は、基盤となるストレージ階層の種類に関わらず有効です。

ThunderAgent はエージェントクライアントと推論バックエンドの間に位置し、各ワークフローをスケジューリング可能なプログラムとして抽象化します。実行フェーズ、KV フットプリント、ノード配置をプログラムテーブルで追跡し、メモリ圧力下では優先度の低いプログラムを一時停止、グローバル待機キューを経由して空き容量が最も多いノードへ再開させます。
評価
ThunderAgent は、CoderForge のようなデータセットの背後にあるハッチとインフラストラクチャと同じ社内合成データ生成パイプラインに統合されています。この環境では、数百人の LLM コーディングエージェントが同時に沙箱環境と数十ターンにわたって相互作用し、トランジェクト(軌跡)を生成しています。
ThunderAgent の性能は、HiCache を使用して KV キャッシュオフロードを実行した 8×H100 ノード単体上で、SGLang のデフォルトスケジューラと比較されました。バッチサイズ 192 の条件下では、SGLang はスループットが 390 トークン/秒に低下し、平均レイテンシは 65 秒となりました。一方、ThunderAgent はスループット 803 トークン/秒を達成し、平均レイテンシはわずか 10.6 秒でした。これにより、スループットとレイテンシのトレードオフにおけるパレートフロンティアが拡大されています。

2 から 8 ノードの H100 を用いたスループットのスケール特性において、ThunderAgent はほぼ線形な拡張性を示し、SGLang Gateway に対する優位性も拡大しています。ノード数 2 で 1.79 倍だったスピードアップ率が、8 ノードでは 2.39 倍に達します。
結論
ThunderAgent の核心は、エージェントのワークフローを「無関係なリクエストの羅列」ではなく、「プログラム」として扱う点にあります。この単一の抽象化によって、KV キャッシュのスラッシング(無駄な書き換え)を防ぎ、ノード間で負荷を最適に分散させ、既存のオフローディングやデコーディング最適化とも互換性を保つことが可能になります。さらに、推論バックエンドを変更せずにワークフローをエンドツーエンドで追跡できるため、実システムへの導入も現実的なものとなっています。
ThunderAgent は当社の合成データパイプラインだけでなく、SkyRL や NVIDIA Dynamo といったオープンソースフレームワークでも採用されています。この「プログラム抽象化」が次世代のエージェント推論システムの基盤として最適だと考えており、コミュニティがこの上でどのような成果を生み出すかを楽しみにしています。
実際に試してみよう
ThunderAgent は既存のスタックにそのまま組み込めるように設計されています。OpenAI 互換エンドポイントを通じて推論バックエンドと連携し、量子化やスペキュレーティブ・デコーディングなど、すでに利用している推論最適化とも併用可能です。クライアント側での変更点は、各リクエストがどのプログラムに属するかを識別するために program_id フィールドを追加するだけです。
ThunderAgent はオープンソースで、すぐに使用できます:
- GitHub: https://github.com/ThunderAgent-org/ThunderAgent
- 論文:https://arxiv.org/abs/2602.13692
大規模なエージェントワークロードを運用中なら、ThunderAgent を使うことで、同じハードウェアから「無料の速度向上」を得られる可能性があります。ぜひ試して、その結果をお知らせください。
原文を表示
Summary
We introduce ThunderAgent, a system for high throughput agentic inference. By introducing a novel program abstraction for agentic LLM request scheduling, ThunderAgent achieves up to 2.5× higher single-node throughput in our synthetic data generation pipeline, and delivers 2.4× speedup on an 8-node cluster with near-linear throughput scaling with respect to GPU nodes.
Key Results
→ More than 2× single-node throughput, with roughly 10× lower P50 latency at high concurrency**→ 2.4× speedup on 8 nodes, near-linear scaling from 16 to 64 GPUs
→ Drop-in: one program_id field, OpenAI-compatible, works with your existing offloading and speculative decoding
ThunderAgent was accepted to ICML 2026 as a Spotlight paper.
LLMs are increasingly deployed as agents. Systems like Claude Code, Codex, and OpenClaw reason, call tools, read results, and reason again, often for dozens of turns before completing a task. Training these agents requires large scale synthetic data generation, since natural web corpora do not contain multi-turn, tool-using agent trajectories. To generate agentic datasets like our recently released CoderForge, we need to run agentic inference at high concurrency.
However, existing inference engines schedule at the request level, where each LLM call is an independent unit with no awareness that it belongs to a longer, multi-turn workflow. When an agent pauses for a tool call, its KV cache can be evicted to make room for other requests, only to be recomputed from scratch when the agent resumes. This creates fundamental inefficiencies in engines such as SGLang, vLLM, and TensorRT-LLM when serving agentic workloads at high concurrency, including KV cache thrashing, imbalanced workloads across mutli-nodes, and resource waste in tool management. In this blog, we focus on the most critical: KV cache thrashing. We refer readers to our paper for a more comprehensive discussion.
What hinders agentic inference at scale
An agentic workflow alternates between two phases: the GPU-heavy reasoning phase where the model is generating tokens and the GPU-idle acting** phase where the agent is waiting for a tool like a compiler to return. When hundreds of agents run concurrently, their KV caches grow at each phase, competing for limited GPU memory. Under this memory pressure, a traditional inference engine like vLLM would evict KV caches using a simple policy: least recently used, regardless of whether that cache will be needed again in seconds.
The result is a vicious cycle. Agent A pauses for a tool call. Its KV cache gets evicted to make room for Agent B's prefill. When Agent A's tool returns, the engine must recompute Agent A's entire conversation history from scratch, which in turn evicts cache for Agent C's context. At high concurrency, this cascade of evictions and recomputations can lead to severe throughput and latency degradation. We refer to this problem as KV cache thrashing.
Simply throwing more GPU nodes at the problem doesn't fully resolve it. Existing multi-node routers such as SGLang Gateway pin each agent to a fixed node to preserve cache locality. But because agentic context lengths grow unpredictably, some nodes are assigned agents with long contexts that exhaust memory, while others sit idle with capacity to spare. The overloaded nodes still face thrashing.
Adopting KV cache offloading doesn't resolve the problem either. Strategies like LMCache and HiCache offload KV caches to CPU memory or disk, which expands total cache capacity but only delays thrashing. When the working set of concurrent agents exceeds all available storage tiers, evictions resume and the same vicious cycle returns.

How ThunderAgent resolves the thrashing problem
Request-level engines cannot fix thrashing on their own, because they never see that a series of LLM calls belongs to one longer workflow. ThunderAgent adds that missing view. ThunderAgent is a lightweight scheduling layer that sits between agentic clients and inference backends. It abstracts each agentic workflow as a schedulable program, tracking its execution phase, KV cache footprint, and node placement.
ThunderAgent mitigates KV cache thrashing through program-level admission control: it monitors the memory pressure on each node and selectively pauses low-priority workflows to reduce the number of programs competing for cache. With fewer concurrent programs, the remaining active workflows achieve significantly higher KV cache hit rates and lower latency. When paused workflows are ready to resume, ThunderAgent routes them to the node with the most available capacity through a global waiting queue, balancing load across the cluster.
For multi-node deployment, ThunderAgent replaces session-based static node-pinning with a global waiting queue. When a paused workflow is ready to resume, ThunderAgent routes its requests to the node with the most available capacity. Such routing strategy balances the tradeoff between KV cache locality and multi-node workload balance, achieving both efficient cache utilization and even load distribution across the cluster.
Beyond multi-node scalability, ThunderAgent is also compatible with KV cache offloading, treating KV cache capacity across GPU HBM, CPU RAM, and disk storage as a unified pool. While offloading alone only delays but does not eliminate thrashing, ThunderAgent's pausing and resuming strategy remains effective regardless of the underlying storage tiers.

Evaluation
We integrate ThunderAgent into our internal synthetic data generation pipeline, the same harness and infrastructure behind datasets like CoderForge, where hundreds of LLM coding agents interact concurrently with sandboxed environments over dozens of turns to generate trajectories.
We compare ThunderAgent against the default scheduler in SGLang on a single 8×H100 node with KV cache offloading using HiCache. At batch size 192, SGLang’s throughput drops to 390 token/s with a mean latency of 65s, while ThunderAgent achieves 803 token/s throughput with mean latency of 10.6s, expanding the Pareto frontier in throughput-latency tradeoffs.

We extend the evaluation to multi-node clusters, comparing against SGLang Gateway on up to 8 H100 nodes. As shown in the graph, ThunderAgent’s throughput scales near-linearly with respect to the number of GPU nodes, growing from 671 to 2,248 steps/min as we scale from 16 to 64 GPUs. Meanwhile, the speedup of ThunderAgent over SGLang Gateway widens with cluster size, from 1.79× at 2 nodes to 2.39× at 8 nodes. While SGLang Gateway causes increasing memory imbalance as the cluster grows, ThunderAgent's global waiting queue routes resumed workflows to whichever node has available capacity, reducing memory imbalance across the cluster.

まとめ
The core shift is treating each agent workflow as a program rather than a series of unrelated requests. That single abstraction is what lets ThunderAgent stop KV cache thrashing, balance load across nodes, and stay compatible with the offloading and decoding optimizations you already run. It is also what makes the system practical to adopt: workflows are tracked end to end without changing your inference backend.
Beyond our own synthetic data pipeline, ThunderAgent has been adopted by open-source frameworks including SkyRL and NVIDIA Dynamo. We think the program abstraction is the right foundation for the next generation of agentic inference systems, and we are excited to see what the community builds on it.
Try it out!
ThunderAgent is designed to drop into your existing stack. It interfaces with inference backends through OpenAI-compatible endpoints, and works alongside the inference optimizations you already use, such as quantization and speculative decoding. The only client-side change is adding a program_id field to identify which program each request belongs to.
ThunderAgent is open source and ready to use:
- GitHub: https://github.com/ThunderAgent-org/ThunderAgent
- Paper: https://arxiv.org/abs/2602.13692
If you're running large-scale agentic workloads, ThunderAgent can help you get a free lunch speedup from the same hardware. Try it out, and let us know how it goes.
AI算出
主要ニュースainew評価高い
AI エージェント推論のボトルネック解決という明確な技術的貢献があり、ICML 採択論文に基づく新製品発表として新規性が高い。ただし、日本企業や日本語特有の文脈は含まれていないため、日本の関連性は低めとなる。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 100
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み