Arm AGI CPUベンチマークがAMDに圧力、ただし1.99倍の優位性はモデル算出
Armは、新プロセッサが選定された7つのワークロードで、AMDのEPYC 9755よりラック当たりでほぼ2倍の仕事を完了できると主張している。Arm AGI CPUベンチマークでは、実測したチップの結果をサーバー電力の前提に基づいてスケールし、平均で1.99倍の優位性を報告した。
この見出しだけを見れば、AMDの決定的な敗北のように聞こえる。しかし、基礎となる結果はより限定的な内容を示している。Armのチップ当たりの平均優位性は1.20倍であり、大幅なラック優位性の主因は、固定された電力予算内により多くのサーバーを収められる点にあった。
Signal65はArmの委託による分析を通じてテストをレビューした。ただし、別個のハードウェア上で比較全体を独自に再実行したわけではない。また、このベンチマークが評価するのはAIエージェントを取り巻くCPU処理であり、モデルの知能やアクセラレータ推論ではない。
したがって、この結果が重要なのには特定の理由がある。Armはインフラ購入者に対し、エージェント型AI向けCPUをソケット性能だけで最終判断するのではなく、ラック当たりの完了作業量で評価するよう求めている。
Arm AGI CPUベンチマークは戦いの場をラックへ移す
Armの中心的な主張は、すべてのAGI CPUがすべてのAMDプロセッサをソケット単位でほぼ2倍上回るというものではない。
ラックスケール分析では、ArmのプロセッサとAMDの第5世代EPYC 9755を比較した。対象はツール実行、検索、Webサービング、ソフトウェアエンジニアリング、モデルサービング支援に関わる7つのワークロードだった。
Signal65は、Armのモデル上のラック性能比が平均1.99倍だったと報告した。個別のラック結果はワークロードに応じて1.43倍から3.19倍の範囲だった。
7つのテストは、MySQL、NGINX、Milvus、Terminal-Bench 2、SWE-benchのリプレイ、fastText、vLLM CPUオーバーヘッドである。これらはAIモデルを取り巻くソフトウェアパスの異なる部分を表している。
MySQLはトランザクションデータベースのスループットを測定する。NGINXはWebおよびAPIリクエスト処理を対象とし、Milvusはエージェントのメモリと検索に用いるベクトル検索を表す。
Terminal-Bench 2は、サンドボックス化されたコマンドライン環境内で実行される作業を調べる。テストでは72種類のタスクを使用し、128個のコピーを同時実行した。
SWE-benchのリプレイは259件のソフトウェアエンジニアリングタスクを対象とした。ベンチマークは各実行時にモデルに異なる行動を選ばせるのではなく、固定されたワークフローを再生した。
このリプレイ手法は、AIエージェントが非決定的であるため重要だ。同じタスクを要求しても、2回の実行で異なるコマンド、リモートサービスの遅延、またはモデル生成のプランが含まれることがある。
fastTextはCPUによる単語表現の学習を測定した。vLLMテストは、モデルの主要な計算処理を除外しながら、モデルサービングを取り巻くプロセッサのオーバーヘッドを測定した。
この最後の区別は、よくある誤読を防ぐ。vLLMの結果は、AGI CPUがGPUと比べて大規模言語モデルの推論をどれほど速く実行するかを示すものではない。
Armのチップは、チップ単位の比較7件中5件で勝利した。Terminal-BenchではAMDを9%、SWE-benchのリプレイでは13%、fastTextでは97%上回った。
AMDは、確立されたインフラワークロード2件で優位を維持した。EPYC 9755は、実測チップレベルでMySQLでは12%、Milvusでは5%高速だった。
NGINXではArmが1.20倍の比率を示した。vLLM CPUオーバーヘッドのワークロードでは、Armは1.16倍となった。
7つの正規化比率全体で、Armのチップ当たりの平均優位性は1.20倍だった。この結果は意味のあるものだが、ラックレベルの主張に付随する1.99倍という数値よりははるかに小さい。
ラックモデルは、定格サーバー電力を考慮に入れることで比較を変えた。AGI CPUの構成に応じて、2ソケットArmサーバーの消費電力を950〜1,050ワットと仮定した。
AMDシステムには、定格電力1,700ワットの推定値を適用した。いずれの計算にも、プロセッサの熱設計電力だけでなく、メモリやその他のサーバー部品が含まれている。
24キロワットのラック電力予算の約8%をネットワークと配電用に確保した後、モデルではArmサーバーを21台または23台収容できた。同じ予算に収められたAMDサーバーは13台だった。
これにより、モデル上のラック当たりの物理Armコア数は5,712〜5,888コアとなった。AMDラックには3,328個の物理コアが搭載された。
結果として生じた密度倍率により、ラックレベルではすべてのArmワークロードがAMDを上回った。チップ当たりではAMDが有利だったMySQLでさえ、ラック当たりではArmがモデル上1.43倍となった。
Milvusはチップ当たり0.95倍から、ラック当たり1.54倍へと移行した。SWE-benchのリプレイは、ラックモデルの下で1.13倍からちょうど2.00倍へ上昇した。
fastTextは最大の比率を記録した。実測チップ結果の1.97倍は、モデル上のラック結果では3.19倍になった。
これらの数値は、電力に制約のあるデータセンターでは総有効作業量を評価すべきだというArmの主張を裏付ける。一方で、実際に稼働する2つのラックが、直接測定した壁面電力の下でこれらのワークロードを完了したことを示すものではない。
エージェント型AIがCPU処理をより可視化する理由
AIエージェントはアクセラレータの外部に相当量の処理を移し、CPU容量をユーザーに見える体験の一部にする。
従来の生成AIリクエストは、モデル推論が中心に見える場合がある。実運用のエージェントは、計画、検索、ツール呼び出し、検証、状態管理を含むより長い一連の処理を実行する。
GPUや他のアクセラレータは依然として高密度なニューラルネットワーク計算を実行する。CPUは周辺の実行パスの多くを調整し、エージェントが選択する多数のツールを動かす。
コーディングエージェントは実践的な例を示す。リポジトリを調査し、サンドボックスを起動し、依存関係をインストールし、コードをコンパイルし、テストを実行して、失敗を分析する場合がある。
各モデル呼び出しは、次のCPU処理ラウンドを引き起こし得る。数千のエージェントを同時に実行すると、コンテナ、データベース、API、ストレージ、スケジューリングシステムにかかる需要は増幅する。
エンタープライズエージェントは異なるプロファイルを生む。レコードを照会し、内部サービスを呼び出し、アクセス方針を適用し、応答をシリアライズし、ワークフロー状態を更新し、監査ログを書き込むことができる。
検索にはインデックス作成とベクトル検索の処理が追加される。モデルサービングでは、アクセラレータの周囲でトークン化、リクエストスケジューリング、バッチ処理、ストリーミング、キャッシュメタデータ管理が加わる。
Armの評価フレームワークは、この作業をエージェントフレームワークの機能とユースケース固有のツールに分けている。また、コンポーネントベンチマークとエンドツーエンドのタスク測定も分離している。
コンポーネントテストは、プロセッサの挙動を切り分けるのに役立つ。エンドツーエンドテストは、より高速なコンポーネントがより高速またはより信頼性の高い完了タスクにつながるかを示す。
どちらの手法も単独では十分ではない。特にモデルのレイテンシが支配的な場合、プロセッサはデータベースベンチマークで優位でも、エージェントの総ワークフローを短縮できない可能性がある。
エンドツーエンドの結果は、性能差の原因を隠すこともある。異なるモデル、ネットワーク、ツール、またはエージェントの判断が、根底にあるプロセッサの差を上回る場合がある。
Armは、こうした手法の橋渡しの一つとして、再生可能なエージェント軌跡を提案している。軌跡はエージェントセッション中に生成された操作を記録し、各システムで同じ順序を実行する。
この技術は、モデルの判断によるばらつきを低減する。また、両プロセッサに同等の作業ストリームが与えられるため、比較の再現性も高まる。
ただし、リプレイはライブシステムの一部を取り除く。測定するのは、インフラが所定の経路をどれほど速く実行するかであり、完全なエージェントスタックのどちらがより良い経路を見つけるかではない。
この境界は、推論と計画というラベルに慎重さが必要な理由を説明している。関連するテストが測るのは、それらのワークフローに対するCPU支援であり、機械推論の質ではない。
同じ注意は並行性にも当てはまる。より多くのエージェント環境を起動できるサーバーが、持続的な利用時に応答時間が崩壊するなら、自動的に優れているとは言えない。
Armの方法論は、応答性を保ちながら完了した有用な作業を重視する。この枠組みは、スループットをデータセンターが直面する物理的制約と結び付ける。
電力供給は、そのような制約の一つとなっている。冷却能力やラックスペースも、チップの入手可能性にかかわらず、事業者が配備できるプロセッサ数を制限する。
この条件下では、ソケット当たりの優位性が必ずしも施設全体で最良の結果を生むとは限らない。中程度に高速なプロセッサでも、対応するサーバーが大幅に多くの電力を消費すれば、ラックスケールでは敗れる可能性がある。
反対に、より効率的なサーバーは、選定されたチップレベルのテストで敗れても、より大きな総容量を生み出せる。ArmのMySQLおよびMilvusの結果は、そのモデル内でこの可能性を示している。
Armは、Fujitsu、Meta、OpenAIの支援を受けてこの方法論を開発した。これらの支援は、より代表性の高いCPU測定への関心を示すが、フレームワークを業界標準にするものではない。
Metaは、実運用のエージェントには、ワークロードがその下のインフラをどのように利用するかについて、より高い可視性が必要だと述べた。OpenAIは、オーケストレーションとツール実行を代表的なベンチマークが必要な領域として挙げた。
Fujitsuは、この取り組みを高性能なArmベースプロセッサの開発と結び付けた。3社の見解はいずれもより良い測定を支持するが、各組織はArmベースのインフラに対する利害も持つ。
フレームワーク自体も、完成したベンチマークスイートではないことを認めている。ワークロードのカテゴリーと測定境界を定義する一方で、スコアリングとより広範な合意は未解決のまま残している。
この区別は不可欠だ。Armは議論を構造化する方法を提案し、その提案に沿ったテストで有利な結果を公表した。
1.99倍の結果は2倍のチップ勝利ではなく密度から生じる
Arm AGI CPUの性能に関する主張は、圧倒的なソケットレベル性能よりも、モデル化された配備密度に大きく依存している。
Armは、すべてのワークロードで同一のハードウェアを利用できなかったため、2つのAGI CPU構成をテストした。Terminal-Bench 2とSWE-benchでは、DDR5-7200メモリ搭載で2.8 GHz動作の128コアチップを使用した。
その他の5つのワークロードでは、DDR5-8000を搭載し、3.2 GHzで動作する136コアAGI CPUを使用した。AMDの比較システムは、DDR5-6400を搭載した128コアのEPYC 9755ソケットを1基使用した。
両プラットフォームは同じベンチマークスクリプトを実行した。ただし、同一のソフトウェア環境で動作させたわけではない。
Armのテストの大半は、カスタムLinux 7.1.3ビルドを備えたUbuntu 24.04を使用した。SWE-benchテストではUbuntu 26.04を使用した。
AMDの主な記録構成では、Ubuntu 24.04とLinux 6.8を使用した。一部の設定もテストごとに異なっていた。
ソフトウェアの違いは、コンパイラの挙動、スケジューリング、ドライバー、アプリケーション性能に影響し得る。そのため、すべての差をプロセッサアーキテクチャだけに帰属させることは難しくなる。
サーバー電力モデルは、もう一つの重要な区別を生む。Signal65とArmは、負荷時の完全な実運用ラックを測定するのではなく、定格値を用いた。
定格電力は依然として容量計画に有用である。一般的な消費電力が低い場合でも、ラックの電気設計や冷却設計を超える機器を事業者は設置できない。
ただし、定格電力はワークロード固有の消費電力と異なる場合がある。あるシステムは特定のアプリケーションでは定格最大値を下回る電力しか消費せず、別のアプリケーションではその値に近づく可能性がある。
実際の消費電力は、メモリ構成、ストレージ、ネットワーク、冷却、電源、ファームウェア、システム管理ポリシーにも依存する。サーバー台数が見出しの数値を左右する場合、これらの変数は重要になる。
メモリの前提は報告された優位性を変化させた。Armの主要モデルでは、ハードウェアスレッド当たり4 GBを割り当てた。
AMDの同時マルチスレッディングは、物理コア当たり2つのハードウェアスレッドを公開する。Armがテストした設計は、コア当たり1スレッドを使用する。
この選択により、モデル化されたAMDサーバーには約2 TBのメモリが、Armサーバーには約1 TBのメモリが与えられた。AMDメモリには336ワット、Armメモリには192ワットを割り当てた。
Signal65は、物理コアごとにメモリを割り当てるシナリオも算出した。その代替案では、AMDの必要メモリ電力は少なくなり、Armの平均ラック優位性は1.99倍から約1.81倍へと低下した。
それでもArmは、モデル上で大きな優位を維持した。この低下は、合理的な容量計画の選択が最終的な数値を大きく変え得ることを示している。
メモリ容量は単なるベンチマーク上の詳細ではない。一部のエージェント導入では、大規模なインデックス、キャッシュ、状態ストア、または同時実行環境を維持する。
より多くのメモリを搭載したサーバーは、より高密度でも容量の少ない構成では効率的にホストできないワークロードを支援できる。したがって、購入者は正規化されたスループットだけでなく、実際に利用可能なシステム容量を比較する必要がある。
AMDのEPYC 9755は、128の物理コアと256スレッドをサポートする。また、汎用、データベース、仮想化、AIホスティングのワークロードで広く利用されるサーバープラットフォームに属している。
ArmのAGI CPUは、より特化した価値提案を狙う。高密度なArmコアと、AIインフラ向けの大容量メモリ帯域およびI/Oを組み合わせている。
この特化によって、どちらかのアーキテクチャが普遍的に優れているわけではない。より良い選択を決める制約条件が変わるのである。
固定された電力上限に直面するクラウド事業者は、ラックあたりの完了ジョブ数を優先するかもしれない。データベースの購入者は、ソケットあたりの性能、ソフトウェアの成熟度、メモリ容量、またはライセンスの挙動を重視する可能性がある。
AIクラスタの運用者は、高価なアクセラレータを常に稼働させられるかを重視する場合がある。CPU側での準備とオーケストレーションが高速化すれば、アクセラレータのアイドル時間を減らせるが、これらのテストはアクセラレータを活用する完全なワークフローを測定していない。
このため、Arm AGI CPUとAMDの比較は、見出しが示唆するほど広範ではない。これは、選定されたCPU可視のタスクと、モデル化された導入シナリオの比較である。
これは総保有コストの調査ではない。公開された結果には、調達コスト、ソフトウェア移行、運用サポート、ネットワーク、施設変更に関する完全な比較は含まれていない。
また、Armを関連するすべてのx86プロセッサと比較したものでもない。AMDにはほかのEPYC構成があり、Intelはエンタープライズおよびクラウド導入でXeonプラットフォームを展開して競合している。
NvidiaのVeraプロセッサは、Armベースの第2の選択肢を加える。別のVeraワークロード調査では、エージェント類似タスクにおいてEPYC 9755に対する強力なコアあたりの結果が報告された。
この調査は電力やサーバー全体のスループットを測定していない。その限定的な結果は、コアあたり、ソケットあたり、ラックあたり、エンドツーエンドの主張を分けて考える必要性を改めて示している。
AMDも、エージェント型AIシステムにおけるCPUの重要性を訴えている。同社のエージェント型CPUに関する主張は、オーケストレーション、データ処理、セキュリティ、アクセラレータ支援を強調している。
したがって本質的な対立点は、CPUが重要かどうかではない。購入者がワークロードをどう定義し、システムをどう正規化し、コンポーネント測定をどう導入判断に変換すべきかにある。
Arm AGI CPUの性能主張が立証していないこと
Signal65はArmの記録と計算を検証したが、そのプロセスは独立した研究所による再実行と同等ではなかった。
Signal65は、Armのテスト実行をリモートで観察した。元のログ、結果ファイル、スクリプト、構成記録を検査した。
別のレビュー担当チームは、自身のコードで計算を再構築した。分析によると、7件すべての結果を0.5%以内で再現したという。
この作業は、レビューされていないベンダーのグラフよりも厳密な検証を提供する。報告された比率が取得された結果とラックモデルから導かれるかを確認するためだ。
それでも、この分析はArmが委託し、テストシステムもArmが提供した。Signal65は同等のハードウェアを調達し、自社ラボで実験全体を独立して繰り返したわけではない。
レビューには構成情報の不足もあった。Signal65が独自に確認できたBIOSおよびメモリ設定は、別のサンドボックス比較で使われたEPYC 9965システムのものだけだった。
AGI CPUおよびEPYC 9755システムについて、すべてのBIOSおよびメモリ設定を独自に検証することはできなかった。この点は、小さな性能差の要因に関する確実性を制限する。
この区別は、差が接近している結果ほど重要になる。97%のfastText優位性が軽微な設定変更で消える可能性は低いが、5%や9%の差はより詳細な検証に値する。
算術平均にも別の制限がある。正規化比率を平均すると、実際の導入でその処理がどの程度頻繁に実行されるかにかかわらず、各ワークロードに同じ影響力が与えられる。
ある企業はデータベーストランザクションを絶えず実行し、fastTextモデルのトレーニングはほとんど行わないかもしれない。別の企業は数千のコーディングサンドボックスを運用し、トランザクション基盤はほとんど持たない可能性がある。
したがって、公開された1.99倍という平均値は、すべての購入者の容量増加を予測するものではない。各運用者は、自身の実行プロファイルに基づくワークロード加重の結果を必要とする。
テストスイートには、確立されたアプリケーションと、新興のエージェント代理指標が混在している。MySQLとNGINXには長い歴史がある一方、リプレイベースのエージェントベンチマークは比較的新しい。
この組み合わせは、エージェントが身近なインフラを呼び出すため有用である。一方で、選定された構成が何に同じ重みを与えるかを決めるため、議論の余地もある。
元の報道は、この結果がエージェント型AI全体での優位性を確立するものではないと指摘した。プロセッサ、ワークロード、構成、そしてArmが開発した手法が、その範囲を定義している。
vLLMの結果には、完全なGPU推論は含まれていなかった。推論および計画のカテゴリーでは、モデルがより正確に推論したかどうかをテストしていない。
ラック計算には、直接測定された24キロワットの導入は含まれていない。ラックインフラ用の容量を確保した後、定格システム電力からサーバー台数をモデル化した。
価格は公開比較の対象ではなかった。アプリケーションのライセンス、移行作業、スタッフ研修、既存の導入ツールとの互換性も対象外だった。
こうした省略はベンチマークを無効にするものではない。結果が裏付けられる範囲を定義するものである。
Armは、文書化された前提条件の下で、テスト対象システムがより高いモデル上のラックスループットを生み出したと合理的に主張できる。しかし、その主張をエージェント型AIにおける普遍的なリーダーシップへと拡大することはできない。
AMDは、チップ単位での2つの勝利と、メモリ前提が及ぼす影響を合理的に指摘できる。だが、それらの点は公開モデル内でのArmの密度上の優位性を消し去るものではない。
最も生産的な解釈は、この二つの立場の間にある。Armは、本番ハードウェアでのより広範かつ独立したテストに値する、もっともらしい仮説を提示した。
その仮説とは、ラック電力と持続的なエージェントツールのスループットが、従来のソケット比較よりも大きな重みを持つべきだというものだ。1.99倍という結果は、その主張における初期のケーススタディである。
購入者にとっては、現在の勝者以上に手法そのものが影響力を持つ可能性がある。共通で透明性の高いスイートがあれば、運用者は同一の境界条件でArm、AMD、Intel、Nvidiaを比較できるようになる。
そのようなスイートには、測定済みのシステム電力、同等のソフトウェア、文書化されたファームウェア、ワークロード単位の重み付け、再現可能なエンドツーエンド検証が必要になる。
また、あらゆる要素を単一の比率に圧縮するのではなく、複数の観点を報告すべきである。コアあたり、ソケットあたり、ワットあたり、ラックあたり、ドルあたりの結果は、それぞれ異なる運用上の問いに答える。
タスクの成功とレイテンシは、インフラのスループットと分けて扱うべきである。より多くのリプレイ済みアクションを完了するシステムでも、モデルやネットワークの遅延が支配的なら、より良いエージェント成果をもたらすとは限らない。
Armのラック主張が成り立つかを決める3つのシグナル
本番ハードウェア、より幅広い競合比較、顧客導入が、Armのモデル上の優位性が運用上の優位性になるかを決定する。
第1のシグナルは、最終的な本番AGI CPUシステムにおける独立テストである。Signal65は、現在の結果が初期システムを反映しており、より広範な追跡調査が計画されていると述べた。
説得力のある追跡調査では、各ワークロード中のサーバー全体の電力を測定すべきである。比較可能なオペレーティングシステム、コンパイラ設定、メモリ容量、ファームウェア、冷却条件を使用する必要がある。
最も強力なテストは、複数のサーバーを実際に搭載し、ラック計算を実験的に検証するものだろう。それにより、密度、ネットワーク、熱特性、持続的利用率がモデル通りに動作するかを示せる。
本番テストが1.99倍の平均値に近い水準を維持すれば、Armの立場ははるかに強くなる。大幅に低下すれば、定格電力に基づくモデル化が導入可能な容量を過大評価していたことを示す。
第2のシグナルは、より幅広いプロセッサ群との比較である。AMD EPYC 9755は重要だが、1つのx86プロセッサが市場全体を代表することはできない。
AMDのより新しい、より高コア数の選択肢は、密度計算を変える可能性がある。Intelは、Webサービング、データベース、検索、ツール実行で異なる性能を示すかもしれない。
Nvidia Veraも、Arm互換コアを用いながら異なるシステム設計を通じてAIインフラを狙うため、直接比較に値する。そのアクセラレータ接続性は、別の導入経路を生み出す。
より広範なテストでは、同じワークロードと透明な採点を使用すべきである。ベンダー固有のベンチマーク選定では、購入者は互換性のない主張を比較することになる。
複数の競合製品に対してArmがラック優位性を維持すれば、その手法は有利な1対1の組み合わせを超えた信頼性を得る。優位性が大きく変動するなら、ワークロード選定のほうが重要な論点になる。
第3のシグナルは、運用データが開示された実際の顧客導入である。Armは、AGI CPUをハイパースケーラーやほかの大規模AIインフラ運用者向けに位置付けている。
公開導入では、移行前後の完了作業量、レイテンシ、電力、利用率を報告すべきである。また、Armアーキテクチャに必要となったソフトウェア変更も説明すべきだ。
運用上の証拠は、ベンチマークが見逃す問題を明らかにできる。これには、依存関係の互換性、可観測性、コンテナイメージの可用性、ワークロード配置、障害復旧、管理者の負担が含まれる。
顧客の結果が最も重要になるのは、持続的な本番トラフィックを扱う場合だ。短時間のデモでは、数千の永続的なエージェントによる需要パターンを再現できない。
2026年10月のArmベンチマーク発表は、ラック規模でインフラを評価する明確な根拠を示している。同時に、エージェントアーキテクチャの変化に合わせて手法も進化しなければならないと述べている。
この認識は適切である。エージェント型ソフトウェアは依然として流動的であり、今日の代表的なツールシーケンスが、明日には時代遅れの代理指標になる可能性がある。
インフラチームは、Arm AGI CPUベンチマークを普遍的な調達判断としてではなく、自社のボトルネックを検討する契機として活用すべきである。
まず、エージェントがどこで時間を費やしているかを追跡する。モデル推論を、検索、サンドボックス起動、ツール実行、データベースアクセス、オーケストレーション、検証から分離する。
次に、それらの段階を実際の制約に対応付ける。クラスタは、電力上限、メモリ容量の制約、アクセラレータの飢餓状態、あるいは許容できないタスクレイテンシに直面しているかもしれない。
このプロセスにより、幅広いベンダーの主張を検証可能なローカルの問いへと変換できる。また、単一のベンチマーク平均が、ワークロード固有の容量計画に取って代わることも防げる。
エージェントインフラを評価するエンジニアリングチームは、ベンチマークのメモ、構成記録、導入上の知見を検索可能なナレッジベースに保管できる。この記録は、ソフトウェアやハードウェアの変更により以前の比較が無効になった場合に価値を持つ。
Armは、出発点を示した。同社のプロセッサは、選定された7つのワークロードで、チップあたり平均1.20倍、モデル化されたラックあたり平均1.99倍を記録した。AMDは依然としてチップ単位の2つのテストで勝利しており、複数の前提がより大きな比率を形作っている。
次の判断は、独立したテスターとインフラ購入者に委ねられる。実測された本番ラックはArmの密度面での優位性を再現するのか、それとも実際のワークロードによって差は縮まるのか。
