AWS Graviton4 ベンチマークまとめ

CPU・SoC

2025.05.01

はじめに
AWS Graviton4 プロセッサのアーキテクチャ概要
ベンチマーク手法と対象ワークロード
1. クラウドワークロード向け CPU ベンチマークの種類
2. ベンチマーク結果解釈の留意点
ワークロード別ベンチマーク結果と分析
価格性能分析
ユースケース適合性と推奨事項
結論

はじめに

Amazon Web Services (AWS) は、クラウドワークロードに最適化された価格性能を提供することを目的として、カスタムシリコンの開発に注力してきました。その取り組みの集大成の一つが、Amazon Elastic Compute Cloud (Amazon EC2) 向けに設計された AWS Graviton プロセッサファミリーです ¹。Graviton プロセッサは急速に普及し、現在では 50,000 を超える顧客が Graviton ベースのインスタンスを利用しています ⁵。本レポートで分析する AWS Graviton4 は、その最新世代であり、パフォーマンスとエネルギー効率の大幅な向上を約束しています ⁷。

Graviton の登場は、データセンターにおける Arm アーキテクチャ (RISC: Reduced Instruction Set Computing) の台頭という、より大きなトレンドの一部です。従来、サーバー市場は x86 アーキテクチャ (CISC: Complex Instruction Set Computing) が主流でしたが、Arm はその電力効率の高さとカスタム最適化の可能性から、クラウドプロバイダーにとって魅力的な選択肢となっています ⁴。AWS Graviton は、この変化を牽引する重要な存在です ⁸。

本レポートは、公開されている英語および日本語の Web サイトからの情報を基に、AWS Graviton4 のベンチマーク結果を深く掘り下げ、データに基づいた分析を提供することを目的としています。具体的には、前世代の Graviton プロセッサや競合する x86 プロセッサ（Intel、AMD）と比較して、様々なワークロードにおけるパフォーマンスと価格性能を評価します。レポートは、アーキテクチャ概要、ベンチマーク手法、ワークロード別分析、価格性能分析、ユースケース適合性、そして結論という構成で展開します。

AWS Graviton4 プロセッサのアーキテクチャ概要

主要スペックと技術詳細

AWS Graviton4 プロセッサは、AWS がクラウドワークロード向けに最適化した最新世代のカスタム CPU であり、そのアーキテクチャは性能と効率の向上に重点を置いて設計されています。

コアアーキテクチャ: Graviton4 は、Armv9.0-A 命令セットアーキテクチャ ⁴ に基づく Arm Neoverse V2 コアを採用しています ⁴。重要な特徴として、各 vCPU (仮想 CPU) が物理コアに直接対応している点が挙げられます ²。これは、Intel や AMD の x86 プロセッサで一般的な同時マルチスレッディング (SMT) とは異なり、vCPU 間のリソース共有を最小限に抑え、より予測可能で安定したパフォーマンスと、コア間の分離強化に繋がる可能性があります ²。
コア数: Graviton4 は、1 ソケットあたり 96 個の物理コアを搭載しています ⁴。これは、前世代の Graviton3 が搭載していた 64 コアから 50% の増加となります ⁸。デュアルソケット構成を採用するインスタンス (例: r8g.48xlarge, x8g.48xlarge) では、最大 192 vCPU までスケールアップが可能です ⁶。
キャッシュ階層: 各コアには 2MB の L2 キャッシュが搭載されており ⁸、これは Graviton3 や Graviton2 のコアあたり 1MB から倍増しています ⁶。これにより、コアが必要とするデータへのアクセス速度が向上し、パフォーマンス改善に寄与します。Arm の資料によれば、ソケットあたり 36MB のシステムレベルキャッシュ (SLC) も搭載されています ¹⁸。
メモリサブシステム: Graviton4 の最も顕著な強化点の一つがメモリサブシステムです。12 チャネルの DDR5-5600 メモリを採用し ⁸、ピーク時で最大 536.7 GB/s のメモリ帯域幅を実現します ⁹。これは、Graviton3 の 8 チャネル DDR5-4800 と比較して 75% もの帯域幅向上に相当します ⁷。このメモリ帯域幅の大幅な向上は、Graviton4 がメモリ律速（メモリ帯域幅が性能のボトルネックとなる）のワークロード、例えば大規模データベース、インメモリキャッシュ、そして多くの HPC アプリケーション（計算流体力学や地震波イメージングなど）において顕著な性能向上を示す主要な要因となっています ⁸。Graviton3 が DDR4 から DDR5 へ移行して帯域幅を改善したのに対し ²⁸、Graviton4 はチャネル数 (8→12) とチャネルあたりの速度 (4800→5600 MT/s) の両方を向上させることで、この飛躍的な帯域幅増強を達成しています ⁸。
セキュリティ強化: セキュリティはクラウド環境において最重要事項であり ⁸、Graviton4 はハードウェアレベルでの強化が施されています。常時有効なメモリ暗号化 (DRAM、Nitro Card 接続、コア間コヒーレントリンクを含む) ⁷、vCPU ごとの専用キャッシュ ⁸、ポインタ認証 (Pointer Authentication, Armv8.3+ の機能) ²⁹、そして分岐ターゲット識別 (Branch Target Identification, BTI) ⁴ といった機能を搭載しています。BTI は、制御フローを乗っ取るタイプの高度な攻撃に対する防御を強化します。これらの機能は、ハードウェアレベルのセキュリティ機能と仮想化オーバーヘッドの削減を実現する AWS Nitro System 上に構築されています ⁵。従来の CPU ではソフトウェアやオプションのハードウェア機能に依存することが多かったメモリ暗号化が、Graviton4 では主要なハードウェアインターフェースに統合され、常時有効化されています ⁸。これにより、設定の複雑さが軽減され、ソフトウェアベースの暗号化と比較してパフォーマンスへの影響が少なくなる可能性があります。この包括的なハードウェアベースのセキュリティ機能は、金融やヘルスケアなど、特にセキュリティ要件の厳しい業界にとって Graviton4 を強力な選択肢とし、コンプライアンス対応を簡素化する可能性があります ⁸。

