ローカルLLMでコンテキストを128Kにすると何が起きるか｜VRAM5.4倍・速度4分の1を実測
この記事の要点
- コンテキスト長を4K→128Kにすると VRAMは5.4倍（2,563→13,887 MiB）
- 速度は64Kまでほぼ横ばいだが、128Kで70.67→15.06 tok/s と約4分の1に落ちる
- 3Bのモデルでも128Kを確保するとT4の15GBを90%使う。モデル本体より KVキャッシュのほうが重い
- 量子化は Q4→FP16 で VRAM 2.34倍・速度 1.73倍遅い。要約の品質差はごくわずかだった
「コンテキスト長128K対応」と書かれていても、実際にその長さを確保するとどうなるかを測った日本語の資料は見当たりません。
APIなら長文で単価が上がるモデルがあるという話で済みますが、ローカルではVRAMという物理的な制約に直接ぶつかります。実際に測りました。
測定環境
| GPU | Tesla T4（VRAM 15,360 MiB） |
| 実行基盤 | Ollama 0.32.5 |
| モデル（実験1） | llama3.2:3b（128K対応・Q4） |
| モデル（実験2） | gemma3:4b の Q4 / Q8 / FP16 |
| 測定日 | 2026年8月3日 |
速度は Ollama が返す eval_count / eval_duration から算出。VRAMは nvidia-smi の実測値です。
実験1：コンテキスト長を4Kから128Kまで振る
| コンテキスト長 | VRAM | 全体に占める割合 | 前段からの増分 | 速度 |
|---|---|---|---|---|
| 4,096 | 2,563 MiB | 17% | — | 70.67 tok/s |
| 8,192 | 3,091 MiB | 20% | +528 MiB | 71.20 tok/s |
| 16,384 | 4,003 MiB | 26% | +912 MiB | 73.02 tok/s |
| 32,768 | 5,827 MiB | 38% | +1,824 MiB | 73.44 tok/s |
| 65,536 | 9,475 MiB | 62% | +3,648 MiB | 70.66 tok/s |
| 131,072 | 13,887 MiB | 90% | +4,412 MiB | 15.06 tok/s |
VRAMはコンテキスト長にほぼ比例して増える
増分を見ると、コンテキスト長を倍にするたびにVRAMの増分も倍になっています（+528 → +912 → +1,824 → +3,648）。KVキャッシュがコンテキスト長に比例するという理屈どおりの結果です。
注目すべきは、モデル本体より KVキャッシュのほうが重くなることです。llama3.2:3b の本体はディスク上で2.0GB、4Kコンテキストでの使用量は2,563 MiB。ところが128Kにすると13,887 MiBで、増分の11,324 MiB はすべてコンテキストのためのメモリです。
3Bという小さなモデルでも、128Kを確保すればT4の15GBを90%使い切ります。
速度は64Kまで落ちない。128Kで急に落ちる
4Kから64Kまで、速度は70〜73 tok/s でほぼ横ばいでした。むしろ16K〜32Kでわずかに速いくらいです（測定誤差の範囲と見るべきでしょう）。
ところが128Kで15.06 tok/s まで落ちます。約4分の1です。
VRAMが90%まで埋まり、余裕がなくなったところで性能が崩れています。ロード時間も他が3.7〜4.9秒なのに対し、128Kだけ9.98秒かかりました。
「載る」ことと「実用的に動く」ことは別だという、実務で最も知りたい線がここに出ています。
この結果の読み方
| 使い方 | 必要VRAM（3Bモデルの場合） |
|---|---|
| 通常の会話（4K〜8K） | 約2.5〜3GB |
| 長めの文書を扱う（32K） | 約5.8GB |
| 大きなコードベースや資料（64K） | 約9.5GB |
| 128Kをフルに使う | 約13.9GB |
8GBのGPUなら32Kまで、12GBなら64Kまでが現実的な線になります。128Kを実用速度で使いたいなら、16GBでは足りません。
実験2：量子化による違い
同じ gemma3:4b を Q4 / Q8 / FP16 で比較しました。
| 量子化 | ディスク | VRAM | 速度 | 取得時間 |
|---|---|---|---|---|
| Q4（既定） | 3.3 GB | 3,759 MiB | 45.73 tok/s | 42.4秒 |
| Q8 | 5.0 GB | 5,327 MiB | 40.58 tok/s | 54.6秒 |
| FP16 | 8.6 GB | 8,795 MiB | 26.44 tok/s | 89.3秒 |
Q4 から FP16 にすると、VRAMは2.34倍、速度は1.73倍遅くなります。
品質の差はごくわずかだった
同じ要約タスクの出力です。
Q4:
生成AIの利用拡大に伴い、API利用料が重要なコスト要素となっている。 モデルによって単価に大きな差があり、入力長や選択によって費用が大きく変動する可能性がある。 そのため、企業は用途に応じたモデル選定でコスト削減を図っている。
FP16:
生成AIの利用拡大に伴い、API利用料が重要なコスト要素となっている。 モデルによって単価に大きな差があり、入力長によっても費用が変動するため、表示価格だけでは請求額を正確に見積もれない。 多くの企業は用途に応じたモデル選定でコスト削減を図っている。
FP16のほうが原文の情報を1つ多く拾っています（「表示価格だけでは見積もれない」の部分）。Q8も同様でした。ただしQ4の出力も要約として破綻はなく、実用上の差は小さいと言えます。
VRAMを2.34倍、速度を1.73倍犠牲にして得られる差がこの程度であれば、多くの用途ではQ4で十分でしょう。VRAMに余裕がないなら、量子化を上げるよりコンテキスト長に回したほうが効きます。
実務的な結論
- VRAMの見積もりは「モデルサイズ＋コンテキスト分」で考える。 モデル本体だけ見ていると足りなくなります
- コンテキスト長はVRAMにほぼ比例。 3Bモデルでも128Kなら約13.9GB
- 速度は限界近くまで落ちない。落ちるときは急に落ちる。 64Kまで70 tok/s台を維持し、128Kで15 tok/sになりました
- 量子化はQ4で十分な場面が多い。 FP16にしてもVRAMと速度の代償に見合う品質差は出ませんでした
- 余ったVRAMは量子化を上げるよりコンテキスト長に回すほうが効く
測定条件について
T4 1機種・モデル2つ・各条件1回ずつの結果です。 ここで測ったのは「コンテキストを確保したときのVRAMと速度」であって、 長文を実際に入れたときの応答精度ではありません。 128Kでの速度低下はVRAM逼迫が原因と見られますが、内部の挙動までは追っていません。
関連
- ローカルLLM 4モデルをT4で実測 — 速度・VRAM・日本語の正確性
- AI料金比較表 — 全モデルの単価とコンテキスト長
測定に使ったスクリプトと生データは手元に保存しています。手順は記事内に記載したとおりで、同じ条件で再現できます。公開のご要望があればお問い合わせからご連絡ください。