AI モデル共設計：ハードウェアに優しい大規模言語モデルの設計

AI の性能は、主に以下の3 つの次元で決まります。

• 精度: モデルが推論を行い、出力を生成する能力
• スループット: データセンターが 1 秒間に生成できるトークン数
• 対話性: ユーザーに対する応答速度。これはレイテンシによって大きく左右されます

実際の運用では、これら3 つの要素をバランスよく調整する必要があります。精度が高くても応答が遅ければ意味がなく、スループットが速くてもユーザー体験にラグが生じれば価値は半減します。そのため、実用的なシステムでは精度・スループット・対話性を総合的に最適化することが求められます。

本稿では、精度を犠牲にすることなくスループットと対話性を高めるためのモデル設計の選択について解説します（精度とのトレードオフが生じる場合はその旨を明記します）。

精度を一定に保った場合、問題は2 次元のパレートフロンティアの問題となります。一方を改善すれば他方が犠牲になることが一般的です。目指すべきは、このフロンティア全体を外側に押し広げ、曲線下の面積を最大化することです（図 1 を参照）。

まずは、現在最も注目されている AI ワークロードである大規模言語モデル（LLM）から始めましょう。このトレードオフには 2 つの視点があります。

1 つ目はシステムデプロイヤーで、ファーム全体の処理能力（秒間トークン数）を最優先します。もう 1 つはユーザーで、最初のトークンまでの遅延やトークン間の遅延が短いことを重視します。トークン間の遅延の逆数が「ユーザーあたりの秒間トークン数」であり、この値が高いほど応答性は高まります。

単一のレスポンスの流れは以下のようになります。

プロンプト → [最初のトークンまでの遅延] → 最初のトークン → [トークン間の遅延] → 次のトークン …

これは、最新のハードウェア上でモデルを円滑に動かしたい開発者向けの実践的な入門書です。考え方はシンプルです。ハードウェアと整合性の取れたモデルは、単に高速で動作するだけでなく、スケーラビリティも向上し、コストを抑えられ、より広い採用につながります。

まず、デプロイメントの状況を 2 つの軸で捉えてみましょう（以下の図 2 を参照）。

ワークロードは短いコンテキストから長いコンテキストまで多岐にわたり、サービス目標も「処理能力重視（秒間トークン数の最大化）」から「応答速度重視（レスポンス時間の最小化）」まで様々です。その中間に位置するケースも多く存在します。

各ユースケースには異なる最適化が必要です。コンテキスト長が長くスループット重視の推論では、処理時間の大半をアテンションが占めます。一方、レイテンシを最優先する推論では、アテンションとFFN（フィードフォワード層）の時間を短縮するためにモデル並列性を導入しますが、その代償として通信コストや固定オーバーヘッドが増加します。

コンテキスト長が短くスループット重視のケースでは、アテンションとFFN の処理時間がより均等に配分されるため、大規模展開時にはエキスパート並列性などの並列化手法から恩恵を受けられます。

アンダールの法則が適用されます。ある部分を最適化しても、その部分が占める実行時間の割合に応じた効果しか得られません。もしアテンションが実行時間の 77% を占めているなら、フィードフォワード層のチューニングによる改善は限定的なものに留まります。投資対効果が高いのは、アテンション経路を最適化するところにあります。自分がどの運用モードにいるかを把握することが、どこに集中すべきかを判断する鍵となります。

この投稿では、システムエンジニアでなくてもハードウェアから最大限の性能を引き出すための、意思決定のための簡単な指針を提供します。本シリーズの各章では、ハードウェアを意識した設計の異なる側面を取り上げ、計算ボトルネックの回避やデータセンター規模での円滑なデプロイ、ユースケースに合わせた設計の実現、そして実践的なスケーリングを支援します。

賢く設計し、迅速に展開し、幅広くスケールさせる。それでは始めましょう。

LLM の線形層におけるハードウェアフレンドリーなサイズ設計

トランスフォーマーの設計において重要な選択の一つがアスペクト比、つまりモデル幅と層数（L）のバランスです。デコーダー型モデルでは、これらの要素がスタック全体における計算とメモリの配分を決定づけます。モデル幅自体は、MLP 層における隠れ次元（H）と中間投影次元（H prime）という 2 つの次元によって設定されます。