Graviton3 との比較

Graviton4 は、前世代の Graviton3 からアーキテクチャの多くの側面で進化を遂げています。主な違いは、コアアーキテクチャが Neoverse V1 から V2 へ、ソケットあたりの最大コア数が 64 から 96 へ、コアあたりの L2 キャッシュが 1MB から 2MB へ、メモリチャネルが 8 チャネル DDR5-4800 から 12 チャネル DDR5-5600 へと強化された点です。これらの改良により、AWS は Graviton4 が Graviton3 と比較して、汎用コンピューティング性能で最大 30%、データベースワークロードで最大 40%、大規模 Java アプリケーションで最大 45% 高速化し、メモリ帯域幅は 75% 向上したと主張しています ⁴。一方で、報告されているクロック周波数の向上は比較的小幅です（例: G3 の 2.6GHz に対し G4 は 2.7/2.8GHz）⁹。

表1: Graviton4 vs. Graviton3 アーキテクチャ比較

特徴 (Feature)	Graviton4	Graviton3
コアタイプ (Core Type)	Arm Neoverse V2	Arm Neoverse V1
最大コア数/ソケット	96	64
L2 キャッシュ/コア	2MB	1MB
メモリチャネル数	12	8
メモリタイプ (Memory Type)	DDR5-5600	DDR5-4800
最大メモリ帯域幅 (推定)	最大 536.7 GB/s	(G4比で約 57%)
主要セキュリティ機能	常時メモリ暗号化, Pointer Authentication (PA), Branch Target ID (BTI)	常時メモリ暗号化, Pointer Authentication (PA), BTI (一部)

出典: ⁴

Graviton4 搭載 EC2 インスタンスファミリー

AWS は、Graviton4 プロセッサを搭載した複数の EC2 インスタンスファミリーを提供しており、それぞれ異なるワークロード要件に対応するように最適化されています。

M8g/M8gd: 汎用インスタンスファミリーで、コンピューティング、メモリ、ネットワークリソースのバランスが取れています。アプリケーションサーバー、マイクロサービス、中規模データストア、クラスターコンピューティングなどの幅広い用途に適しています ³。最大 192 vCPU / 768 GiB RAM の構成が可能で ²⁵、M7g インスタンスと比較して最大 3 倍の vCPU とメモリを提供します ²⁵。M8gd はローカル NVMe SSD ストレージを搭載します。
R8g/R8gd: メモリ最適化インスタンスファミリーで、メモリと vCPU の比率が 8:1 です。高性能データベース、インメモリキャッシュ (Redis, Memcached など)、リアルタイムビッグデータ分析といったメモリ集約型ワークロードに最適です ³。最大 192 vCPU / 1536 GiB (1.5 TiB) RAM までスケール可能で ⁷、R7g と比較して最大 3 倍の vCPU とメモリを提供します ⁷。R8g は、Graviton プロセッサ搭載インスタンスとして初めてベアメタルオプション (metal-24xl, metal-48xl) を提供します ⁷。R8gd はローカル NVMe SSD を搭載します。
C8g: コンピューティング最適化インスタンスファミリーで、HPC (ハイパフォーマンスコンピューティング)、ビデオエンコーディング、ゲーム、CPU ベースの機械学習 (ML) 推論など、計算負荷の高いアプリケーション向けに設計されています ³。(提供されている資料では R8g/X8g/M8g ほど詳細なスペック情報は多くありませんが、存在は確認されています ³)。
X8g: 大容量メモリ最適化インスタンスファミリーで、メモリと vCPU の比率が 16:1 と非常に高くなっています。Redis や Valkey などの大規模インメモリデータベース、PostgreSQL, MySQL, MariaDB などの大規模リレーショナルデータベース、EDA (電子設計自動化) ワークロード、リアルタイム分析、メモリ制約のあるマイクロサービスなどに最適です ³。最大 192 vCPU / 3072 GiB (3 TiB) の RAM を搭載可能で ⁶、これは X2gd インスタンスの最大 3 倍の vCPU とメモリに相当します ⁶。X8g は、Graviton4 搭載インスタンスの中で GiB あたりのコストが最も低いとされています ²⁹。

表2: Graviton4 EC2 インスタンス仕様概要

インスタンスファミリー	最大 vCPU	最大メモリ (GiB)	メモリ:vCPU 比	最大ネットワーク帯域幅 (Gbps)	最大 EBS 帯域幅 (Gbps)	主なターゲットワークロード
M8g	192	768	4:1	50	40	アプリケーションサーバー, マイクロサービス, 中規模データストア, クラスターコンピューティング
R8g	192	1,536	8:1	50	40	データベース, インメモリキャッシュ, リアルタイムビッグデータ分析
C8g	(未詳)	(未詳)	(未詳)	(未詳)	(未詳)	HPC, ビデオエンコーディング, ゲーム, CPU ベース ML 推論
X8g	192	3,072	16:1	50	40	大規模インメモリ/リレーショナル DB, EDA, リアルタイム分析, メモリ制約マイクロサービス

出典: ³

ベンチマーク手法と対象ワークロード

Graviton4 の性能を評価するためには、適切なベンチマーク手法を選択し、その結果を正しく解釈することが不可欠です。

クラウドワークロード向け CPU ベンチマークの種類

クラウド環境における CPU 性能評価には、主に以下の種類のベンチマークが用いられます。

合成ベンチマーク (Synthetic Benchmarks): CPU やメモリサブシステムなどの特定コンポーネントに負荷をかけ、純粋な計算能力を測定します。

