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内のメモリ帯域とは完全に別のレイヤです。混同すると診断を間違えます。

単一GPUで、モデルの重みとKVキャッシュがどちらもVRAMに載り切っている状態では、推論中にPCIeを通る大容量データはほとんどありません。データ量としては極めて小さく、生成速度にはほぼ関与しません。「eGPUをx4接続で使っているから生成が遅いのでは」という推測は、この条件を満たしている限り外れます。

系外帯域が効いてくるのは別の局面。モデルのロード時間、VRAMに載り切らずシステムRAMへオフロードした場合の推論、複数GPUで分割して動かす場合のGPU間通信（層分割で生成しているあいだの受け渡しは小さく、効きやすいのはロードと長い入力の一括処理、およびテンソル並列のような分割方式です）。この分割時の帯域はローカルLLMを2枚のGPUのVRAMプールで動かす、レーン数の選び方はAI用PCのマザーボードとPCIeレーンの選び方で扱っています。本記事ではGPU内のVRAM帯域だけを扱うので、以降で「帯域」と書いたらVRAM帯域を指すと考えてください。

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

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

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

トークン生成は事情が反転します。denseモデルなら、1トークンを作るのにモデルの重みの大部分を読み出す必要がある（MoEでは実際に活性化される専門家の重みが主な読み出し対象で、総パラメータ数より小さくなります。後述）。しかし処理する対象は1トークン分のベクトル1本だけ。読み出したデータに対して実行できる演算はごくわずかで、演算器は大半の時間データ待ちになります。7GBの重みを持つモデルなら、理屈の上では1トークンごとに7GB近くを読み出している計算。毎秒50トークン出すには毎秒350GB相当の読み出しが必要になり、単一〜小バッチではこの帯域が天井として先に現れます。複数のリクエストをまとめて処理すると、1回読み出した重みを複数シーケンスのトークン計算に使えるぶん演算密度が上がり、演算側の制約が相対的に強くなります。

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

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

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

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

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

ollama run gemma4:12b --verbose

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

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

量子化はまさにこれを狙う手法です。FP16（16ビット浮動小数点）で保持していた重みを4ビット相当に圧縮すれば、データ量はおおよそ4分の1近くまで落ちます。読み出すバイト数が減るぶん、帯域という天井に当たるまでの余裕が増える。量子化で生成が速くなりやすい理由を「計算が軽くなるから」と説明されることがありますが、生成フェーズに関しては読み出し量が減ることの寄与が大きい。ただし実際の形式はスケール値などの付随データを持つので厳密に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に載せようとしたもので、全層は載らず、サイズ差だけでも8GB近くがCPU側にオフロードされた状態での値です。常駐率100%で計測した Phi-4 14B の 74.3 tok/s（2026年7月24日・Ollama 0.32.3、後述）とは同条件では比べられません。常駐率だけでなく、計測日とモデルも違います。denseモデルと違い、MoEは1トークンで使う専門家が総パラメータのごく一部なので、CPU側へ回る量も小さく済んでいることが一因と考えられます。ただしどの専門家がGPU側とCPU側に置かれ、1トークンごとに何が転送されたかは測っていないため、この計測だけで確定はできません。それでも総パラメータ35B級がこの水準で回っているのは、MoEが1トークンあたりに読み出す量を総パラメータ数より小さく抑えているためと考えられますが、本記事の計測だけで要素ごとに分解することはできません。

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

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

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

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

同じモデルを別の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。それでも生成速度には差が出ました。この差の内訳を、本記事の計測値だけから要素ごとに分解することはできません。生成フェーズは帯域側が先に上限に達しやすいことを踏まえると、メモリ帯域やメモリコントローラの効率も差に効いている可能性があります。

ここからはGPUを固定してモデル側を変えた別のランです。同じ RTX 5080 で他のモデルも測っています（2026年7月24日・Ollama 0.32.3、出力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へ、この傾向をそのまま一般化することもできません。世代が変わればメモリ種別もコントローラの設計も変わります。

同じカードで、メモリクロックだけを下げて測る

