NVIDIA Dynamoがエージェント推論を強化 TTFTが最大5倍速くなる仕組み

AIコーディングエージェントが急速に普及する中、推論インフラの課題も表面化しています。

2026年5月8日、NVIDIAはオープンソース推論フレームワーク「Dynamo」に対してAIエージェントのマルチターン対応を強化した技術解説を公開しました。Claude Code、Codex、OpenClawといったコーディングエージェントを実際に動かして発見した問題と、その解決策を具体的な数値とともまとめた内容です。

この記事でわかること：

セッション固有ヘッダーがKVキャッシュを壊す仕組みと解決策
TTFTを最大5倍改善する --strip-anthropic-preamble フラグの効果
推論とツールコールのインターリーブ問題とDynamoの修正内容
ストリーミングツールディスパッチの仕組みと利点
Claude Code・Codex・OpenClawをDynamoに接続する設定方法

Streaming Tokens and Tools: Multi-Turn Agentic Harness Support in NVIDIA Dynamo | NVIDIA Technical Blog

An agentic exchange must preserve a structured interaction: assistant turns interleave reasoning with one or more tool c…

NVIDIA Technical Blog

AIエージェントが推論インフラに突きつける課題

コーディングエージェントはすでに生産環境で大量のコードを生成している。Stripeのエージェントは週1,300本超のPR、Spotifyは月650本超を生成しており、Claude CodeやCodexは1回のコーディングセッションで数百回のAPIコールを行う。各呼び出しには会話履歴の全体が含まれるため、推論スタックのKVキャッシュへの負荷は相当なものになる。

Claudeを例にとると、最初のAPIコールでプレフィックスのKVキャッシュが書き込まれた後、同じワーカーへの後続呼び出しは85〜97%がキャッシュヒットになる。read/write比は11.7倍、書き込み1回に対して読み取りが約12回という「一度書いて何度も読む」パターンだ。KVキャッシュをいかに再利用できるかが、エージェント向け推論の中心的な最適化課題となっている。

NVIDIAはこの状況に対応するため、Dynamoをエージェントネイティブな推論フレームワークとして進化させている。今回の記事はDynamo上でClaude Code・Codex・OpenClawを実際に動かして特定した問題と、その修正内容の詳細を解説している。

KVキャッシュを無効化するセッション固有ヘッダー

最もインパクトの大きな発見は、KVキャッシュの再利用を完全に妨げるヘッダーの問題だ。

Claude Codeは52,000トークン規模のシステムプロンプトを送信するが、その先頭にセッションごとに変わるbillingヘッダーが付与される。

x-anthropic-billing-header: cc_version=0.2.93; cch=abc123def456==;
You are Claude Code, an interactive CLI tool...

このヘッダーがプロンプトの先頭にある限り、システムプロンプトの内容が同じでも、トークン列の起点が毎回変わるためKVキャッシュが一切再利用されない。新規ユーザーだけでなく、同じユーザーの新規セッションでも毎回フルのprefillが走る。

Dynamoが追加した --strip-anthropic-preamble フラグはこのヘッダーをトークナイズ前に除去する。NVIDIAがB200 1基で52Kトークンのプロンプトを用いて計測した結果は以下のとおりだ。

状態	TTFT
安定したプレフィックス（ヘッダーなし）	168ms
`--strip-anthropic-preamble` 適用後	169ms
セッション固有ヘッダーあり	912ms

ヘッダーを除去するだけで、TTFTが912msから169msに戻る。新規セッションの初回リクエストで744ms、約5倍の改善になる。フラグを1つ加えるだけで達成できる改善としては大きい。

推論とツールコールのインターリーブ問題

推論モデルを使うエージェントでは、1ターンの中で思考とツールコールが交互に現れる場合がある。

<think>reasoning_0</think> tool_call_0 <think>reasoning_1</think> tool_call_1

以前のDynamoは、この形式を次のように再構築してしまっていた。

<think>reasoning_0 reasoning_1</think> tool_call_0 tool_call_1

