Modal、Nvidia Vera CPUを採用へ、サンドボックスのスループットが2倍に
Modalは、社内テストで高負荷時のスループットが最大2倍になったことを受け、Nvidia Vera CPUを採用する。これは、同社がこれまで依存してきたIntelとAMDのプロセッサに対する挑戦となる。スループットとは、単位時間あたりに完了する作業量を指す。この結果は共有コンピューティング能力に関するものであり、すべてのAIタスクが2倍の速さで完了することを約束するものではない。
この違いにより、競争圧力の焦点が明確になる。NvidiaはAIモデルを取り巻く通常のソフトウェア実行を狙っており、そこではIntelとAMDがすでにModal向けのプロセッサを供給している。CPU（中央処理装置）は、汎用的なソフトウェア命令を実行する。AIサービスでは、生成されたコードの実行や、モデル応答の合間に発生する処理も含まれる。
Modalの調査結果は、特定の購買論拠を裏付ける。すなわち、混雑したサーバー上で完了した有用な作業量によってプロセッサを評価するという考え方だ。ただしVeraの導入にはソフトウェア変更も必要であり、Modalは既存のサプライヤーを維持する方針だ。当面の話は、同社の全設備を置き換えるものではなく、有望なワークロード適性を持つ追加のハードウェア選択肢である。
Modal、計画中のサンドボックス展開にNvidia Vera CPUを採用へ
Modalは10月19日のエンジニアリング投稿で、前週にサンフランシスコで初のVeraサーバーを受け取ったと述べた。同社は初期の並行テストにおいて、同等のIntel Granite Rapidsマシンと比べてスループットが最大2倍になったと報告している。サンドボックスのスループットに関する調査結果では、Veraサポート導入の計画を説明しており、全設備への展開が完了したとはしていない。
確認された変更は、顧客テストに裏付けられた計画中のアーキテクチャ拡張であり、本番導入にはなおエンジニアリング作業が必要である。
サンドボックスは、他の活動から隔離した状態でコードを実行する環境である。AIコーディングエージェントにとって、この環境は提案した変更が実行可能な現実に直面する場所となる。モデルは修正案を提示できるが、ソフトウェアは依然としてビルド、実行、結果の返却を行う必要がある。
これは、単一アプリケーション用のプロセッサ選定とは異なるハードウェア判断を生む。クラウド事業者は、無関係な顧客ジョブが共存した際にどのように振る舞うかを考慮しなければならない。望ましいサーバーは、個々のジョブを許容できないほど遅くすることなく、テナント全体の生産的な活動を支える必要がある。
したがって、Modalのテストは将来の運用事業者による証拠として重要である。NvidiaにはVeraを有利に見せる利害がある一方、Modalも別のアーキテクチャを導入した場合の影響を負う。新ハードウェアのサポートには、性能上の優位性が顧客に届く前から作業が追加される。
だからといって、Modalが独立した試験機関になるわけではない。その結果は、選定したワークロードと運用上の優先事項に左右される同社の測定値である。それでも、互換性対応に取り組むという決定は、孤立したベンダーのデモンストレーションよりも、この結果に大きな商業的意味を与える。
導入に関する表現には注意が必要だ。サーバーの受領、評価の完了、サポート計画の発表、通常の顧客トラフィックへの対応は、それぞれ異なる段階である。これらを、VeraがすでにModalのサービス全体を稼働させているという単一の主張にまとめるべきではない。
同様に、スループットの優位性は、すべての顧客に同一の改善をもたらすことを示すものではない。プロセッサ時間をほとんど消費しないワークロードもある。一方で、外部サービスを待つ時間が長いものもある。ハードウェアによる効果が利用者に届く度合いは、ジョブのどの部分が実際にプロセッサに依存するかによって決まる。
したがって有用な問いは、Nvidiaが突如として最速のCPUサプライヤーになったかどうかよりも狭い。Veraが、許容可能な応答時間の下で、ソフトウェアとハードウェアのサポート範囲を拡張するに足る追加容量をModalにもたらすかどうかだ。
この問いが、本記事の主な競争線を形作る。すなわち、Modalが確立しているIntelとAMDのインフラに対するNvidiaの新たな選択肢である。ベンチマークはこの競争を始めるが、運用上の価値を決めるのは展開経験となる。
AIエージェントはモデル呼び出しの間にあるプロセッサへ圧力をかける
AIエージェントは、モデルが次の命令を生成した後も有用な作業が続くため、CPU購入の判断を広げる。
AIエージェントとは、目標に向けた手順を選択・実行するためにモデルを利用するソフトウェアである。その進行はモデルの判断と、それを実行するシステムの両方に依存する。いずれか一方の改善も、完了を制限する作業に対処する場合にのみ効果をもたらす。
例として、コーディングタスクを考えてみよう。エージェントは変更を提案し、テストを実行し、失敗を読み取り、アプローチを修正する。生成された回答は中間段階にすぎない。エージェントが利用できるフィードバックを周辺ソフトウェアが提供するまで、タスクは完了しない。
これは、並列性の高い計算を高速化するGPU（画像処理装置）の役割を損なうことなく、プロセッサ性能を重要なものにする。ハードウェアのカテゴリはプロセスの異なる部分を支える。モデル計算を高速化しても、必要なソフトウェア実行を待つ時間をなくすことはできない。
Nvidiaの7月のエージェントワークロード分析は、高負荷時に持続するCPU性能がAIサービスの進行に影響すると論じている。これはModalの結果を独立して確認するものではなく、ベンダー側の主張である。その関連性は仕組みにある。逐次的な依存関係により、CPUの遅延はCPU自体を超えて重大な影響を持ち得る。
IntelとAMDへの圧力は、買い手が比較をどう定義するかから生じる。購入基準が、稼働中のサーバー上で完了したエージェント作業を重視する場合、一般的なプロセッサ仕様は補助的な証拠となる。それだけで判断が決着するわけではない。
たとえばコア数は、利用可能な実行リソースを示す。しかし、依存関係を持つ多様なタスク群がどれほど速く完了するかを自動的に明らかにするものではない。買い手はなお、実際のアプリケーションと周辺プラットフォームの振る舞いを観察する必要がある。
同じことは、見出しを飾るベンチマーク勝利にも当てはまる。結果が商業的に説得力を持つのは、顧客が認識するサービス上の制約に結び付くときだ。追加容量は、それが別のボトルネックを生んだり、サービス品質を損なったりせずに利用できる場合に最も重要になる。
Modalにとって潜在的な利点は、顧客のエージェントを支えるインフラに関係する。開発者にとって重要なのは、他の利用者が活動している際にもジョブが確実に完了するかどうかである。エンタープライズの買い手にとっての問題は、利用が拡大してもサービス容量が予測可能であり続けるかどうかだ。
これらの利害は重なり合うが、同一ではない。運用事業者は、個々の顧客体験を直ちに変えることなく、需要を受け止める余地を拡大できる。顧客も、どのプロセッサが改善をもたらしたかを知らずに、応答性の向上を体験することがある。
この分離は、安易な誇張を防ぐ。NvidiaがCPUとして追加の検討対象を得たからといって、すべてのAIアプリケーションがVeraを必要とすることにはならない。これは、エージェント実行が、従来は要件を満たしていたハードウェアをクラウド事業者が再考する別の理由を与えることを示している。
その結果として生じる競争上の需要は具体的だ。既存サプライヤーは、代表的で稼働中のシステムにおいて魅力を維持する必要がある。Nvidiaは、選定された評価での優位性が、信頼できるサービスへの移行後も維持されることを示す必要がある。
Nvidia Veraベンチマークは競合状態における有用な作業を検証する
Modalが公開しているAgentless Agent Benchは、単純な「2倍高速」という見出しでは欠けている重要な方法論上の詳細を示している。これは、参照解を備えた50件の選定済みTerminal-Benchタスクを使用し、モデル応答時間とネットワーク活動を除外する。実行は、その検証器に合格した場合にのみ完了として数えられる。
Nvidia Veraベンチマークが検証するのは、定義された実行ワークロードであり、自律エージェント全体の知能や速度ではない。
参照解は、タスクを完了するための既知のコマンドを提供する。モデルの意思決定プロセスを除外することで、それらのコマンドを実行するマシンを切り分けやすくなる。次に検証によって、実行が単に早く終了したのではなく、許容可能な結果を生んだかどうかが確認される。
リポジトリは、直列テストと並行テストの両方を説明している。直列テストではタスクを個別に実行する。並行テストでは複数のタスクがマシンのリソースを競い合う。これらのアプローチは異なる問いに答えるため、結果を同等に扱うべきではない。
直列結果は、競合するベンチマークジョブからの干渉なしに実行特性を把握するのに役立つ。並行結果は、リソースを共有する必要があるときに何が起こるかを調べる。あるプロセッサは前者の条件では一般的に見えても、後者では魅力的になる場合がある。
ここで競合が重要になる。競合とは、稼働中のタスクがメモリアクセスや実行能力などの共有リソースを奪い合う状態を指す。個々のタスクが単独では合理的に動作していても、進行を制限し得る。
したがって、Vera vs x86の比較には運用条件を付す必要がある。ここでx86とは、議論されているIntelおよびAMDシステムが使用する命令ファミリーを指す。意味のある主張は、命令ファミリーの普遍的な順位ではなく、高負荷時のテスト済みワークロードに関するものである。
サーバー運用事業者は、スループットとレイテンシ、すなわちタスクの完了に必要な経過時間も区別する必要がある。高いスループットは有用だが、無制限の遅延を許容すれば、この測定は商業的に誤解を招くものになる。容量には応答性に関する基準も伴う必要がある。
共有サービスが全体としてより多くのジョブを完了する一方で、一部の顧客がはるかに長く待たされる状況を想像してみよう。総スループットは改善するが、対話型の作業には適さないサービスになる可能性がある。買い手には、その可能性を認識できるだけの詳細が必要だ。
ベンチマークの検証要件は、未完了または不正確な実行によって結果が水増しされるべきではないという別の懸念に対応している。ただし、これらの選定された検査に合格しても、より広範なモデル精度が立証されるわけではない。参照解は、エージェントの推論品質を決める意思決定プロセスそのものを除外している。
事前構築された環境も範囲を規定する。測定前にソフトウェアを準備することで、セットアップによる干渉を減らし、実行を切り分けやすくなる。新しい環境の起動や依存関係の取得時に顧客が遭遇する、あらゆる遅延を測定するものではない。
これらの選択は、対象を絞ったハードウェア実験としては妥当である。結果が、すべてのエージェント挙動のエンドツーエンド指標として提示された場合にのみ問題となる。焦点を絞ったベンチマークは、焦点を絞った結論を支えるべきだ。
Nvidia Veraベンチマークは、テスト設計を検証できるため、さらなる評価を行う有用な根拠となる。公開されたハードウェアと設定で結果を再現すれば、その説得力は高まる。実際のサービストラフィックへ実験を拡張すれば、異なるものの同様に必要な問いに答えられる。
Vera vs x86には別アーキテクチャをサポートするコストも含まれる
VeraはArmを使用しており、Modalの既存設備を支えるx86ソフトウェアターゲットとは異なる命令アーキテクチャである。NvidiaのVera CPU architectureは、このプロセッサを単体サーバーとアクセラレータと組み合わせたシステムの両方に位置付けている。これにより、GPU購入の付属品にとどまらず、汎用実行インフラの直接的な候補となる。
有利なプロセッサー性能は、別のソフトウェア対象をサポートするために必要なエンジニアリングおよび運用の負担を上回らなければならない。
互換性はまず、必要なソフトウェアが正しく実行できるかどうかから始まる。ソースコードの移植性は役に立つが、アプリケーションはライブラリ、ビルドツール、パッケージ化されたコンポーネントにも依存する。移行を成功させるには、稼働環境全体を考慮しなければならない。
コンテナ化によってこの違いがなくなるわけではない。コンテナはソフトウェアと依存関係をまとめるが、実行可能なコンポーネントは依然として基盤となるアーキテクチャをサポートする必要がある。そのため、同じパッケージを異なるマシン間で移動させる際にも、一部を再ビルドまたは置き換える必要が生じる場合がある。
必要な作業は、デモを動かすことにとどまらない。運用担当者には、再現可能なビルド、障害の明確な診断、更新後も期待どおりの動作が維持されるという確信が必要だ。サポート対象のプラットフォームが増えるたびに、エンジニアが理解すべき組み合わせも増加する。
このため、IntelとAMDを維持することには実務上の合理性がある。既存のワークロードは慣れ親しんだ対象を引き続き利用でき、互換性のあるワークロードはVeraの候補となる。このアプローチでは、全面的な変換を求めるのではなく、実証された適合性に応じて導入を進められる。
一方で、利用可能なマシンに作業を割り当てるスケジューリングは複雑になる。混在するフリートでは、各ジョブを実行可能なハードウェアへ送る必要がある。互換性のないマシンに存在する容量は、待機中のジョブを自動的に処理できない。
この制約は、需要が変化する際に重要となる。Veraサーバーの追加は、あるワークロード区分の容量を拡大しても、別の区分では制約を残す可能性がある。したがってフリートを評価するには、利用可能なプロセッサーを単純に合計するだけでは不十分だ。
競争比較では、この非対称性を認識すべきである。IntelとAMDは、すでにModalの導入済みソフトウェア環境をサポートしているという利点を持つ。Nvidiaは、既存の選択肢では不要な作業を正当化できるだけの価値を示さなければならない。
同時に、互換性は別のアーキテクチャに対する恒久的な否定判断ではない。継続的な負担を繰り返し得られる運用上の利益が上回る場合、エンジニアリング投資は価値を持ちうる。閾値は、ワークロードの規模、ソフトウェアの移植性、そして運用者がサポートを維持する能力によって決まる。
だからこそ、Vera対x86はアーキテクチャへの忠誠心を競うものではなく、購入判断として扱うべきだ。命令セットの系統だけで、あらゆる結果が決まるわけではない。プロセッサー設計、メモリー構成、ソフトウェア、導入条件のすべてが結果に影響する。
別のArmベースの選択肢が存在したとしても、それだけでVeraと同じ挙動を再現できるわけではない。命令アーキテクチャを共有することは互換性の関係を示すものであり、同一の性能を意味しない。購入者は、実際に運用する予定のシステムで測定値を確認する必要がある。
移行判断を記録する開発者にとって、検索可能なナレッジベースは、テスト条件や互換性に関する知見を保存する手段となる。この記録は、観測されたハードウェア上の利点と、導入計画の過程で持ち込まれた仮定とを区別するのに役立つ。
Modalの動きは、同社がこうしたトレードオフを検討する意思を示しているため、Nvidiaに機会を与える。同時に、適切なハードウェアは性能目標だけでなくソフトウェア要件も満たす必要があるため、IntelとAMDにも継続的な役割を残す。
2倍という結果は、重要な購入判断をなお未解決のまま残している
Tom’s Hardwareのプロセッサー導入に関する報道によると、ModalはAMDおよびIntelのCPUを維持する予定だ。同記事は、構成の詳細やエネルギー比較に情報の空白があることも指摘している。社内テストをより広範な購入推奨へと読み替える際、これらの制約は重要である。
利用可能な証拠はワークロード固有の機会を裏付ける一方、普遍的な性能または効率の順位付けは未確立のままである。
二次的な見出しではIntelとAMDがまとめて扱われているが、Modalによる最も明確な数値的説明は、同時負荷下でのIntelとの比較を示している。読者は、この結果をすべてのAMDプロセッサーに対する同一の優位性へと暗黙に変換すべきではない。
また、「同等」という表現だけでは比較の全体像を説明できない。購入者は、その同等性が何を意味するのかを知る必要がある。比較可能なプロセッサー資源、類似のシステム容量、あるいは別の選定された制約なのか。定義が異なれば、同じ測定結果でも解釈は変わりうる。
メモリーには特に注意を払うべきだ。メモリー帯域幅は、一定時間内にメモリーシステムを通じてどれだけのデータを移動できるかを示す。ワークロードが繰り返しデータ待ちになる場合、実行能力を増やすだけでは制約要因を解消できないことがある。
この観察は、Veraの正確な優位性を証明するものではなく、もっともらしい評価上の問いを与えるにすぎない。結果をメモリーに帰するには、メモリーの挙動を他のシステム差異から切り分ける証拠が必要である。スループットのグラフだけでは、因果関係の全体的な説明を確立できない。
エネルギー効率には独自の測定が必要だ。より多くの作業を完了するマシンは、より多くの電力を消費する可能性もある。逆に、全体としてより少ないエネルギーで有用な作業を完了する可能性もある。対応する電力データと定義済みの測定期間がなければ、スループットだけからどちらの結論も自動的には導けない。
商業的な効率はさらに広い概念である。運用者は、電力に加え、調達、導入、サポート、利用率を考慮しなければならない。公表された結果のどれも、顧客がサービス料金の同程度の削減を受けることを確立していない。
信頼性も比較に含めるべきである。管理された実行でより速く完了したとしても、保守時の挙動、障害復旧、より大規模な導入における一貫性は分からない。こうした要素は、測定された容量のうちどれだけが信頼できる顧客向け容量になるかに影響する。
ネットワーク遅延やモデル遅延を除外することには、方法論上の緊張関係がある。除外すればプロセッサー比較はより明確になる。一方で、その結果がエージェントの総完了時間をどれほど直接的に予測できるかは限定される。
リモート応答が支配的なアプリケーションでは、CPUの改善によって短縮できる時間は少ない。ローカル実行が支配的なアプリケーションには、この結果を調査するより強い理由がある。したがって、同じハードウェア上の知見でも、顧客ごとに異なる重要性を持ちうる。
これはベンチマークを無効にするものではない。コンポーネントを分離してその寄与を理解することは、通常の手法である。誤りとなるのは、アプリケーション自体を測定せずに、コンポーネントの測定上の向上をアプリケーション全体へ適用することだ。
競合各社の世代交代は、さらに別の変動要因を生む。導入判断では、関連する提供スケジュールで入手可能なシステムを比較すべきである。導入済みの1台のマシンに対する結果だけで、同じサプライヤーの後継製品との結果まで決まるわけではない。
懐疑的な結論は具体的だ。Modalは同時実行向けにVeraをテストする信頼できる理由を示したが、公開情報はあらゆる購入基準を解決してはいない。これは、導入ニュースを市場全体への判決として扱わずとも、意味のあるものにするには十分である。
導入状況、独立した再現、競合各社の対応を注視する
次に必要な証拠は、報告された実行性能の向上を、利用可能な容量、再現可能な測定、現在の購入代替案へと結び付けるものである。
第一に、明確に定義されたModalの展開を注視したい。サポート発表では、どのワークロードがVeraを利用できるのか、どこで容量が利用可能になるのか、どのような互換性要件が適用されるのかを明らかにすべきだ。こうした詳細は、評価がどのように顧客向けサービスへ転換されるかを示す。
最も強い導入シグナルは、顧客がすでに依存している同じ運用プロセスを通じて、通常のワークロードが問題なく稼働することだ。対象を絞ったプレビューも進展を意味するが、準備状況と規模について裏付けられる結論はより限定的になる。
利用可能になっただけでは、スループットの優位性が持続することは示されない。有用な追跡証拠には、完了時間や実行失敗を含む、代表的な需要下での挙動が記述されるだろう。それにより、ハードウェア上の知見を顧客が認識できる結果へ結び付けられる。
第二に、明確な構成による独立した再現を注視したい。別の評価者は、マシン、ソフトウェア設定、ワークロードの選定、完了ルールを開示すべきだ。これらの条件なしに見出しの数値を繰り返しても、注目度は増す一方で、検証への寄与はほとんどない。
テスト条件を合理的に変えても優位性が維持されるなら、再現はその根拠を強化する。より小さな差であっても有益な情報となる。購入者が、当初の結果がどこまで一般化でき、どこから特定の設定に依存するのかを把握する助けになる。
本番環境の測定はさらに別の層を加える。ベンチマークは問いを切り分けるために雑音を取り除くが、サービスはその雑音が存在するなかで運用されなければならない。どちらの証拠も重要だが、それぞれ異なる目的を維持すべきである。
第三に、IntelとAMDが購入判断にどう答えるかを注視したい。関連する対応は、購入者が実際に入手できるシステムを用い、比較可能なエージェント実行ワークロードで示される性能だ。別のベンチマークでの勝利は文脈を与えても、Modalの知見を直接解決するものではない。
競争上のテストでは、個々のジョブと高負荷のホストの違いも維持すべきだ。単独実行が速くなることには価値がありうるが、それだけで容量の問題に答えるわけではない。同様に、総容量の増加には、許容できる応答時間プロファイルが必要となる。
今後数か月で、これらのシグナルはModalの判断の重要性を広げるか、あるいは狭めるだろう。明確な展開と独立した確認はNvidiaの主張を強める。互換性の制約が続く、またはワークロード固有の結果にとどまる場合は、当初の知見を消すことなく、その影響範囲を限定する。
AIインフラを評価する読者は、まずワークフローの中で時間を消費している部分から確認したい。プロバイダーには、モデル遅延、ソフトウェア実行、共有容量の待機を区別するよう求めるべきだ。すべての性能主張には、テストされたワークロードとハードウェア構成を併記する。ModalがNvidia Vera CPUを採用する際、実行可能な問いは、その選択が利用中のサービスにおける有用な作業へどのように影響するかだ。スループット比を一般的な購入原則として扱う前に、展開状況を追跡し、再現可能な結果を精査し、現在の代替案と比較してほしい。あなたのアプリケーションで重要なのは、個々の実行の高速化、同時実行ジョブ数の増加、それともプラットフォームが混雑している際のより一貫した完了だろうか。
