AI の性能は 3 つの次元に依存します:

  1. 精度: モデルがどれだけ正確に推論し、出力を生成するか
  2. スループット: データセンターが 1 秒間に生成できるトークン数
  3. 対話性: ユーザーにとってのモデルの応答性、主にレイテンシに支配される

デプロイメントはこれら 3 つすべてをバランスさせる必要があります。高精度であっても応答が遅ければ意味がなく、純粋なスループットが高くてもユーザー体験が遅延だらけなら価値がありません。実用的なシステムでは、精度、スループット、対話性を同時に最適化します。

本記事ではスループットと対話性に焦点を当て、精度を犠牲にせずに両者を形成するモデル設計の選択肢について説明します(精度のトレードオフが生じる場合は明記します)。

精度を固定した場合、問題は 2 次元の Pareto フロンティアになります。通常、一方を改善すると他方が犠牲になります。目標はフロンティア全体を外側に押し出し、曲線下の面積を最大化することです(下の Figure 1 を参照)。

Line chart showing system throughput (tokens/s) falling as interactivity (tokens/s/user) rises, with the goal of pushing the trade-off curve outward.
Figure 1. システムスループットと対話性の Pareto フロンティア

まず、今日の最も主要な AI ワークロードである LLM から始めます。このトレードオフには 2 つの視点があります。システム運用者はフリート全体のスループット(tokens/sec)を優先し、ユーザーは最初のトークンとトークン間の低レイテンシを重視します。トークン間レイテンシの逆数は tokens/sec/user で、値が高いほど応答性が向上します。

単一の応答は次のようになります:プロンプト → [first-token latency] → 最初のトークン → [inter-token latency] → 次のトークン、以下同様。

本記事は、モデルを最新のハードウェア上で効率的に動作させたいモデル開発者向けの実践的な入門ガイドです。基本的な考え方はシンプルです。ハードウェアに適合したモデルは、単に高速に動作するだけでなく、スケーラビリティが向上し、コストが低減し、より広範な採用につながります。

まず、デプロイメントの状況を 2 軸で整理します(下の Figure 2 を参照)。

Four pie charts showing how LLM execution time splits across GEMM, attention, communication, and other layers, varying by context length and by latency- vs throughput-oriented serving.
Figure 2. 異なるワークロード体制(横軸)とサービス目標(縦軸)におけるレイテンシ内訳

ワークロードは短文脈から長文脈まで、サービス目標はスループット指向(tokens/sec の最大化)からレイテンシ指向(応答時間の最小化)まで幅があり、多くのケースが中間になります。

各象限で必要な最適化は異なります。長文脈・スループット指向のサービングでは、ほとんどの時間が attention に費やされます。一方、レイテンシ指向のサービングでは、attention と FFN を短縮するためにモデル並列化を追加しますが、その代償として通信と固定オーバーヘッドが発生します。短文脈・スループット指向のサービングでは、attention と FFN に時間が比較的均等に分散され、大規模化時にはエキスパート並列化などの並列化の恩恵を受けやすくなります。

Amdahl の法則が適用されます。一部分を最適化しても、その部分が占める時間にしか効果がありません。attention がランタイムの 77% を占める場合、feed-forward レイヤーを調整してもわずかな改善しか得られず、attention パスに注力する方が効果的です。自分のワークロード体制を理解することで、どこに注力すべきかが明確になります。

本記事では、システムエンジニアでなくてもハードウェアから最大限の性能を引き出すための簡単な経験則を紹介します。以降の各章では、ハードウェア対応設計の異なる側面を順に取り上げ、計算ボトルネックの回避、データセンター規模でのスムーズなデプロイ、使用ケースに合った設計の選定、および実践的なスケーリングについて解説します。

より賢く設計し、より速くデプロイし、より広くスケールしましょう。それでは始めましょう。

LLM における線形レイヤのハードウェア親和型次元設計