SPEC CPU 2017: 業界標準として広く利用され、整数演算 (SPECrate/speed Integer) と浮動小数点演算 (SPECrate/speed Floating Point) の性能を測定するスイートです ³⁸。システムのプロセッサ、メモリサブシステム、コンパイラの性能を評価します。
Geekbench: クロスプラットフォーム対応のベンチマークで、シングルコアおよびマルチコアの性能を、ファイル圧縮、画像処理、機械学習といった実世界にインスパイアされたタスクを通じて測定します ³⁹。結果は集約されたスコアとして表示されます ⁴¹。
Coremark: CPU コアのパイプライン性能に焦点を当てた、比較的小規模な合成ベンチマークです ¹⁴。
Stress-ng: システムに高負荷をかけるストレステストツールですが、負荷下での「1秒あたりの偽オペレーション数」などを測定でき、特定の条件下でのスループット指標として用いられることがあります。ただし、結果の解釈には注意が必要です ⁴²。
アプリケーションレベルベンチマーク (Application-Level Benchmarks): 実際のアプリケーションや、その挙動を模倣したミニアプリケーションを用いて、より現実的なシナリオでの性能を測定します。

Web サーバー: Nginx や Apache HTTP Server を対象とし、Apache Bench (AB) や wrk などのツールを用いて、秒間リクエスト処理数 (RPS) やレイテンシを測定します ⁴²。
データベース: PostgreSQL (pgbench など)、MySQL/MariaDB、ClickHouse、RocksDB などのデータベースシステムに対し、秒間トランザクション数 (TPS)、クエリ実行時間 (レイテンシ)、スループットなどを測定します ³。
HPC (ハイパフォーマンスコンピューティング): miniFE (有限要素法ミニアプリ) ¹⁴ のようなミニアプリケーションや、OpenFOAM (計算流体力学) ¹⁴、LAMMPS (分子動力学) ¹⁵、GROMACS (分子動力学) ¹⁷、WRF (気象予測) ¹⁸、Relion (構造生物学) ¹⁸、Incompact3D (流体力学) ¹⁷ といった実際のアプリケーション、あるいは DevitoPRO ²³ のようなカーネルを用いて、シミュレーション実行時間やスループット (例: GROMACS の ns/day) を測定します。
AI/ML 推論: llama.cpp ¹⁹、PyTorch ¹⁰、TensorFlow ³¹ などのフレームワークを用い、主に CPU 上で大規模言語モデル (LLM) などを実行し、1 秒あたりのトークン生成数 (Tokens/sec)、最初のトークン生成までの時間 (Time-to-first-token)、クエリレイテンシなどを測定します ¹⁹。Geekbench AI ⁵³ のような専用ベンチマークも登場しています。
その他: コードコンパイル (LLVM, Gem5, Godot エンジンなど) ¹⁷、暗号処理 (OpenSSL ¹⁶, gcrypt ⁴², XMRig ¹⁷)、データ圧縮 (7-Zip ¹⁷, LZ4 ²¹)、3D レンダリング (Blender ¹⁷)、Java アプリケーション (SPECjbb ³⁸, JMH ⁴²) など、特定の用途に合わせたベンチマークが存在します。

ベンチマーク結果解釈の留意点

ベンチマーク結果を比較・評価する際には、以下の点に注意する必要があります。

構成詳細の重要性: テスト結果は、使用された具体的な構成に大きく依存します。インスタンスタイプ (vCPU 数、メモリ容量、世代、ファミリー例: r8g vs c8g)、OS (例: Ubuntu 24.04, Amazon Linux 2023)、カーネルバージョン (例: Linux 6.8)、コンパイラ (GCC のバージョン、最適化フラグ)、およびテスト対象ソフトウェアのバージョン (データベース、ベンチマークツール、アプリケーション) など、詳細な構成情報を確認することが極めて重要です ¹⁶。これらのいずれかが異なると、結果は大きく変動する可能性があります。
ベンチマークツールと方法論: 使用されたツール (例: Phoronix Test Suite ¹⁶, Apache Bench ⁴², wrk ⁴³) によって測定対象や方法が異なります。テストパラメータ (接続数、実行時間、データセットサイズなど) を理解することも重要です。また、ネットワーク帯域幅などがボトルネックとなり、CPU 本来の性能が測定できていない可能性にも留意が必要です ²⁰。
潜在的なバイアス: ベンダー自身が公開するベンチマーク結果は、自社製品に有利なワークロードが選択されている可能性があります。対照的に、Phoronix、Seeds Std、外道父の匠ブログなどの独立した第三者によるテストは、より客観的な視点を提供することが期待されます ⁷。比較対象が「同一条件」(例: 同じ vCPU 数、メモリ容量) で行われているか ¹²、あるいは「ベアメタル」インスタンス同士の比較か ²¹ も確認すべき点です。
電力消費データの欠如: クラウドインスタンスでは、CPU やシステムの消費電力を直接測定するためのセンサー情報がユーザーに公開されていない場合がほとんどです ²¹。これは、Graviton4 の本来の環境における「ワットあたり性能」という、トータルの効率を評価する上で重大な制約となります。AWS は Graviton の高いエネルギー効率を主張していますが ³、独立した第三者がクラウド環境でこれを直接検証することは困難です。結果として、エネルギーコストを含む真の TCO (総所有コスト) の比較は、AWS の公称値や推測に頼らざるを得なくなります。これは、Arm アーキテクチャの主要なセールスポイントの一つであるエネルギー効率に関する評価を難しくしています。

ワークロード別ベンチマーク結果と分析

収集されたベンチマークデータに基づき、主要なワークロードカテゴリ別に Graviton4 の性能を分析します。

汎用コンピューティングと Web アプリケーション

Web サーバーやアプリケーションサーバーは、クラウドにおける最も一般的なワークロードの一つであり、Graviton プロセッサの主要なターゲットです ³。

