AI アクセラレータのパフォーマンスとベンチマーク

大規模言語モデル（LLM）を主なワークロードとして使用する AI ハードウェアを評価するには、一貫性のあるベンダーニュートラルなアプローチが必要です。このガイドでは、NVIDIA、AMD、 Google、AWS などのさまざまなベンダーの AI アクセラレータ チップのパフォーマンスを比較する方法について説明します。原則と方法論は、あらゆる AI チップやワークロードに適用できますが、例では、LLM ワークロードを実行する NVIDIA グラフィック処理ユニット（GPU）と Tensor Processing Unit（TPU）の一般的な業界ペアリングに焦点を当てています。 Google

モデルは通常、特定のハードウェア プラットフォーム向けに最適化されているため、モデルのパフォーマンスのみを評価しても、ハードウェアの機能を理解するには不十分です。LLM 用のアクセラレータ チップを評価する際は、マイクロベンチマーク、ルーフライン分析、トレーニングと推論の両方のモデル ベンチマークという 3 つの重要な側面を考慮します。

マイクロベンチマークとルーフライン分析は、特定のアクセラレータ プラットフォームの機能と可能性を理解するために不可欠です。この情報がわかると、トレーニングと推論にわたるモデル ベンチマークにより、チップ間の実際のワークロードの比較と、モデル アーキテクチャが特定のプラットフォーム向けに最適化されているかどうかの分析情報が得られます。

パフォーマンスの側面

評価者は、次の 3 つの側面からパフォーマンスを検討し、特定のアクセラレータ システムをより包括的に理解することをおすすめします。

  • マイクロベンチマーク: ハードウェアの仕様が最高水準であっても、アプリケーションが実際にその仕様を活用できるとは限りません。マイクロベンチマークを使用すると、1 秒あたりの浮動小数点演算数（FLOPS）、高帯域幅メモリ（HBM）、ネットワーキング帯域幅が実際のワークロードで達成可能なことにどのように影響するかを評価できます。
  • ルーフライン分析: メモリ帯域幅または計算速度によって、ハードウェアの最適な使用率が妨げられる可能性があります。ルーフライン モデルとさまざまなシステム コンポーネントのオペレーション強度（OI）を使用して、ハードウェアとワークロードの適合性を確認できます。マイクロベンチマークとルーフラインを組み合わせることで、選択したハードウェアがさまざまな種類のワークロードで実現できる理論的な評価が得られます。
  • モデルのベンチマーク: トレーニング ワークロードと推論ワークロードでベンチマークを実行して、チップあたりのトークン数（TPS/チップ）を測定すると、異なるプラットフォームで同じモデルを評価できます。初期結果がマイクロベンチマークとルーフライン分析の結果と異なる場合は、以前に特定したルーフラインを実現するために追加のソフトウェア作業が必要であることを示しています。たとえば、シャーディング戦略の変更やカスタム カーネルの採用などがあります。

モデルのベンチマークは、特定のモデル、スケール、プラットフォームの特定の時点のスナップショット アプローチです。高度なユーザーは、パフォーマンスを評価する際に、業界のトレンド（モデル アーキテクチャなど）、マイクロベンチマーク、ルーフラインの結果も考慮します。

モデルとハードウェアの共同設計

パフォーマンス評価では、テスト対象のハードウェアのコンテキストでモデル アーキテクチャを慎重に検討する必要があります。効率的に設計されたモデルは、特定のプラットフォームのニュアンスを活用するために、特定のハードウェア プラットフォーム向けに共同設計されることがよくあります。そのため、これらのモデルは他のプラットフォームや、同じプラットフォームの異なる世代を十分に活用できない可能性があります。たとえば、NVIDIA Hopper GPU 用に設計されたモデルは、AMD GPU や NVIDIA Blackwell GPU を十分に活用できない場合があります。

この考慮事項は、機能が異なる可能性のあるハードウェア プラットフォーム間で移行する場合に特に重要です。これは、あるプラットフォーム向けに設計されたモデルが、別のプラットフォームで最高のパフォーマンスを実現するために、構成の変更やソフトウェアの変更、またはその両方を必要とする可能性があるためです。最適化されたモデルのベンチマークは、ベンダーの「理論上のピーク」パフォーマンスのマーケティング主張を検証し、実際の結果を測定するために不可欠です。独立系アナリスト企業 SemiAnalysis は、「理論上の FLOPS を比較しても、全体像の一部しかわかりません。重要なのは実効 FLOPS です。ピーク値は実際のワークロードではほとんど達成されないからです。」

