AI推論でメモリ帯域はどこに効くか｜プロンプト処理と生成で詰まる場所が入れ替わる仕組み

メモリ帯域とは、GPUが自身のVRAMとの間で1秒あたりに読み書きできるデータ量である。

ローカルLLMを動かしていて「長い文章を投げると最初の一文字が出るまで待たされる」「出始めてからの速度はモデルを変えると大きく動く」という差を体感したことはありませんか。この二つは原因が別で、前者は演算器の量、後者はメモリ帯域が上限を作っています。同じGPU・同じモデルでも、処理のフェーズが変われば詰まる場所が入れ替わる。この切り分けを押さえると、GPUを買い替えるべきか、モデルを小さくすべきかの判断が変わります。

メモリ帯域という数字が指しているもの

メモリ帯域は、GPUの演算コアとGPU基板上のVRAMとの間でやり取りできるデータ量を、1秒あたりのバイト数で表した数字です。単位はGB/s。ここで扱うのはあくまでGPUの内側の話で、PCカードとしてのGPUがマザーボードやCPUとやり取りする速度とは別物になります。

なぜこの数字がAI処理で問題になるのか。LLMの推論は、モデルの重み（学習済みのパラメータ）をVRAMから読み出し、演算コアに流し込んで計算するという動作の繰り返しで進みます。演算コアは非常に速い。しかし読み出しが追いつかなければ、コアはデータが届くのを待つだけの時間を過ごします。この「待たされている時間」が実効速度を決めている場面が、AI推論には確実に存在する。

ハードウェア側もここを分かっていて、メモリと演算器の距離を物理的に詰める方向に投資が向いています。HotHardwareが報じたSamsungのFMS 2026（Santa Clara開催）での発表内容は、まさにその一例。詳しくは後半で扱います。

数字そのものの読み方には注意が必要です。GPUのカタログに載る帯域値は理論上のピーク値で、実際にその値でデータが流れ続けるわけではありません。メモリコントローラの効率、アクセスパターン、キャッシュのヒット率で実効値は変わります。バス幅と転送レートから自分で計算した値を公式スペックと同列に扱うのも避けたほうがいい。算出値なら算出値と分けて考えてください。

PCIe・OCuLinkの帯域とは別の話

GPUとホストPCをつなぐPCIeやOCuLinkの帯域は、GPU内のメモリ帯域とは完全に別のレイヤです。混同すると診断を間違えます。

モデルの重みがすべてVRAMに載り切っている状態では、推論中にPCIeを通る大容量データはほとんどありません。データ量としては極めて小さく、生成速度にはほぼ関与しません。「eGPUをx4接続で使っているから生成が遅いのでは」という推測は、モデルがVRAMに収まっている限り外れます。

系外帯域が効いてくるのは別の局面。モデルのロード時間、VRAMに載り切らずシステムRAMへオフロードした場合の推論、複数GPUに層を分割して割り当てた場合のGPU間通信。複数GPUに層を分割した場合の帯域はローカルLLMを2枚のGPUのVRAMプールで動かす、レーン数の選び方はAI用PCのマザーボードとPCIeレーンの選び方で扱っています。本記事ではGPU内のVRAM帯域だけを扱うので、以降で「帯域」と書いたらVRAM帯域を指すと考えてください。

プロンプト処理と生成で、詰まる場所が入れ替わる

LLMの推論は、入力されたプロンプトをまとめて処理する段階（prefill）と、そこから1トークンずつ出力を作る段階（decode）に分かれます。この二つは計算の性質がまったく違い、性能の上限を作る要素も別物。

プロンプト処理では、入力トークンが数百から数千まとめて存在しています。モデルの重みを1回読み出せば、その重みを全トークンに対して同時に適用できる。行列とベクトルの掛け算ではなく、行列同士の掛け算になるわけです。読み出したデータ1バイトあたりの演算量が大きいため、演算器がフル稼働してもデータ供給が追いつく。ここで上限を作るのは演算器の数と動作クロック、つまり演算性能側になります。

トークン生成は事情が反転します。1トークンを作るために、モデルの重みをほぼ全部読み出す必要がある。しかし処理する対象は1トークン分のベクトル1本だけ。読み出したデータに対して実行できる演算はごくわずかで、演算器は大半の時間データ待ちになります。7GBの重みを持つモデルなら、理屈の上では1トークンごとに7GB近くを読み出している計算。毎秒50トークン出すには毎秒350GB相当の読み出しが必要になり、帯域がそのまま天井として現れます。

