NVIDIA、アジェンティック AI フリート課題解決に Vera CPU を提案

AI ファクトリーは相互接続されたシステムであり、その経済性は、電力と資本をいかに効率的に完了したエージェントタスクに変換できるかにかかっています。GPU がモデルを実行する一方で、CPU はオーケストレーション、ツール実行、サンドボックス化された計算を担当します。

従来のコンピューティングのようにランタイムプロファイルが安定しているわけではなく、エージェントワークロードは予測不可能で変動が激しいものです。163,594 件のエージェントセッションからのテレメトリデータに基づくと、97% 以上のセッションが独自のトラジェクトリプロファイルを示しました（図 1）。この多様性により、複数の特殊な CPU デザインポイントを用いてファームを最適化する現実的なアプローチは困難です。

実際の運用環境におけるテレメトリデータは、これらの多様なトラジェクトリがどのように展開されるかも示しています。セッション全体を通じて、実行は推論の長い連続的な連鎖に従い、その間に散発的に並列作業のバーストが挟まれます。この実世界のデータから、支配的な順次パスは厳密にレイテンシによって制約されており、全体のセッション完了時間を決定づけることがわかります。一方、一時的なファンアウト（分岐）には、利用可能なスレッドの並行性と、低レイテンシのスレッド単位の実行能力の両方が求められます。

AI ファクトリーは、個別のツール呼び出しシナリオを想定してフラット化されたファームウェアを構築するのではなく、単一のバランス型 CPU デザインポイントを採用する必要があります。NVIDIA Vera CPU はこのバランスを実現するために設計されており、典型的なエージェントワークロードにおいてコアあたりの最高パフォーマンスを提供することでクリティカルパスを加速し、同時に断続的なファンアウトバーストも吸収します。

エージェント軌道のクリティカルパスに沿った最適化

エージェント軌道の形状は、その「長さ」と「幅」によって定義されます（図 2）。

• 長さ: エージェントがターンを完了するまでに必要な推論ステップ数、ツール呼び出し回数、リトライ回数、およびサブタスクの数。

• 幅: 各段階で並列に展開される作業量——同時実行されるツール呼び出し、検索操作、サンドボックス環境、またはサブエージェントの数。

セッションの幅が広くても、並列バーストは一時的である一方、依存チェーンは実行全体を通じて持続するため、実質的な待機時間は逐次処理チェーンに集中しがちです。広範なフォールアウト（分岐）が発生している最中であっても、スレッドごとのレイテンシは依然として極めて重要です。主要エージェントは、並列タスクが完了するまで待機し、次のステップへ進むことができません。

したがって、CPU ファームウェアの最適化目標は、単なるコア数ではなく、「完了したユーザーセッションの総数」であるべきです。高コア数のシステムは表面上は効率的に見えますが、実際にはトレードオフを強いることが多いのです。コア密度の目標を達成するために、エージェントのクリティカルパスにおけるレイテンシ最小化に必要なシングルスレッド性能を犠牲にしてしまうからです。

逐次的でレイテンシに敏感なタスクを低性能のコア上で実行させたり、大規模で多様なクラスター間で高い同期オーバーヘッドが発生したりすると、エージェンティックワークフローは著しく劣化します。エージェントワークロードに適した CPU は、並列ツール実行やサブエージェントのフォールアウトを吸収できる十分なコア数と、総エージェントレイテンシを支配する逐次ステップを加速するための強力なシングルスレッド性能の両方を兼ね備えている必要があります。

実際のエージェントセッションとはどのようなものか

これは、実際のエージェントのテレメトリデータを用いて検証可能です。図3に示す実世界のClaude Codeセッションでは、主要なエージェントが33分間の実行時間の大部分において、長い逐次軌道を進んでいます。

テレメトリデータからは、エージェント型ワークロードの形状における二つの側面が読み取れます。すなわち、意味のある分岐（fan-out）と、長い依存関係の連鎖です。サブエージェントの活動は並列作業のバーストを生み出し、これを迅速に処理する必要がありますが、ユーザーによる一連の操作全体としては、各ステップが次のステップを解放する順序付けられた主要な軌道を進みます。したがって、CPUファームウェアには、遅延なく分岐バーストを吸収できる十分な並列処理能力が必要であると同時に、エンドツーエンドの完了時間を決定するレイテンシに敏感なパスにおいて、高いスレッドあたりの性能も維持できなければなりません。