上の比較は2枚のGPUが同時に違うため、帯域の寄与を取り出せませんでした。そこで1枚のGPUのメモリクロックだけを下げて測りました。同じカードならメモリバス幅は変わらないので、帯域はメモリクロックにほぼ比例します。クロックを半分にすれば帯域も半分になる、という関係です。使ったのは RTX 4070 SUPER（12GB）です。本記事が主に扱う RTX 5080 / RTX 5060 Ti とは別のカードなので、絶対値をそのまま持ち込まないでください。見たいのは倍率の動き方です。なお固定したのはメモリクロックだけで、GPUコア側のクロックは固定していません。演算側が完全に一定だったことまでは確認できていない点に注意してください。

クロックを 10,251MHz から 5,001MHz へ、つまり約2.05倍下げると、生成速度は 1.84〜1.94倍まで落ちました。別GPU同士で見たときの「帯域比2.1に対して速度比1.6」より、はるかに比例へ寄っています。ただしこの2つはランタイムもモデルも違う別のランなので、寄り方の差を「同じカードかどうか」だけに帰することはできません。2枚を比べたときになぜ1.6までしか離れなかったのかも、この計測からは特定できません。演算性能の差で説明しようとすると向きが合わない点には注意が要ります。先のGPU比較表のとおり RTX 5080 のほうがCUDAコアも約2.3倍多いので、演算側が効いているなら速度比は帯域比より大きくなる方向に働くはずで、1.6へ小さくなる理由にはならないからです。

完全な比例ではありません。比例なら 2.05倍のはずが、実際は 1.84〜1.94倍で、未達の幅は 5.5〜10.1%。後述する約5%のばらつきを当てはめると、gemma3:12b と llama3.1:8b はこの幅を超えて未達、qwen3:14b は幅の縁にあたります。この5%は 10,251MHz 側の1モデルで見えた下振れなので、当て方はあくまで目安です。帯域に依存しない処理が残っているぶん落ち方が緩んだ、という読み方はできますが、断定はできません。今回はGPUコア側のクロックを固定していないので、メモリクロックを下げて電力に余裕が出たぶんコア側が上振れして差を埋めた、という可能性を切り分けられていないからです。

さらに 810MHz まで落とすと、今度は向きが逆になります。クロック比 12.66倍に対し、生成速度は qwen3:14b が 14.03倍、llama3.1:8b が 13.22倍、gemma3:12b が 12.78倍。中央値どうしで見ると3モデルとも比例より大きく落ちています。すぐ上で挙げた「帯域に依存しない処理が残る」という読み方では、クロックを下げるほど落ち方は緩む方向にしか働かないので、この向きの超過は説明できません。次に見るとおり、ばらつきの幅を明確に超えているのは qwen3:14b だけで、説明を要するのもこの1モデルです。別の要因が加わった可能性がありますが、本記事の計測では特定できていません。

もっとも、どのモデルで超過と言えるかには慎重さが要ります。同じ条件を3回測っても値は動きます。gemma3:12b は 10,251MHz で 49.5〜52.1 tok/s と、中央値から約5%下振れした回がありました。この約5%を粗い参考幅として当てはめると、超過分は qwen3:14b が約11%でこれを超えますが、llama3.1:8b は約4%で幅の内側、gemma3:12b は約1%でさらに内側です。明確に大きく見えるのは qwen3:14b だけでした。ただしこれは3回の測定から取った目安で、統計的な誤差の境界ではありません。倍率はいずれも2つの中央値の比なので、低クロック側の振れが乗れば判定に使える幅は5%より広くなります。

測定条件：RTX 4070 SUPER（12GB・OCuLink接続）単体、Ollama 0.32.3、3回計測の中央値。出力は上限128トークンを指定していますが、実際に生成されたのは qwen3:14b が83、gemma3:12b が80、llama3.1:8b が110トークンでした。メモリクロックは nvidia-smi の --lock-memory-clocks で固定しています（10,501MHz を指定すると実際には 10,251MHz で動作）。GPUコアのクロックは固定していません。3モデルともGPU常駐率100%で、あふれていない状態の値です。表の tok/s は小数第1位に丸めており、本文の倍率は丸める前の中央値から計算しています。とくに 810MHz のように値が小さい行では丸めの影響が大きく、たとえば qwen3:14b の 810MHz 比は表の値から計算すると約13.9倍、丸める前の中央値からは 14.03倍になります。計測日は2026年9月9日。

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

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

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

容量が挙動そのものを決める作りは、LLM以外の推論実装にも見られます。前述の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をアクセラレータの直上に垂直に積層する構想です。移動距離を詰めることで遅延を減らし帯域を上げる狙い。