一般的なLLM推論では、同じモデル、同じGPUでも、長文を読ませている間は演算性能が、回答が出ている間はメモリ帯域が性能を決めている。これがフェーズによる入れ替わりの正体です。

「入力が長いと待たされる」と「出力が遅い」は別の原因

体感に落とすと分かりやすくなります。長い資料を貼り付けて質問したとき、最初の一文字が出るまでの待ち時間が伸びる。これはプロンプト処理の時間で、実用的な長さの範囲では入力トークン数に概ね比例します（長大なコンテキストではAttention由来の非線形なコストが乗ります）。ここを短縮したいなら演算性能の高いGPUが効く。

一方、出始めてからの1秒あたりのトークン数は、モデル重みの読み出しが支配的な比較的短いコンテキストでは、入力の長さの影響が小さくなります。こちらを速くしたいならメモリ帯域と、読み出すデータ量そのものを減らす工夫が効いてきます。

自分の使い方がどちら寄りかで、投資先が変わります。長大なコードベースを読ませて短い修正案を出させる使い方なら前者。短い指示から長文を書かせる使い方なら後者。どちらも重い使い方なら、演算性能と帯域の両方が上位のGPUを選ぶしかありません。

ollama run gemma4:12b --verbose

生成側が帯域で決まるなら、モデルサイズと量子化が直接効く

トークン生成の速度は、1トークンあたりに読み出すバイト数で大きく決まります。読み出す量はおおむねモデルの重みのサイズと一致するため、重みを小さくすれば読み出しも減り、生成が速くなる。

量子化はまさにこれを狙う手法です。FP16（16ビット浮動小数点）で保持していた重みを4ビット相当に圧縮すれば、データ量はおおよそ4分の1近くまで落ちます。読み出すバイト数が減るぶん、帯域という天井に当たるまでの余裕が増える。量子化で速度が上がる理由を「計算が軽くなるから」と説明されることがありますが、生成フェーズに関しては読み出し量が減ることの寄与が大きい。当サイトでも量子化フォーマット別にVRAMと速度を実測した記事を別途公開しています。

もっとも、量子化には品質面のトレードオフがあります。ビット幅を落とせば出力の精度や一貫性に影響が出る可能性がある。本記事は速度とメモリの観点だけを扱っており、品質については未評価です。実際に使うモデルとタスクで確認してください。

MoE（Mixture of Experts）構成のモデルが同じ総パラメータ数のdenseモデルより生成が速いのも、同じ理屈で説明できます。MoEは1トークンごとに全パラメータを使うのではなく、一部の専門家ネットワークだけを活性化する構造。読み出しに関わる量が総パラメータ数より小さくなるため、サイズの割に生成が速い。当サイトの検証環境（RTX 5080単体・2026年6月18日・Ollama 0.30.7、出力512トークン・3回計測の中央値）で qwen3.6:35b-a3b を計測すると 67.7 tok/s でしたが、この計測は配布サイズ約24GBのモデルを16GBのVRAMに載せようとしたもので、全層は載らずGPU常駐率62%（残りはCPU側にオフロード）の状態での値です。常駐率100%で計測した Phi-4 14B の 74.3 tok/s（2026年7月24日・Ollama 0.30.7、後述）とは同条件では比べられません。denseモデルなら常駐率62%でこの速度は出にくいところです。MoEは1トークンで使う専門家が総パラメータのごく一部なので、CPU側へ回る量も小さく済んでいることが一因と考えられます。ただしどの専門家がGPU側とCPU側に置かれ、1トークンごとに何が転送されたかは測っていないため、この計測だけで確定はできません。それでも総パラメータ35B級がこの水準で回っているのは、MoEが1トークンあたりに読み出す量を総パラメータ数より小さく抑えているためと考えられますが、本記事の計測だけで要素ごとに分解することはできません。

コンテキストを伸ばすと読み出し対象が増える

