OCI上のNVIDIA Vera Rubin、マルチギガワット規模へ拡張、CPUの役割も拡大
NVIDIAとOracleは10月27日、OCI上でNVIDIA Vera Rubinの一般提供開始と併せて、マルチギガワット規模への拡張計画を発表した。この発表では、新たなGPU容量に加え、モデル呼び出しの間に発生する処理向けの単体Vera CPUを打ち出している。その意義はクラスターの大型化にとどまらない。アプリケーションの変化に応じて、顧客はこれらのリソースを個別に拡張できる。
OCIはOracle Cloud Infrastructureの略称であり、モデルを呼び出してツールを実行するソフトウェアシステム、すなわちエージェントを構築する開発者に対し、この柔軟性を訴求している。こうしたアプリケーションは、回答の生成と通常のコンピューティング処理を交互に行う。モデル提供能力を増やしても、周辺の処理が自動的に高速化されるわけではない。
中心的な緊張関係は、導入済みコンピューティング容量の拡大と、その容量を生産的に維持することの間にある。Google Cloudはすでに、IronwoodとAxionを通じてCPUとアクセラレータを連携させたインフラを推進している。Oracleの発表は、こうしたシステムレベルの競争をより鮮明にするとともに、NVIDIAのCPU事業をGPUの隣でより目立つ位置へと押し上げる。
OCI上のNVIDIA Vera Rubin、提供開始と拡張計画を組み合わせる
直近の製品投入と計画中のインフラ拡張は、異なる節目を意味する。
NVIDIAとOracleは共同のVera Rubin拡張において、現在の提供状況と将来の規模を区別している。Vera Rubin NVL72システムとVera CPUはOCIで一般提供されている。一方、これらのシステムを用いたOCI Superclustersのマルチギガワット規模への拡張は、依然として計画として示されている。
この区別は、見出しを解釈する読者にとって重要だ。一般提供は商用製品の提供開始を示す。しかし、計画された拡張全体が設置済み、通電済み、確保済み、または顧客ワークロードに供されていることを意味するものではない。
ギガワットは、完了したコンピューティング作業ではなく電力を測る単位である。電力コミットメントを有用なAIサービスへ転換するには、設備、ネットワーク、冷却、ソフトウェア、顧客による導入が必要となる。したがって見出しは、提供済みアプリケーション出力の相応の量を裏付けることなく、意図されたインフラの規模を示している。
ラック自体は、より具体的な基準点となる。NVIDIAのNVL72仕様では、72基のRubin GPUと36基のVera CPUを組み合わせた構成が説明されている。GPU、すなわちグラフィックス処理装置は、モデルのトレーニングと推論、つまりモデル出力を生成するプロセスの中核となる並列計算を担う。
これらのコンポーネントはラック内で連携するが、個別のCPU提供は異なる購買判断に対応する。ツール実行やアプリケーションサービスを運用する顧客には、密接に接続されたモデル提供システムの外側にもコンピューティング容量が必要となる。OracleとNVIDIAは、顧客がCPUとGPUのリソースを独立して拡張できるとしている。
実務上の意味は、顧客がアプリケーションを構成する方法の柔軟性にある。ある段階が混雑したからといって、チームが必ずしもすべてのリソースプールを拡張する必要はない。モデル生成、コード実行、検索、あるいは別の工程のどれに追加容量が必要かを評価できる。
これはアーキテクチャ上の選択肢であり、自動的な効率改善ではない。アプリケーションには依然として、適切なリソースへ処理を振り分け、需要変化に対応するソフトウェアが必要だ。独立したスケーリングは運用者に新たな制御手段を与えるが、その使い方を決めるものではない。
購入者にとって、この発表は可用性と提供について別々の疑問を生む。どの構成を今すぐ入手できるのか。どこで入手できるのか。Oracleは導入期間全体にわたって、どの程度の容量を約束できるのか。
こうした疑問は、拡張計画をどの程度重視すべきかも左右する。大規模な将来の設置規模は、長期的な調達にとって有用な文脈となる。特定の割り当て、サポート対象の構成、導入時期は、エンジニアリング上の判断に向けたより直接的な証拠となる。
エージェントのワークロードが、モデル呼び出しの間のコンピューティングに圧力をかける
この発表は、主にGPU群の規模でAI容量を測るチームに課題を突き付ける。
モデルの応答は、エージェントの仕事の一部にすぎない。アクションを選択した後、アプリケーションはそれを実行し、結果を確認し、次に何を行うかを判断する必要がある。こうした段階では、異なるコンピューティング要件と異なる遅延要因が生じる。
障害が発生したアプリケーションの修復を任されたコーディングエージェントを例に考えてみよう。エージェントはプロジェクトファイルを取得し、モデルに変更案を求め、テストを実行し、その結果を次の判断に戻す。ユーザーには一連のタスクとして見えるが、モデルとテストランナーは異なる作業を行っている。
制約が生成処理にある場合、モデル提供容量の追加は役立つ。しかし、テストが実行環境を待っている場合や、依存関係のコンパイルに時間を費やしている場合には効果が限定される。重要な問いは、どのコンポーネントの仕様が最も優れているかではなく、ワークフローのどこで待ち時間が発生しているかになる。
NVIDIAとOracleは、ツール実行、コードテスト、データ取得を、エージェントを支えるCPU集約的なタスクとして明示的に挙げている。CPU、すなわち中央処理装置は、一般的なアプリケーション命令を実行し、こうした周辺処理の多くを管理する。両社は、単体のVera容量をこれらの段階を個別に支援する手段として位置付けている。
OracleのVera CPU導入では、初期導入として15万CPUという規模が示されている。Oracleは初期顧客へのアクセスについても説明し、OpenAIがエージェント型ワークロード向けにVeraを本番環境へ導入しているとしている。これらはOracleの発信を通じて提示された、サプライヤーおよび顧客側の発言である。
CPU数は、Oracleがこの提供に割り当てる規模を示す。しかし、特定の顧客が何基のプロセッサを確保できるか、どの程度高負荷で稼働させるか、あるいはどれほどのアプリケーションスループットを提供するかは明らかにしない。こうした区別により、導入規模が運用上の証拠の代替となることを防げる。
直近の圧力は、インフラ計画担当者とAIアプリケーションチームにかかる。彼らは、モデルリクエストと、そのリクエストが引き起こす処理とのバランスを理解する必要がある。アクセラレータ数を中心とする調達プロセスでは、そのバランスが十分に検討されないままになる。
だからといって、すべてのエージェントアプリケーションに専用CPU導入が必要というわけではない。一部のワークフローは、外部サービスを待つ時間が大半を占める。また、ツール実行が比較的少ないまま、長いモデル応答を生成するものもある。適切なリソース構成は、アプリケーションの実際の処理手順に依存する。
同じ原則はナレッジワークフローにも当てはまる。AIナレッジベースを検索するアシスタントは、有用な回答を生成する前に関連資料を取得しなければならない。追加の生成容量では、アクセス不能な文書、不足した権限、遅い検索を補うことはできない。
企業の購入者にとって、これはインフラ判断をユーザー体験へと結び付ける。タスクの経路上のどこかで停止すれば、サービスは遅く感じられる。遅延がモデル、ツール、データベース、それらを調整するソフトウェアのどこから生じたかを、顧客が区別することはほとんどない。
したがって、この発表はより広い評価基準を促している。チームは中間段階を含め、インフラが完了したタスクをどのように支えるのかを問うべきだ。これが今回の発表によって生じる圧力である。アプリケーション性能の説明は、導入済みハードウェアの説明と同じほど重要になる。
独立したスケーリングはスケジューリングの問題に対応する
CPUとGPUの拡張を分離しても、アプリケーションがその分離を効果的に利用できる場合にのみ役立つ。
OCI上のNVIDIA Vera Rubinの仕組みは、アーキテクチャの観点では明快だ。モデルが必要とする場面では密接に接続されたリソースをまとめて維持し、需要パターンが異なる周辺タスクには別個のコンピューティング容量を提供する。
NVIDIAのRubinプラットフォームアーキテクチャは、連携したコンピューティング、ネットワーク、ソフトウェアを中心に設計されたシステムを説明している。プロセッサ間のNVIDIAの高速接続であるNVLinkは、モデルコンピューティングシステム内部の通信を支える。この内部接続の目的は、ツール実行ワーカーの別プールを割り当てることとは異なる。
この区別は、よくある誤解を避ける。独立したスケーリングは、NVL72ラック内のすべてのコンポーネントが個別に変化することを意味しない。これは、顧客がアプリケーションインフラ全体で異なるCPUおよびGPUリソースを拡張できることを表す。
コーディングエージェントの例に戻ろう。テスト処理の急増では、モデル需要が比較的安定していても追加の実行ワーカーが必要になる場合がある。別のワークロードでは、コンパイルやテストの増加を伴わずにモデルリクエストだけが増える可能性がある。
固定的な割り当てでは、一方のリソースプールが十分に利用されない一方で、別のプールに待ち行列が発生する恐れがある。独立したプールは、運用者にこの不均衡を調整する手段を与える。得られる効果は、ソフトウェアが制約を認識し、有用な容量を適時に確保できるかどうかにかかっている。
ここで、利用可能なリソースへの作業の割り当てであるスケジューリングが中心的な役割を果たす。アプリケーションは、ツールをどこで実行するか、どのデータを渡すか、いつ結果を返すかを決定する必要がある。作業が効率的に到達できなければ、プロセッサの追加は不完全な答えにとどまる。
データ配置はこの判断を複雑にする。ワーカーには、ファイル、依存関係、認証情報、関連するアプリケーション状態へのアクセスが必要だ。モデル提供インフラから実行処理を切り離すと、ソフトウェアが管理すべき新たな境界が生まれる。
この境界は本質的に欠点ではない。より明確な割り当てと分離を支援できる。しかし購入者は、別個のリソースプールの利点を評価する際、その運用上の影響も考慮すべきだ。
有用な評価では、代表的なタスクを送信から完了まで追跡する。モデル出力の生成、ツール待ち、コード実行、情報取得、失敗したステップの再試行に費やされた時間を記録する。目的は、追加容量が結果を変える箇所を特定することにある。
成功裏の完了も重要だ。失敗するタスクが増えたり、追加の試行が必要になったりするのであれば、実行速度の向上の価値は下がる。意味のある比較では、消費されたリソースを検討する間も、タスクと受け入れ基準を一定に保つ。
これらは、発表で公表された結果ではなく、評価の原則である。両社の効率性に関する主張を支えるために、どのような証拠が必要かを説明している。今回の発表は利用可能なアーキテクチャを示しており、特定のアプリケーションにおける価値は顧客側の測定によって示される必要がある。
ワークロードが時間とともに変化すると、運用上の課題はさらに大きくなる。現在は主に質問に答えるサービスでも、製品更新後にはより多くのアクションを実行するようになるかもしれない。独立したスケーリングは、アプリケーションが運用者に必要な情報を提供していることを前提に、対応の余地を与える。
これにより、CPU提供はGPU投入の単なる付属要素ではなくなる。NVIDIAとOracleがアプリケーションインフラに関与できる新たな領域を生み出す。顧客が恩恵を受けるかどうかは、そのインフラが実際に行う作業にどれだけ適合しているかに依存する。
クラウド各社は完全なAIアプリケーションを軸に競争している
Oracleの発表は、AIモデルを支える汎用コンピューティングを含む、協調型システムをめぐる競争の一部である。
Google Cloudは、アクセラレータとCPUの開発を明確に結び付けているため、有用な比較対象となる。同社のIronwood and Axionに関する発表では、エージェントワークフローに必要な協調について論じられている。IronwoodはGoogleが機械学習向けに設計した専用プロセッサであるTPUであり、Axionは汎用コンピューティングを担う。
その関連性はアーキテクチャにある。Googleはモデルの高速化を、それを取り巻くアプリケーションサービス、データ準備、その他の作業とあわせて説明している。OracleとNVIDIAは現在、Rubinシステムと個別に利用できるVera CPUを通じ、同様の必要性を強調している。
これは、製品や性能が同等であることを示すものではない。両プラットフォームは、プロセッサ、ソフトウェア環境、サービス内容、導入形態において異なる。それでも両社の発表は、共通する購買上の問いを示している。すなわち、完全なシステムがアプリケーションをどれだけ適切に支えられるかという問いである。
Oracleにとって、単体のVera CPUは、NVIDIAアクセラレータへのアクセスという論点を超えて議論を広げる。同社は、モデルサービングと、それを取り巻く実行処理向けのリソースを提案できる。これにより顧客は、自社のエージェントをどこで実行するかを判断する際に、もう一つの構成を評価できる。
NVIDIAにとって、この発表は、統合ラック内での役割を超えて、同社CPUの商業的重要性を拡大する。顧客がVeraを独立した実行サービスに採用すれば、NVIDIAは顧客のコンピューティングアーキテクチャのより大きな部分に関与することになる。
この可能性を、あらゆる環境に当てはまる移行理由と混同すべきではない。既存アプリケーションには、確立済みの依存関係や運用慣行がある。チームは、新しい構成を採用・維持するために必要な作業と比較検討しなければならない。
競争圧力は従来型のサーバー導入にも及ぶ。Veraを検討する購入者は、すでに自社ツールやアプリケーションサービスを実行しているシステムとの比較を求めるだろう。チームは自社ワークロードにおける挙動を理解しているため、既存インフラは実用的な基準線となる。
したがって、最も有力な比較は顧客の既存アプリケーションから始まる。実行プラットフォームを変えることで、タスク完了率、応答性、リソース消費、運用信頼性が改善するかを検討する。コンポーネント単位の優位性は、この判断の一部にしか答えない。
ソフトウェアの継続性も重要である。確立されたモデルサービング環境を持つ企業は、新しい構成が自社のデプロイおよびサポートプロセスにどのように適合するかを考慮する。こうしたプロセスを無視するハードウェア評価は、導入に必要な作業を過小評価する。
このため、競争に関する見方は、裏付けのない勝者宣言とは切り分けるべきである。Oracleのローンチは利用可能な選択肢を広げる。GoogleのCPU・アクセラレータ戦略は関連する文脈を示す。どちらの発表も、すべてのエージェントワークロードでどのプラットフォームが最良の成果をもたらすかを証明するものではない。
より大きな変化は、サプライヤーが顧客に評価を求める対象にある。アクセラレータの仕様は依然として重要だが、それを支える実行環境も同じ議論に加わりつつある。インフラプロバイダーは、各コンポーネントがタスク全体を通じてどのように連携するかを説明しなければならない。
OCI上のNVIDIA Vera Rubinを追う読者にとって、これが最も有用な競争の捉え方である。見出しが示すのは、より大規模なインフラ投資だ。購買判断で問われるのは、特定のサービスの組み合わせが、現在の構成よりも効果的にアプリケーションを支えられるかどうかである。
提供時期とプロセッサ数には重要な未解決の疑問が残る
今回の発表は製品と計画を示したが、顧客の生産性が普遍的に向上することを示したわけではない。
第一の不確実性は、一般提供開始と実際の利用可能性のつながりにある。公開ローンチは、すべての顧客の割り当て、導入場所、提供スケジュールを明らかにするものではない。購入者は、発表を実装計画へ落とし込む前に、これらの詳細を把握する必要がある。
第二は、計画されている数ギガワット規模の展開に関する点である。発表は拡張について説明しているが、見出しだけでは完全な提供スケジュールは分からない。読者は、今後の情報が明らかになるにつれ、意図された規模と稼働中の能力を区別すべきである。
第三は、アプリケーションの成果に関する点である。大規模なCPU導入と新世代GPUだけでは、エージェントが有用な作業をどれだけ速く完了するかは定量化できない。そのためには、明確に定義されたワークロードと、はっきりした比較基準が必要となる。
Oracleの発表には性能に関する主張が含まれるが、独立して評価可能な手法で裏付けられない限り、それらは企業側の主張にとどまる。購入者は、宣伝される改善の背景にある構成、ソフトウェア、ワークロード、測定範囲を検証すべきである。
その測定範囲は、特にエージェントにとって重要である。プロセッサの実行速度を測ることと、モデル呼び出しや外部サービスを含む完全なタスクを測ることは異なる。一つの段階での改善が、ワークフロー全体で同じ改善を示すわけではない。
リソース利用率と顧客価値にも違いがある。稼働率の高いプロセッサが、価値ある作業、再試行、あるいは不要な計算を処理している可能性がある。高い活動量は、受け入れ可能な成果につながる場合にのみ意味を持つ。
逆に、一部のアイドル容量には運用上の目的がある。アプリケーションは、急増、障害、応答時間要件に備えて余力を維持する場合がある。評価では、回避可能な無駄と、サービス上の約束を満たすために確保された容量を区別すべきである。
独立したスケーリングは、意思決定もアプリケーション運用者へ移す。チームは、いつ容量を追加するか、どれだけ保持するか、依存先に障害が起きた場合にどう対応するかを決めなければならない。柔軟性には価値があるが、測定と運用上の判断を必要とする選択肢も増える。
セキュリティも別の側面を加える。生成されたコードを実行するエージェントには、環境とアクセスに対する制御が必要だ。サンドボックス、すなわち隔離された実行環境は、そのコードが到達できる範囲を制限するが、その有効性は周囲の実装に依存する。
顧客は、スループットとあわせて、実行権限、データ処理、障害封じ込めを評価すべきである。不適切なアクセス権を持つ高速なワーカーは、より良い本番システムを生み出さない。これは特に、エージェントが機密情報を取得したり、接続された企業向けツールを通じて操作したりする場合に重要である。
移行は別の問いを提示する。アプリケーションを異なるCPU環境へ移すには、ソフトウェア依存関係とデプロイ互換性を確認する必要がある。必要な作業はアプリケーションに依存するため、広範なローンチ発表だけで、すべての顧客について結論を出すことはできない。
これらの不確実性は、ローンチの価値を損なうものではない。正確に判断するために必要な証拠を示している。両社は明確なアーキテクチャ上の根拠を持つインフラ選択肢を発表したが、そこから得られる運用上の利点は依然としてワークロードに左右される。
したがって、慎重な解釈は具体的である。独立したCPUおよびGPUリソースは、需要の不一致に対処する別の方法を顧客に与える。その選択肢が無駄を減らすか、応答性を改善するかは、アプリケーションレベルの結果によって示されなければならない。
容量へのアクセス、顧客測定、実行ソフトウェアを注視する
次に必要な証拠は、発表されたインフラを、取得可能な容量と完了した顧客ワークロードに結び付けるものである。
第一のシグナルは、より具体的なアクセス情報である。今後数カ月、顧客はサポート対象の構成、導入場所、割り当て条件、拡張の節目を注視すべきだ。これらの詳細により、発表された製品が実用的な容量にどう結び付くかが明らかになる。
より具体的な提供情報は、拡張が短期的な顧客計画を支えるという根拠を強める。アクセスに関する詳細を伴わず、総規模の強調だけが続けば、この点は依然として不明確なままである。
このシグナルは、GPUシステムと単体CPUそれぞれで重要である。一方を採用する顧客が、もう一方を採用する顧客と同じ要件やタイムラインを持つとは限らない。個別の提供情報があれば、独立スケーリングという提案を評価しやすくなる。
第二のシグナルは、完全なワークフローに関する顧客測定である。有用な証拠には、アプリケーション、従来の構成、変更されたリソース、受け入れ基準が記載されるべきだ。また、タスク完了とリソース消費に何が起きたかも説明すべきである。
たとえばコーディングエージェントの評価では、モデル生成だけで終わらせず、実行とテストを含めるべきである。検索アプリケーションでは、その基盤となる情報へのアクセスを含めるべきだ。こうした境界をまたいでユーザーのタスクを追跡すると、比較の説得力は増す。
追加のVera容量が測定された実行上の制約を解消することを示す証拠は、ローンチの中心的な主張を支持する。一方、遅延の大半が別の場所で発生しているという結果は、関連するユースケースを絞り込む。どちらの結果も、購入者がより適切な判断を下す助けとなる。
第三のシグナルは、分離されたリソースプールをより運用しやすくする本番ソフトウェアである。アプリケーションがワーカー割り当て、データアクセス、実行状態、障害をどのように扱うかを注視すべきだ。これらの機能によって、独立したリソースが協調サービスとして機能できるかが決まる。
ハードウェアの選択肢が、ただちに利用可能なアプリケーションアーキテクチャを生み出すわけではないため、このシグナルには注意を払う価値がある。運用者には、作業がどこで待機しているかを理解するための十分な可視性と、対応するための十分な制御が必要である。すべてのコンポーネントが同程度に改善しなくても、より優れた協調は効率性の根拠を強める。
これらのシグナルを組み合わせることで、OCI上のNVIDIA Vera Rubinを現実的に追跡できる。容量開示は提供状況を示す。顧客測定は価値を示す。実行ソフトウェアは、利用可能なコンポーネントを接続する実務を示す。
開発者にとって、この発表は自社エージェントワークフローがどこで時間を費やしているかを確認する契機となる。企業の購入者にとっては、アプリケーションレベルの証拠を求める理由となる。ユーザーにとって重要な成果は、依然として有用な作業を確実に完了するサービスである。
新しいインフラ構成にコミットする前に、代表的なタスクをシステム全体で追跡し、実際の制約を特定する。プロバイダーには、利用可能な容量と計画中の拡張、コンポーネントの主張と測定済みのアプリケーション結果を区別するよう求める。評価には実行、検索、障害、復旧を含める。代替案を比較する際は、ワークロードと受け入れ基準を一貫させる。このアプローチにより、購買判断を顧客が完了させる必要のある作業に結び付けたまま、OCI上のNVIDIA Vera Rubinを公正に評価できる。追加のCPUまたはGPU容量は、あなたのアプリケーションのどの段階を改善し、その改善を示すにはどのような測定が必要だろうか。