例: gpt-oss-120B チャレンジ

ベンチマークの一般的な落とし穴は、設計されていないハードウェアでモデルを評価することです。OpenAI の gpt-oss-120B オープンウェイト モデルは、モデル アーキテクチャをターゲット シリコンに密接にマッピングする必要がある理由の一例です。次の例は、モデルの共同設計が重要であり、プロセスの早い段階で行う必要があることを示しています。

gpt-oss-120B モデルは、アテンション ヘッドのディメンションとして 64 を使用します。これは多くの GPU 最適化モデルでは標準ですが、TPU アクセラレータではアーキテクチャの不一致が生じます。Trillium や Ironwood などの TPU は、行列乗算ユニット（MXU）を完全に飽和させるために、256 の倍数の行列ディメンション用に最適化されています。ヘッド ディメンション 64 は TPU 向けに最適化されていないため、TPU システムで gpt-oss-120B を実行すると、1 秒あたりのトークン数（TPS）とモデルの FLOPS 使用率（MFU）が低下します。ハードウェアは、256x256 の実行グリッドに合わせるために、残りのスペースをゼロで埋め、クロック サイクルと電力のパディングを効果的に無駄にします。

TPU のベンチマークとして gpt-oss-120B を使用すると、実際にはソフトウェア アーキテクチャの不一致を反映しているにもかかわらず、ハードウェアの性能が低いと誤ってシグナルが送信される可能性があります。アクセラレータの「上限」を正確に評価するには、特定のジオメトリ用に共同設計されたモデルでテストします。たとえば、Gemma 4 のようにヘッド ディメンションが 128 または 256 のモデルです。このモデルのパフォーマンスは、ゼロのパディングを回避して MXU を「埋める」カスタム カーネルで改善できますが、専門知識が必要であり、GPU と同じレベルのパフォーマンスは得られません。ヘッドのサイズを TPU に最適化するように変更することもできますが、この変更により既存のモデルの重みが無効になるため、再トレーニングが必要になります。

ベンチマークの原則

公平で将来性のある評価を行うには、アクセラレータ間のベンチマークで次の原則を考慮してください。

  • 費用対効果に注目する: 一部のベンダーは単一チップの生パフォーマンスに注目していますが、システム レベルの費用対効果は、総所有コスト（TCO）と価値全体をよりよく表しています。チップ A のパフォーマンスがチップ B より 20% 優れており、コストが 50% 高い場合、評価者はチップ B の 1 ドルあたりのパフォーマンスの向上を認識する必要があります。また、ワットあたりのパフォーマンスもコストの一部として考慮してください。
  • 最新の AI ワークロードを表現する: 業界のトレンドを考慮しながら、一般的な Transformer ベースのモデル、大規模なクラスタ、最新のフレームワークに焦点を当てます。たとえば、業界がスパース Mixture of Experts（MoE）モデルに移行すると、FLOPS を完全に最適化することが難しくなり、ネットワークからより高い二分帯域幅が要求されます。
  • デベロッパーの要件を幅広くサポートする: さまざまなワークロード（トレーニング、ファインチューニング、さまざまな LLM やその他のモデルでのサービング）のパフォーマンス、柔軟性、スケーラビリティを検討します。
  • ベンダーに依存しないモデルとツールを選択する: アクセラレータ間で実行されるモデルとエンジンを選択して、アクセラレータ間の評価を容易にします。たとえば、Qwen や Gemma などのオープンモデルと、GPU や TPU で実行される vLLM などのオープンソース推論エンジンを使用します。ハードウェア固有の PyTorch/CUDA スタックは避けてください。モデル トレーニングのベンチマークでは、プラットフォーム間でモデルが一定の場合、ベンダー固有のフレームワーク（TPU の場合は MaxText、GPU の場合は Megatron など）が最も有用です。
  • モデルの共同設計: 経験豊富なユーザーがモデルを共同設計し、ハードウェア プラットフォームを最大限に活用します。チップ A でトレーニングされたモデルがチップ B で優れた「すぐに使える」パフォーマンスを発揮することを期待しないでください。
  • ハードウェア システム全体を考慮する: 一部のアクセラレータは、FLOPS などの 1 つの分野で高いパフォーマンスを宣伝できます。ただし、メモリ帯域幅などの他の領域のボトルネックにより、アクセラレータの機能が大幅に制限される可能性があります。システムで考慮すべきその他の側面は、チップの仕様、チップのネットワーキング、スケールアウト アーキテクチャです。
  • ハードウェアとソフトウェアの信頼性: 大規模なトレーニングや重要な推論オペレーションの中断は、非常にコストがかかる可能性があります。同様に、AI アクセラレータの有用性は、その上で実行されるソフトウェアによって決まります。価値を最大限に高めるには、大規模な実績のある成熟した信頼性の高いソフトウェア スタックが不可欠です。