CPU は、特定の瞬間にコアの一部を停止してスレッド単体の性能を一時的に向上させることができます。しかし、これによりコアあたり 8 GB のメモリが遊んでしまい、総所有コスト（TCO）に大きな負担を強いることになります（図 4）。優れた CPU デザインは、特定のフェーズだけを切り離して最適化するのではなく、ワークロード全体の流れを見据えて設計されます。

このアプローチでは、スレッドごとの応答性の高さ、意味のある並行処理、十分なメモリ帯域幅、そして効率的な電力消費を組み合わせることで、CPU コア、DRAM、GPU の HBM、およびより広範なメモリアーキテクチャを効果的に活用しながら、完了するユーザー操作の数を最大化します。

Vera CPU が実現するこのバランス

Vera CPU は、この運用ポイントを意識して設計されています。NVIDIA Olympus コアを搭載し、CPU 全体が稼働している状態でも、スレッドごとの高い性能を維持できるようにしています。広範なフロントエンド、高度な分岐予測、深いアウト・オブ・オーダー実行、そして高帯域幅のメモリサブシステムにより、各コアはコードフットプリントの拡大や分岐処理の多い制御フロー、動的ランタイム、依存関係の重い実行といった複雑な状況でも、確実に前進し続けることができます。

上記の Claude Code のデータが示す通り、エージェント型ワークロードにも同様のバランスが求められます。それは、ファンアウト（分岐）を吸収するための並行処理と、支配的なシーケンシャルパスを高速化するためのスレッド単体の速度です。

図 5 に示された推定 SPEC CPU® 2026 の結果は、この設計ポイントを検証するものです。コンパイラ、静的解析、Python ベンチマークといった典型的なエージェントワークロードにおける Vera CPU のコアあたりの負荷パフォーマンスを強調し、また Olympus がエージェントのクリティカルパスに必要な性能を犠牲にすることなく並列処理をどのように処理するかを示すことで、NVIDIA Vera CPU は最新の競合製品と比較して最大 1.5 倍のエージェントパフォーマンスを実現します。

最適なエージェントファームには単一の CPU 設計ポイントで十分

Vera は、実在するエージェントのあらゆる軌道に対応して構築されているため、エージェント AI ファームにとってより効率的な CPU の基盤となります。ソケット負荷が最大の状態でも強力なシングルスレッド性能が、遅延に敏感な逐次パスをスムーズに維持します。一方、コア全体での高い並列処理能力と十分なメモリ帯域幅が、断続的なツール呼び出しやサブエージェントの分岐（ファンアウト）を吸収します。Vera CPU の低遅延モノリス型アーキテクチャは、さらにトポロジー起因のストールやこれらのフェーズ間の変動を削減します。

このバランスの取れた設計により、リソースが遊んでしまうことを防ぎます。逐次処理時にも並列バースト時にもコアは生産性を維持し、各コアに接続されたメモリも有効活用され、未利用の計算資源に縛り付けられることがありません。また、予測不能なツール呼び出しパターンに対応するために、フラットを複数の専門化された CPU デザインポイントに分割する必要も減らされます。

その結果、この CPU プラットフォームは、計算能力・メモリ帯域幅・電力を、より多くの完了したエージェントターンに変換します。これにより、大規模な AI ファクトリーの生産性とフラットの経済性が向上します。

NVIDIA Vera CPU のアーキテクチャとパフォーマンスの詳細については、NVIDIA Vera CPU ホワイトペーパーをご覧ください。

NVIDIA Vera の SPEC CPU® 2026 結果は、2026 年 7 月に社内測定したものです。パフォーマンス測定と構成の詳細については、NVIDIA Vera CPU ホワイトペーパーを参照してください。AMD Venice の結果は、リンクに基づいています。Venice の個別ワークロードのパフォーマンスは、SPECrate®2026_int_base スコア 2070 を基に推定され、構成要素は社内での Turin 測定値を基準に正規化されています。結果は環境により変動する可能性があります。

SPEC®、SPEC CPU®、SPECrate®は、Standard Performance Evaluation Corporation（www.spec.org）の登録商標です。

謝辞

本稿は、Ivan Goldwasser、Diana Aung、Hannah Coutand、Ian Finder、Benjamin Klieger、Arnav Jaiswal、Dylan Mitic、および多くの関係者の専門知識と洞察によって実現されました。