GPUパフォーマンスチューニング：LLMのトレーニングと推論におけるスループット最大化

2025年12月8日更新

2025年12月アップデート： FP8トレーニングがH100/H200およびBlackwellで本番環境対応となり、FP16と同等の精度で2倍のスループットを実現。Hopperアーキテクチャ向けに最適化されたFlash Attention 3が1.5〜2倍の高速化を達成。vLLM 0.6+とTensorRT-LLMが継続的バッチ処理と投機的デコーディングにより、推論スループットを3〜5倍向上。torch.compileとTritonバックエンドがPyTorch 2.4+でデフォルトに。NVIDIA NeMo Framework 2.0がエンドツーエンドで最適化されたトレーニングパイプラインを提供。

完璧に設定された8-GPUノードは理論FLOPSの98%を達成する一方、チューニングが不十分な同一システムは43%にとどまり、年間38万ドルの未活用ハードウェアコストを浪費しています。¹ MLPerfベンチマークによると、トップパフォーマーは同一のH100 GPUから中央値の提出者と比較して2.3倍のスループットを引き出しており、その差はハードウェアの優位性ではなく、完全にソフトウェア最適化に起因しています。² 理論性能と実際の性能のギャップはすべてのAIチームを悩ませており、たった1つのパラメータ設定ミスがトレーニング時間を2倍にしたり、推論コストを3倍にしたりする可能性があります。GPUパフォーマンスチューニングをマスターした組織は、デフォルト設定を使用する競合他社と比較して、モデルトレーニングを60%速く完了し、トークンあたり40%低いコストで推論リクエストを処理しています。

NVIDIAの最適化ガイドは、異なるフレームワーク、カーネル、設定にわたって1,200ページに及びますが、ほとんどのチームは複雑さと時間の制約により、利用可能な最適化の20%未満しか実装していません。³ 典型的なLLMトレーニングには、メモリ割り当て、カーネルスケジューリング、通信パターン、数値精度に影響を与える300以上のチューニング可能なパラメータが含まれます。各パラメータは非線形な方法で他のパラメータと相互作用します：バッチサイズを増やすとGPU使用率は向上しますが、メモリ不足エラーを引き起こしたり、収束を悪化させたりする可能性があります。最適化空間は非常に広大で、網羅的な探索は不可能であり、性能向上とエンジニアリング工数のバランスをとる体系的なアプローチが必要です。

メモリ帯域幅のボトルネックがLLM性能を制限

最新のLLMは、計算限界に達するはるか前にメモリの壁にぶつかります。H100の3.35TB/sメモリ帯域幅は1,979 TFLOPSの計算を支え、591:1の計算対メモリ比を生み出します。⁴ LLM推論は各トークン生成でモデル重みを繰り返し読み取るため、メモリ帯域幅が制約要因となります。FP16精度の70Bパラメータモデルは重みだけで140GBを必要とし、H100メモリ全体を消費してアクティベーションとKVキャッシュのスペースがほとんど残りません。

メモリ最適化はアクセスパターンの理解から始まります。シーケンシャル読み取りは理論帯域幅の95%を達成しますが、ランダムアクセスは15%に低下します。LLMは混合パターンを示します：重み読み取りはシーケンシャルのままですが、アテンションメカニズムはキーバリューキャッシュへの不規則なアクセスを生み出します。メモリレイアウトの最適化はスループットを劇的に向上させます。行優先と列優先のストレージは、特定の操作でメモリアクセス効率を4倍変化させます。テンソルを128バイト境界に揃えるようにパディングすると、帯域幅使用率が72%から91%に向上します。⁵

Flash Attentionは、演算を融合してHBMアクセスを削減することでメモリ効率を革新しました。標準的なアテンションメカニズムは中間行列をHBMに書き込み、一時データのために帯域幅を消費します。Flash AttentionはSRAMタイル内でアテンションを計算し、メモリトラフィックを10〜20倍削減します。⁶ この最適化により、GPT-3などのモデルで4倍長いコンテキスト長と2.4倍速いトレーニングが可能になります。実装にはGPUアーキテクチャに基づいた慎重なタイルサイズ選択が必要です：H100の最適タイルサイズは、SRAM容量の増加によりA100とは異なります。

バッチサイズ最適化はスループットと収束のバランスをとる

