エージェンシーシステムの複雑化に対応する極限の共設計

生成 AI の爆発的な最初の章は、人間がリクエストを送りモデルが応答するという形に定義されていました。しかし、エージェントの章は異なります。 エージェントは事前に決定された行動シーケンスに従いません。ツールを呼び出し、異なるタスクとモデルを持つサブエージェントを起動し、メモリに情報を保持し、自身のコンテキストウィンドウを管理し、完了したかどうかを自分自身で判断します。その過程で、これらのシステムはトークン消費量、コンテキスト長、レイテンシ要件を極めて厳しい領域へと押し上げます — これがまさに現在、NVIDIA の極限共設計スタックと NVIDIA Vera Rubin プラットフォームを形作っている圧力です。 本稿では、この進化を 3 つのパートに分けて分析します: - エージェントがトークンをどのように消費するか - なぜ従来のサービング方式ではその経済性が成り立たないのか - エージェント向けに特別に設計されたインフラスタックはどのようなものか ## チャットボットからエージェントへの移行 図 1 に示すように、生成 AI の普及は単純な相互作用モデルから始まりました：ユーザーのメッセージ 1 つに対しチャットボットの応答が 1 つ返り、これを繰り返します。モデルはコンテキストウィンドウ内の記憶から応答し、チャット履歴は線形的に成長し、システムへの要求も予測可能です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image7.webp)*図 1. 複雑さの順に並べた 3 つの AI 相互作用パターン：標準チャットボット（線形）；ツール付きチャット（有界、可変）；およびエージェント型（連鎖型、高エントロピー）* ツール呼び出しの導入は、AI チャットボットの動作方法を根本的に変えます。モデルが計算機を呼び出して数学を推測する代わりにできるようになると、全体の作業負荷が変わります。ツールの応答はコンテキストウィンドウに直接追加されるため、入力シーケンスに予測不可能性が生じます。これは、ツールの出力サイズが特定のクエリとツールの設計（関連データをどのように処理するかを含む）に依存するためです。プロセスはまだプロンプトと最終回答によって制限されていますが、標準的なチャットの単純な予測可能性は失われます。 エージェントを導入すると、この動的性はさらに複雑になります。モデルが1 つのツールを呼び出す力を持つなら、それはいくつのツールを使用するか、そしてどのような順序で使用するかを決定する力も持つことになります。例えば、メール作成を任されたエージェントは以下のようなことができます： - 既存の correspondence を読む - コンテキストのためにドライブを確認する - 受信者の身元を確認する - その後、メールを作成する この連鎖がモデルがエージェントとなる場所であり、作業負荷が「確率的なスパイクを伴う線形的予測可能性」から「構造的に確率的なもの」へとシフトする場所です。その結果、各エージェントセッションの形状は互いに非常に異なる振る舞いを示す可能性があります。 ## エージェントアーキテクチャの特徴 現代のエージェントアーキテクチャは、効果的なコンテキスト管理、ツール使用、タスク最適化を可能にする、エージェント階層と最適化技術の混合で構成されています： ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image9.webp)*図 2. 標準的なエージェント/サブエージェントアーキテクチャの単純なフローダイアグラム* - プライマリエージェント: エンドツーエンドでタスク全体を遂行する責任を負う。サブタスクに取り組むサブエージェントをオーケストレーションする場合もある。通常、プライマリエージェントは最も賢いモデルによって駆動され、ユーザーと直接対話を行う。 - サブエージェント: プライマリエージェントによって生成され、より狭義のタスクを処理するものであり、プライマリエージェントと同様にコンテキストウィンドウを自己管理する能力を持つ。多くの場合、サブエージェントはアーキテクチャ上、プライマリエージェントと同一か非常に類似しているが、実際のプライマリエージェントから提供されるプロンプトに基づいてより限定的なタスクスコープを持つ点で異なる。 - ファイルシステムの状態維持: エージェントがメモリやツール呼び出しの出力をファイルに書き込み、その後その内容を検索または再読することによって生じる追加的な状態維持機能。これはコンテキスト管理および記憶のための手法として機能する。 - 要約と圧縮: エージェントのコンテキストウィンドウを要約して圧縮し、新しい情報のためのスペースを確保するとともに入力処理コストを削減する技術。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image5.webp)*図 3. エージェントセッション全体にわたるリクエストごとの入力トークン増加を示す簡略化された定性的グラフ* 今日、最も人気のあるエージェントツールのいくつかは、類似したアーキテクチャを採用しています。Claude Code などのツールにおける主要エージェントは、より小さなコンテキストウィンドウを活用しタスクを並列化するために、作業をサブエージェントに委譲することが頻繁にあります。システムは推論ステップのたびに入力トークンを処理しなければならないため、より小さなコンテキストを利用することは、より高い効率性をもたらし、結果として入力トークンの処理コストを低下させます。このアーキテクチャは、[context rot](https://www.trychroma.com/research/context-rot) と呼ばれる現象に対する必要な防御策を提供します。これは、拡大するコンテキストが必然的に出力品質の低下をもたらすという現象です。タスクの複雑さが増大すると、意図的な圧縮イベントが発生し、トークンを無限にスケールできないことへの対応として、主要エージェントのコンテキストウィンドウを急激に縮小します。 ## エージェントシステムのワークロードダイナミクスと経済性 Anthropic は [multi-agent system](https://www.anthropic.com/engineering/multi-agent-research-system)（マルチエージェントシステム）の構築に関するレポートにおいて、これらのシステムが標準的なチャットよりも最大で 15 倍ものトークンを消費すると推定しています。この大幅な増加は、これらのアプリケーションが大規模に経済的に利益を生むために、トークンの単位経済性の改善を必要とします。この推論経済性への課題に対処するには、エージェントの経済性を支配するシステムレベルのトークンスループットおよびレイテンシ要件に対する深い理解が必要です。 これらのワークロードのコストと複雑さは、実際のエージェントセッションの分析を通じて最もよく理解できます。図 4 は、Claude Code のコーディングタスクにおける測定例を示しています。グラフ上の線は、セッション中にサブエージェント（オレンジ色）およびメインエージェント（灰色）によって行われた各リクエストにおける入力シーケンス長（コンテキスト＋ISL）を表しています。単一のセッションであっても、このトレースは、ロングコンテキスト容量、キャッシュのプログラム可能性、予測可能なトークンあたりのレイテンシが、純粋なモデル品質と同様に重要である理由を明確に示しています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image4.webp)*図 4. メインエージェントとサブエージェントにわたる 33 分間に及ぶ 283 リクエストを含む、ライブの Claude Code エージェントコーディングセッションからのコンテキスト成長トレース* この 33 分のセッションでは、225 のサブエージェント呼び出しを調整する 58 のメインエージェントターンを追跡しています。283 回の推論リクエスト全体で、コンテキストウィンドウは 15K トークンからピーク時の 156K トークンまで成長しますが、その後コンテキスト圧縮イベントにより約 20K トークンに減少します。このトレースは、エージェントのトークン消費量がタスクの性質だけでなく、エージェントシステムの動作によっても大きく形成されることを明確に示しています。 デフォルトのエージェントは、委任やコンパクションを行っていない場合に入力コンテキストを急速に蓄積するため、キャッシュ読み込みによる入力トークンコストがターンごとに再発します。最初の 40 ターンを通じて、主要なエージェントは平均して約 85K トークンのコンテキストを持ち、コンパクション後にセッションでさらに 100 万トークンを追加する前に、合計で約 350 万の入力トークンを処理します。これらはまさに、高帯域幅メモリ（HBM）や Vera Rubin NVL72 のような高スループットプラットフォームが重要となる条件です。なぜなら、長文コンテキストのプロンプトは経済的に扱いやすいまま維持されつつ、プリフィル需要が拡大し続ける必要があるからです。 プロンプトキャッシングがこのパターンを可能にしています。KV キャッシュの再利用がない場合、すべての入力トークンを完全に再処理する必要があります。主要な API プロバイダーはキャッシュヒットに対して約 90% の割引を提供しているため、キャッシュヒット率が 95% の場合、入力処理コストは約 85% 低下します。プロンプトキャッシングがなければ、このコストはおよそ 6 倍高くなります。コーディングエージェントは、特にツール出力が小さい場合に 95-98% のキャッシュヒット率を維持することが一般的です。そのため、プロンプトキャッシングは単なる API 機能ではなく、システム全体の課題として認識されるようになっています。高いキャッシュヒット率を維持するには、効率的な CPU 側の KV キャッシュ管理と、NVIDIA CMX のような専用設計の高容量コンテキストストレージが必要であり、これにより長いプレフィックスを保持し、セッションがスケールする際に迅速に復元することが可能になります。 サブエージェントのトレースに含まれる 225 のリクエストは、それぞれ固有のコンテキストと特定のツール定義を利用する個別の推論セッションを示しています。サブエージェントは総出力トークン量を増加させる傾向がありますが、新鮮なコンテキストウィンドウから開始し、委譲されたタスクに関連する情報のみを継承することで、入力コストを削減します。また、より小さなモデル上で実行可能であり、これにより遅延とコストが削減されつつも、狭い範囲のタスクに対する精度は維持されます。 コンテキストの圧縮（compaction）も同様に重要です。これはコンテキストウィンドウの制限に達するのを回避し、コンテキストローテーションの影響を軽減するとともに、コスト管理における副次的な効果をもたらします。コンテキストウィンドウを 156K トークンから 20K トークンに縮小することは、キャッシュされた入力トークンの支出を即座に削減し、次のタセットのための余地を生み出します。 以下の図 5 では、定性的に見て処理されたトークンの大部分がキャッシュから取得されていることが明白です。これが起こると、ネットワークおよびメモリシステムの挙動がユーザーが知覚する遅延に直接影響を与え始めます。NVLink 6、ConnectX-9、BlueField-4、Spectrum-X といった低遅延ファブリックは、共有コンテキストへのアクセスを維持し、複数のエージェント間でセッションが分岐した際の再計算ペナルティを軽減するのに役立ちます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image6.webp)*図 5. 生実行中の Agentic Claude Code コーディングセッションからのトークンキャッシング内訳トレース。33 分間にわたる 283 のリクエストにわたって、キャッシュされた入力トークンと未キャッシュの入力トークンを区別しています（図 4 と同じセッション）* この例から、エージェントのトークン動向は非常に複雑であり、トークンの消費量がプライマリエージェントとサブエージェント全体に急速に拡大することが明確になります。この増大するトークン需要の下でこれらのアプリケーションをスケーリングする際の課題を理解するには、提供されるパフォーマンス要件を検討する必要があります。 ## エージェントワークロードのパフォーマンス要件 エージェントワークロードの価値を引き出すには、高いモデル知能、大きなコンテキスト、そして低遅延が必要です。これらのエージェントが洞察を生成する速度が速いほど、その価値は指数関数的に高まります。この速度により R&D サイクルが短縮され、ハーン制御が改善され、複雑なマルチエージェントループが可能になります。これらの機能を可能にするトークンは本質的に処理コストが高いため、提供されるパフォーマンスがこれらのシステムをスケーラブルかつ収益性のあるものとするための重要なレバーとなります。 これらのトークンのコストを下げるには、プロデューサーが大規模モデルに対して大規模なコンテキストで高い相互動作領域におけるスケールを維持する必要があります。以下の図 6 は、標準的な推論パフォーマンスのパレート曲線を通じてこのボトルネックを示しています。曲線の左側は高いスループットを提供しますが、エージェントワークロードが機能できない相互動作の低い極端な領域です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image1.webp)*図 6. GPU 単位でのバッチ処理、標準的なコーディング、およびエージェントアプリケーションワークロードにおけるスループットと相互動作のトレードオフを示す定性的なパレート曲線* これらのワークロードは、代わりに曲線の右側にある高インタラクティブ側にシフトして初めて正常に動作できます。エージェントシステムは膨大なトークン量を消費しながらも、エンドユーザーのインタラクションを維持するために高速な生成速度を要求します。問題は、この低遅延を実現しようとすると、通常システムのスループットが劇的に低下してしまうことです。スループットの低下は、トークンあたりのコストが高額になることを意味し、スケールしたエージェントシステムの経済性を困難にします。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image8.webp)*図 7. バッチ処理、標準的なコーディング、およびエージェントアプリケーションのワークロードにおける、100 万トークンあたりのコストとインタラクション性のトレードオフを示す定性的なパレート曲線* このボトルネックを打破するには、インフラ設計の完全な転換が必要です。現代の GPU は膨大な計算能力と広帯域を提供していますが、低遅延でのスケール維持には、単一のアーキテクチャが提供できるもの以上のものが求められます。その答えは「極限共設計（Extreme Co-Design）」です。このアプローチでは、各フェーズに特化したハードウェアを最適化し、これらの固有の課題を単一のプロセッサではなく、プラットフォーム全体に委ねます。 ## 1 つのプロセッサでは不十分な理由 これらの独自の要求は、計算能力（FLOPs）やメモリ容量を増やすだけでは解決されません。その理由は、エージェントが動作するアーキテクチャの性質によるものであり、単一のプロセッサでこれらを同時に解決することは不可能だからです。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image1-1.webp)*図 8. エージェントワークロードに対する恩恵を強調する NVIDIA の極限共設計戦略の一部を示す図* 必要とされているのは、各ボトルネックが専用ハードウェアにマッピングされ、極限共設計（extreme co-design）によって統合システムとしてオーケストレーションされたプラットフォームです（上記の図 8 を参照）。 - プラットフォーム Vera Rubin NVL72 は、Blackwell の百万トークンあたりのコストの 10 分の 1 でキャパシティと計算能力を提供します。HBM（High Bandwidth Memory）の容量が、長期コンテキストパイプラインを扱いやすくする要因であり、計算密度がスケール時のプレフィルコストを吸収します。 - Vera CPU は、エージェントレイテンシの低減、シームレスな KV キャッシュオフロード、統合された CPU-GPU 実行により、ツール実行のギャップを埋めます。 - Groq 3 LPX は、スループットとレイテンシのトレードオフを打破します。SRAM（Static Random Access Memory）ファーストアーキテクチャは、厳密にバウンドされた低ジッターのトークン生成を実現し、これは単一エージェントの変動がパイプライン全体に伝播する際に特に重要です。 - ネットワーキングチップ（NVLink 6 スイッチ、ConnectX-9 SuperNIC、BlueField-4 DPU、Spectrum-X Ethernet）は、エージェントワークロード向けの統合された低レイテンシサービングファブリックを構築し、エージェントがより迅速に協調し、共有コンテキストへのアクセスを維持し、セッションの拡大に伴う高コストな再計算を回避できるようにします。 - ソフトウェアスタックコンポーネント： Dynamo と Attention-FFN Disaggregation (AFD) は、最適なプロセッサに処理を分割し、実行を調整することでリソース競合とレイテンシを削減し、一貫したサービングパスを実現します。さらに、Dynamo はエージェント・ハネスに対してキャッシュのプログラム可能性を公開しています。 - NVFP4 は精度オーバーヘッドを低減するため、MoE エージェントは知能性を犠牲にすることなく、より低いレイテンシ、より高いスループット、およびより少ないメモリ負荷で実行できます。 - TRT-LLM WideEP は最先端の MoE に対する大規模なエキスパート並列処理を最適化し、エージェントがより低いレイテンシとより高いスループットで高知能な応答を提供できるようにします。 - Speculative Decoding (推測的デコーディング) は、可能性の高いトークンを並列生成して迅速に検証することで、エージェントの応答レイテンシを削減し、大規模モデルにおける低レイテンシ推論を加速します。 これら 7 つのチップとソフトウェア・スタックを極限まで共設計 (Extreme Co-Design) によって組み合わせることで、Vera Rubin プラットフォームは、400k の大規模コンテキストを持つトリリオンパラメータ級の MoE モデルにおいて、ユーザーあたり 400 トークン以上の処理速度を実現できます。このレベルのパフォーマンスは、エージェントにおける歴史的なトレードオフの概念を転換します — 高いユーザーあたりの速度と高いシステム・スループットを提供するために、モデルを小さくして品質を犠牲したり、コンテキストウィンドウを制限したりする必要はもはやありません。この領域において、アジェンティック・アーキテクチャは高価な実験ではなく、大規模展開可能な製品として実現可能になります。 Vera Rubin プラットフォームの仕様や LPX に関する詳細については、それぞれのローンチ日ブログをご覧ください： - NVIDIA Vera Rubin プラットフォームの内部：6 つの新チップと 1 つの AI スーパーコンピュータ - NVIDIA Groq 3 LPX の内部：NVIDIA Vera Rubin プラットフォーム向けの低遅延推論アクセラレーター

エージェンシーシステムの複雑化に対応する極限の共設計

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト