LLM（大規模言語モデル）を使ったサービスで、応答が思ったより遅い、GPUを増やしてもスループットが伸びない、という状況に心当たりがあるなら、原因はモデルの大きさではなく「メモリ帯域幅」かもしれません。この記事では、推論基盤の選定やコスト試算をする開発者・SREの方に向けて、LLM推論のボトルネックの正体と、その確認方法を整理します。
GPUを積めば積むほど速くなるという前提で設計を進めていると、あるところから費用対効果が急に悪化します。これは設定ミスではなく、GPUというハードウェアの構造的な制約に起因する現象です。
何が起きるか: 「計算が遅い」ように見えて実は「待っている」
LLMの推論には性質の異なる2つの処理があります。ひとつは prefill（プリフィル）です。ユーザーが入力したプロンプト全体を一度に読み込んで解析する処理で、複数トークンを並列に計算できます。行列演算がまとまって発生するため、GPUの並列演算能力をフルに活かせる場面です。
もうひとつが decode（デコード）です。モデルが回答を1トークンずつ生成する処理を指します。50番目のトークンを作るには49番目のトークンが確定していないといけないため、並列化ができません。
さらに厄介なのは、1トークン生成するたびに、モデルの重み（パラメータ）をメモリからほぼ全量読み出す必要がある点です。たとえば700億パラメータのモデルなら、1トークンあたり約140GBのデータをメモリから演算ユニットへ転送します。これをトークンの数だけ繰り返します。
この結果、GPUの演算ユニットは「計算が遅い」のではなく「メモリからのデータ転送を待っている」状態になります。業界ではこれを memory wall（メモリの壁）と呼びます。H100の場合、メモリ帯域幅は約3.35TB/sありますが、140GB/トークンという転送量の前では、演算能力に見合った速度が出ない場面が生じます。
なぜ起きるか: GPUは「計算装置」として設計されている
GPUはもともと画像処理向けに、大量の並列演算をこなすために設計されたハードウェアです。深層学習の学習フェーズやprefillのような「並列に大量の演算をする」用途とは相性が良い一方、decodeのように「1つずつ順番に、かつメモリ依存の強い」処理には最適化されていません。
演算性能を示す指標としてFLOPS（1秒あたりの浮動小数点演算回数）がよく語られますが、decodeが支配的なワークロードでは、FLOPSよりもメモリ帯域幅（GB/sやTB/s単位）のほうが実効速度を決めます。これがいわゆる「compute-bound（演算律速）」と「memory-bound（メモリ律速)」の違いです。
この構造を正面から突いた専用チップの例が、2016年創業のGroq（グロック）です。創業者のJonathan RossはGoogleのTPU（Tensor Processing Unit）初代の開発リーダーを務めた人物で、「AIの性能を決めるのは演算力ではなくメモリ帯域幅になる」という予測のもとにアーキテクチャを設計しています。GPU以外の選択肢が生まれている背景には、この「メモリの壁」への対応という共通の課題があります。
自分のプロジェクトが該当するか確認する方法
自社の推論基盤がこの制約の影響を受けているかどうかは、いくつかの角度から確認できます。
- ワークロードの性質: 長い出力を生成するチャットボットやエージェント型アプリ（複数回のモデル呼び出しを連鎖させる構成）は decode 比率が高く、影響を受けやすい構成です
- バッチサイズの設定: 推論サーバー（vLLMやTensorRT-LLMなど）の設定でバッチサイズが小さいままだと、メモリ帯域の使用効率が低いまま運用している可能性があります
- GPU使用率とメモリ帯域使用率の乖離:
nvidia-smi dmonなどでSM使用率（演算ユニットの稼働率）とメモリ帯域使用率を並べて見て、演算は暇なのに転送だけ埋まっている状態がないか確認します - モデルサイズとレイテンシの関係: パラメータ数を2倍にしたときにレイテンシがほぼ比例して伸びるなら、memory-boundな挙動をしている兆候です
- 出力トークン数とスループットの相関: 出力が長いリクエストほど1トークンあたりの処理時間が悪化していないか、APIのレスポンスタイムのログを確認します
クラウドでGPUインスタンスを借りている場合は、インスタンスタイプの仕様表でメモリ帯域幅（Memory Bandwidth）の欄を必ず確認してください。VRAM容量だけを見て選ぶと、容量は足りていても帯域幅が足りず、decodeが遅いままということが起こり得ます。
対策の手順
メモリの壁の影響を軽減するために、実際に試せる対策を段階的に整理します。
1. 推論エンジンの見直し: vLLMのPagedAttention（KVキャッシュをページ単位で管理する仕組み)や、continuous batching（複数リクエストを動的にまとめてバッチ処理する機能)に対応したサーバーへの切り替えを検討します。これによりメモリ転送の無駄を減らせます
2. 量子化の適用: モデルの重みをFP16からINT8やINT4に圧縮すると、1トークンあたりの転送データ量そのものが減ります。精度低下とのトレードオフを評価する必要はありますが、decode速度の改善に直結します
3. Speculative decoding(投機的デコード)の検討: 小さい補助モデルで複数トークンを先に予測し、大きいモデルでまとめて検証する手法です。1回のメモリ読み出しで複数トークン分を処理できるため、実効的な帯域効率が上がります
4. ハードウェア選定の見直し: 帯域幅重視のワークロードであれば、GroqのLPU(Language Processing Unit)や、AWSのInferentia2のような推論特化チップの評価も選択肢に入ります。ベンチマークは自社のプロンプト長・出力長に近い条件で取ることが前提になります
5. バッチサイズとレイテンシのトレードオフ調整: バッチサイズを上げるとスループットは改善しますが、個々のリクエストのレイテンシは伸びます。SLA(サービス品質保証)に応じて許容範囲を先に決めてからチューニングします
# GPUのSM使用率とメモリ帯域の目安を簡易確認する例
nvidia-smi dmon -s um -c 5上記コマンドで sm（演算ユニット使用率）と mem（メモリ使用率）を並べて見て、memが高くsmが低い状態が続くようであれば、メモリ律速の傾向が出ていると判断する材料になります。
まとめ
LLM推論が遅い原因は、GPUの演算性能不足ではなく、モデルの重みをメモリから読み出す転送量そのものであることが少なくありません。
次に自社の基盤を見直す際は、まず nvidia-smi dmon などでSM使用率とメモリ帯域使用率を並べて確認し、memory-boundな挙動が出ていないか調べてみてください。
そのうえで、推論エンジンのcontinuous batching対応状況、量子化の適用余地、GPUインスタンスのメモリ帯域幅スペックの3点を順に見直すと、コストと速度のバランスを取りやすくなります。