性能比較 (vs. G3/x86): AWS は、Graviton4 が Graviton3 と比較して Web アプリケーションで最大 30% 高速であると主張しています ⁴。日本のシーズ株式会社が実施した WordPress 環境での Apache Bench テストでは、Graviton4 (r8g.2xlarge) が Graviton3 (r7g.2xlarge) より 44% 高速であり、さらに Intel Xeon 第4世代 (r7i.2xlarge) よりも 67% 高速という結果が報告されています ⁴²。これは AWS の主張を上回る性能向上を示しています。一方で、外道父の匠ブログによるより広範なベンチマークスイートでは、Graviton4 の Graviton3 に対する平均的な CPU 性能向上は約 19% と報告されており、テスト内容によって結果が変動することを示唆しています ³²。Phoronix が実施した多数のベンチマークの幾何平均では、Graviton4 (64 vCPU) は Graviton3 (64 vCPU) より約 30% 高速、Intel Xeon 8488C (r7i, 64 vCPU) より約 5% 高速でしたが、AMD EPYC 9R14 (r7a, 64 vCPU) よりは約 25% 遅いという結果でした ¹²。
Web サーバーに関する洞察: Nginx は一般的なベンチマーク対象です ⁴³。シーズ社のテストでは、WordPress スタックにおいて特に Apache と MySQL (MariaDB) のコンポーネントで Graviton4 の性能が優れていることが確認されました ⁴²。Arm のドキュメントでも、Apache Kafka、Memcached、Elasticsearch など、Web 関連の様々なソフトウェアで Graviton が性能向上をもたらすことが示されています ⁴⁵。

表3: Web アプリケーションベンチマーク比較 (例: Seeds Std WordPress/Apache Bench)

インスタンスタイプ	メトリック (Metric)	結果 (Result)	R7i 比 (相対性能)	R7g 比 (相対性能)	コストパフォーマンス (RPS/USD)
r8g.2xlarge	秒間リクエスト数 (RPS)	6888.23	1.67x	1.44x	14615
r7g.2xlarge	秒間リクエスト数 (RPS)	4780.38	1.16x	1.00x	11159
r7i.2xlarge	秒間リクエスト数 (RPS)	4117.26	1.00x	0.86x	7780

出典: Seeds Std. ブログ ⁴² (us-east-1 オンデマンド料金に基づく計算)

この表は、特定の Web アプリケーションワークロードにおいて、Graviton4 (r8g) が前世代 (r7g) および競合の Intel (r7i) インスタンスと比較して、性能とコストパフォーマンスの両面で優位性を示したことを具体的に示しています。

データベース

データベースは、性能要件が厳しく、クラウド移行の主要な対象となるワークロードです ³。

性能比較 (vs. G3/x86): AWS は、Graviton4 が Graviton3 比でデータベース性能が最大 40% 向上したと主張しています ⁷。Phoronix による 64 vCPU でのベンチマークでは、ClickHouse、PostgreSQL、RocksDB において Graviton4 が Graviton3 から「巨大な」性能向上を示しました ¹⁶。ClickHouse では Intel Xeon 8488C を上回り、AMD EPYC 9R14 に匹敵する性能を見せ ⁴⁸、PostgreSQL でも Intel Xeon および AMD EPYC と同等の競争力のある性能 (“dancing with”) を示しました ⁴⁸。Tom’s Hardware のレポート (Phoronix データに基づく) でも、PostgreSQL で Graviton4 が Graviton3 より大幅に高速であることが確認されましたが、AMD/Intel よりは遅いとされました。しかし、RocksDB 9.0 では Graviton4 が AMD と Intel の両方を上回る性能を示しました ¹⁷。ClickHouse 社自身のブログでも、Graviton4 は Graviton3 に対して平均 23-30%、特定のクエリでは最大 76% の性能向上を示したと報告されています ²⁰。シーズ社のテストでは、WordPress スタックの一部である MariaDB で Graviton4 が高い性能を示しました ⁴²。SAP HANA Cloud では、Graviton4 は Graviton3 と比較して分析ワークロードで最大 25%、トランザクションワークロードで最大 40% の性能向上が測定されています ⁶。
Amazon RDS / Aurora: Graviton4 ベースの M8g および R8g インスタンスは、Amazon RDS for PostgreSQL, MySQL, MariaDB で一般提供が開始されています ⁶⁰。これらのインスタンスは、同等サイズの Graviton3 ベース RDS インスタンスと比較して、最大 40% の性能向上と最大 29% の価格性能向上を提供するとされています (オンデマンド価格ベース、エンジンやワークロードに依存) ⁴⁷。Amazon Aurora でも Graviton はサポートされています ³。
ワークロード依存性: Graviton4 のデータベース性能は、使用するデータベースエンジンや具体的なワークロードの特性に大きく依存する傾向が見られます。Graviton3 からの大幅な性能向上と x86 との競争力は明らかですが、特に ClickHouse や RocksDB のような特定のエンジンで優れた性能を発揮する一方で、PostgreSQL のような他のエンジンではテストによって評価が分かれる場合があります。これは、Graviton4 の強化されたメモリ帯域幅や Neoverse V2 コアアーキテクチャが、各データベースエンジンの内部実装 (メモリ使用、キャッシング、スレッド管理など) とどのように相互作用するかに起因すると考えられます。したがって、AWS が「データベースで 40% 高速」⁷ といった一般的な主張をする一方で、ユーザーは自身の特定のデータベースとワークロードでベンチマークを実施し、性能を評価することが重要です。

表4: データベースベンチマーク比較 (例: Phoronix Mix – 64 vCPU)

データベース/ベンチマーク	インスタンスタイプ	メトリック (Metric)	結果 (例)	R7i 比 (相対性能)	R7g 比 (相対性能)
ClickHouse	r8g.16xlarge	クエリ/秒	高	> 1.0x	>> 1.0x
ClickHouse	r7i.16xlarge	クエリ/秒	中	1.0x	–
ClickHouse	r7a.16xlarge	クエリ/秒	高	> 1.0x	–
PostgreSQL (pgbench)	r8g.16xlarge	TPS	高	~ 1.0x	>> 1.0x
PostgreSQL (pgbench)	r7i.16xlarge	TPS	高	1.0x	–
PostgreSQL (pgbench)	r7a.16xlarge	TPS	高	~ 1.0x	–
RocksDB (Read/Write)	r8g.16xlarge	オペレーション/秒	最高	> 1.0x	>> 1.0x
RocksDB (Read/Write)	r7i.16xlarge	オペレーション/秒	中	1.0x	–
RocksDB (Read/Write)	r7a.16xlarge	オペレーション/秒	中	< 1.0x	–

出典: Phoronix ⁴⁸, Tom’s Hardware ¹⁷ の結果に基づく定性的な要約。具体的な数値は元記事参照。

ハイパフォーマンスコンピューティング (HPC)