H、H′、L の 3 つの要素は、モデルが並列化戦略にどれだけきれいに適合し、GPU 間でどのようにスケーリングするかを決定します。本稿では、これら 3 つの選択がスループット、対話性、そして拡張性にどう影響するか、特に線形層（linear layers）に焦点を当てて解説します。

演算強度の役割 （原文の技術表記: H prime）

ハードウェア上の性能は、ロフライモデルによって上限が決まります。ワークロードがどこに位置するかは、その演算強度（arithmetic intensity）によって決まります。これは、移動するメモリ 1 バイトあたりに行われる計算操作の数を指します。

演算強度が低いワークロードはメモリの帯域幅によって制限され（メモリーバウンド）、一方、演算強度が高いものはデバイスのピーク演算スループット（FLOPS）によって制限されます。最大の処理能力（1 秒あたりのトークン数）を追求する場合、ハードウェアの計算能力を最大限に活用するために、ワークロードを計算バウンド領域へ導く必要があります。

一方、レイテンシが敏感なデコーディングは逆で、並行度が低く動作するためメモリーバウンドになります。そのため、応答時間の短縮にはメモリアクセス時間の削減が鍵となります。

図 3：ルーフラインモデル。リッジポイントより下ではワークロードはメモリー帯域幅によって制限され、上ではデバイスのピーク演算スループットによって制限されます。ワークロードの演算強度（1 バイトあたりの演算回数）が、どちらの領域に属するかを決定します。

1 バイトあたりの演算数を上げる簡単な方法としてバッチサイズを増やす手がありますが、モデルの形状も重要です。ここでは H と H prime が GEMM を計算集約型にするかメモリ集約型にするかをどう決定するかを見ていきましょう。

単一デバイス上で実行する際、H と H prime は、以下の形式の行列積（GEMM）の形状を決定します。

C equals A B

一般的な線形代数ライブラリで用いられる慣習に従えば、行列 A は M 行 K 列のサイズ（M × K）を持ち、B は K 行 N 列（K × N）となります。 （原文の技術表記: M times K、K times N）

製品 C は、長さ K の内積を M×N 個出力します。これには M×N×K 回の融合乗算加算（FMA）が必要です。 （原文の技術表記: M times N、M times N times K）

各FMA（乗算加算）は2回の浮動演算（FLOP）に相当するため、計算コストは以下のようになります。

FLOPs equals 2 times M times N times K

読み込みバイト数は、M × K × bytes_sub_A + N × K × bytes_sub_B に等しい。

書き込みバイト数は、M × N × bytes_sub_C に等しい。 （原文の技術表記: Read Bytes equals M times K times bytes sub A plus N times K times bytes sub B、Write Bytes equals M times N times bytes sub C）

ここで、bytes sub A comma B comma C は使用される精度によって設定される要素ごとのバイト数を表します。入力を A、重みを B とすると、以下の Table 1 がトークン数と対応しています。

トークン数は並列度とシーケンス長の積に等しく、これを各線形層における GEMM の M、N、K にそれぞれ対応させます。H と H プライムも同様にマッピングされます。 （原文の技術表記: Tokens equals concurrency times sequence length、H prime）

表1 トークン数、H、および H' を用いて表した、トランスフォーマーブロック内の線形層における GEMM 次元（M、N、K）

例えば、すべての行列積演算（GEMM）が「正方行列」である場合を考えます。つまり、トークン数が H' と H に等しい状態です。このとき、1 回の GEMM で約 2 H cubed FLOPs の計算が行われ、同時に約 3 H squared のデータ転送が発生します。 （原文の技術表記: Tokens equals H prime equals H）

メモリ要素の規模が大きくなるほど、演算強度は H に比例して増加します。

実務的な影響として、H または H' の値が小さい場合、トークン次元が大きかったとしても、GPU は計算よりもデータ転送に相対的に多くの時間を費やすことになります。 （原文の技術表記: H prime）