Microbenchmark

アクセラレータのベンチマークのコンテキストでは、マイクロベンチマークは、コンピューティング コア、メモリ、インターコネクトなどの特定のハードウェア コンポーネントを分離し、複雑なソフトウェア スタックの干渉なしに絶対的な上限を測定します。多くのベンダーは「シングルチップのピーク FLOPS」を強調していますが、現実世界の AI は分散システムの問題です。マイクロベンチマークは、チップが単に強力であるのか、データセンターの規模に合わせて設計されているのかを理解するのに役立ちます。

マイクロベンチマークを使用して、ハードウェアのピーク パフォーマンスを測定し、モデル アーキテクチャとは無関係に、システムの実際の制限について学習します。マイクロベンチマークは、将来のユースケースやモデル アーキテクチャに対してアクセラレータを評価する場合に特に役立ちます。

アクセラレータを効果的にマイクロベンチマークするには、次の点を評価します。

ベンチマーク 説明
密な一般行列乗算（GEMM）の使用率 さまざまな精度で高度に最適化された GEMM カーネルを実行して、アクセラレータのコア コンピューティング ユニットの生の持続的な数学的処理能力を測定します。
高帯域幅メモリ（HBM）ストリーミング メモリ帯域幅マイクロベンチマークを実行して、アクセラレータのオンボード メモリの持続的な読み取り、書き込み、コピーの速度を測定します。健全なバイト対 FLOP 比率を維持するアーキテクチャでは、コンピューティング コアがアイドル状態になるのを防ぐことができます。
分散コレクティブ（all-reduce と all-gather） 数千個のチップで標準化された集団通信テストを実行し、クラスタのスケールアップに伴ってネットワークの帯域幅とレイテンシがどの程度低下するかを測定します。
ホストからデバイス（H2D）への転送レートとデバイスからホスト（D2H）への転送レート ホスト CPU のシステムメモリとアクセラレータの間で大量の連続したデータ ストリームをプッシュし、PCIe バスまたはカスタム インターコネクト間の転送速度を測定します。
サーマル スロットリングと電力消費の持続 ラックレベルの電力消費をモニタリングしながら、最大使用率の GEMM ループを 48 時間連続で実行し、持続的な熱安定性と実際の電力効率を評価します。

マイクロベンチマークの比較例

2 つのチップの比較例を以下に示します。架空のチップ A は架空のチップ B よりも優れているように見えますが、実際にはパフォーマンスが劣る可能性があります。

ベンチマーク名 テスト済みのチップ A の結果 チップ A の仕様 テスト / 仕様の比率 チップ B のテスト結果 チップ B の仕様 テスト / 仕様の比率
チップ間ネットワーキング 800 GBps 1,000 GBps 80.0% 850 GBps 900 GBps 94.4%
gemm/peakTOPS 1,800 TFLOPS 2,500 TFLOPS 72.0% 1,800 TFLOPS 2,000 TFLOPS 90.0%
メモリ帯域幅 6,000 GBps 8,000 GBps 75.0% 6,500 GBps 7,500 GBps 86.7%
ホストからデバイス 58 GBps/チップ 70 GBps/チップ 82.9% 60 GBps/チップ 65 GBps/チップ 92.3%
デバイスからホスト 55 GBps/チップ 70 GBps/チップ 78.6% 55 GBps/チップ 65 GBps/チップ 84.6%

