大規模言語モデルの学習・運用を支える数学的基盤

LLM の「速さ」と「安さ」を決める数学的方程式：メモリ帯域幅とバッチサイズの真実

大規模言語モデル（LLM）の推論速度や API 価格がなぜそのようになっているのか、その核心には複雑なアルゴリズムではなく、ハードウェアの物理的な制約を数式で表した「Roofline モデル」があります。MatX CEO のライナー・ポップ氏は黒板の前で、バッチサイズやコンテキスト長が計算時間とメモリ帯域幅にどう影響し、システム全体の最適解（ゴールデンロックスゾーン）を決定するかを解説しました。

この分析を理解すれば、なぜ特定のモデルが高速なのに高価なのか、逆に低速だが安価なサービスが存在するのか、そして AI インフラ設計者が直面する根本的なトレードオフが見えてきます。

バッチサイズとレイテンシの数学的関係

推論にかかる時間（レイテンシ）は、単一の計算処理時間やメモリへのデータ読み込み時間の単純な合計ではありません。それは「計算に要する時間」と「メモリ帯域幅を介したフェッチに要する時間」の最大値として定義されます。

「バッチサイズが大きいほど計算量は線形に増加しますが、メモリ帯域幅の制約は一定に近い挙動を示します。この 2 つの曲線の交点が、最適なバッチサイズの存在を示唆しています。」

具体的には、モデルの重み（パラメータ）を読み込む時間と、推論中に生成される KV キャッシュ（Key-Value Cache）をフェッチする時間がボトルネックとなります。

• 計算時間の成分: アクティブなパラメータ数にバッチサイズを乗じた値を、チップの FLOPs（1 秒間の演算回数）で割ったもの。バッチサイズが大きくなるほど直線的に増加します。
• メモリ帯域幅の成分: アクティブなパラメータに加え、KV キャッシュのサイズも加わります。これはバッチサイズに依存しますが、コンテキスト長（文脈の長さ）が長いほど顕著になります。

多くのユーザーを同時に処理する「バッチ処理」を行わない場合、パフォーマンスは最大で 1000 倍低下する可能性があります。逆に、適切なバッチサイズで処理することで、GPU の計算リソースを効率的に使い切ることができます。

コンテキスト長がコスト曲線を変える仕組み

推論の速度とコストは、コンテキスト長（入力される文章の長さ）によっても劇的に変化します。これは KV キャッシュの管理方法に起因しています。

自己回帰的な推論では、新しいトークンを生成するたびに、過去のすべてのトークンに対する「注意（アテンション）」を計算する必要があります。これを効率化するために、過去のトークンの情報を保存したKV キャッシュが使用されます。

• KV キャッシュの増加: コンテキスト長が 100K から 200K に伸びると、キャッシュサイズも比例して増え、メモリ帯域幅からのデータ読み込み時間が延びます。
• ボトルネックの移行: コンテキストが短い間は計算能力（FLOPs）がボトルネックですが、コンテキストが長くなると、メモリ帯域幅がボトルネックとなります。これにより、レイテンシは急激に増加します。

「最適なコンテキスト長の範囲からわずかに外れても、MFU（モデルフロー利用率）は 50% に低下する可能性があります。これは、アーキテクチャの設計次第で改善される余地がある点です。」

現在主流の「密なアテンション」ではスケーリングが難しいため、業界はスパースアテンションやスペキュレーティブ・ディコーディングなどの技術に期待を寄せています。これらは、必要な部分のみを計算することで、コンテキスト長に対するコスト曲線の傾きを緩やかにする可能性があります。

Roofline モデルと「ゴールデンロックスゾーン」

システム設計の最適化において重要なのが、Roofline モデルと呼ばれる分析手法です。これは、計算リソース（FLOPs）とメモリ帯域幅（Bandwidth）のバランスが取れた状態を指します。

• Golden Locks Zone: 計算時間とメモリフェッチ時間がほぼ等しくなる点。ここで運用することで、MFU を最大化できます。
• 最適バッチサイズの算出: この平衡点を数式で解くと、多くの GPU では「スパースティ（非密度）の約 300 倍」程度のバッチサイズが最適解となります。例えば DeepSeek のようなモデルでは、アクティブなパラメータ数が少ないため、バッチサイズは数千トークン程度に設定されます。

「メモリ帯域幅が広い場合、重み読み込みに使えるリソースが相対的に減るため、より大きなバッチサイズで処理する必要があります。これはハードウェアの特性に依存する無次元定数によって決定されます。」

この最適解を外れると、GPU の計算能力が遊んでしまうか、メモリ帯域幅が溢れてレイテンシが増加します。API 価格設定はこの「ゴールデンロックスゾーン」での運用効率をベースに成り立っています。

メモリ容量の制約と並列化戦略のジレンマ

モデルが大きくなるにつれ、ボトルネックは計算性能からメモリ容量へと移行します。特に MoE（Mixture of Experts）アーキテクチャでは、この問題が顕著になります。

MoE では、入力されたトークンを複数の「エキスパート」にルーティングし、必要な専門家のみを呼び出します。これにより、パラメータ数は増大しても計算量は抑えられますが、メモリ容量の確保と通信コストという新たな課題が生じます。

• 並列化の難しさ: 256 のエキスパートを持つモデルを 72 基の GPU で実行する場合、GPU あたり 3〜4 つのエキスパートを割り当てる必要があります。しかし、各エキスパートは独立した GPU に配置されるため、トークンをルーティングする際にオールツーオール通信（All-to-All Communication）が発生します。
• ラック内の壁: データセンターでは、1 つのラック内（スケールアップ）と、ラック間（スケールアウト）で通信速度に 8 倍もの差があります。MoE の通信パターンがラックを超えて行くと、ネットワーク帯域幅がボトルネックとなり、システム全体のパフォーマンスが低下します。

「よりスパースなモデルにするには、より大きなバッチサイズが必要になります。しかし、それを実現するにはメモリ容量の増強と、ラック内での高速な通信インフラが不可欠です。」

現在のハードウェア設計では、ケーブルの密度や冷却能力の制約から、1 つのラックに収容できる GPU 数（64 基〜72 基程度）に限界があります。500 基を超える大規模なラックを実現するには、スイッチの配置や配線の複雑さが劇的に変化するため、技術的なハードルが高いのが現状です。

まとめ

LLM の推論速度とコストは、単なるアルゴリズムの良し悪しではなく、「計算性能」と「メモリ帯域幅」の物理的なバランス、そして「ラック内通信」というインフラ設計の制約によって決定されています。最適化のためには、バッチサイズをハードウェア特性に合わせて調整し、スパースアテンションや効率的な並列化戦略を採用することが不可欠です。この数学的基盤を理解することは、AI エンタープライズが API コストを最適化し、次世代のインフラ設計を行うための重要な指針となります。