バッチを大きくするとGPU使用率は向上しますが、モデル収束に予測不可能な影響を与えます。各GPUはTensor Coreの次元によって決定される特定のバッチサイズの倍数で最も効率的に実行されます。H100 Tensor CoreはFP16演算を16x16の行列タイルで処理するため、16で割り切れるバッチサイズが最適です。⁷ バッチサイズ127は61%の使用率しか達成しませんが、バッチサイズ128は94%に達します。この劇的な違いは、ハードウェアスケジューリングが2のべき乗の次元と完全に一致することに起因します。

勾配累積により、メモリ制約なしで大きな実効バッチサイズが可能になります。バッチサイズ2048でのトレーニングはメモリを超過する可能性がありますが、バッチサイズ64の32ステップにわたって勾配を累積すると、同等の結果が得られます。この手法は数学的に等価でありながら、メモリ制限内に収まります。勾配同期の頻度が低くなるため、通信オーバーヘッドがわずかに増加します。スマートな実装は勾配計算と通信をオーバーラップさせ、レイテンシを完全に隠蔽します。

動的バッチサイジングは、LLMトレーニングにおけるシーケンス長の変動に適応します。固定バッチサイズはシーケンス長が変動するとパディングトークンで計算を浪費します。動的バッチ処理はシーケンスを効率的にパッキングし、スループットを20〜35%向上させます。⁸ メモリ割り当てが予測不可能になるため、実装の複雑さが増します。プーリングを伴う事前割り当て戦略により、性能を維持しながらフラグメンテーションを防ぎます。

混合精度トレーニングは精度損失なしで高速化

FP16でのトレーニングは、慎重な数値管理によりモデル品質を維持しながら、FP32と比較してスループットを2倍にします。Tensor CoreはH100 GPUでFP32で312 TFLOPS、FP16で989 TFLOPSを達成します。⁹ 3.2倍の計算優位性と2倍のメモリ節約が組み合わさり、より大きなモデルやバッチサイズが可能になります。Automatic Mixed Precision（AMP）フレームワークは精度管理を透過的に処理しますが、内部を理解することでより良い最適化が可能になります。

損失スケーリングはFP16トレーニングにおける勾配アンダーフローを防ぎます。勾配はしばしばFP16の最小表現可能値（5.96e-8）を下回り、ゼロとして現れて学習を停止させます。¹⁰ 損失を2^16倍することで、勾配をFP16の表現可能範囲にシフトさせます。動的損失スケーリングは勾配統計に基づいて乗数を調整し、アンダーフローとオーバーフローの両方を防ぎます。最適なスケーリング係数はモデルアーキテクチャとデータセットによって異なります。

FP32のマスター重みコピーは、FP16で計算しながら更新精度を維持します。大きな重みへの小さな勾配更新はFP16算術で消失します。FP32で重みを維持することで更新が正確に累積されます。オーバーヘッドは重みのメモリを50%追加しますが、計算コストは無視できます。高度な実装は確率的丸めを使用して適切なノイズを注入し、場合によっては収束を改善します。

カーネル融合がメモリボトルネックを排除

個別に起動するGPUカーネルは中間結果のためにメモリトラフィックを生成します。シンプルな層正規化には、平均、分散、減算、除算、スケーリングのための個別カーネルが含まれます。各カーネルはHBMからの読み取りと書き込みを行い、必要な帯域幅の5倍を消費します。融合カーネルはレジスタと共有メモリで全体の演算を計算し、入力と出力のみでHBMにアクセスします。

カスタムカーネルは特定のモデルアーキテクチャを最適化します。標準GEMMカーネルは一般的な行列乗算を処理しますが、Transformerブロックでの最適化機会を逃します。アテンション、フィードフォワードネットワーク、層正規化のための専門カーネルはスループットを30〜50%向上させます。¹¹ 開発にはCUDAの専門知識とアーキテクチャ固有のチューニングが必要です。ApexやTransformerEngineなどのライブラリは、一般的な演算のための最適化カーネルを提供します。

コンパイルフレームワークはグラフ最適化を通じてカーネル融合を自動化します。PyTorchのtorch.compileは計算グラフを分析し、融合カーネルを自動生成します。¹² XLAも同様にTensorFlowとJAXモデルを最適化します。コンパイルオーバーヘッドは長いトレーニングランで償却されます。初期コンパイルには数分かかりますが、その後のイテレーションは20〜40%速く実行されます。プロファイルガイド最適化は、観測された入力形状に特化することでさらに性能を向上させます。

分散トレーニングのための通信最適化

