エージェントがGPUを待たせる時間を、CPUで埋めにきた — Vera CPUがOCIで一般提供、だが公表スペックは0件で、数字が揃ったのはIntel Xeonを積むNVL8だけ

NVIDIAとOracleが10月27日、Vera Rubin NVL72とVera CPUのOracle Cloud Infrastructure（OCI）での 一般提供（GA）を発表した^[1]。注目すべきはGPUではなくCPU側である。 発表文が売り込んでいるのは演算性能ではなく、エージェントがモデル呼び出しの合間にやる仕事—— ツールの実行、コードの実行、データの取得 —— が遅いとGPUが待たされる、という問題設定だ^[1]。 ただしNVIDIAは、そのVera CPUについてコア数も動作周波数もメモリ帯域幅も、1つの数値も公表していない。 今回の発表で仕様が揃ったのは、同時に「導入を計画」と書かれたHGX Rubin NVL8だけであり、 そのホストCPUはIntel Xeon 6である^[1]。

1. 一般提供になったもの、「計画」と書かれたもの#

発表は3層に分かれている。読む側がこれを混ぜると、発表の重さを取り違える。

第1に一般提供（GA）になったのは、Vera Rubin NVL72とVera CPUのOCI上での提供である^[1]。 第2に「計画」と書かれたのが、OCIスーパークラスタをVera Rubin NVL72で マルチギガワット規模まで拡張することと、HGX Rubin NVL8の導入である^[1]。 第3に既に動いている実績として挙げられたのが、OpenAIがテキサス州Abileneで 10万基を超えるNVIDIA Blackwell GPUのOCIスーパークラスタ上でGPT-6 Astraを訓練し提供してきた、という一点だ^[1]。

つまり今回示された最大の実数は、Rubin世代のものではない。 10万基超という数字はBlackwellの実績であり、Rubin側は「マルチギガワット規模」という 単位だけの表現で、GPU基数も電力の具体値も出ていない^[1]。 本紙は半導体・GPUの月次総括で 10月27日のRubin NVL72のGAを既に扱っているが、今回の発表本文を通して読むと、 Rubin世代について新しく数字が付いた箇所はNVL8の構成表だけである。

2. 公表された数字と、公表されなかった数字#

発表文に実際に書かれている値だけを並べる。埋められない欄は「—」にしてある。推測で埋めない。

一般提供に入った製品の性能値が1つも無く、まだ「計画」の段階にある製品の構成表だけが詳しい。 この非対称は、発表の性格をよく表している。 GAは調達できる状態になったという事実の告知であって、性能の開示ではない。

3. 数字が揃った1構成のホストCPUは、NVIDIA製ではない#

HGX Rubin NVL8は、Rubin GPUを8基に絞り、x86ベースのサーバ構成に載せる計画の製品である^[1]。 ホストは64コアのIntel Xeon 6を2基、メモリは4TB DDR5、ネットワークは6.4Tbpsの高速RDMAとされる^[1]。 NVIDIAはこの構成の狙いを、「x86ベースのアプリケーションとの互換性を保ったまま、 より小さな8GPU構成で次世代Rubinを採用できるようにする」ことだと書いている^[1]。

ここは素直に読む価値がある。Vera CPUを載せた72GPUラックを最上段に置きながら、 NVIDIA自身が既存のx86資産を捨てずに済む下の段を同じ発表の中に用意した。 72GPUのラックスケールは、電力・冷却・調達単位のすべてがデータセンター側の前提を要求する。 8GPU・x86・4TB DDR5という構成は、その前提を満たせない組織に対する現実的な降り口であり、 だからこそ具体的な数値が必要だったのだろう。

4. 「モデル呼び出しの合間」という問題設定#

発表文のCPU側の論旨は明快である。エージェントは応答を生成するだけでなく、 ツールを呼び、コードを実行し、情報を取得してタスクを完了させる。 そのCPU集約的な処理が遅いと結果が遅れ、モデル呼び出しの間GPUが待たされる^[1]。 NVIDIAはこれに対して、高いシングルスレッド性能で個々のツール呼び出しとコード実行を速め、 高いメモリ帯域幅でコアにデータを供給し続けることでGPUの遊休時間を減らす、と説明している^[1]。

運用面の手当ても併記されている。OCI Kubernetes EngineでCPUとGPUのリソースを独立にスケールさせ、 遊休容量を減らすこと^[1]。そしてOracle Acceleronが、信頼できないAI生成コードを 実行するワークロードにハードウェアベースの隔離を提供すること^[1]。