HPC は、科学技術計算やシミュレーションなど、極めて高い計算能力を要求される分野です。

性能比較 (vs. G3/x86): Arm コミュニティブログによるベンチマーク (Graviton4 R8g vs Graviton3E C7gn、vCPU あたり性能比較) では、Graviton4 が HPC ワークロード全体で幾何平均 +24% の性能向上を示しました ¹⁸。個別のアプリケーションでは、OpenFOAM で約 +17%、LAMMPS で +32%、Relion で +41%、WRF で +24% の向上が見られました ¹⁸。これらの向上は、Neoverse V2 コアのマイクロアーキテクチャ改善、クロック周波数向上、そしてコアあたり +16.7% 増加したメモリ帯域幅に起因すると分析されています ¹⁸。さらに、192 コア構成のインスタンス同士 (Graviton4 r8g.48xlarge vs AMD EPYC Genoa c7a.48xlarge) の比較では、Graviton4 が幾何平均で 15.2% 優位であったと報告されています ¹⁸。Phoronix の 64 vCPU でのベンチマークでも、miniFE (有限要素法) や Incompact3D (流体力学) で Graviton4 が Graviton3 から「驚異的な」性能向上を示し、AMD EPYC 9R14 を上回る結果となりました ¹⁷。OpenFOAM では EPYC 9R14 と同等の性能でした ¹⁷。一方、GROMACS (分子動力学) では Graviton4 は Graviton3 から着実な性能向上を見せたものの、EPYC や Xeon の方が高速でした ¹⁷。DevitoPRO による地震波イメージングベンチマークでは、Graviton4 は Graviton3 に対して約 1.8 倍 (Isotropic, Self-adjoint TTI カーネル) および約 1.5 倍 (Fletcher TTI カーネル) 高速でした ²³。EDA (電子設計自動化) の RTL シミュレーションでは、Graviton4 は Graviton3 比で最大 37% 高速であると報告されています ¹⁰。
Arm の HPC における競争力: これらの結果は、Arm Neoverse V シリーズコアが、特にメモリ帯域幅に敏感な主流の HPC ワークロードにおいて、現在非常に競争力が高く、場合によってはリーダーシップを発揮できるレベルに達していることを示しています。HPC 分野における従来の x86 の優位性に挑戦し、クラウドでの科学技術計算プラットフォームとして Arm が現実的で、かつコスト効率の高い選択肢となり得ることを示唆しています。Graviton4 の Neoverse V2 コアと大幅に強化されたメモリサブシステム ⁸ の組み合わせは、多くの HPC コードにとって最適なバランスを提供しているようです。これは単なる漸進的な改善ではなく、クラウド HPC アーキテクチャとしての Arm の本格的な登場を意味し、AWS 上の HPC ユーザーの将来的な選択に影響を与えるでしょう。

表5: HPC ベンチマーク比較 (例: Arm Blog & Phoronix Mix)

アプリケーション	インスタンスタイプ (比較対象)	メトリック (Metric)	主要な結果/出典
miniFE	G4 R8g vs G3 R7g, EPYC R7a (64 vCPU)	実行時間/スループット	G4 >> G3, G4 > EPYC ¹⁷
Incompact3D	G4 R8g vs G3 R7g, EPYC R7a (64 vCPU)	実行時間/スループット	G4 >> G3, G4 > EPYC ¹⁷
OpenFOAM	G4 R8g vs G3E C7gn (per vCPU), EPYC R7a/C7a	実行時間/スループット	G4 > G3E (+~17%/vCPU), G4 ≈ EPYC (64 vCPU), G4 > EPYC (192 vCPU) ¹⁷
LAMMPS	G4 R8g vs G3E C7gn (per vCPU), EPYC C7a	実行時間/スループット	G4 >> G3E (+32%/vCPU), G4 > EPYC (192 vCPU) ¹⁸
GROMACS	G4 R8g vs G3 R7g, EPYC R7a, Xeon R7i	ns/day (スループット)	G4 > G3, G4 < EPYC/Xeon ¹⁷
Relion	G4 R8g vs G3E C7gn (per vCPU), EPYC C7a	実行時間/スループット	G4 >> G3E (+41%/vCPU), G4 > EPYC (192 vCPU) ¹⁸
DevitoPRO	G4 R8g vs G3 R7g, G2 R6g	GPoints/sec (スループット)	G4 ≈ 1.5x-1.8x G3, G4 ≈ 2.7x-3.6x G2 ²³

AI/ML 推論

AI/ML 推論は、学習済みモデルを使用して新しいデータに対して予測を行うプロセスであり、クラウドにおける重要なワークロードです。

CPU ベース推論の性能: Graviton4 は、CPU ベースの AI/ML 推論ワークロード向けにも位置づけられています ³。llama.cpp フレームワークを用いたベンチマークでは、Arm Kleidi による最適化を活用した Graviton インスタンスが、x86 代替と比較して最大 4 倍優れたトークンあたりコストパフォーマンス (tokens per dollar) を示したと報告されています ⁵¹。特に Graviton4 (C8g.16xlarge) は、量子化技術を用いることで、Llama 3 70B のような大規模言語モデル (LLM) を、人間が読める速度を超える 5-10 トークン/秒で実行可能であり、これは Graviton3 インスタンスではリソース制約から不可能だったとされています ¹⁹。Graviton3 (C7g.16xlarge) と比較した場合、Graviton4 (C8g.16xlarge) は Llama 3 8B モデルにおいて、プロンプトエンコーディングで 14-26%、トークン生成で 5-50% の性能向上を示しました ¹⁹。Zenn の記事では、Graviton4 は Graviton3 比で 15-28% の ML 性能向上があると報告されています ⁵⁸。PyTorch などのフレームワークにおける Graviton 向けの最適化も性能向上に寄与しています ¹⁰。Graviton3 は、より広いベクトル演算ユニット (SVE) と bfloat16 データ型のサポートにより、Graviton2 比で最大 3 倍の ML 性能向上を実現していました ⁴。Graviton4 の Neoverse V2 コアも、SVE/SVE2、Bfloat16、INT8 命令をサポートしており、AI/ML ワークロードに適しています ¹⁰。
CPU 推論の実行可能性: これらの結果は、Graviton4 が CPU ベースでの LLM 推論の適用範囲を、従来よりもはるかに大きなモデル (70B パラメータ実証) へと拡大したことを示唆しています。量子化技術や llama.cpp + Arm Kleidi のような最適化されたフレームワークと組み合わせることで、特定のレイテンシ要件を満たす範囲において、GPU に対するコスト効率の高い代替手段を提供する可能性があります。70B モデルで 5 トークン/秒を超える性能を CPU で達成した ¹⁹ ことは、対話型アプリケーションなどでの実用性を高めます。示された高い価格性能比 ⁵¹ は、ML モデルのデプロイにおいてコストと性能のバランスを取る上で魅力的な選択肢となります。