KVキャッシュは、これまでに処理したトークンの中間状態を保持しておく領域です。以下は通常のfull-attention系を前提にした説明で、sliding-window attention など参照範囲を絞る方式では挙動が変わります。llama.cpp 系のランタイムでは設定したコンテキスト長のぶんをモデルのロード時にまとめて確保するため、VRAM占有量を決めるのは会話の長さではなく設定値のほうです。会話が進んで増えるのは、1トークンあたりに読み出す量です。

KVキャッシュは容量を設定分だけ最初に押さえ、読み出し量のほうを会話の進行に応じて押し上げます。各トークンを生成するたびに、それまでのキャッシュを参照する必要があるため、長い会話が続くほど1トークンあたりの読み出しが増えていきます。会話が長く続くほど生成が遅くなるのは、この積み上がりが効いているからです。なお、コンテキスト長の設定値を大きくしただけで即座に増えるのはKVキャッシュ用に確保するVRAM量のほうで、1トークンあたりの読み出しが増えるのは実際にトークンが溜まったぶんになります。

KVキャッシュがVRAM設計上のパラメータとして扱われている例は、LLM以外の推論実装にも見られます。MarkTechPostが公開したLingBot-Mapのチュートリアル実装では、VRAM制約に応じてフレーム数・カメラ反復回数・KVキャッシュのパラメータを切り替える構成が紹介されていました（公式のLingBot-Map自体はこれらをユーザー指定のオプションとして持ちます）。これは3D再構成のパイプラインでLLMの生成速度とは対象が異なりますが、「利用可能なVRAM量が実行時パラメータを直接決める」という設計が実装レベルで一般化している事例として参照できます。

同じモデルを別のGPUで動かした実測

同じモデルを異なるGPUで測ると、生成側の速度がどれくらい動くかが見えます。ただしこの2枚は帯域も演算性能も同時に違うため、帯域だけを取り出した検証にはなりません。当サイトの検証環境で、Gemma 4 12B を RTX 5080 と RTX 5060 Ti でそれぞれ計測した結果が以下です。

この2枚の対比は2026年6月4日に LM Studio（llama.cpp 2.13.0 CUDA）で計測したもので、モデルは Gemma 4 12B の Q4_K_M（LM Studio の model id は gemma-4-12b-it）、コンテキスト長4096・4回計測の中央値です。GPU常駐は nvidia-smi のVRAM増分で確認し、両GPUとも全層がGPUに載った状態でした。RTX 5060 Ti は OCuLink 接続ですが、Gemma 4 12B（Q4_K_M）はモデル読み込みによるVRAM増分が約9GB（RTX 5080側で9,168MiB）で16GBに収まり全層がGPUに載るため、接続帯域は生成速度にはほぼ影響しません。

メモリ帯域はNVIDIA公式の比較ページ（Compare 50 Series Specs）の記載値です。個別の製品ページには帯域の行がありません。帯域比は約2.1倍に対し、実測の速度比は約1.6倍。VRAM容量は同じ16GB、メモリ種別も同じGDDR7。それでも生成速度には差が出ました。この差の内訳を、本記事の計測値だけから要素ごとに分解することはできません。生成フェーズは帯域側が先に上限に達しやすいことを踏まえると、メモリ帯域やメモリコントローラの効率も差に効いている可能性があります。

別のランになりますが、同じ RTX 5080 で他のモデルも測っています（2026年7月24日・Ollama 0.30.7、出力512トークン・3回計測の中央値・GPU常駐率100%）。Phi-4 14B（Ollama: phi4:14b）が74.3 tok/s、Mistral 7B（Ollama: mistral:7b）が148.1 tok/s。モデルが小さくなるほど1トークンあたりの読み出しが減り、速度が上がるという傾向がはっきり出ています。GPUを変えずにモデルを変えたときの速度変化は、重みサイズと素直に対応する形です。

帯域の差がそのまま速度の差にならない理由

ここで注意したいのが、カタログ上の帯域比と実測の速度比は一致しないという点。

実効速度は複数の要素の合成で決まります。メモリコントローラがどれだけピーク帯域に近い転送を維持できるか、キャッシュがどれだけヒットするか、演算性能が生成フェーズでも部分的に効いてくるか、ランタイムの実装がどれだけ最適化されているか。帯域だけを取り出して速度を割り出すことはできません。「比例しない」という事実だけを押さえておけば十分です。

上の2枚以外のGPUへ、この傾向をそのまま一般化することもできません。世代が変わればメモリ種別もコントローラの設計も変わります。

帯域の話の手前にある、容量という関門

メモリ帯域を検討する前に、そもそもモデルがVRAMに載るかという関門があります。ここを超えられなければ帯域の議論に進めません。

VRAMに載り切らない場合、推論エンジンは一部の層をシステムRAMへオフロードするか、実行そのものを諦めます。オフロードが発生すると、CPU側に置かれた層はCPUが計算し、その重みはシステムRAMから読み出されます。PCIeを渡るのは層の境目でやり取りする活性ベクトルで、量そのものは小さい。それでも大きく遅くなるのは、システムRAMの帯域がVRAM帯域の数分の1から1/10程度にとどまるうえ、CPU側の演算とトークンごとの往復待ちが積み上がるためです。落ち込み幅を大きく左右するのは常駐率そのものではなく、1トークンあたりCPU側で読み出す実効パラメータ量です。denseモデルはCPU側に残った層の重みを毎トークン読み直すため落ち込みが大きく、1トークンで活性化する量が小さいMoEでは、同じ常駐率でも落ち込みが小さくなる場合があります。当サイトの検証環境でも、denseモデルで16GBに収まらない構成では速度が大きく落ち込むケースを確認しています（MoEの例は前述）。

容量が挙動そのものを決める設計は、推論を実装する側でも当たり前になっています。前述のLingBot-Mapのチュートリアル実装は、VRAM制約に応じてフレーム制限やカメラ反復回数を切り替える例。「VRAMが足りないと落ちる」ではなく「VRAMに合わせて処理量を変える」という作りです。

学習・ファインチューニングの領域では、容量の制約が推論よりさらに厳しくなります。MarkTechPostがUnsloth・Axolotl・TRL・LLaMA-Factoryを比較した記事では、学習スループット・ピークVRAM・マルチGPUスケーリングの3軸が比較の基準に据えられていました。同記事によれば、Unslothは手書きのTritonカーネルでモデリングコードの一部を置き換えており、特定のモデルとGPUの組み合わせで大きな速度差が報告されています。学習では、モデルの重みに加えて、順伝播で生じる中間activation、勾配、オプティマイザの状態なども保持する必要があり、必要な容量が跳ね上がる。保持する対象は学習方式によって変わり、LoRAやQLoRAのように更新するパラメータを絞る手法では内訳が異なります。同じGPUでも推論と学習では扱えるモデルサイズがまったく違います。

帯域を稼ぐ方向にハードウェアが動いている

メモリと演算器の間のデータ移動コストは、業界全体が投資している課題です。HotHardwareの報道によれば、SamsungはFMS 2026（Santa Clara）で、zHBMと呼ぶコンセプト段階のアーキテクチャを公開しました。

zHBM changes the geometry by vertically stacking HBM directly on top of the AI accelerator.

出典: HotHardware「Samsung’s zHBM 3D Memory Concept Forecasts 8X Speed Over HBM5」 https://hothardware.com/news/samsung-zhbm-3d-memory-concept

従来のHPC・AIサーバ向け設計では、HBM（広帯域メモリ）のパッケージはシリコンインターポーザ上でプロセッサの横に配置されます。速い構成ではあるものの、データはメモリとアクセラレータの間を水平方向に一定の距離だけ移動しなければならない。zHBMはこの配置を変え、HBMをアクセラレータの直上に垂直に積層する構想です。移動距離を詰めることで遅延を減らし帯域を上げる狙い。

HotHardwareによれば、同社が示した目標値は次世代のウェハボンディング技術を前提として、HBM5比で最大8倍の帯域、10倍以上の密度（同誌は「同じスペースで10倍の容量」と説明）。このうち帯域8倍は同誌の報道に依拠する数値です。熱抵抗を半分以下に削減するという主張も出ています。ただし、すでに1kWを超える消費電力に達しているAIチップで放熱がどう変わるのかは、原文でも不明とされています。アクセラレータとメモリの間の層に顧客固有のカスタムIPを統合できる柔軟性も示されました。あわせてzNAND-Oと400層超のV10 BV-NANDも公開されています。

ここで押さえておきたいのが、これらがすべてコンセプト段階の目標値だという点。原文はzHBMを「conceptual architecture」と表現し、限定的な展開すら先の話だと明記しています。比較対象のHBM5自体が将来の規格です。「実現する」ではなく「目標として掲げている」と読むのが正確です。