ルーフライン分析

ルーフライン分析（またはルーフライン モデル）を使用すると、さまざまなシステム コンポーネントのオペレーション強度（OI）と、特定の設計が特定のプラットフォームにどの程度適しているかを分析するための可視化を行うことができます。

AI アクセラレータ チップのスループットは、主に次の 3 つの要因によって制約されます。

  1. コンピューティング容量: チップのピーク時の数学的スループット（FLOPS）。
  2. メモリ帯域幅: チップのローカル高帯域幅メモリ（HBM）との間でデータを転送できる速度。
  3. ネットワーク帯域幅: 分散トレーニングまたは推論中にチップ ネットワーキングを使用して、複数のチップ間でデータを共有できる速度。たとえば、ICI（TPU の場合）または NVLink（GPU の場合）の転送レートです。

ルーフラインの詳細については、ルーフラインについてをご覧ください。

標準のルーフライン プロットは、次の 2 つの軸で構成されます。

  • X 軸（動作の強度）: 動作の強度は、コンピューティング作業（FLOPS）とメモリ トラフィック（転送されたバイト数）の比率で、FLOPS / バイトで表されます。これは、メモリから取得されたデータのバイトごとに実行されたコンピューティング作業の量を示します。
  • Y 軸（達成可能なパフォーマンス）: 達成可能なパフォーマンスは、1 秒あたりの FLOPS で表されます。これは、実際に達成されたコンピューティング スループットを表します。

ハードウェアのピーク パフォーマンスがメモリ帯域幅とコンピューティング容量によって制限される様子を示すルーフライン モデルのグラフ

「屋根」は、ハードウェアの最大値を表す 2 つの交差する線で構成されます。

  1. 斜めの屋根（メモリバウンド）: 達成可能なパフォーマンス = ピーク メモリ帯域幅 × 演算強度。このラインでは、パフォーマンスはコンピューティング ユニットにデータを供給できる速度によって厳密に制限されます。
  2. フラット ルーフ（コンピューティング バウンド）: 達成可能なパフォーマンス = ピーク コンピューティング容量。このラインでは、コンピューティング ユニットが最大容量で実行されるのに十分な速度でデータが供給されます。

この 2 つの線が交差する点をリッジポイントと呼びます。これは、ハードウェア使用率を最大にするためにワークロードに必要な最小 OI を定義します。

上の図では、Algo 1 はグラフの「メモリバウンド」とラベル付けされた部分にあり、コンピューティング ユニットを十分に活用していません。一方、Algo 2 は OI が高く、「compute bound」とラベル付けされたグラフの部分にあります。Algo 1 を最適化するには、ユーザーはアルゴリズムを変更して、データ移動を減らしながら計算を増やし（OI を増やし）、パフォーマンスを右に、リッジ ポイントに向かってシフトさせます。

OI ワークロードの低と高の例

  • HBM の運用強度が低い（メモリバウンド）: 要素ごとのオペレーション（ReLU や GeLU などのアクティベーション関数）、レイヤ正規化、自己回帰デコード（バッチサイズ = 1 の推論）などのワークロード。
  • 高い HBM 運用強度（コンピューティング バウンド）: GEMM や大規模バッチの畳み込みニューラル ネットワークなどのワークロード。行列乗算では、取得したデータが何度も再利用される（行と列の乗算）ため、OI が非常に高くなり、ワークロードはフラットなコンピューティング ルーフの下に配置されます。

モデルのベンチマーク

モデル ベンチマークでは、実際のモデルのパフォーマンスを測定します。トレーニングと推論のベンチマークを使用すると、特定の時点での一般的なモデルのパフォーマンスを比較できます。

次の表は、トレーニング ワークロードと推論ワークロードのモデル ベンチマークから取得できる分析情報を比較したものです。