表6: AI/ML 推論ベンチマーク比較 (例: Arm Blog Llama 3)

モデル	インスタンス	メトリック (Metric)	結果 (例)	G4 vs G3 向上率 (%)
Llama 3 8B	G4 C8g.16xlarge	プロンプトエンコーディング速度	高	14-26%
Llama 3 8B	G3 C7g.16xlarge	プロンプトエンコーディング速度	中	–
Llama 3 8B	G4 C8g.16xlarge	トークン生成速度 (トークン/秒)	高	5-50%
Llama 3 8B	G3 C7g.16xlarge	トークン生成速度 (トークン/秒)	中	–
Llama 3 70B	G4 C8g.16xlarge	トークン生成速度 (トークン/秒, 量子化)	5-10 トークン/秒	(G3では実行不可)

出典: Arm Community Blog ¹⁹

コンピレーション、暗号化、その他

上記カテゴリ以外の多様なワークロードにおける Graviton4 の性能を見ていきます。

コードコンパイル: Graviton4 はこの分野で非常に優れた性能を示します。Gem5 シミュレータや LLVM のコンパイル時間において、Graviton3/Graviton2 だけでなく、比較対象の AMD EPYC 9R14 や Intel Xeon 8488C よりも高速でした ¹⁷。これは、優れた価格性能と相まって、CI/CD (継続的インテグレーション/継続的デリバリー) のビルドサーバー用途に非常に魅力的であることを示唆しています ¹⁷。
暗号処理: 結果はまちまちです。Graviton4 は Graviton3 から大幅な性能向上を示しました ¹⁷。x86 との比較では、XMRig GhostRider テストで Xeon R7i を上回りましたが EPYC には及ばず、OpenSSL の各種アルゴリズム (ChaCha20, AES-GCM, Poly1305) では Graviton3 を大きく引き離し EPYC とは競争力がありましたが Xeon には劣る結果となりました ¹⁷。シーズ社のテストでは、OpenSSL sha256 では Graviton4 が強さを見せたものの、gcrypt のハッシュ化では R7i に劣りました ⁴²。
データ圧縮 (7-Zip): 驚くべきことに、Graviton4 は 7-Zip の圧縮・展開ベンチマークにおいて、Graviton3、EPYC 9R14、Xeon 8488C のすべてを上回る性能を示しました ¹⁷。
3D レンダリング (Blender): Graviton4 は Graviton3/Graviton2 から大幅に高速化しましたが、Blender 4.0.2 の各種レンダリングテストにおいては、一貫して EPYC や Xeon インスタンスよりも遅い結果となりました ¹⁷。
Java: AWS は、Graviton4 が大規模 Java アプリケーションにおいて Graviton3 より 45% 高速であると主張しています ⁴。シーズ社の Java JMH ベンチマークでは、Graviton4 が Graviton3 を上回り、さらに R7i よりも優れた結果を示しました ⁴²。
コンピレーションと圧縮における強み: コードコンパイルや 7-Zip での Graviton4 の強力なパフォーマンスと優れた価格性能は、このプロセッサが開発者関連のワークロード (CI/CD) やデータ圧縮・展開を伴うタスクにおいて特に有利であることを示しています。これらの分野では、場合によっては x86 プロセッサを性能面でも上回る可能性があります。コンパイル作業は CPU とメモリを集中的に使用します。Graviton4 の多数のコア、改善された Neoverse V2 コアアーキテクチャ、そして高いメモリ帯域幅が、Gem5 や LLVM のようなテストで x86 をリードする要因となっていると考えられます ¹⁷。7-Zip での好成績は予期せぬものでしたが、特定のアルゴリズムやデータ処理における効率の高さを示唆しています ¹⁷。インスタンスコストの低さと相まって ¹⁷、ビルドファームやデータ処理パイプラインにとって説得力のある価値提案を生み出しています。

表7: コンピレーション/暗号化/その他ベンチマーク比較 (例: Phoronix/Tom’s Hardware Mix)

ベンチマーク	インスタンス (比較対象)	メトリック (Metric)	Xeon 比 (相対性能)	G3 比 (相対性能)	Perf/$ ランク (推定)
Gem5 コンパイル	G4, G3, Xeon, EPYC	実行時間 (秒)	G4 > Xeon	G4 >> G3	G4 (1位)
LLVM コンパイル	G4, G3, G2	実行時間 (秒)	–	G4 > G3 >> G2	G4 (高)
7-Zip 圧縮	G4, G3, Xeon, EPYC	MIPS	G4 > Xeon	G4 > G3	G4 (高)
OpenSSL SHA256	G4, G3, Xeon, EPYC	スループット	G4 < Xeon	G4 > G3	G4 (中)
Blender BMW27 レンダリング	G4, G3, Xeon, EPYC	実行時間 (秒)	G4 < Xeon	G4 > G3	G4 (低)

出典: Phoronix/Tom’s Hardware ¹⁷ の結果に基づく要約。Perf/$ランクは性能とコストからの推定。

価格性能分析

性能だけでなく、コスト効率、すなわち価格性能比は、クラウドインフラを選択する上で極めて重要な要素です。

Graviton4 のコスト効率