Transformer の重要な設計選択肢の 1 つはアスペクト比、すなわちモデル幅とレイヤ数(\(L\))のバランスです。デコーダスタイルのモデルでは、これらの要素がスタック全体での計算とメモリの分散を支配します。幅自体は 2 つの次元、すなわち隠れ層次元(\(H\))と MLP レイヤの中間射影次元(\(H'\))によって決まります。

合わせて \(H\)、\(H'\)、\(L\) は、モデルが並列化戦略にどのようにマッピングされ、GPU 間でどのようにスケールするかを形作ります。本記事では、これら 3 つの選択がスループット、対話性、スケーラビリティに与える影響を、特に線形レイヤに焦点を当てて考察します。

算術強度の役割

どのようなハードウェアでも、達成可能な性能はルーフライン・モデルによって制限されます。ワークロードがどこに位置するかは、算術強度(メモリ移動 1 バイトあたりの計算操作数)によって決まります。

算術強度が低いワークロードはメモリ帯域幅によって制限され(メモリバウンド)、高いワークロードはデバイスのピーク計算スループット(FLOPS)によって制限されます(コンピュートバウンド)。最大スループット(1 秒あたりのトークン数)を目標とする場合、ワークロードをコンピュートバウンド領域に押し上げ、ハードウェアの全計算能力を活用したいと考えます。

レイテンシに敏感なデコーディングは逆で、低い並行度で実行されメモリバウンドになるため、メモリアクセス時間を短縮することが応答レイテンシの低減につながります。

Roofline plot where performance rises with arithmetic intensity in the memory-bound region, then flattens at the compute-bound peak past the ridge point.
Figure 3. ルーフライン・モデル。リッジポイントより下ではワークロードはメモリ帯域幅に制限され、上ではデバイスのピーク計算スループットに制限される。ワークロードの算術強度(1 バイトあたりの操作数)がどの領域に該当するかを決定する

1 バイトあたりの操作数を増やす簡単な方法はバッチサイズを大きくすることですが、モデル形状も重要です。以下では \(H\) と \(H'\) が GEMM をコンピュートバウンドにするかメモリバウンドにするかを決定する様子を見ていきます。単一デバイスで実行する場合、\(H\) と \(H'\) は次の形式の GEMM の形状を決定します:

\(C = AB\)

典型的な線形代数ライブラリで用いられる慣習に従い、\(A\) は \(M \times K\) の行列(\(M\) 行、\(K\) 列)、\(B\) は \(K \times N\) とします。積 \(C\) は \(M \times N\) の出力を持ち、各出力は長さ \(K\) のドット積で、\(M \times N \times K\) 回の fused multiply-add (FMA) が必要です。1 回の FMA は 2 FLOPs(乗算 1 回、加算 1 回)であるため、コストは以下のようになります:

\(\text{FLOPs} = 2 \times M \times N \times K\)

\(\text{Read Bytes} = M \times K \times \text{bytes}_A + N \times K \times \text{bytes}_B\)

\(\text{Write Bytes} = M \times N \times \text{bytes}_C\)

ここで \(\text{bytes}_{A,B,C}\) は使用する精度によって決まる要素あたりのバイト数です。\(A\) を入力、\(B\) を重みとすると、Table 1 はトークン数(\(\text{Tokens} = \text{concurrency} \times \text{sequence length}\))、\(H\)、\(H'\) を各線形レイヤの GEMM の \(M\)、\(N\)、\(K\) にマッピングします。

レイヤ名射影
(in → out)
GEMM MGEMM NGEMM K
Q/K/V 入力線形*H → 3HTokens3HH
Attention 出力線形HHTokensHH
FFN-1 (up-projection)HHTokensHH
FFN-2 (down-projection)H′ → HTokensHH

Table 1. Transformer ブロック内の線形レイヤの GEMM 次元(M, N, K)を Tokens、H、H′ で表したもの

すべての GEMM が「正方形」、すなわち \(\text{Tokens} = H' = H\) である場合を考えてみます。1 つの GEMM は \(2H^{3}\) FLOPs を実行し、約 \(3H^{2}\) 要素のメモリを移動するため、算術強度は \(H\) とともに増加します。実践的な意味は、\(H\) または \(H'\) のいずれかが小さい場合、トークン次元が大きくても GPU は計算よりもデータ移動に比例して多くの時間を費やすということです。

具体例として、GB300 上で FFN-2 に意図的に小さな \(H'=512\) と \(H=8192\) を用い、4-bit 入力・8-bit 出力を用いた場合を考えます。Table 2 に示すように、大きなトークン数(高い GEMM-M)でもこのレイヤはメモリバウンドのままデータ移動に支配され、出力が FP8 で入力が FP4 であることと、reduction 次元が小さいため GEMM がメモリバウンドのままとなります。

M (Tokens) \(N\) \(K\) math (µs) FP4 read (µs) FP8 write (µs)
256 8192 512 0.14 0.30 0.26
2048 8192 512 1.15 0.37 2.10
16384 8192 512 9.16 0.89 16.8
Table 2. GB300 上での FFN-2(\(N\) = 8192、\(K\) = 512)の理論的な GEMM あたりの所要時間。FP4 ピーク演算性能 15 PFLOPS、メモリ帯域幅 8 TB/s を仮定。どのトークン数でもメモリ時間が演算時間を上回り、レイヤは常にメモリバウンドのまま

Figure 4 のプロットは、GB300 シリコン上でのこの様子を示しています。NVFP4 GEMM を用い、トークン次元(GEMM-M)を大きな 8192 に固定した状態で、reduction 次元(GEMM-K)(左)と射影次元(GEMM-N)(右)をスイープします。いずれの場合も、スイープした次元が小さいとスループットが急激に低下し、小さな \(N\) または \(K\) ではハードウェアが十分に活用されないことが確認できます(\(N\) と \(K\) はレイヤに応じて \(H\) または \(H'\) に対応します。Table 1 を参照)。

Two line charts showing NVFP4 GEMM throughput on GB300 rising and saturating as the K (left) and N (right) dimensions grow, and falling sharply when they are small.
Figure 4 (Left). GB300 上での NVFP4 GEMM スループット vs reduction 次元 \(K\)(\(M\) = 8192、\(N\) = 9728 固定)。\(K\) ≈ 6144 付近で飽和。持続スループットの 80% に到達するには \(K\) > 3072 が必要。Figure 4 (Right). GB300 上での NVFP4 GEMM スループット vs 射影次元 \(N\)(\(M\) = 8192、\(K\) = 8448 固定)。\(N\) ≈ 6144 付近で飽和。持続スループットの 80% に到達するには \(N\) > 2560 が必要

これはモデル設計者にとって重要なポイントです。モデル次元は、計算を飽和させるためにバッチサイズと同等に重要です。

Guideline 1: パラメータ数が固定されたモデルでは、重み行列をできるだけ正方形に近くし、射影次元または reduction 次元のいずれも小さくしすぎないようにする。

しかし、サイズだけでは十分ではありません。高い Tensor Core 利用率を達成するには、GEMM の次元が基盤となるタイル形状にきれいにマッピングされる必要があります。整列が悪いとタイル量子化が発生し、算術強度が高い場合でもスループットが低下します。

GPU による GEMM の実行方法

GPU は出力行列をタイルに分割し、各タイルをストリーミングマルチプロセッサ(SM)で計算することで GEMM を実行します。最近の GPU では、SM は単独で動作する必要はなく、1 つの大きなタイルで協調動作できます。clusterMMA では隣接する 2 つの SM が 1 つのタイルで協調し、Cooperative Grid Array (CGA) では SM のグループ全体が 1 つのクラスタとして協調動作します。

協調によりデータ再利用が向上しますが、有効タイルサイズも拡大するため、次元はより大きな値の倍数である必要があります。次元が有効タイルの倍数でない場合、エッジタイルは部分的にしか埋められませんが、完全なタイル分の計算が起動・実行され、使用されない(パディングされた)部分は無駄な作業となり、サイクルを浪費してスループットを低下させます。Figure 5 に示すように、256×128 のベースタイル、clusterMMA、4×2 CGA を用い、GEMM-N を細かいステップでスイープすると、N が 256(clusterMMA による 2×128)または 512(CGA による 2×256)の倍数であるときに局所的なスループットの極大値が現れます。

Sawtooth chart showing NVFP4 GEMM throughput on GB300 peaking when GEMM-N is a multiple of 256 or 512 and dipping in between.
Figure 5. GB300 におけるタイル量子化効果によるスループット。M×N 出力行列に対して 256×128 タイルを clusterMMA と 4×2 CGA で強制的に使用したカーネルで測定

この無駄を避けるため、モデル次元をタイルサイズの大きな倍数にし、GPU キャッシュライン幅に整列させる必要があります。最低でも 128 の倍数は安全で移植性の高い下限値であり、256(clusterMMA)または 512(CGA)の倍数はより大きな協調タイルに適合し、最大のスループットを得られます。

Guideline 2: モデル次元を最低でも 128 の倍数にして GPU タイルサイズおよびキャッシュライン幅に整列させ、clusterMMA と CGA によって形成されるより大きなタイルに適合させるために 256 または 512 を優先する。

幅広モデルは深層モデルよりもハードウェア親和性が高い

パラメータ予算が固定されている場合、幅広モデルは重み再利用の増加とシーケンシャルなクリティカルパスの短縮により、深層モデルよりも高い算術強度と低いレイテンシを実現します。これにより、幅広モデルはスループット指向とレイテンシ指向の両方のサービス目標に有利になります。

ただし、アスペクト比はモデル品質にも影響します。深さは表現力に寄与するため、「幅広であれば常に良い」というわけではなく、有用な幅対深さの範囲が存在します。精度が維持される範囲でのみ幅を優先し、単にモデルを幅広にするためにレイヤを削減するべきではありません。

Guideline 3: 選択肢がある場合は、多くの小さな演算よりも少ない大きな演算を優先する。これにより算術強度が最大化され、ハードウェア利用率が向上し、スループットと対話性の両方が向上する。言い換えれば、幅広の Transformer モデルは深層モデルよりもハードウェア親和性が高い。

量子化を性能レバーとして活用する

量子化は、計算バウンドとメモリバウンドの両方の作業を支援します。数学的スループットを向上させ、同時にメモリトラフィックを削減できるためです。Blackwell システムは NVFP4 とともに FP8 や FP16/BF16 などの他のビット幅フォーマットをサポートします(下の Figure 6 を参照)。

Bar chart of dense Tensor Core throughput on GB300: about 2.5 PFLOPS for FP16/BF16, 5 for FP8, and 15 for FP4.
Figure 6. データ型ごとの密な Tensor Core スループット

NVFP4 はモデル精度と速度のバランスを目的に設計されており、各 16 値マイクロブロックに細粒度の FP8 (E4M3) スケールを適用し、さらにテンソルごとに 2 段階目の FP32 スケールを適用します。この階層的スケーリングにより、量子化誤差を大幅に低減しつつ 4 ビット計算の速度を維持できるため、NVFP4 は幅広い LLM ワークロードで高精度に近い精度を実現できます(下の Figure 7、DeepSeek-R1 を参照)。

Grouped bar chart showing DeepSeek-R1 accuracy under NVFP4 staying within about one point of the FP8 baseline across seven benchmarks.
Figure 7. DeepSeek-R1 の NVFP4 による精度は FP8 ベースラインに非常に近く、ほとんどのベンチマークで約 1 ポイント以内に収まり、SciCode、Math-500、AIME 2024 では FP8 を上回る

NVIDIA はこれを現実的にするためのエンドツーエンドツールを提供しています。TensorRT Model OptimizerLLM Compressor は、post-training quantization (PTQ)、quantization-aware training (QAT)、および高度なキャリブレーションをサポートし、最小限の精度損失でモデルを NVFP4 に量子化できます。

その結果、線形レイヤなどの行列乗算が中心の演算のほとんどが、モデル忠実度を維持しつつ NVFP4 をフルに活用して高いスループットを実現できます。低ビット幅での学習の詳細については、Pretraining Large Language Models with NVFP4 (NVIDIA Research, 2025) を参照してください。

Guideline 4: ネットワークに計算コストの高い演算を導入する際は、デプロイ時に量子化可能かどうかを検討する。低精度実行の恩恵を受けられるレイヤを設計することが、現代の GPU の性能を最大限に引き出す鍵となる。

大規模エキスパート並列化がスループットを向上させる

スループット指向のサービングでは、目標はシンプルです。可能な限り多くのユーザーを、可能な限り高速に、可能な限り少ない GPU で処理することです。最先端の LLM の多くが Mixture-of-Experts (MoE) モデルである現在、これを実現する非常に効果的な方法がエキスパート並列化 (EP) です。attention をデータ並列化し、FFN エキスパートを GPU 間で分散させます。

attention にデータ並列化 (DP) を用いることで、tensor 並列化 (TP) の主要な制約である部分結果を結合するための高コストな AllReduce を回避できます。このオーバーヘッドは並行度とともに増大し、スループットを低下させるため、TP はこの用途には適していません。DP attention はより自然にスケールします。GPU を追加するとグローバル並行度が直接上昇し、並行度が高いほど MoE FFN 内の GEMM-M が大きくなります。

トークンルーティングが均一であると仮定すると:

\(\text{GEMM-}M = \frac{\text{global concurrency} \times \text{top-}k}{\#\text{experts}}\)

ここで global concurrency は GPU あたりの並行トークン数 × GPU 数、top-k はトークンあたりに活性化されるエキスパート数(DeepSeek-R1 では 8)、#experts はエキスパート総数(DeepSeek-R1 では 256)です。GEMM-M は並行度とともに増加し、モデルのスパース度とともに減少するため、並行度を押し上げることがスパース MoE モデルにおける高い GEMM 利用率の鍵となります。また、1 GPU あたりの並行度は KV キャッシュのフットプリントによって上限があるため、EP をより多くの GPU に拡大することがこれを引き上げる主要な手段となります。

各エキスパートの有効バッチ(GEMM-M)が並行度の制限やトークンルーティングの不均衡により小さくても、EP を拡大することは 2 つの点で役立ちます:

  1. 集約帯域幅による高速実行:より多くの GPU にエキスパートを分散させることで、エキスパート重みのロードに利用可能な有効メモリ帯域幅が増加し、エンドツーエンドの FFN レイテンシが低減します。
  2. 1 GPU あたりのメモリフットプリントの削減:各 GPU がエキスパートの一部のみを保持するため、メモリが解放され、1 GPU あたりの有効並行度を増加させ、計算をより飽和させることができます。

EP には all-to-all 通信オーバーヘッドとエキスパート負荷不均衡という 2 つの課題がありますが、NVIDIA の TensorRT-LLM の Wide-EP 機能が両方に対応します:

  • Blackwell マルチノード NVLink システム上で EP をスケールする高性能 all-to-all カーネル
  • 実時間負荷パターンに基づいてエキスパートトラフィックを再分散し、偏ったトークン・エキスパート分布下でも安定を保つ適応型ロードバランサ

詳細は TensorRT-LLM のエキスパート並列スケーリングに関する ドキュメント を参照してください。スループット指向の MoE デプロイメントでは、エキスパート並列化が主要なレバーとなります。

Guideline 5: 多数のエキスパートを持つ複雑でスパースな MoE モデルでも、適切な並列化戦略、特にエキスパート並列化を広くスケールさせることで高いスループットを実現できます。

パイプライン並列化を考慮した設計

パイプライン並列化は、prefill と decode を分離する場合に関連します。これは特定のモデルサイズ、トラフィックパターン、レイテンシ目標に対して有効なサービング戦略となり得ます。NVIDIA Research の Beyond the Buzz: A Pragmatic Take on Inference Disaggregation (2025) で分析したように、prefill と decode を異なるモデル分割で実行することで、それぞれを個別に最適化・スケールし、全体的なスループットを向上させることができます。

prefill では、高いスループットを維持しつつ、特に長文脈での first-token latency (FTL) を低減するために積極的な並列化が必要です。Chunked Pipeline Parallelism (CPP) がこの用途に適しています。モデルレイヤを GPU 間で分割するとともに、入力コンテキストをパイプラインを流れるチャンクに分割します(下の Figure 8 を参照)。

Diagram of a two-stage pipeline where input token chunks flow through the stages over time, so layers and chunks process in parallel.
Figure 8. Chunked Pipeline Parallelism はトークンとレイヤを GPU 間で分割してパイプライン実行を実現

これにより、prefill ワーカーは広い tensor 並列化に頼ることなく、厳しい FTL 予算内で長いシーケンスを処理できます(下の Figure 9 を参照)。

Chart showing that as pipeline-parallel size grows from 1 to 32, first-token latency drops steadily while tokens/s/GPU stays roughly constant.
Figure 9. Chunked Pipeline Parallelism はスループットを犠牲にせずに FTL を低減。例:DeepSeek-R1 の 256K 入力長 prefill で、パイプライン並列サイズを増加させると FTL が低下し、tokens/s/GPU はほぼ一定に保たれる

CPP が効果を発揮するには、パイプラインステージがバランスしている必要があります。不均衡なステージはパイプラインバブルを引き起こし、一部の GPU をアイドル状態にします。ステージをバランスさせる効果的な方法は、均等に分割可能な繰り返し可能なレイヤパターンでモデルを構築することです。

Guideline 6: モデルを、バランスの取れたパイプラインステージに容易に分割できる規則的で繰り返し可能なレイヤパターンで設計する。これにより、Chunked Pipeline Parallelism に適したモデルとなり、厳しい first-token latency 目標を満たしつつ高いスループットを実現できる。

レイテンシ指向のサービス目標を満たすハイブリッド並列戦略

ここまではスループットに焦点を当ててきました。レイテンシ指向のサービングは異なる制約に従います。低レイテンシを実現するには、1 GPU あたりの作業量を減らす(並行度を下げる)か、GPU を増やす必要があります。しかし、バッチを小さくしても最終的には attention レイテンシしか低減できません。FFN レイテンシは、GEMM-M が小さくなっても GEMM-N と GEMM-K の次元が大きいためメモリバウンドになり、\(N \times K\) 行列の重み読み込みがボトルネックとなります。

この低並行度領域では、attention と FFN を独立して並列化する必要があります。FFN は TP、EP、または TP×EP で重みを GPU 間に分散させることで高速化できます。TP は大きなエキスパートを持つ粗粒度 MoE モデルに適し、EP は細粒度 MoE モデルに適します。細粒度 MoE モデルでは \(H'\) が小さいため、TP では非効率的に小さな GEMM が生成されるためです。

一方、attention は TP と KV 並列化の恩恵を受けます。ただし、TP は KV ヘッド数までしかスケールせず、それを超えると KV キャッシュを複製する必要が生じ、冗長な作業が発生します。現代の MQA/GQA/MLA モデルは KV ヘッド数が少ないため、すぐにボトルネックになります。Helix Parallelism (NVIDIA Research, 2025) は、attention 中に KV キャッシュをシーケンス次元でシャーディングし、FFN では同じ GPU を TPxEP に再利用することでこの問題を克服します。Helix は TensorRT-LLM でサポートされています。これらのハイブリッド方式では追加の通信が発生しますが、Blackwell NVL72 の高帯域幅 NVLink ファブリックがその大部分を吸収し、残りは計算とオーバーラップさせることができます。

Guideline 7: モデルとデプロイメントを設計する際は、attention と FFN の並列化を分離し、GPU をスケールすることで支配的なボトルネックを戦略的に狙って対話性を向上させる。

次のステップ

次のモデルを設計する際は、これらのガイドラインを設計チェックリストとして活用してください:

  • 次元を正方形に近く、128(理想的には 256)の倍数に保つ
  • 深さよりも幅を優先する
  • 低精度(NVFP4)実行向けにモデルを設計する
  • パイプライン並列化にきれいにマッピングできる規則的で繰り返し可能なレイヤパターンを用いる

このような小さな選択が GPU 利用率を有意に向上させ、同じハードウェアからより高速な推論、より高いスループット、より優れた対話性を実現できます。

これらを実践するには、NVFP4 量子化には NVIDIA TensorRT Model Optimizer を、エキスパート、パイプライン、Helix 並列化 には TensorRT-LLM をご覧ください。