Samsungが示した目標値は、次世代のウェハボンディング技術を前提として、HBM5比で約8倍の性能、10倍を超えるメモリ密度、3倍のエネルギー効率、そして熱抵抗を半分以下に削減、というものです。ここで約8倍とされているのは性能であって、Samsungは帯域が何倍になるかを明示していません。HotHardwareは見出しで「8X Speed」と表現していますが、一次資料に戻せば「性能が約8倍」と読むのが正確です。ただし、すでに1kWを超える消費電力に達しているAIチップで放熱がどう変わるのかは、HotHardwareの記事でも不明とされています。アクセラレータとメモリの間の層に顧客固有のカスタムIPを統合できる柔軟性も示されました。あわせてzNAND-Oと400層超のV10 BV-NANDも公開されています。

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

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

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

それでも参考になる点があります。データの移動距離と移動量を減らす方向に大規模な投資が向かっているという事実自体は、本記事で扱った、データ移動がAI性能の制約になるという構造とも整合します。演算器を増やすだけでは解決しないと業界が判断しているからこそ、メモリ側の物理構造に手を入れる構想が出てくるわけです。

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

まとめ

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

その手前に容量という関門があることも忘れないでください。VRAMに載らなければ帯域以前の問題になります。単一〜小バッチのローカルLLM生成なら、容量→帯域→演算の順に確認していけば、買い替えるべきか、量子化で対応すべきかの判断がつきます。

本記事が扱ったのはGPU内のVRAM帯域に限定した話で、PCIeやOCuLinkの系外帯域は別レイヤ。帯域まわりの実測として提示したのは、2枚のGPUで同一モデルを測った結果と、RTX 4070 SUPER 単体でメモリクロックだけを下げた結果の二つです（このほかモデルを変えたときの実測も本文で挙げています）。前者は帯域も演算性能も同時に違う比較で、帯域比と速度比は一致しませんでした。帯域だけを動かしたのは後者で、こちらは比例寄りの動きになりました。ただし後者も完全な比例ではなく、極端に低いクロックでは3モデル中1モデルで逆方向へのずれも出ました（残る2モデルは測定のばらつきの範囲内。幅の見積もり自体も粗い目安です）。どちらも他のGPUへそのまま一般化はできません。量子化やモデル選択が出力品質に与える影響も本記事では未評価です。次のステップとしては、自分が実際に使うモデルを手元のGPUで測り、待ち時間の内訳がプロンプト処理側と生成側のどちらに寄っているかを確認するところから始めるのが確実です。

よくある質問

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

別のGPUに買い替える場合、比例する保証はありません。実効速度はメモリコントローラの効率、キャッシュのヒット率、演算性能、ランタイムの実装の合成で決まります。帯域は上限を作る要素の一つであって、カタログ値から速度を逆算することはできません。実際に使うモデルでの実測値を探してください。なお本記事で RTX 4070 SUPER 単体のメモリクロックだけを下げて測った範囲では比例寄りの動きになりましたが、これはカードをまたぐ比較とは別の話です。

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

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

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

denseモデルのトークン生成では、1トークンごとにモデルの重みの大部分を読み出すため、読み出すバイト数が速度を左右します（MoEでは活性化される専門家の重みが主な対象になります）。量子化でビット幅を落とせばデータ量が減り、帯域という上限に当たるまでの余裕が増えるので、生成は速くなりやすい。ただし形式に合った実装がなければ削減した量がそのまま速度になるとは限らず、出力品質への影響も別の問題です。実際に使うモデルとタスクで確認してください。

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

KVキャッシュの影響が大きい部分です。現行の llama.cpp では、KVキャッシュに使うVRAMは設定したコンテキスト長のぶんがロード時に確保されるため会話中に増えるわけではなく、会話が伸びて増えるのは1トークンあたりの読み出し量のほうです。帯域側から効いてくるため、長い会話ほど生成が遅くなります。ただしこれは参照範囲を絞らない（full-attention）方式を前提にした話で、sliding-window attention のように参照する範囲に上限がある方式では、ある長さから1トークンあたりの読み出しの増え方が緩みます（窓のある層と全体を参照する層が混在する構成では、増え方が緩むぶんにとどまります）。

参考資料

• Samsung 公式: Samsung Unveils Next-Gen 3D-Memory Vision at FMS 2026（zHBM の目標値の出典）
• 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