マルチGPUトレーニングには通信パターンの慎重な最適化が必要です。NCCL（NVIDIA Collective Communications Library）は最適化されたプリミティブを提供しますが、適切な設定が必要です。リングallreduceは理論的に帯域幅最適な通信を達成しますが、実際の実装は同期オーバーヘッドに悩まされます。ツリーアルゴリズムは小さなメッセージのレイテンシを削減し、リングアルゴリズムは大きな転送のスループットを最大化します。

ネットワークトポロジの認識は通信効率を劇的に向上させます。NVLink経由で接続されたGPUは900GB/sの双方向帯域幅を達成しますが、PCIeは64GB/sに制限されます。¹³ 頻繁に通信するGPUをNVLink接続ノードに配置する配置戦略は、通信時間を5分の1に削減します。階層型allreduceは、InfiniBand経由のノード間通信の前にNVLink上でローカルリダクションを実行します。

勾配圧縮は最小限の精度コストで通信量を削減します。top-k勾配のみを送信するか、INT8に量子化すると、トラフィックを100〜1000倍削減します。¹⁴ エラーフィードバックメカニズムは、切り捨てられた勾配を将来のイテレーションのために累積します。圧縮率はモデルのスパース性と勾配分布に依存します。適応スキームはトレーニングフェーズに基づいて圧縮を調整し、重要な収束期間中は圧縮を少なくします。

Introlのパフォーマンスエンジニアリングチームは、グローバルカバレッジエリア全体で10,000以上のGPUデプロイメントを最適化し、LLMワークロードで一貫して理論性能の85〜95%を達成しています。¹⁵ 当社の最適化プレイブックは、初日からハードウェア使用率を最大化しながら、デプロイメントまでの時間を40%短縮します。

推論固有の最適化

推論最適化はトレーニング最適化とは根本的に異なります。ユーザー向けアプリケーションではスループットよりもレイテンシが重要です。計算ではなくメモリ帯域幅がボトルネックになります。サービスコストが総費用を支配するため、効率が重要です。

キーバリューキャッシュ管理が推論効率を決定します。各トークン生成はKVキャッシュ全体を読み取り、シーケンス長に比例してメモリ帯域幅を消費します。PagedAttentionはKVキャッシュメモリを仮想化し、無駄を60%から5%未満に削減します。¹⁶ この手法により、長いシーケンスで4倍高いスループットが可能になります。実装には慎重なメモリプール管理とリクエストスケジューリングが必要です。

量子化はモデルサイズと帯域幅要件を削減します。INT8量子化はメモリ使用量を半分にしながら、ほとんどのモデルでFP16精度の99%を維持します。¹⁷ INT4は97%の精度保持で4倍の圧縮を達成します。量子化対応トレーニングは精度低下に堅牢なモデルを生成します。トレーニング後量子化は多くのモデルで機能しますが、キャリブレーションデータセットの選択が必要です。

継続的バッチ処理は、容量が利用可能になり次第新しいリクエストを開始することで推論スループットを最大化します。静的バッチ処理は新しいリクエストを開始する前にすべてのリクエストが完了するのを待ち、短いシーケンスでリソースを浪費します。継続的バッチ処理は可変長リクエストでスループットを2.5倍向上させます。¹⁸ 動的メモリ管理とスケジューリング要件により、実装の複雑さが増します。

実際の最適化結果

ケーススタディ1：金融サービスLLMトレーニング - モデル：70Bパラメータのカスタムアーキテクチャ - ハードウェア：64x H100 GPU - ベースライン：847トークン/秒/GPU - 最適化：Flash Attention、混合精度、勾配累積 - 結果：1,923トークン/秒/GPU（2.27倍の改善） - トレーニング時間が18日から8日に短縮 - コスト削減：トレーニングランあたり24万ドル

ケーススタディ2：ヘルスケア推論システム - モデル：13Bパラメータの医療アシスタント - ハードウェア：8x A100 GPU - ベースライン：トークンあたり142msレイテンシ、820トークン/秒スループット - 最適化：PagedAttention、INT8量子化、継続的バッチ処理 - 結果：47msレイテンシ、2,140トークン/秒（2.6倍スループット） - 百万トークンあたりコスト：$0.73 → $0.28

ケーススタディ3：Eコマースレコメンデーションエンジン - モデル：175BパラメータのMoEモデル - ハードウェア：128x H100 GPU - ベースライン：43% MFU（Model FLOPS Utilization） - 最適化：エキスパート並列処理、カーネル融合、トポロジ認識配置 - 結果：71% MFU（1.65倍の改善） - 推

[翻訳のためコンテンツを切り詰め]