一般的な主張: AWS は一貫して、Graviton プロセッサが同等の x86 ベースインスタンスと比較して最大 40% 優れた価格性能を提供すると主張しています ¹。インスタンス自体のオンデマンド価格も、同等の x86 インスタンスより最大 20% 低く設定されています ³。特に X8g インスタンスは、Graviton4 搭載インスタンスの中でメモリ GiB あたりのコストが最も低いとされています ²⁹。
ワークロード固有の指標: 多くの独立系ベンチマークでは、オンデマンド料金に基づいて「ドルあたりの性能」(performance per dollar) が計算され、比較されています ¹⁶。

コンパイル (Gem5, Godot): Graviton4 が最も優れた価値を提供 (例: Gem5 で $0.186/run vs x86 で 0.288/run以上)[17]。∗∗∗HPC(Incompact3D,OpenFOAM):∗∗Graviton4は良好なコストパフォーマンスを示しました[17,27]。DevitoPROベンチマークでは、IsotropicとSelf−adjointTTIでGraviton4が最高のTP/ (Tera-points per dollar) を示しましたが、Fletcher TTI では Graviton3 が最高でした ²³。
データベース (ClickHouse, PostgreSQL): Phoronix のテストでは、Graviton4 がこれらのワークロードで最高の性能/ドルを示しました ⁴⁸。RDS においても、Graviton4 は Graviton3 比で最大 29% の価格性能向上が謳われています ⁴⁷。
AI/ML 推論 (llama.cpp): x86 代替と比較して最大 4 倍優れたトークン/ドル性能が報告されています ⁵¹。
Web (WordPress/AB): シーズ社のテストでは、R8g がドルあたりの速度で最高でした ⁴²。

競合プロセッサとの比較

G4 vs G3: Graviton4 インスタンス (例: R8g) は、対応する Graviton3 インスタンス (例: R7g) よりも一般的に約 10% 高価です ³²。しかし、多くの場合 20-30% 以上、時にはそれ以上の性能向上が見られるため、結果的に Graviton4 の方が優れた価格性能を提供することが多いです ²³。
G4 vs Intel/AMD: Graviton4 は、特に AMD EPYC との比較において、幾何平均などの総合的な生性能では劣る場合があるものの ¹²、多くの場合で優れた価格性能を提供します。これは、Graviton インスタンス自体の価格が x86 インスタンスよりも低く設定されていることが大きな要因です ³。ただし、どの程度価格性能で有利になるかは、ワークロードによって大きく異なります ¹⁷。
オンデマンド vs. スポット価格: 価格性能の計算は通常、オンデマンド料金に基づいて行われます ¹⁶。しかし、R8g インスタンスのスポット価格が、リリース直後にオンデマンド価格の 1/10 程度という異例の低価格で観測されたことが報告されています ³²。スポット価格は変動しますが、タイミングによっては劇的なコスト削減の可能性があります。
AWS の価格戦略: AWS が Graviton に対して採用している積極的な価格戦略、特に R8g の初期の低スポット価格 ³² や、x86 に対する一貫した約 20% の価格差 ³ は、Arm アーキテクチャの採用を強力に推進しようとする戦略的な意図を示唆しています。これは単なる技術的な優位性だけでなく、AWS 自身の垂直統合 (自社でのチップ設計) ⁴ を活用して競合他社よりも低い価格を設定し、顧客を自社エコシステムに引き込むための市場形成戦術と見ることができます。価格は、既存の慣性や潜在的なソフトウェア互換性の懸念 ¹¹ を克服するための強力なインセンティブとなります ³。自社でシリコンを設計することで ⁴、Intel や AMD に支払うマージンを回避し、この価格競争力を生み出しています。

表8: 価格性能サマリー

ワークロードカテゴリ	最も価格性能が良いプロセッサ (推定)	次点のプロセッサ (推定)	主要な結果/出典
Web アプリケーション	Graviton4	Graviton3	⁴²
データベース (混合)	Graviton4	EPYC / Graviton3	¹⁷ (ワークロード依存)
HPC (メモリ律速)	Graviton4	EPYC / Graviton3	¹⁷ (ワークロード依存、一部 G3 優位)
AI/ML 推論 (CPU, llama.cpp)	Graviton4	(x86比で大幅優位)	⁵¹
コードコンパイル	Graviton4	EPYC	¹⁷

エネルギー効率と持続可能性

AWS は、Graviton インスタンスが同等の EC2 インスタンスと比較して、同じ性能を最大 60% 少ないエネルギーで実現すると主張しています ³。これは、Arm アーキテクチャ固有の高い電力効率に起因するとされています ⁴。
このエネルギー効率は、運用コストの削減に貢献するだけでなく、顧客が持続可能性の目標を達成し、二酸化炭素排出量を削減するのに役立ちます ³。これは、AWS 自身の持続可能性目標とも一致しています ⁸。
AWS 上で直接的な電力測定は困難ですが ²¹、主張されているエネルギー効率が正確であれば、特に大規模なデプロイメントにおいて、インスタンス価格だけではない大幅な TCO 削減に繋がります。また、環境意識の高い組織にとっては、説得力のある採用理由となります。エネルギーコストはデータセンター TCO の主要な構成要素であり、Graviton の価値提案の重要な一部となっています ³。

ユースケース適合性と推奨事項

Graviton4 は多くのワークロードで優れた性能とコスト効率を発揮しますが、すべてのシナリオで最適とは限りません。

Graviton4 が特に有利なユースケース

ベンチマーク結果とアーキテクチャ特性から、Graviton4 は以下のユースケースで特に強みを発揮すると考えられます。