具体的な例として、GB300 上で 4 ビット入力と 8 ビット出力を用い、意図的に H prime equals 512 と H equals 8192 に設定した FFN-2 を考えてみましょう。下の Table 2 が示す通り、トークン数が多く GEMM-M の負荷が高い場合でも、この層は依然としてメモリーバウンド状態にあります。これはデータ転送がボトルネックとなっているためです。出力が FP8 で入力が FP4 というビット幅の違いにより書き込みコストが大きくなること、そして縮小次元が小さいために GEMM がメモリーバウンドに陥ることが主な原因です。

表2：GB300上におけるFFN-2の理論的な1 GEMMあたりの所要時間（N=8192、K=512）。ピーク演算性能をFP4で15 PFLOPS、ピークメモリ帯域を8 TB/sと仮定。トークン数に関わらずメモリアクセス時間が計算時間を上回るため、この層は常にメモリーバウンド状態にある

図 4 のプロットは、GB300 シリコン上でのこの挙動を示しています。NVFP4 GEMM（行列積）においてトークン次元（GEMM-M）を固定した大規模な 8192 とし、削減次元（GEMM-K）と射影次元（GEMM-N）それぞれをスweep して評価しました。左側が削減次元、右側が射影次元の結果です。どちらの場合も、スweep する次元の値が小さいとスループットが急激に低下します。これは、N または K の値が小さいとハードウェアが十分に活用されていないことを裏付けています。

（N と K は層によって H または H プライムに対応します。詳しくは上記の表 1 を参照してください。） （原文の技術表記: H prime）

図 4（左側）。GB300 における NVFP4 GEMM のスループットと、削減次元 K の関係（M=8192, N=9728 は固定）。

K が約 6144 に近づくと飽和し、持続スループットの 80% を達成するには K が 3072 より大きくなる必要があります。

図 4（右側）。GB300 における NVFP4 GEMM のスループットと投影次元 N の関係（M=8192、K=8448 は固定）。

N が約 6144 に近づくと飽和し、持続スループットの 80% を達成するには N > 2560 が必要です。

モデル設計者にとって重要な点は、計算リソースを最大限に活用するにはバッチサイズだけでなく、モデルの次元数も同様に重要だということです。

ガイドライン 1: パラメータ数が固定されたモデルでは、重み行列がほぼ正方形になるよう設計し、投影（projection）または縮小（reduction）のどちらかの次元を極端に小さくしないようにしてください。

しかし、サイズだけで十分ではありません。高い Tensor Core の利用率を達成するには、GEMM の次元数が基盤となるタイル幾何学構造にきれいにマッピングされる必要があります。アライメントが悪いとタイルの量子化が発生し、演算強度が高くてもスループットが低下してしまいます。

GPU における GEMM の実行方法

GPU は出力行列を複数のタイルに分割し、それぞれのタイルをストリーミングマルチプロセッサ（SM）が計算することで GEMM を実行します。最近の GPU では、SM が単独で動作する必要はありません。SM は協調してより大きな 1 つのタイルを処理できます。「clusterMMA」では隣接する 2 つの SM が協力して 1 つのタイルを担当し、「Cooperative Grid Array（CGA）」を使えば、複数の SM をまとめて 1 つのクラスターとして連携させることも可能です。

協調処理によりデータ再利用性は向上しますが、その分、有効なタイルサイズが大きくなるため、アライメントを保つには次元値がより大きな値の倍数である必要があります。もしある次元がこの有効タイルサイズの倍数でない場合、エッジ部分のタイルは部分的にしか埋められませんが、それでもフルサイズの計算として起動・実行されてしまいます。その結果、パディングされた不要な部分は実質的な作業を行わず、サイクルを浪費してスループットが低下します。

図 5 はこの現象を示しています。ベースタイルサイズが 256×128 で、clusterMMA と 4×2 の CGA を使用した場合、GEMM-N を微細なステップでスイープすると、N が 256（clusterMMA から 2×128）または 512（CGA から 2×256）の倍数であるときにローカルスループットの極大値が得られます。