分析情報 トレーニング ワークロード 推論ワークロード
スケール 大規模なテスト（1 万個以上のチップ、最大モデルでは 10 万個以上）が実施されることが多い。分散ワークロード、通信オーバーヘッド、クラスタレベルのネットワーキングの上限に関する分析情報を提供します。 多くの場合、小規模なテスト（1 ～ 64 個以上のチップ）。プラットフォームが同時ユーザーと負荷の下での迅速なスケールアップをどのように処理するかについての分析情報を提供します。
パフォーマンス 多くの場合、コンピューティング バウンドになります。チップあたりの 1 秒あたりの処理トークン数とモデルの FLOPS 使用率（MFU）を測定します。 レイテンシの影響を受けやすい。ファースト トークンまでの時間（TTFT）、トークン間のレイテンシ、ユーザーあたりの 1 秒あたりの生成トークンの合計数を測定します。
レイテンシ 大規模なデータセットの読み込み時のストレージ ボトルネックをハイライトする I/O とインターコネクトのレイテンシ、同期勾配更新時のノード間のネットワーク レイテンシ。 キューイングの遅延、エンドポイントのレイテンシ、ユーザー向けの待機時間をハイライトするエンドツーエンドのレスポンス レイテンシ。

トレーニングのベンチマーク

ハードウェアとネットワーキングの真の効率を判断するには、特定の代表的なモデル アーキテクチャを一定に保ちながら、アクセラレータ間でパフォーマンスを単一の比較可能な指標（チップあたりのトークン数 / 秒（TPS / チップ））に正規化する必要があります。クラスタのサイズをスケーリングするにつれて TPS/チップがどのように変化するかを追跡することで、システムの隠れた「スケール税」を明らかにします。

アクセラレータの費用でパフォーマンスを正規化するには、TPS/チップを各チップの費用で除算して TPS/チップ/$ を求めます。これが別の比較ポイントになります。

ベンチマーク対象の各モデルについて、次の点を評価します。

ベンチマーク 説明
ベースラインの TPS/チップと TPS/チップ/$ を測定する

最小限の実行可能なクラスタでターゲット モデルを実行します。グローバル トレーニング スループット（1 秒あたりに処理されるトークンの合計数）を記録し、チップ数で割ってベースラインの TPS/チップを確立します。アクセラレータの費用で割って、TPS/チップ/$ を取得します。

別の方法として、トレーニング中にモデルの FLOPS 使用率（MFU）を観察して、理論上の最大値に対する実際のスループットの比率を測定します。これは、ハードウェアのパフォーマンスがベンチマークにどれだけ近いかを把握するのに役立ちます。ただし、TPS/チップほど有用なチップ間の比較はできません。
スケーリングのパフォーマンス低下を評価する クラスタを 256 個、1,024 個、4,096 個のチップにスケーリングし、まったく同じモデルを実行します。各スケールで TPS/チップを再計算します。
グッドプットを考慮する

モデルが実際に学習している場合にのみ、生の TPS/チップが重要になります。グッドプットを計算して、LLM のトレーニング状態を直接進める有用な計算のレートを測定します。ハードウェア障害、ネットワークの停止、チェックポイントの復元で無駄になった時間とエネルギーは明示的に除外します。

AI アクセラレータを大規模に評価する場合、グッドプットは、ハードウェアが実際の障害が発生しやすいクラスタでパフォーマンスを維持する効果を明らかにするため、理論上のスループットよりも投資収益率をより現実的に把握できます。

次の表に、トレーニングのベンチマークとして推奨されるモデルを示します。

サイズ アーキテクチャ モデル 根拠
小（80 億） 高密度 Llama 3.1 8B Llama 3 は、MLPerf などのベンチマーク標準で長年にわたり人気のある標準モデルです。
中（700 億） 高密度 Llama 3.1 70B Llama 3 は、MLPerf などのベンチマーク標準で長年にわたり人気のある標準モデルです。
大規模（6,710 億） MoE DeepSeek-V3 671B DeepSeek-V3 は 2025 年にサイズとパフォーマンスの新しい基準を確立し、多くのマルチチップ プラットフォームで最適化されています。

例: 1 ドルあたりのパフォーマンスに正規化する

Chip_A、Chip_B、Chip_C のベンチマーク比較を考えてみましょう。一般的なモデルのトレーニング ベンチマークを実行して、TPS のパフォーマンスを確認します。次に、同じモデルの Chip_A のパフォーマンスと Chip_B および Chip_C のパフォーマンスの比率を確認します。