OpenAI側の言葉も、この文脈に合わせて置かれている。同社計算基盤のCTOであるUday Ruddarraju氏は 「急速に増えているエージェント用サンドボックスのワークロードでコードを実行しツールを動かすために必要な 負荷時性能を、OCI上のVera CPUが提供する」とし、本番投入に入ると述べた^[1]。 別の計算基盤責任者Sreekanth Pothanis氏は、フロンティアモデルの進展に基盤が追いつく必要があると述べている^[1]。 NVIDIAのハイパースケール・HPC担当副社長Ian Buck氏の言は 「AIファクトリーは生産的で、長持ちし、使い回せる（fungible）ものでなければならない」である^[1]。この発表にジェンスン・フアンの言葉は入っていない。

5. フィジカルAIから見ると何が変わるのか#

GPUの話に見えて、ロボット側に直接効くのはCPU側の論点である。 ロボットの実機・シミュレーション両方で、計算時間の大きな部分は行列積ではない。 センサ入力の前処理、座標変換、衝突判定、プランナ、ミドルウェアのノード間通信、 シミュレータの1ステップ進行 —— いずれもシングルスレッド性能とメモリ帯域幅に素直に効く領域で、VLAの推論そのものより、その周りの工程がボトルネックになる場面は珍しくない。 発表文が書いている「ツールの実行・コードの実行・データの取得でGPUが待たされる」という構図^[1]は、 ロボット側の制御ループと工程構造がほぼそのまま同じである。

もう1つは隔離の話だ。信頼できないAI生成コードをハードウェアで隔離するという要件^[1]が、 クラウド側の商品説明に明記されたこと自体が本紙にとっての論点である。 モデルが書いたコードを人が読まずに実行する運用は、画面の中なら失敗がプロセスの終了で済む。 同じ構造を実機のエンドエフェクタに繋ぐと、 失敗は物理的な動作として外に出る。本紙はエージェントへの判断の委譲で この境界を扱ったが、隔離がソフトウェアの約束からハードウェアの機能へ降りてきた流れは、 自律機械の運用条件を考えるうえで押さえておく価値がある。

一方で、今回の発表にロボティクスの記述は一切無い。 Isaac SimもGR00Tも世界モデルも出てこない。 これはクラウド事業者向けの訓練・推論・エージェント基盤の発表であり、 ロボット学習への効き方は本紙の読みであって、NVIDIAの主張ではない。 机の上の側の動きはDGX Stationとロボット向け参照ワークフローに、 供給制約の側はHBM不足に分けて扱っている。

6. 発表者自身が付けた但し書き#

見落とされがちだが、Oracleは自社の記述に対して明示的な留保を付けている。 「前述の内容は当社の一般的な製品方向性を示すことを意図したものであり、 情報提供のみを目的とし、いかなる契約にも組み込まれない。いかなる資料・コード・機能の提供を確約するものでもなく、 購買判断の根拠にすべきではない」という文言である^[1]。 記事の情報は2026年10月27日時点のものであり、Oracleは更新義務を負わないとも書かれている^[1]。

この留保が直接かかるのは、GAになった部分ではなく「計画」の部分だ。 すなわちマルチギガワット規模への拡張とHGX Rubin NVL8の導入である^[1]。 本紙が本文で「計画」と「一般提供」を分けて書いたのは、この但し書きがあるからである。 NVIDIA側も同様に、成長・性能・提供時期に関する記述が将来予想であり、 製造を第三者に依存すること、技術開発と競争の影響を受けることを列挙している^[1]。

7. 本紙の見方#

この発表の実質は、AIファクトリーの採算の話である。 GPUが遊休すると、償却と電力はそのまま走り続ける。 NVIDIAとOracleが並べた手札 —— Vera CPUによるCPU側の高速化、 CPUとGPUを独立にスケールさせるKubernetes、x86に降りられるNVL8、世代をまたぐCUDAの継続最適化^[1]—— は、どれもすでに買った設備の稼働率を上げるための道具として並んでいる。 Buck氏の「fungible（使い回せる）」という語の選択は、その文脈を正確に言い当てている^[1]。

だから本紙は、この発表を性能競争の一歩としては読まない。性能値が無いからである。 読むべきは、計算基盤の競争軸がピーク性能から遊休時間の削減へ移ったことの確認であり、 その移動はロボット側の計算設計にもそのまま当てはまる。 Vera CPUが実際に何をどれだけ速くするのかは、第三者の実測が出てから書く。