こうした無駄を避けるには、モデルの次元値をタイルサイズの大きな倍数とし、GPU のキャッシュライン幅とも整合させることが重要です。安全かつ移植性の高い下限として 128 の倍数を選ぶのが妥当です。より高いスループットを得るためには、clusterMMA や CGA によって形成される大きなタイルに合わせるため、256 または 512 の倍数を優先すべきです。

*ガイドライン 2: * モデルの次元値は少なくとも GPU のタイルサイズおよびキャッシュライン幅に合わせて 128 の倍数とし、clusterMMA や CGA が形成する大きなタイルに合わせるため、256 または 512 を優先すること。

パラメータ予算が固定された場合、幅広モデルの方が深層モデルよりハードウェアに優しい

パラメータ数が一定の場合、幅広モデルは重みの再利用率が高く、逐次的なクリティカルパスが短いため、深層モデルよりも高い演算強度と低レイテンシを実現します。この特性により、スループット重視のサービス目標にも、レイテンシ重視の目標の両方において有利に働きます。

ただし、アスペクト比はモデルの品質にも影響を与えます。表現力には深さが寄与するため、「幅広であるほど常に良い」という単純な話ではなく、精度が保たれる範囲内で幅を広げる「適切な幅と深さのバランス帯」が存在します。モデルを単に広くするために層を削るのではなく、精度が損なわれない限り幅優先で設計するのが適切です。

*ガイドライン 3:** 選択肢がある場合は、多数の小さな演算よりも少数の大きな演算を選ぶべきです。これにより演算強度が最大化され、ハードウェアの利用効率が向上し、スループットと対話性の両面でメリットが生まれます。つまり、幅広のトランスフォーマーモデルの方が、深層モデルよりもハードウェアに優しいのです。

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

量子化は、計算リソース制約のあるワークロードとメモリ制約のあるワークロードの両方において、数学演算のスループットを高めつつメモリアクセス量を同時に削減することで効果を発揮します。Blackwell システムでは、NVFP4 に対応しており、その他にも FP8 や FP16/BF16 など様々なビット幅フォーマットをサポートしています（図 6 を参照）。

NVFP4 はモデルの精度と速度のバランスを最適化するために設計されています。この方式では、16 値からなるマイクロブロックごとに微細な FP8 (E4M3) スケールを適用し、さらにテンソル単位で第 2 レベルの FP32 スケールを追加します。こうした階層的なスケーリングにより量子化誤差が劇的に削減されつつ、4 ビット演算の高速性が維持されます。その結果、NVFP4 は幅広い LLM ワークロードにおいて高精度モデルに匹敵する精度を実現します（図 7、DeepSeek-R1 を参照）。

NVIDIA はこの実現を支援するエンドツーエンドのツールを提供しています。NVIDIA Model Optimizer や LLM Compressor では、ポストトレーニング量子化（PTQ）、量子化意識トレーニング（QAT）、高度なキャリブレーションに対応しており、精度の低下を最小限に抑えながら NVFP4 形式への量子化が可能です。

その結果、線形層など行列乗算を多用する演算は、NVFP4 をフル活用してスループットを最大化しつつ、モデルの精度も維持できます。低ビット幅でのトレーニングの詳細については、NVIDIA Research（2025 年）が発表した Pretraining Large Language Models with NVFP4 をご覧ください。

*ガイドライン 4:* 計算コストの高い演算をネットワークに導入する際は、推論時に量子化可能かどうかを検討してください。低精度実行で恩恵を受けられるレイヤーを設計することが、現代の GPU の性能を最大限引き出す鍵となります。

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

スループット重視のサービスでは目標はシンプルです。「可能な限り少ない GPU で、できるだけ多くのユーザーを、できるだけ高速に処理する」ことです。現在、最先端の大規模言語モデル（LLM）の多くが Mixture-of-Experts (MoE) 構造を採用しているため、これを達成する最も効果的な手法の一つがエキスパート並列性（EP）です。具体的には、アテンション演算にはデータ並列性を適用し、FFN のエキスパートを複数の GPU に分散させるアプローチです。