ベンチマーク Chip_B TPS の割合としての Chip_A TPS Chip_C TPS の分数としての Chip_A TPS
Small dense: Llama 3.1 8B 0.82 0.62
MoE: Mixtral 8x7B 0.72 0.55
大規模な高密度: Llama 3.1 405B 0.77 0.61
大規模 MoE: DeepSeek-V3 0.85 0.62
平均値 0.79 0.60

上記の表のデータに基づくと、Chip_A のパフォーマンスは Chip_B のパフォーマンスの平均 0.79 倍、Chip_C のパフォーマンスの平均 0.60 倍です。これ以上の情報がない場合、Chip_C の方が優れているという結論になります。

ただし、Chip_A の費用が 100 ドル、Chip_B の費用が 180 ドル、Chip_C の費用が 200 ドルの場合、パフォーマンス / ドル（perf/$）に正規化すると結果が変わります。

ベンチマーク Chip_B のパフォーマンス/$ に対する Chip_A のパフォーマンス/$ の割合 Chip_C のパフォーマンス/金額に対する Chip_A のパフォーマンス/金額の比率
Small dense: Llama 3.1 8B 1.48 1.24
MoE: Mixtral 8x7B 1.30 1.10
大規模な高密度: Llama 3.1 405B 1.39 1.22
大規模 MoE: DeepSeek-V3 1.53 1.24
平均値 1.42 1.20

パフォーマンス/ドルを比較ポイントとすると、Chip_A は Chip_B を平均 42%、Chip_C を平均 20% 上回ります。

推論ベンチマーク

トレーニングは多額の初期資本的支出ですが、サービング（推論）は長期的な運用費用となります。TPS/チップが高いほど、同じ運用ワークロードをサポートするために必要な物理サーバーの数が少なくなり、エネルギー消費量とデータセンターのフットプリントを大幅に削減できます。

推論では、レイテンシ要件を満たしながらスループットを最大化し、応答性の高いユーザー エクスペリエンスを確保することが目標です。固定モデルの TPS/チップの評価を標準化することで、さまざまなチップのパフォーマンスを直接比較できます。

推論のベンチマークを行う場合は、TPS/チップ/$ を計算してパフォーマンスを正規化します。

ベンチマーク 説明
レイテンシ SLA を確立する

まず、ユーザー エクスペリエンスに関する厳格な SLA を設定します。たとえば、予測可能なテールレイテンシ（P99）が 100 ミリ秒などです。TTFT（500 ミリ秒未満）と出力トークンあたりの時間（TPOT）を使用して、応答性のユーザー エクスペリエンスを測定します。
バッチサイズをプッシュする ハードウェアに対する同時リクエスト数（バッチサイズ）を徐々に増やします。バッチサイズを大きくするとスループットは向上しますが、最終的にはレイテンシが低下します。
最大持続 TPS/チップを記録する

ハードウェアが P99 レイテンシ SLA に違反した場合は、停止します。そのバッチサイズのシステム スループットの合計を記録し、チップ数で割ります。これが TPS/チップの値です。

汎用アクセラレータの中には、バッチ負荷が高いと「テールレイテンシ」（処理時間のランダムな急上昇）が発生し、ユーザーの満足度を維持するために、オペレーターが使用率を低くして実行しなければならないものもあります。

プレフィル（コンピューティング バウンド）とデコード（メモリ帯域幅バウンド）の 2 つの異なるフェーズで測定してください。
トークン 1,000 個または 100 万個あたりの TCO を計算する 1 つのチップの償却された資本コストとエネルギー コストを、その最大持続 TPS/チップで割ります。これにより、技術的なベンチマークが財務指標に変換され、実際の費用が明らかになります。

次の表に、推論のベンチマークに推奨されるモデルを示します。

サイズ アーキテクチャ モデル 根拠
小（80 億） 高密度 Llama 3.1 8B Llama 3 は、MLPerf などのベンチマーク標準で長年にわたり人気のある標準モデルです。
中（700 億） 高密度 Llama 3.1 70B Llama 3 は、MLPerf などのベンチマーク標準で長年にわたって人気のある標準モデルです。
大（480B） MoE Qwen3 Coder 480B Qwen3 480B は、最先端の OSS コーディング モデルです。

次のステップ