スケールアウト型ワークロード: Web サーバー、マイクロサービス、コンテナ化されたアプリケーション (EKS, ECS Fargate ³ を含む)、アプリケーションサーバーなど、水平スケーリングが一般的なワークロード ³。コアあたりの良好な性能と優れた価格性能が活きます。
メモリ集約型アプリケーション: 大規模データベース (リレーショナル DB、RocksDB や ClickHouse のような NoSQL/分析 DB)、インメモリキャッシュ (Redis, Memcached, Valkey)、リアルタイムビッグデータ分析 ³。R8g および X8g インスタンスの高いメモリ帯域幅と容量が性能向上に貢献します。
HPC ワークロード (特にメモリ律速): 計算流体力学 (CFD, OpenFOAM)、有限要素解析 (FEA, miniFE)、地震波イメージング、特定の分子動力学 (LAMMPS, Relion)、EDA ³。高いメモリ帯域幅と Neoverse V2 コアの性能が有利に働きます。
Java アプリケーション: ベンチマークで顕著な性能向上が示されています ⁴。
CPU ベース AI/ML 推論: 特に量子化や最適化されたフレームワークを使用する場合、大規模モデルに対してもコスト効率の良い選択肢となります ³。
開発者ワークロード: コードコンパイル (CI/CD ビルドサーバー) ¹⁷。優れた性能と価格性能を提供します。
圧縮/展開タスク: 7-Zip での強力なパフォーマンスが報告されています ¹⁷。

Graviton4 導入検討時の注意点

Graviton4 への移行を検討する際には、以下の点に留意する必要があります。

性能が劣る可能性のあるワークロード:

特定の暗号アルゴリズムで、x86 の専用ハードウェアアクセラレーションや命令セットが優位な場合 (例: 一部の OpenSSL テストでの Xeon ¹⁷、gcrypt ハッシュでの Xeon ⁴²)。
AVX-512 のような x86 固有の命令セットに高度に最適化されたワークロード (Graviton は SVE/SVE2 を搭載) ¹³。
特定の HPC コードで x86 が依然としてリードしている場合 (例: 一部テストでの GROMACS ¹⁷)。
コアあたりの性能は全体的に高いものの、特定のシナリオでは高クロック x86 コアのピークシングルスレッド性能に劣る可能性があります ¹³。
3D レンダリング (Blender) では x86 に遅れをとる結果が示されています ¹⁷。

ソフトウェア互換性と移行の労力: アプリケーションやライブラリが Arm64 (AArch64) アーキテクチャ向けにコンパイルされている必要があります。エコシステムは広範に成長していますが ³、特定の OS、コンテナイメージ、ISV ソフトウェア、依存関係についてサポートを確認し、検証することが不可欠です。一般的な言語やフレームワーク (Java, Python, Node.js, Go, Ruby,.NET Core, PHP) では移行の労力は最小限であると報告されることが多いですが ⁷、カスタムソフトウェアや古いソフトウェアではより多くの作業が必要になる可能性があります。CI/CD パイプラインをマルチアーキテクチャビルドに対応させる必要も考慮すべきです ⁶¹。AWS は Porting Advisor for Graviton のようなツールを提供しています ³。
互換性の壁: Arm ソフトウェアエコシステムは大幅に成熟しましたが ²⁰、ニッチなソフトウェア、レガシーシステム、あるいは特定のプロプライエタリなサードパーティ製ソフトウェアとの互換性の問題は、一部の組織にとって Graviton 採用の最大の現実的な障壁となり得ます。Graviton の価格性能メリットに関わらず、重要なソフトウェアコンポーネント (特定の ISV アプリケーション、カスタムビルドのバイナリ、古いライブラリなど) が Arm64 版を提供していない、あるいは再コンパイル後に性能が出ない場合、移行が頓挫する可能性があります。そのため、移行前の徹底的なテストと依存関係の分析は譲れないステップとなります。

導入推奨シナリオ

上記の点を踏まえ、Graviton4 の導入が特に推奨されるシナリオは以下の通りです。

新規アプリケーション開発: Graviton4 の強みが活きるワークロードでは、最初から Graviton4 をデフォルトとして採用し、最高の価格性能を活用する。
既存ワークロードのコスト最適化: 古い x86 インスタンス (例: M5, R5, C5) で稼働している Web サーバー、データベース、キャッシュ、データ処理パイプラインなど、コンピューティングコストが高いワークロードを Graviton4 に移行し、大幅なコスト削減と多くの場合性能向上を目指す ³⁶。移行はリスクの低いワークロードから開始し、検証を進めるのが賢明です ⁶⁶。
持続可能性目標を持つ組織: Graviton4 のエネルギー効率を活用し、二酸化炭素排出量を削減する ³。
マネージドサービスの利用: RDS, Aurora, ElastiCache, OpenSearch, EKS/ECS Fargate など、Graviton ベースのオプションが利用可能なマネージドサービスを利用している場合、容易に価格性能の向上を実現するために移行を検討する ³。

結論

AWS Graviton4 は、前世代の Graviton3 から著しい進化を遂げ、AWS が主張する通り、多くの主要なクラウドワークロード (Web、データベース、Java、HPC、AI 推論、コンピレーションなど) において 30% 以上の性能向上を実現しています。この性能向上は、Arm Neoverse V2 アーキテクチャの採用と、大幅に強化されたメモリサブシステムによって支えられています。

クラウドコンピューティング市場において、Graviton4 は AWS の Arm ベースコンピューティングにおけるリーダーシップを確固たるものにし、Intel Sapphire/Emerald Rapids や AMD Genoa といった同時代の x86 プロセッサに対する極めて競争力のある代替選択肢としての地位を確立しました。一部の特定のワークロードやピーク性能では最高性能の x86 チップに譲る場面もありますが、Graviton4 は多くのワークロードでそれらに匹敵するか上回る性能を示し、一貫して優れた価格性能とエネルギー効率を提供します。これは、データセンターにおける長年の x86 複占に対する信頼できる脅威となっています ⁸。

Graviton プロセッサの急速なリリースサイクル (約 5 年で 4 世代) ¹⁸ は、AWS が今後も Arm ベースの性能向上を積極的に推進していくことを示唆しています。AMD (Turin) や Intel (Granite Rapids) が次世代 x86 チップをリリースし ¹²、Ampere Computing のような他の Arm ベンダーも進化を続ける中で ¹⁴、競争はさらに激化するでしょう。Arm 向けソフトウェアエコシステムの継続的な最適化も、今後の成功にとって不可欠な要素となります。Graviton4 の登場は、Arm がもはやニッチな存在ではなく、要求の厳しい多様なクラウドワークロードに対応可能な、主流の高性能オプションであることを明確に示しています。