OCI上のNvidia Vera、単体CPUでXeonとの競争に参入
OCI上のNvidia Veraは、Oracle顧客に単体CPUという選択肢を提供する。一方、別のテストでは、デュアルXeonサーバーの2倍を超えるメモリ帯域幅が報告されている。NvidiaとOracleは10月27日、一般提供開始とともに、AIインフラを数ギガワット規模へ拡張する計画を発表した。ここで重要なのは、プロセッサは独立して利用可能であり、拡張はなお計画段階にあるという点だ。
このベンチマークはTom’s Hardwareによるもので、Oracle Cloud Infrastructure（OCI）ではなく、別個のVeraサーバーをテストしたものだ。これはプロセッサの能力に関する根拠を示すが、Oracleインスタンスでの性能を確立するものではない。本記事は公開されたこの根拠を分析するものであり、独自のハードウェアテストを提示するものではない。
競争の焦点は、AIモデルの応答と応答の間に実行される処理にある。Intel XeonとAMD EPYCのプロセッサは、すでに企業インフラ全体でこうしたサービスを担っている。Oracleの判断により、Nvidiaはこの市場に参入する新たな道を得る。プロセッサ互換性に加え、メモリ移動とアプリケーション実行が調達基準となっていく。
OCI上のNvidia Vera、GPU購入からCPU容量を切り離す
OracleはVeraを独立して展開可能なコンピューティング容量として提供し、Nvidiaアクセラレータのホスティングを超える役割をプロセッサに与える。
CPU（中央処理装置）はアプリケーション命令を実行し、汎用コンピューティング処理を管理する。GPU（画像処理装置）は、AIモデルの学習・運用で一般的に使われる並列ワークロードを実行する。顧客がこれらをまとめて購入する場合でも、それぞれはAIアプリケーションの異なる段階を支える。
両社の単体CPU展開に関する発表では、顧客がCPUとGPUのリソースを独立して拡張できることが明示されている。これにより、モデル容量の増加を必要とせず、より多くのアプリケーション処理を必要とする組織に実用的な選択肢が生まれる。
Vera Rubin NVL72は、CPUとともに発表された大規模なラック構成だ。72基のGPUを、プロセッサ間通信のためのNvidiaインターコネクトであるNVLinkで接続する。単体Veraサービスは、別の購買判断に対応する。つまり、それらのモデルを取り巻くソフトウェアをどこで実行するかという判断だ。
例として、コーディング支援ツールを考えてみよう。モデルが変更案を提示し、実行サービスがテストを行い、アプリケーションが次のモデル応答に向けて結果を返す。モデル自体が別の場所で動いていても、テストサービスはCPUリソースを消費する。
顧客は繁忙期に追加の実行容量を必要とする一方、モデルサービスにはまだ余力があるかもしれない。これらのリソースを別々に購入できれば、インフラを需要により近づけて調整する機会が生まれる。それが効率を改善するかどうかは、アプリケーションの実際のリソース使用状況に依存する。
Oracleの提供開始発表は、計画されている物理的な拡張とも切り分けて捉えるべきだ。数ギガワット規模とは、現在稼働している単体Vera容量の測定値ではなく、想定されるインフラ構築を表す。顧客が直ちに予約できる機器の量を示すものではない。
この違いは、購入者がニュースをどう読むべきかを左右する。一般提供開始は商用オファリングの成立を示す一方、展開規模は供給、建設、顧客導入に関わる。いずれの表現も、それだけでアプリケーション性能を示すものではない。
単体オファリングは、潜在顧客とのNvidiaの関係も変える。チームは完全なRubinシステムの導入を先に決めなくても、サービス用途でCPUを評価できる。その場合、プロセッサは当該サービス固有の要件に基づいて価値を示さなければならない。
これは、アクセラレータの追加導入を判断する場合よりも厳しい比較を生む。購入者は、Rubin GPUと直接通信しないワークロードを含め、既存インフラよりもVeraが自社アプリケーションを適切に処理できるかを問える。
結果として競争の中心となるのは、使い慣れたエンタープライズの問いだ。どのサーバー構成が、許容可能な運用負荷で必要な処理を実行できるのか。NvidiaのAIにおける位置づけは注目を集めるが、プロセッサがどこに適合するかは、通常のアプリケーション挙動によって決まる。
圧力はモデル呼び出しの間にあるサービスにかかる
単体Veraは、AIアプリケーションが次の処理へ進む速さを左右するCPUサービスに競争圧力をかける。
AIエージェントとは、モデル出力を用いてアクションを選択・実行するソフトウェアだ。アプリケーションは情報を取得し、プログラムを実行し、結果を確認し、再びモデルの応答を求めることができる。各アクションには依存関係が生じ、モデルだけを高速化しても取り除けない。
技術的な質問に答える前に、アシスタントが社内文書を検索しなければならないとしよう。その応答は、検索の完了、権限の確認、そして結果がモデルへ届くことに依存する。検索サービス内部で生じる遅延に対し、モデル容量を増やしても効果は小さい。
同じ考え方はコード実行にも当てはまる。モデルはテストをすばやく生成できても、アプリケーションが混雑した実行環境を待つことがある。実行遅延がタスク全体の意味ある割合を占める場合、その環境の改善は有用になる。
Oracleは、こうした周辺サービスを想定するエージェント型CPUワークロードとして挙げている。例にはツール実行、検索、分析、運用アプリケーションが含まれる。これらは想定されるワークロード適合性であり、すべての導入で利益が得られる保証ではない。
直近の圧力は、これらのサービス向けに次のプラットフォームを選定するインフラチームにかかる。アプリケーションが計算、メモリ移動、ストレージアクセス、あるいは別システムの待機のどこに時間を費やしているかを明らかにする必要がある。ボトルネックごとに、適した投資は異なる。
購入者はすでに、自社プロセッサを中心に構築されたソフトウェア、展開手順、運用経験を持っているため、IntelとAMDは引き続き重要だ。その既存投資には実用的な価値がある。競合プロセッサは、別のサポート対象環境を導入する理由となるだけの利点を示す必要がある。
したがって比較は、ベンチマークの順位表を超える。大幅なアプリケーション変更を必要とする高速サービスは、最小限の調整で既存ソフトウェアを動かせるサービスとは異なる導入判断に直面する。
Oracleにも、これらのサービスを慎重に区別する動機がある。顧客に必要なのは、すべてのアプリケーションに単一のプロセッサ推奨を当てはめることではなく、自身のワークロード構成を支えるインフラだ。幅広いカタログは、選択肢と評価作業の両方を増やす。
開発者にとっては、最適化に関する議論の出発点が変わる。ハードウェアを選ぶ前に、チームはアプリケーションのどの部分が有用な結果を遅らせているかを示す根拠を必要とする。そうでなければ、有望なCPUが特定されていない問題への答えになってしまう。
エンタープライズ購入者にとっても結果は似ている。AIインフラの提案では、モデル提供と並んでアプリケーション実行を考慮すべきだ。モデルだけを評価すると、ユーザーが適時かつ完全な結果を受け取れるかを左右するシステムを見落とすおそれがある。
この圧力が最も強いのは、同時に多数のタスクが実行される並行性の下で、周辺サービスがすでに苦戦している場所だ。そこでは、単発のデモンストレーションよりも、継続的な負荷におけるプロセッサの挙動が重要になる。
Vera CPUのメモリ帯域幅は特定のボトルネックを狙う
Veraのアーキテクチャ上の主張は、コア数だけを性能の十分な根拠とみなすのではなく、CPUコアにデータを十分供給し続けることから始まる。
メモリ帯域幅は、システムが一定時間内にメモリから転送できるデータ量を測る。大量のデータセットを繰り返し処理するアプリケーションでは、演算能力を使い切る前にこの限界に達することがある。その場合、データ供給が改善されなければ、処理リソースを追加しても効果は限定的だ。
NvidiaのVeraメモリアーキテクチャの説明では、88コア、176スレッド、最大毎秒1.2テラバイトのメモリ帯域幅が示されている。スレッドは、ソフトウェアが利用可能な処理リソースに作業を分割できるようにする実行経路だ。
このチップは、低消費電力メモリ技術であるLPDDR5Xを使用する。Nvidiaはさらに、プロセッサ全体で一貫した共有データを維持する内部インターコネクトである第2世代コヒーレンシファブリックについても説明している。公表されたバイセクション帯域幅は毎秒3.4テラバイトだ。
これらの帯域幅の数値は、システムの異なる部分を表している。外部メモリトラフィックと内部通信は関連する機能を果たすが、両者の評価値を相互に置き換えることはできない。どちらの仕様も、アプリケーションの完了速度を直接示すものではない。
Vera CPUのメモリ帯域幅は、有用な作業がプロセッサの小さく高速なキャッシュを超えたデータへの反復アクセスに依存する場合に重要になる。キャッシュは、頻繁に使用する情報を実行リソースの近くに保持し、メインメモリから取得する必要性を減らす。
例として、同時リクエストに応答しながら作業用データセットを繰り返し走査する分析サービスを考えよう。こうした走査がメモリ転送を飽和させるなら、帯域幅の追加はスループット向上へのもっともらしい道筋となる。スループットは、一定時間内に完了する処理量を測る。
別のアプリケーションでは、時間の大半をリモートストレージの待機に費やすかもしれない。同じメモリ改善が対処できる遅延の割合は小さくなる。ソフトウェアに付けられた分類ラベルよりも、ワークロード特性が重要な理由はここにある。
Arm互換性も、この評価に含めるべきだ。ArmはVeraが対応するプロセッサ命令アーキテクチャであり、ソフトウェアが実行できる命令を定義する。既存アプリケーションとその依存関係は、性能が有用な比較対象となる前に、互換性のあるビルドを必要とする。
移植性の高い言語で書かれたサービスでも、アーキテクチャ固有のコンポーネントに依存していることがある。データベース拡張機能、セキュリティソフトウェア、コンパイル済みライブラリには注意を払う必要がある。アプリケーションの起動に成功しても、すべての依存関係が同じ最適化経路をたどることを意味しない。
これがNvidiaの機会の中核となる仕組みだ。データ供給と実行の特性が価値あるサービスに適したプロセッサを提供する。これは、すべてのエンタープライズCPUを置き換えるというより具体的な提案だ。
アーキテクチャ上の論拠は、Veraをテストする理由を示す。しかし、ソフトウェアの挙動、展開構成、継続的な利用率が、その能力のどれだけがユーザーに届くかを決めるため、購入判断を確定させるものではない。
Vera対Xeonのベンチマークは明確な境界を伴う優位性を示す
Tom’s Hardwareの結果は、テスト構成におけるメモリ帯域幅の優位性を裏付ける一方、OCI上のアプリケーション性能は未測定のままである。
同誌のサーバーメモリベンチマークは、VeraとデュアルIntel Xeon 6980Pシステムを比較している。配列操作を用いて持続的なメモリ転送を測定するベンチマークであるSTREAM triadで、帯域幅が2倍を超えたと報告している。
テストされたVeraシステムはLPDDR5X-9600メモリを使用していた。Xeonとの比較では、より高い転送速度向けに設計されたメモリモジュールであるMRDIMMを使用し、毎秒8,800メガトランスファーで動作させた。これらの構成の詳細は、結果が適用される範囲を定めるうえで役立つ。
Tom’s Hardwareは、スレッド配置がVeraの帯域幅に大きく影響したとも報じている。同誌は、並列実行スレッドを処理リソース全体に分散する設定であるOpenMPのspreadポリシーを使用した。詳しいテスト構成は、今後公開予定のレビューで示されるとしている。
これらの知見が重要なのは、メーカー仕様を超える測定上の優位性を示しているためだ。ただし、この測定が答えるのは、Veraによってアプリケーション全体が2倍高速になるかどうかよりも限定的な問いである。
サービスは、メモリ処理に加え、ストレージアクセス、ネットワーク通信、シリアル実行を組み合わせることがある。シリアル実行とは、順番に処理しなければならない作業を指す。あるコンポーネントを改善しても、残りのコンポーネントはそのまま残る。
この区別は、特にエージェントに関係する。ワークフローは一時的にメモリ集約型の処理を実行した後、外部ツールをより長く待つ場合がある。プロセッサーのベンチマーク上の位置にかかわらず、総完了時間は両方の段階を反映する。
VeraとXeonの比較には、完全な構成も関わっている。測定結果は、プロセッサー、メモリ、ソフトウェア、チューニングが一体となって生み出したものだ。購入者は、その差のすべてを単一のアーキテクチャ上の機能に帰すべきではない。
スレッド配置は、環境を確認すべきもう一つの理由となる。研究室で有利に働く配置ポリシーが、本番環境では明示的な設定を必要とする可能性がある。物理サーバーを分離されたソフトウェア環境に分割する仮想マシンは、評価すべき別の導入レイヤーをもたらす。
公正な比較では、各プラットフォームで合理的なチューニングを認めるべきだ。競合製品を不適切な設定のままにすれば、ハードウェアの違いだけでなく構成の選択も測定することになる。逆に、結果を維持するために通常とは異なる保守が必要なら、記録すべき運用上の負担が生じる。
公開されたベンチマークは、エネルギー効率の順位を示すものではない。それには、システムが比較可能な作業を行っている間の消費電力を測定する必要がある。帯域幅の結果だけでは、完了したアプリケーションタスクがどれほどのエネルギーを消費するかは分からない。
また、データベース、コンパイル、アプリケーションサーバーのすべてで普遍的な勝者を示すものでもない。同じ言語やデプロイメントフレームワークを共有していても、ワークロードごとに異なるリソースへ負荷がかかる。
したがって、Vera CPUのメモリ帯域幅は、報告された構成内で実証された強みとして注目に値する。次に必要な証拠は、この強みを、購入者が実際に導入できるサービスで再現可能なアプリケーション結果へと結び付けることだ。
Oracleの展開はIntelの余地を残し、導入時の検証を求める
OracleはVeraを追加する一方、Rubinシステム向けにIntelベースの選択肢も維持しており、全面的な置き換えという説明よりもワークロードに応じた選択のほうが説得力を持つ。
計画されているHGX Rubin NVL8構成は、8基のRubin GPU、2基の64コアIntel Xeon 6プロセッサー、4テラバイトのDDR5メモリを組み合わせる。DDR5は、広く使われている世代のサーバーメモリ技術である。この計画中の提供形態は、Veraと並行してx86アプリケーションの経路を維持する。
X86は、ここで扱うIntelおよびAMDのサーバープロセッサーが採用する命令アーキテクチャだ。別のプロセッサーが一部のテストでより強い結果を出したとしても、既存のソフトウェア要件を抱えるアプリケーションにとって、この選択肢の維持は重要である。
Oracleのより広範なinfrastructure roadmapでも、AMDおよびIntelとの継続的な取り組みが示されている。計画中のAMD EPYC E7インスタンスと、Intel Diamond RapidsベースのX14提供形態が挙げられている。これらは、今回の発表によって確立された提供済みの選択肢ではなく、引き続きロードマップ上の項目である。
そのため、競争環境は、Nvidiaが参入して既存CPUが退出するというほど単純ではない。Oracleは、利用可能なプロセッサーとアクセラレーターの組み合わせを拡大している。購入者は、アプリケーション互換性とモデル提供用ハードウェアの選択を切り分けられる。
可用性そのものにも慎重な読み取りが必要だ。Oracleの詳細なVera instance specificationsでは、ベアメタルとFlex仮想マシンの両方を説明している。ベアメタルでは、仮想化された一部ではなく、物理サーバーを顧客が直接利用できる。
説明されているデュアルプロセッサー構成は、176コア、352スレッド、1テラバイトのシステムメモリを提供する。これらのインスタンス詳細は、個々のプロセッサーの仕様と区別しなければならない。
OracleのCPUに関する投稿は一般提供開始を発表している一方で、インスタンスは今四半期に一部リージョンへ展開されるとも述べている。この表現は、特定の顧客が必要な地域で適切な容量をいつ確保できるのかという実務上の疑問を残す。
データ所在地の要件を持つ組織にとって、リージョンに関する確約は重要である。他の場所でプロセッサーを利用できても、特定の管轄区域に制限された導入の問題は解決しない。容量も、単なる評価アクセスではなく、想定するサービスに十分でなければならない。
Oracleはさらに、初期段階で150,000基のCPUを各リージョンで利用可能にすると述べている。この発表にはリージョン別の割り当ては示されておらず、列挙されたすべてのユニットがすでに顧客ワークロードを処理していることを示す証拠もない。
性能に関する主張も、同様に分けて考える必要がある。Oracleは、エージェント型CPU性能が最大80%高速化するというNvidiaの主張を引用しているが、その結果がプラットフォームベンチマークであることも明示している。OCIのインスタンスレベルでの測定ではない。
この開示により、購入者がその主張をサービス予測へどれほど自信を持って変換できるかには限界がある。適切な対応は、想定するインスタンス、アプリケーションビルド、運用設定を一体としてテストすることだ。
移行作業も、この評価に含めるべきである。重要なサービスを移す前に、チームには互換性のある依存関係、デプロイメントイメージ、監視、復旧手順が必要になる。これらの要件はハードウェアを否定するものではなく、信頼性高く利用するために必要な作業を定義する。
最も強い導入根拠は、アプリケーション上の効果と管理可能な運用変更を組み合わせたものだ。顧客が再現できない条件でのみ見える優位性よりも、こうした検証を経ても維持されるプロセッサーの優位性のほうが重視に値する。
スタンドアロンのVeraがより広く採用されるかを示す三つのシグナル
次に必要な証拠は、利用可能な容量、再現可能なアプリケーション性能、初期評価を超えた継続利用を示すものである。
第一のシグナルは、より明確なリージョン別の可用性である。今後数カ月で、購入者はアプリケーションが必要とする場所で、文書化されたインスタンスアクセスを確認すべきだ。再現可能な導入を支える展開は、Veraが実用的なインフラ選択肢であるという見方を強めるだろう。
容量情報は、Oracleが展開する予定のものだけでなく、顧客が実際に確保できるものを説明すべきである。予約アクセス、サービス制限、構成ドキュメントは、ローンチ発表を運用上の意思決定につなげる助けとなる。
第二のシグナルは、独立して再現可能なOCIアプリケーションテストである。これは、互換性のあるソフトウェアビルドと明確に文書化された設定のもと、同等の作業を行うサービスを比較すべきだ。最も有用な結果は、持続的な同時実行負荷の下で、完了した作業量と応答時間の両方を示すものとなる。
飽和状態に近い場面では、応答時間に特に注意を払うべきだ。サーバーは魅力的な平均スループットを報告できても、一部のリクエストは大幅に長く待たされる可能性がある。こうした遅延は、すべてのツール呼び出しの完了に依存するワークフローを持つユーザーに影響し得る。
VeraとXeonの比較では、同一のマーケティング分類よりも同等の作業が重要である。テストでは、メモリ構成、ソフトウェアのチューニング、リソース割り当てを説明すべきだ。そうでなければ、読者は結果がテスト構成を超えて通用するか判断できない。
報告された帯域幅の優位性がメモリ集約型サービスを改善することを示す証拠は、アーキテクチャ上の主張を強める。無関係なボトルネックが支配的な結果は、その主張が適用できるアプリケーションの範囲を狭める。
第三のシグナルは、ワークロードの結果を開示したうえでの継続的な本番導入である。顧客の参加は有益だが、名前の挙がった導入だけでは、性能や運用負荷に関する証拠としては限定的である。アプリケーションとその測定された挙動の説明のほうが、より多くの情報をもたらす。
有用な事例では、サービスを移行した理由、導入後に何が変わったか、どの制約が残ったかを説明する必要がある。また、プロセッサーの効果と、ソフトウェア、ストレージ、アプリケーション設計に同時に加えられた変更を区別すべきである。
適したサービス全体で採用が広がれば、クラウドインフラにおける独立したCPU事業というNvidiaの主張を裏付けることになる。特殊化された導入の限定的な集合に集中するなら、より狭い役割を示すことになる。どちらの結果も、強力なメモリベンチマークの結果と両立し得る。
開発者が今すぐ行うべきことは、アプリケーションにすでに存在するCPU依存の段階を測定することだ。実行が停滞する箇所を特定し、代表的なワークロードを維持し、環境を記録する。これにより、別のプロセッサーを評価する前に有用なベースラインが作られる。
チームは、searchable knowledge baseでこれらの知見を整理し、構成に関するメモをアプリケーション結果と結び付けておける。その目的は、その後の比較で異なる結果が出た際にも文脈を維持することにある。
Nvidia Vera on OCIは、メモリトラフィックまたはCPU実行がすでに有用な作業を制約している場面で評価に値する。まず、ボトルネックが測定済みのサービスから始め、代表的な負荷の下で完全な導入構成を比較する。アプリケーションバージョン、チューニングの選択、リソース割り当てを明示したままにする。繁忙期にも改善が持続するか、チームがサービスを信頼性高く運用できるかを問う。可用性を確定したものと見なす前に、リージョン別の容量に関する証拠を求める。メーカーの主張と独立した測定を分け、それぞれの結果の限界を保持する。有用な購買上の問いは具体的である。このプロセッサーは、チームが再現できる条件下で、アプリケーションが実際に行う作業を改善するのか。