アテンションにデータ並列性（DP）を採用することで、テンソル並列性（TP）が抱える重大な制限を回避できます。それは、部分的な結果を結合するために必要な高コストな AllReduce 演算です。このオーバーヘッドは同時実行数が増えるほど大きくなり、スループットを低下させるため、この用途には TP は不向きです。一方、DP を用いたアテンションはより自然にスケールします。GPU を追加することでグローバルな同時実行数が直接向上し、その結果、MoE の FFN における GEMM-M の規模も大きくなります。

トークンのルーティングが均一であると仮定した場合：

GEMM から M を引いた値は、分子が「グローバルな並行処理数 × 最大 k」と分母が「専門家の総数」である分数で表されます。

ここでいうグローバルな並行処理数とは、1 つの GPU あたりの同時トークン数に GPU 台数を掛けたものです。top-k は 1 トークンあたり活性化される専門家の数（DeepSeek-R1 では 8）、#experts は専門家の総数（DeepSeek-R1 では 256）です。

GEMM-M は並行処理が進むほど大きくなり、モデルのスパース性が高まると小さくなるため、スパースな MoE モデルで GEMM の利用率を高める鍵は並行処理を増やすことにあります。一方、GPU あたりの並行処理数は KV キャッシュのサイズによって上限が決まっているため、EP（Expert Parallelism）の幅を広げてより多くの GPU に専門家を分散させることが、並行処理数を引き上げる主要な手段となります。

各専門家の実効バッチサイズ（GEMM-M）が小さくても、並行処理数の不足やトークンのルーティングの偏りによるものであっても、EP の幅を広げることは 2 つの点で有効です。

• アグリゲート帯域幅を活用した高速化：専門家をより多くの GPU に分散させることで、専門家重みの読み込みに利用可能な実効メモリ帯域幅が増え、FFN（Fully Connected Feedforward Network）全体のレイテンシが短縮されます。

• GPU あたりのメモリ使用量の削減：各 GPU は専門家の一部のみを保持するため、メモリに余裕が生まれ、GPU あたりの実効並行処理数を増やして計算リソースをより効果的に活用できます。

EP には「all-to-all コミュニケーションのオーバーヘッド」と「専門家間の負荷偏り」という 2 つの課題がありますが、NVIDIA の TensorRT-LLM に搭載された Wide-EP 機能は、これら両方の課題に対応しています。 （原文の技術表記: GEMM minus M equals the fraction with numerator global concurrency times top minus k and denominator number sign experts）

Blackwell マルチノード NVLink システム上で EP（エキスパート並列）をスケーリングする高性能なオール・トゥー・オールカーネルと、歪んだトークンやエキスパートの分布下でも安定性を保つために、リアルタイムの負荷パターンに基づいてエキスパートトラフィックを再分配する適応型ロードバランサーを実装しています。

詳細は、TensorRT-LLM のドキュメントにあるエキスパート並列スケーリングに関するページをご覧ください。スループット指向の MoE（Mixture of Experts）デプロイにおいて鍵となるのは、エキスパート並列です。

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

パイプライン並列化を意識した設計

プリフィルとデコードを分離する（disaggregate）場合、パイプライン並列化が重要になります。これは特定のモデルサイズやトラフィックパターン、レイテンシ要件に対して効果的なサービング戦略となり得ます。NVIDIA Research が 2025 年に発表した「Beyond the Buzz: A Pragmatic Take on Inference Disaggregation」で分析した通り、プリフィルとデコードに異なるモデル分割を適用することで、それぞれを個別に最適化・スケールでき、結果として全体のスループットが向上します。

事前処理（prefill）では、特に長いコンテキストにおいてスループットを維持しつつ最初のトークンまでの遅延（FTL）を削減するために、積極的な並列化が求められます。この用途には、チャンクド・パイプライン・パラレリズム（CPP）が非常に適しています。CPP はモデル層と入力コンテキストの両方をチャンクに分割し、それらがパイプライン内を流れるように処理します（図 8 を参照）。

これにより、事前処理ワーカーは広範なテンソル並列化に頼ることなく、厳しい FTL の制約の中で長いシーケンスを処理できるようになります（図 9 を参照）。

Figure 9. Chunked Pipeline Parallelism reduces FTL without sacrificing throughput. Example: DeepSeek-R1 prefill at 256K input length, increasing pipeline parallel size redu