トークン数は同じでも、どの推論がどのツールコールに対応するかという構造が失われる。ツールコールを説明する推論ブロックが、ツールコールに紐付いた状態で保持されないためだ。さらに、次のターンに渡す際に必要な思考ブロックが誤って削除されるケースも確認されていた。PR #7358でこの問題が修正された。

NVIDIAの検証によると、52Kトークンのシステムプロンプトと約500トークンの思考ブロックを含むアシスタントターンにおいて、思考ブロックが正しく保持された場合のTTFTは167msだったが、内容が変更された場合は322msまで増加した。約1.9倍の差になる。

修正は3点からなる。推論パーシングの責任範囲を1か所に集約したこと、チャットテンプレートが reasoning_content を直接読める場合はそのまま使うようにしたこと、ツールコールが含まれるターンでは truncate_history_thinking=false に設定して次ターンのコンテキストを保護するようにしたことだ。ツールコールのないターンとツールコールのあるターンで、思考の扱いを切り替えるのがポイントになっている。

ストリーミングツールディスパッチ

以前のDynamoでは、ツールコールを含むレスポンスはストリームが終了するまでバッファリングされていた。推論トークンはリアルタイムで届くのに、ツールコールだけはターン終了後に一括で届く設計のため、ハーネスがツールを実行できるタイミングが遅れていた。

--enable-streaming-tool-dispatch フラグを有効にすると、DynamoはツールコールがパースされEのイベントを即座にSSEで送信する。

event: tool_call_dispatch
data: {"choice_index":0,"tool_call":{"index":0,"id":"call-...","type":"function","function":{"name":"calculator","arguments":"{\"expression\":\"42 * 17\"}"}}}

ハーネスはこのイベントを受け取った時点でツールを実行できる。デルタを積み上げて引数が揃うまで待つ処理も、独自のパーサーも不要だ。ストリームの終了を待たずにツールが動き始めるため、エージェントの応答性が向上する。

設定方法

フロントエンドはこの3フラグをセットで指定する。

python -m dynamo.frontend \
  --http-port 8000 \
  --enable-anthropic-api \
  --strip-anthropic-preamble \
  --enable-streaming-tool-dispatch

ワーカー側には、使用するモデルに合わせた推論パーサーとツールコールパーサーを指定する。NVIDIAの検証ではNemotron-3-Super-120Bに対して nemotron_deci と qwen3_coder を組み合わせている。

Claude CodeやOpenClawはAnthropicのMessages APIを通じてDynamoに接続できる。

ANTHROPIC_API_KEY=local-dev-token \
ANTHROPIC_BASE_URL=http://localhost:8000 \
claude --model nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4

CodexはOpenAIのResponses APIで接続する。この際、モデルIDとカタログプロファイルの対応が正しく設定されているかが重要だ。NVIDIAの検証では、カタログプロファイルの有無でエージェントのツールコール数が1セッションあたり約2倍変わることが確認されている。カタログのaliasを適切に設定することで、ツールコール数が2,081回対2,205回とほぼ同等になった。

DynamoがエージェントとのAPIギャップを縮める理由

AnthropicのマネージドAPIインフラでは、プレフィックスマッチング・キャッシュ配置・エビクション制御がプロバイダー側で最適化されている。自前のGPUでオープンソースモデルを動かすチームには、そうした仕組みがデフォルトでは存在しない。

Dynamoが今回のアップデートで示したのは、「ハーネスが持っている情報をインフラに渡す」という方向性だ。セッション固有ヘッダーを除去してKVキャッシュを安定させること、思考ブロックの正確な継承を保証すること、ツールコールを即時ディスパッチすること——これらはいずれも、エージェントの動作の構造をサービング層が正しく理解することで初めて実現できる最適化だ。

v1.1.0では dynamo-protocols、dynamo-parsers、dynamo-tokenizers がスタンドアロンのクレートとして提供される予定だ。独自のハーネス対応サービングパスを構築したいチームが、Dynamoの内部実装を丸ごとコピーせずに利用できるようになる（参考）。