データセンター側の動きと手元のGPU選びの距離

zHBMはエンタープライズのAIデータセンターと大規模HPC向けに設計された技術で、DIY PC愛好家を含む一般消費者が手にする類のものではないと原文も述べています。コンシューマGPUの世代交代に直接つながる話ではありません。

それでも参考になる点があります。データの移動距離と移動量を減らす方向に大規模な投資が向かっているという事実自体が、生成フェーズで帯域が上限を作るという本記事の構造を裏側から支持している。演算器を増やすだけでは解決しないと業界が判断しているからこそ、メモリ側の物理構造に手を入れる構想が出てくるわけです。

手元の判断は現行製品の公式仕様と実測で行ってください。将来技術の目標値は、どちらのGPUを買うかという問いには答えてくれません。

まとめ

AI推論で「メモリ帯域が効く」と言われる場面は、正確にはトークン生成の側です。一般的なLLM推論では、プロンプト処理はまとめて計算できるぶん演算器の量が上限を作り、生成は1トークンごとに重みを読み直す必要から帯域が上限を作る。長文を投げた直後の待ち時間と、出始めてからの速度は別々の要素で決まっています。

その手前に容量という関門があることも忘れないでください。VRAMに載らなければ帯域以前の問題になります。容量→帯域→演算の順に確認すれば、買い替えるべきか、量子化で対応すべきかの判断がつきます。

本記事が扱ったのはGPU内のVRAM帯域に限定した話で、PCIeやOCuLinkの系外帯域は別レイヤ。実測として提示したのは2枚のGPUで同一モデルを測った結果であり、他のGPUへそのまま一般化はできません。量子化やモデル選択が出力品質に与える影響も本記事では未評価です。次のステップとしては、自分が実際に使うモデルを手元のGPUで測り、待ち時間の内訳がプロンプト処理側と生成側のどちらに寄っているかを確認するところから始めるのが確実です。

よくある質問

Q. メモリ帯域が大きいGPUなら生成速度も比例して上がりますか？

比例しません。実効速度はメモリコントローラの効率、キャッシュのヒット率、演算性能、ランタイムの実装の合成で決まります。帯域は上限を作る要素の一つであって、カタログ値から速度を逆算することはできません。実際に使うモデルでの実測値を探してください。

Q. PCIe x4接続だと生成が遅くなりますか？

モデルの重みがすべてVRAMに載っている状態なら、生成速度にはほぼ影響しません。推論中にPCIeを通る大容量データがほとんどないためです。PCIeの帯域が効くのは主にモデルのロード時間です。オフロード時も遅くなりますが、llama.cppの一般的なレイヤオフロードでは、その主因はリンク幅ではなくシステムRAM帯域とCPU演算になります（方式によってはPCIe自体が効く構成もあります）。

Q. 量子化すると速くなるのはなぜですか？

トークン生成では1トークンごとにモデルの重みを一通り読み出すため、読み出すバイト数が速度を左右します。量子化でビット幅を落とせばデータ量が減り、帯域という上限に当たるまでの余裕が増える。ただし出力品質への影響は別の問題で、実際のタスクで確認が必要です。

Q. コンテキストを長くすると遅くなるのはメモリ帯域のせいですか？

KVキャッシュの影響が大きい部分です。llama.cpp系のランタイム（Ollama や LM Studio など）では、VRAMの占有量は設定したコンテキスト長のぶんがロード時に確保されるため会話中に増えるわけではなく、会話が伸びて増えるのは1トークンあたりの読み出し量のほうです。帯域側から効いてくるため、長い会話ほど生成が遅くなります。

参考資料

• HotHardware: Samsung’s zHBM 3D Memory Concept Forecasts 8X Speed Over HBM5
• NVIDIA 公式: Compare 50 Series Specs（メモリ帯域の出典）
• NVIDIA 公式: GeForce RTX 5080 製品ページ
• NVIDIA 公式: GeForce RTX 5060 ファミリー製品ページ
• MarkTechPost: Unsloth vs Axolotl vs TRL vs LLaMA-Factory
• MarkTechPost: LingBot-Map Tutorial: GPU-Aware Inference and Point Cloud Export