3行まとめ
このテーマをもう少し広げて見るなら、NVIDIA MiniMax M3確認：100万トークンの長文推論をNIMとDynamoで試す前に見ること と NVIDIA DGX Spark Enterprise Manageability確認：Fleet LifecycleとCloud-Initで複数台導入前に見ること も合わせて確認してください。AgentPerfの同時エージェント性能を、長文脈・ツール呼び出し・NIM/Dynamo評価の具体的なモデル選定に接続できるため。
単発のtokens/sではなく、長文脈、複数ターン、ツール呼び出しを含む同時エージェント数を見る。
GB300 NVL72はAgentPerf初回条件でH200比最大20倍のagents per MW、61.4K concurrent agents per MWが示された。
自社SLO、電力枠、ラック/クラウド構成、推論エンジン、責任分界を分けて確認する。
数値は2026年6月13日時点の公開情報に基づくため、導入前には対象モデル、SLO、構成条件を再確認する必要があります。
NVIDIAとArtificial Analysisが示したAgentPerf/AA-AgentPerf初回結果は、AIエージェント基盤を単発のtokens/sではなく、長文脈、複数ターン、ツール呼び出し、SLOつきの同時実行数で読むための材料です。
NVIDIAはGB300 NVL72について、DeepSeek V4 Pro系のAgentPerf条件でH200比最大20倍のagents per megawatt、NVIDIA Technical Blogの表では61.4K concurrent agents per MWと57.5 concurrent agents per GPUを示しています。ただし、これは全AIワークロードで常に同じ差が出るという意味ではありません。
導入企業や開発チームは、20倍という見出しより先に、自社のSLO、電力枠、ラック/クラウド構成、推論エンジン、ツール処理、契約上の責任分界を確認する必要があります。
この記事は、NVIDIA公式Blog、NVIDIA Technical Blog、Artificial AnalysisのAA-AgentPerfページとMethodology、NVIDIA NVL72 AI Factory docs、NVIDIA Vera Rubin Platformページを2026年6月13日午前に確認して書いています。NVIDIA Watch JapanはNVIDIA Corporationおよび関係会社とは非提携の独立ブログです。掲載内容は投資助言ではなく、製品、サービス、ソリューションの確認メモです。
AgentPerfは従来のLLM推論ベンチと何が違うのか
- 1単発LLM call
短い入力に対する応答速度だけでは、実際のcoding agentや業務agentの負荷を表しきれない。
- 2複数ターン
ファイル確認、検索、ツール呼び出し、再考が続き、contextとKV cacheの負荷が積み上がる。
- 3SLOつき同時実行
TTFT、output speed、concurrent agentsを組み合わせ、利用者体験を保てる容量を測る。
- 4インフラ評価
モデル品質のランキングではなく、選んだモデルを何セッション支えられるかを見る材料になる。
正答率、推論品質、ガードレールは別の評価軸です。AgentPerfはインフラ容量の読み方として扱います。
AIエージェント基盤の評価では、1回のプロンプトにどれだけ速く返答できるかだけを見ても足りません。実際のcoding agentや業務agentは、最初の応答で終わらず、ファイルを読む、ツールを呼ぶ、検索する、コードや設定を編集する、コマンド結果を見てもう一度考える、といった流れを何度も繰り返します。
NVIDIA Blogは、従来の推論ベンチが単一のLLM callを測るのに対し、agentic workloadではchained LLM calls、tool call delays、growing contextがインフラに違う負荷をかけると説明しています。Artificial AnalysisのAA-AgentPerfも、real coding agent trajectoriesを使い、同時に何体のエージェントを動かせるかをSLOつきで測る設計です。
AgentPerfはエージェントの賢さではなく、基盤の容量を測る
根拠
AA-AgentPerfは、AIエージェントそのものの正答率や開発能力を直接ランキングするものではありません。Artificial AnalysisのMethodologyでは、time to first token、output speed、最大同時エージェント数を組み合わせ、推論deploymentがどれだけのactive agentsを支えられるかを測るベンチとして説明されています。
この違いは重要です。モデル選定では、コード修正能力、推論品質、長文脈での正確さ、幻覚の少なさも必要です。一方、インフラ選定では「良いモデルを選んだあと、そのモデルを何人分の同時作業として支えられるか」が問題になります。AgentPerfは後者に近い指標です。
注意点
したがって、AgentPerfの結果だけを見て「このGPUならエージェント品質も高い」とは言えません。品質はモデル、プロンプト、ツール設計、評価データ、ガードレールで決まり、AgentPerfはそのモデルをSLO内で何セッション動かせるかを見るための材料です。
長文脈、KVキャッシュ、ツール遅延がボトルネックを変える
Artificial AnalysisのMethodologyでは、AA-AgentPerfのdatasetは複数のuse case、プログラミング言語、モデルから作ったagentic trajectoriesを含み、入力sequence lengthは約5Kから約131K tokens、平均約27K tokensとされています。さらに、tool call delaysは実際のtool duration分布をもとにシミュレートされ、中央値は約1秒と説明されています。
これは、短いチャット応答とはかなり違う負荷です。長い文脈が積み上がるとKV cacheの扱いが効きます。複数ターンが続くとschedulerとprefill/decode分離の効率が見えてきます。ツール呼び出しが挟まると、GPUが速いだけでは体感速度が決まりません。
評価基準
導入判断では、少なくとも次の4つを分けて見ます。
| 指標 | 意味 | 誤読しやすい点 |
|---|---|---|
| P25 output speed | 多数のrequestのうち下位側の出力速度を含めた体感に近い速度 | 平均tokens/sだけを見ると、遅いセッションを見落とす |
| P95 TTFT | 最初のtokenが出るまでの遅さを上位側の遅延で見る | output speedが速くても、初動が遅いとUXは悪化する |
| concurrent agents | SLOを満たしたまま同時に動かせるagent数 | 利用者数そのものではなく、作業中agentの同時数 |
| per MW/per accelerator/per system | 電力、GPU、システム単位で容量を正規化する見方 | 施設全体の消費電力や契約価格とは別物 |
この記事で読む数字の範囲
この記事で扱う主な数字は、2026年6月13日時点で確認したNVIDIAとArtificial Analysisの公開情報です。NVIDIA BlogはGB300 NVL72がH200より最大20倍多いagents per megawattを実行すると説明し、NVIDIA Technical BlogのTable 2はSLO=30 configurationsの例として、GB300 NVL72を61.4K concurrent agents per MW、57.5 concurrent agents per GPU、H200を2.6K per MW、1.4 per GPUと示しています。
ただし、Artificial AnalysisのMethodologyページではDeepSeek V4 Pro (max)のSLO tiersが20、60、180 tokens/sとして表示されています。公開直後のベンチはページや表が更新されることがあります。導入判断で使う場合は、NVIDIA側の解説だけでなく、Artificial Analysisの最新leaderboard、Methodology、対象モデル、SLO tier、system configurationを必ず同時に確認してください。
GB300 NVL72の20倍効率と61.4K per MWをどう読むか
この比較はAgentPerf初回条件の公表値であり、全モデル、全ワークロード、全クラウド契約で同じ差が出るという意味ではありません。
20倍という数字は強い見出しです。しかし、導入判断で大事なのは「すごい」で終わらせず、その数字が何で割られ、何を満たしたうえで、どの条件のagent workloadを支えているのかを読むことです。
NVIDIAが示した20倍は、AgentPerf初回結果におけるNVIDIA GB300 NVL72とNVIDIA H200の比較です。NVIDIA Technical Blogでは、DeepSeek V4 Proを使ったagentic coding benchmarkの文脈で、concurrent agents per MWとper GPUが示されています。これは、GPUを買う数だけでなく、電力枠、rack density、SLO、推論エンジン、冷却、契約形態に関わる数字です。
20倍はランキング見出しではなく、条件つきの容量差として読む
根拠
NVIDIA Blogは、AgentPerfの初回ラウンドでGB300 NVL72がH200より最大20倍多いagents per megawattを実行すると説明しています。NVIDIA Technical Blogは、AA-AgentPerfをmulti-vendor open benchmarkとして位置づけ、DeepSeek V4 Proを対象に同時agent数、output speed、TTFT、per MW、per acceleratorを組み合わせて読む構図を示しています。
ここでの重要点は、20倍が単なる「GPU世代差」ではないことです。GB300 NVL72は72 GPUのrack-scale NVLink domain、Blackwell Ultra、推論ソフトウェア最適化、MoE向けの通信/計算の重ね合わせなどを含むシステムとして扱われています。
条件
記事中で20倍を読むときは、次の条件を同じ段落で見てください。
| 条件 | 確認すること |
|---|---|
| モデル | DeepSeek V4 Pro系のAgentPerf初回条件か |
| SLO | output speedとTTFTのどのtierか |
| 正規化 | per MW、per GPU、per systemのどれか |
| 電力範囲 | accelerator powerか、施設全体の電力か |
| 推論スタック | TensorRT LLM、SGLang、vLLM、Dynamoなど、どの最適化を含むか |
| 構成 | GB300 NVL72 rack-scale構成か、8 GPU構成か、クラウド提供構成か |
この表を埋められないまま「20倍だから採用」と判断するのは危険です。逆に、条件を埋めれば、20倍という数字はAIエージェント基盤の容量計画に使える入口になります。
61.4K concurrent agents per MWは電力枠から逆算する指標
NVIDIA Technical BlogのTable 2は、SLO=30 configurationsの例として、GB300 NVL72が61.4K concurrent agents per MW、H200が2.6K concurrent agents per MWと示しています。これは、同じ電力枠でどれだけのagentic sessionsを支えられるかを見るための指標です。
単純化して読むと、電力が強い制約になるデータセンターでは、同じGPU予算より先に「何MWで何agentを動かすか」が問題になります。AIファクトリーでは、ラック、受電、冷却、ネットワーク、設置リードタイムが調達の前提になります。<a href="https://nvda-watch.blog.mo-gmo.com/nvda-20-dsx-ai-factory-platform/" rel="noopener">NVIDIA DSXのAIファクトリー設計</a>で扱ったように、GPU単体の性能だけではなく、施設と運用まで含めて見ます。
評価基準
61.4K per MWをそのまま単純換算すると、目安は次のようになります。
| 電力枠 | 単純換算した同時agent数の目安 | 導入判断での注意 |
|---|---|---|
| 1MW | 約61,400 | NVIDIA Technical Blogの例をそのまま使った単純換算 |
| 5MW | 約307,000 | 実際にはnetwork、cooling、CPU、storage、PUEを別に見る |
| 10MW | 約614,000 | ラック数、クラスタ、リージョン、運用SLOで線形に伸びるとは限らない |
この表は、容量イメージを作るための粗い換算です。実際の同時agent数は、モデル、context length、tool calls、cache hit、user wait time、queueing、障害時の冗長化で大きく変わります。
注意点
Artificial Analysisの公開ページとMethodologyでは、per MWの値はGPU dieとHBMなどaccelerator側のpower drawをもとにした正規化であり、CPU、networking、cooling overhead、施設PUEを含む総消費電力ではないと説明されています。データセンターのTCOを出すときは、per MWのベンチ値をそのまま電力契約や施設総電力に貼り付けないでください。
per MW、per accelerator、per systemを混ぜない
AgentPerfを読むときに混同しやすいのが、per MW、per accelerator、per systemです。電力が制約ならper MW、GPUの効率や台数を見たいならper accelerator、クラスタやラック単位の最大容量を見たいならper systemが主になります。
確認項目
| 導入課題 | まず見る指標 | 質問例 |
|---|---|---|
| 受電/冷却が上限 | per MW | この構成は施設全体のMWに換算すると何agent相当か |
| GPU台数と費用対効果 | per accelerator | 1 GPUあたりのSLO維持agent数はどれくらいか |
| ラックやクラスタ容量 | per system | 1 rack、1 cluster、1 regionで何agentを支えるか |
| クラウド契約 | price/SLO/region | 公表ベンチに近い構成をどのリージョンで借りられるか |
| 本番UX | TTFT/output speed | P95 TTFTとP25 output speedが自社SLOを満たすか |
ベンチ結果が強いほど、指標を混ぜたくなります。けれど、購買、SRE、ML platform、セキュリティ、財務が同じ表を見ているとは限りません。最初に「自分たちは何で詰まっているのか」を決めることが、AgentPerfの数字を使う前提になります。
AIエージェント基盤選びに落とすときの確認軸
ベンダーには順位ではなく、自社のSLOと似た条件でどの構成が何agentを支えられるかを確認します。
AgentPerfは、AIエージェント基盤のRFPやクラウドGPU選定でそのまま使える数字ではありません。使えるのは、質問の型です。自社のagent workloadをどう定義し、どのSLOを満たしたいのか。その条件で、どのGPU、どの推論エンジン、どのクラウド/オンプレ構成が近いのかを確認するための入口になります。
まず自社のSLOを決める
AgentPerfのSLOに自社を合わせるのではなく、自社のユーザー体験からSLOを決めます。coding agentなら、数秒で次の編集候補が返ることが重要かもしれません。社内検索agentなら、最初のtokenよりも根拠文書の正確さと総回答時間が重要になります。顧客対応agentなら、ピーク時のqueueと失敗時の再試行が効きます。
評価基準
最低限、次の値を自社ログやPoCで測ります。
| 項目 | 見る理由 |
|---|---|
| 平均/上位のprompt length | contextが伸びるほどKV cacheとprefillが効く |
| 1セッションあたりのturn数 | agentic workloadか、単発チャットに近いかを分ける |
| tool callの回数と待ち時間 | GPU以外の遅延がUXを支配するかを見る |
| P95 TTFT | 最初の反応が遅いと利用者の体感が悪くなる |
| P25 output speed | 遅い側の出力速度を含めてSLOを満たすかを見る |
| concurrent active agents | 登録ユーザー数ではなく、同時に作業中のagent数を見る |
注意点
小さなPoCで「平均latencyが良い」だけを見て本番容量を決めないことです。agentic workloadは、平均よりもピーク、長いcontext、リトライ、失敗時の枝分かれ、cacheが効かない初回requestで崩れます。
ワークロード形状をAgentPerfに近いか確認する
AA-AgentPerfはcoding agent trajectoriesを中心にしています。これは、ファイル操作、コード編集、ツール呼び出し、長い文脈が絡むため、AIエージェント基盤の厳しい一例として有用です。一方、すべての業務agentがcoding agentと同じ負荷ではありません。
確認項目
| ワークロード | AgentPerfに近い点 | 追加で見る点 |
|---|---|---|
| coding agent | 長いcontext、複数turn、tool callsが多い | リポジトリI/O、テスト実行、sandbox制約 |
| RAG agent | 検索と回答が連鎖する | vector DB、reranker、権限管理 |
| 社内業務agent | API呼び出しと承認フローが多い | SaaS/API rate limit、監査ログ |
| カスタマーサポートagent | 同時利用と応答速度が重要 | 会話品質、個人情報、handoff |
| データ分析agent | 長い処理とツール実行が多い | SQL、notebook、データ所在地 |
下振れ要因
GPU側のAgentPerfが良くても、実運用では別の場所で詰まります。社内APIが遅い、検索indexが古い、DBクエリが重い、ブラウザ操作が不安定、tool sandboxが詰まる、ネットワーク境界で待つ。こうした遅延は、accelerator benchmarkだけでは吸収できません。
クラウドGPU、NCP、オンプレの比較に使う
AgentPerfの読み方は、クラウドGPU選定にもオンプレAIファクトリーにも使えます。ただし、使い方は違います。クラウドでは、実際に借りられるSKU、リージョン、価格、SLA、データ所在地、NVIDIA Cloud Partnerの提供条件が主になります。オンプレでは、ラック、受電、液冷、ネットワーク、保守、導入リードタイムが主になります。
NVIDIAのクラウドGPU選定やDGX Cloud Lepton/NCPの見方は、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-28-ai-cloud-ecosystem-lepton-ncp/" rel="noopener">NVIDIA AI Cloudエコシステム拡大の記事</a>でも整理しました。AgentPerfを読むときも、クラウド契約とベンチ構成が同じとは限らない点をまず確認します。
条件
ベンダーやクラウド事業者には、次の差分を聞くとよいです。
- 公表値と同じGPU/CPU/network/storage構成か。
- 同じモデル、同じSLO、同じ推論エンジンで測った値か。
- accelerator powerではなく、契約上の電力や施設PUEを含む見積もりはあるか。
- 価格はon-demand、reserved、private contractのどれか。
- 障害時、maintenance時、region制約時のSLOはどうなるか。
- NIM、TensorRT LLM、Dynamo、vLLM、SGLangなどの運用責任は誰が持つか。
なぜNVL72と推論ソフトウェアが効くのか
- 1NVLink scale-up
72 GPUsをrack-scaleのcompute unitとして扱い、巨大モデル分割時の待ち時間を減らす基盤になる。
- 2推論エンジン
TensorRT LLM、Dynamo、vLLM、SGLangなどの選択が、同時セッション時の効率に関わる。
- 3KV cache strategy
長いcontextや繰り返しturnでは、KV cacheの保持、再利用、配置が容量と遅延に効く。
- 4prefill/decode分離
入力処理と出力生成を分けて最適化できるかが、agentic workloadの再現性に影響する。
- 5schedulerとbatching
複数agentの到着タイミングをさばき、SLOを崩さずGPUを使い切れるかを見る。
NVLinkがあるだけで速くなるわけではありません。モデル分割、最適化、ネットワーク、CPU側処理まで揃って初めてベンチの数字に近づきます。
GB300 NVL72の読み方で大事なのは、GPUの名前だけではありません。NVIDIA DocsのNVL72 AI Factory資料では、GB300 NVL72が36 Grace CPUsと72 Blackwell Ultra GPUsをrack-scale designで統合し、fifth-generation NVLinkによって72 GPUsを1つのmulti-GPU compute unitとして機能させる構成が説明されています。
AIエージェント基盤では、大きなMoEモデル、長いcontext、KV cache、複数agentの同時実行が重なります。そこで効くのが、NVLink scale-up、推論エンジン、scheduler、prefill/decode分離、通信と計算の重ね合わせです。
NVLink scale-upは大きなMoEとKVキャッシュで効く
根拠
NVIDIA Docsは、Blackwell世代のfifth-generation NVLinkがGPUあたり最大1800 GB/sを提供し、GB300 NVL72では72 GPUsがfully connected L1 Domainを形成できると説明しています。さらに、各GB300 NVL compute tray/nodeは4 Blackwell Ultra GPUsと2 Grace CPUsを含む構成です。
AgentPerfのようなagentic workloadでは、1回ごとの短い応答だけでなく、長いcontext、繰り返されるturn、MoEのexpert実行、KV cacheの保持が問題になります。GPU間通信が遅いと、巨大モデルを分割しても待ち時間が増えます。NVLink scale-upは、その待ちを減らすための基盤です。
注意点
NVLinkがあるだけで速くなるわけではありません。モデル分割、parallelism、KV cache strategy、batching、scheduler、prefill/decode分離、network、storage、CPU側の処理が揃って初めて数字になります。導入前には、ベンチと同じような最適化が自社構成で使えるかを確認する必要があります。
TensorRT LLM、Dynamo、vLLM、SGLangは確認リストとして扱う
NVIDIA Blogは、TensorRT LLMがconcurrent agent sessionsの拡大時にも効率を維持する例として、inputs processingとoutputs generationを分けて最適化することを説明しています。NVIDIA Technical Blogは、SGLang、TensorRT LLM、vLLM、WideEP/DeepEP、DeepGEMM、fused MoE、NVLink scale-up domainなどの要素を挙げています。
ここで重要なのは、どの推論エンジンが絶対に最速かをこの記事で決めることではありません。読者が導入前に「自分たちのモデルとSLOで、どのエンジン、どの最適化、どのGPU構成なら再現できるか」を聞けるようにすることです。
確認項目
| 項目 | 導入前に聞くこと |
|---|---|
| disaggregated prefill/decode | 自社のcontext長とoutput長で分離の効果が出るか |
| KV cache reuse | agentのturn間でcacheをどう保持し、失効させるか |
| speculative decoding | 対象モデルで使えるか、品質やcostに影響するか |
| MoE expert parallelism | DeepSeek V4 ProのようなMoEでexpert実行をどう分散するか |
| WideEP/DeepEP/fused MoE | 公表ベンチと同じ最適化が利用可能か |
| observability | TTFT、output speed、queue、tool delayを本番で見られるか |
NVIDIA Dynamoのような推論運用スタックの確認項目は、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-23-dynamo-inference-ai-factory/" rel="noopener">NVIDIA Dynamo導入前チェック</a>で詳しく扱っています。AgentPerfの数字を読むときも、ソフトウェア側の責任分界を外さないことが大切です。
CPU側ツール処理も見落とさない
AgentPerfのMethodologyでは、tool call delaysをシミュレートしています。これはagentic workloadの現実に近づける重要な設計ですが、実環境のtool処理をすべて代替するものではありません。
条件
本番のagentは、検索、DB、SaaS API、ブラウザ、自社ワークフロー、コード実行、承認、ファイルアクセスを呼びます。これらはGPUではなく、CPU、storage、network、外部API、権限管理、rate limitに左右されます。GPU側が速くても、tool結果が返らなければエージェントは待ちます。
確認項目
運用監視では、GPU utilizationだけでなく、次の値も見てください。
- tool callごとの待ち時間と失敗率。
- queue waitとretry回数。
- CPU、memory、storage、networkの利用率。
- vector DBや検索indexの応答時間。
- API rate limitとtimeout。
- 権限エラー、監査ログ、承認待ち。
AIエージェント基盤のUXは、GPUとツールの合算です。AgentPerfの結果を入り口にしつつ、実運用ではend-to-endの観測を前提に置く必要があります。
Vera Rubinはどう扱うか
- 今すぐ導入GB300 NVL72 / H200 / クラウドGPU
現在借りられる、または買える構成で、自社SLO、価格、運用責任を確認する。
- 次期更改Vera Rubin
提供時期、調達枠、互換性、クラウド対応、推論エンジンの成熟度を追う。
- 先行PoC自社agent workload
ログ採取、SLO設計、ツール遅延、推論スタックを先に検証する。
将来基盤の期待値と、公開済みベンチの確認済み数値は分けて扱います。
NVIDIAはVera Rubin Platformについても、agentic AIとreasoningに向けた次世代基盤として情報を出しています。NVIDIAのVera Rubin Platformページでは、Rubin GPUのTransformer Engine、最大50 petaFLOPSのNVFP4 inference、sixth-generation NVLink、72 Rubin GPUsと36 Vera CPUsを含むVera Rubin NVL72が説明されています。
ただし、この記事の主役はGB300 NVL72のAgentPerf初回結果です。Vera Rubinは次に見るべきロードマップであり、今回の20倍や61.4K per MWの公表値と同じ確度で混ぜるものではありません。
Vera Rubinは将来期待として別枠にする
根拠
NVIDIAのVera Rubin Platformページは、agentic AIやreasoning、tokens per watt、cost per token、NVLink 6、Vera CPU、Rubin GPU、BlueField、ConnectX、Spectrum-X/Quantum-X800などの文脈で次世代基盤を説明しています。ページ上ではBlackwellとの互換や、より大きなAI factoriesへの拡張も打ち出されています。
注意点
将来基盤の説明には、available timing、partners、価格、供給、実際のクラウド構成、ソフトウェア成熟度が関わります。ベンチで確認済みのGB300 NVL72のAgentPerf結果と、Vera Rubinの期待値を同じ表で単純比較しないでください。
導入判断では今のSLOと次の更改時期を分ける
今すぐAIエージェント基盤が必要なチームは、GB300 NVL72、B300/Blackwell Ultra、H200、クラウドGPU、既存オンプレのどれでSLOを満たすかを見ます。2026年後半以降の大規模更改を計画しているチームは、Vera Rubinの供給時期、クラウド提供、既存コードや推論エンジンの移行性を追います。
評価基準
| 判断 | 見ること |
|---|---|
| 今すぐ導入 | 現在借りられる/買える構成、SLO、価格、運用責任 |
| 次期更改で検討 | Vera Rubinの提供時期、調達枠、互換性、クラウド対応 |
| PoCを先行 | 自社agent workload、ログ採取、SLO設計、推論スタック検証 |
| 待つ判断 | 既存基盤でSLOを満たしており、更新時期が近いか |
次世代を待つこと自体は悪くありません。ただ、待つ理由が「次が強そう」だけだと、現行のagent UXや運用課題を見落とします。今のSLOで困っているのか、次の更改時期まで待てるのかを分けて判断してください。
導入前チェックリストとして何を聞くべきか
セキュリティ、サポート、障害時責任、データ所在地は、性能とは別の条件として確認します。
AgentPerfの数字をRFPや稟議に入れるなら、数字そのものより質問を整えるほうが役に立ちます。ベンダーやクラウド事業者に対しては「AgentPerfで何位か」ではなく、「自社のSLOと似た条件で、どの構成なら何agentを支えられるか」を聞きます。
ベンダーやクラウド事業者に聞く項目
確認項目
| 領域 | 質問 |
|---|---|
| モデル | DeepSeek V4 Pro以外の自社候補モデルでも同じSLOを満たすか |
| SLO | P25 output speed、P95 TTFT、concurrent agentsをどう測ったか |
| GPU構成 | GB300 NVL72、B300 x8、H200 x8など、実提供構成は何か |
| 推論エンジン | TensorRT LLM、Dynamo、vLLM、SGLangなど何を使うか |
| 最適化 | KV cache reuse、disaggregated prefill/decode、speculative decodingを使えるか |
| 電力 | per MWはaccelerator powerか、施設全体か |
| 価格 | on-demand、reserved、private contract、support込みのどれか |
| 運用 | 障害、rollback、observability、security、data boundaryを誰が担うか |
評価基準
良い回答は、ベンチ値と実提供構成の差分を明確にします。悪い回答は、20倍やランキングだけを示し、モデル、SLO、電力範囲、推論エンジン、リージョン、価格、運用責任を曖昧にします。
自社で測る項目
確認項目
自社側では、次のログを集めます。
- 実promptとcontext lengthの分布。
- 1作業あたりのturn数。
- tool callの回数、種類、待ち時間、失敗率。
- output lengthと途中停止の割合。
- cache hit率。
- queue waitとピーク時間帯。
- retry、fallback、human handoffの頻度。
- セキュリティや監査で追加される処理時間。
これらを測ると、AgentPerfのcoding trajectoryに近い部分と、まったく違う部分が見えてきます。近い部分はベンチを参考にしやすい。違う部分は、自社PoCで測り直す必要があります。
注意点
AIエージェント基盤は、導入直後よりも運用開始後に形が変わります。使われるtoolが増え、contextが長くなり、ユーザーが同時に使い、ログや監査要件も増えます。初期PoCの平均latencyだけで本番同時利用者数を決めると、後からSLO違反が見えます。
まとめとして見る4点
今回のAgentPerf初回結果は、NVIDIA Blackwell Ultra GB300 NVL72の強さを示す材料であると同時に、AIエージェント基盤の読み方を変える材料です。
- 20倍という数字は、AgentPerf初回条件、SLO、モデル、推論スタック、電力正規化つきで読む。
- 61.4K concurrent agents per MWは、施設全体の消費電力ではなく、ベンチのpower normalization条件を確認する。
- 自社のSLO、context length、tool delay、concurrent active agentsを先に測る。
- GPUだけでなく、NVLink、推論エンジン、KV cache、prefill/decode、CPU/tool処理、運用監視を一緒に見る。
この4点を押さえると、AgentPerfは「NVIDIAが勝ったニュース」ではなく、自社のAIエージェント基盤を設計するための質問表になります。
次に読むなら
参照した主な情報源
- NVIDIA Blog, "NVIDIA Blackwell Leads on First Agentic AI Infrastructure Benchmark"
https://blogs.nvidia.com/blog/nvidia-blackwell-agentperf-artificial-analysis/
- NVIDIA Technical Blog, "NVIDIA Achieves Leading Agentic Coding Performance on First Agentic AI Benchmark"
NVIDIA Achieves Leading Agentic Coding Performance on First Agentic AI Benchmark
- Artificial Analysis, "AI Hardware Benchmarking & Performance Analysis"
https://artificialanalysis.ai/benchmarks/hardware
- Artificial Analysis, "AA-AgentPerf Methodology"
https://artificialanalysis.ai/methodology/agentperf
- NVIDIA Docs, "System Hardware & Components – NVIDIA NVL72 AI Factory"
https://docs.nvidia.com/enterprise-reference-architectures/nvl72-ai-factory/latest/components.html
- NVIDIA, "Infrastructure for Scalable AI Reasoning – NVIDIA Vera Rubin Platform"
https://www.nvidia.com/en-us/data-center/technologies/rubin/
確認日: 2026年6月13日 Asia/Tokyo。
更新履歴
- 2026年6月13日初版作成
NVIDIA Blog、NVIDIA Technical Blog、Artificial Analysis、NVIDIA Docsの公開情報を確認しました。
- 公開後AgentPerfの再確認
対象モデル、SLO、結果表、system configurationが更新された場合は、導入判断前に最新版へ戻ります。
AA-AgentPerfは公開直後のベンチであり、導入前には最新のMethodologyとleaderboardを確認してください。
- 2026年6月13日: NVIDIA Blog、NVIDIA Technical Blog、Artificial Analysis、NVIDIA Docsの公開情報をもとに初版を作成しました。AA-AgentPerfは公開直後のため、SLO、対象モデル、結果表、system configurationは導入判断前に最新ページで再確認してください。