はじめに

ローカルでLLMを動かしてみたものの、「返事が遅い」「長い資料が入りきらない」「複数人で使うと待たされる」——そんな壁にぶつかっていませんか？

このブログでは RTX 4070（12GBのゲーミングGPU）1枚で、こうした困りごとを1つずつ実測しながらつぶしてきました。この記事は、その総ざらい——「どんな困りごとに、何をすれば、どれだけ速くなるか」を1枚の早見表にまとめたものです。仕組みの細かい話は各記事に譲って、ここでは「自分のケースに効くのはどれか」を最短で見つけられるようにします。

こんな困りごとに効く手段の早見表

こんな困りごと	やること	どれだけ変わるか（実測）	詳しくは
返事が全体的に遅い	① 量子化（モデルを軽くする）	約1.4倍速く（2B AWQ4、164 tok/s）	量子化・MTP比較記事
長い文章の生成が遅い	② 投機デコード（先読み生成）+ 量子化	約1.3倍速く（2B FP8+MTP n=1、147 tok/s）	MTP基礎記事
長い資料が入りきらない・エラーになる	③ KVキャッシュをfp8に	96k tokensまで載る・速度劣化0.4%未満	FP8 KV Cache実測記事
複数人で使うと最初の返答まで待たされる	④ サーバをSGLangに	最初の応答待ち（TTFT）が最大1/8	エンジン比較記事
RAGで毎回同じ資料を読ませて2回目以降も遅い	⑤ prefix再利用（prefix cache）	2回目以降の待ちが最大88%減	prefix cache / RadixAttention 実測

自分の困りごとに近い行を見つけたら、対応する手段の節に飛んでください。

手段① 量子化 — 返事が全体的に遅いとき

困りごと: チャットで質問するたびに、とにかく返事が遅い。

対策: モデルの重み（パラメータ）を圧縮して小さくすることで、GPUが読み込む量が減り、そのまま生成速度が上がります。

実測結果（Qwen3.5-2B、Long生成、concurrency 1）:

構成	tok/s	FP16比
FP16 baseline	115.97	1.00x
FP8	123.88	1.07x
AWQ4（4bit）	164.05	約1.4倍

2B AWQ4でFP16比約1.4倍（164 tok/s）。FP8はそこまで伸びませんが、4B以上ではVRAMを節約して他の手段（投機デコードや長コンテキスト）を載せる土台になります。まず最初に試すべき手段です。

詳細: Qwen3.5-2B で Multi-Token Prediction を試す ② 量子化と MTP の組み合わせ比較

手段② 投機デコード — 長文の生成が遅いとき

困りごと: 要約や記事執筆など、長い文章を生成させると特に遅い。

対策: 「次の数トークンを先読みして予測し、まとめて検証する」方式（MTP / D-Flash など）で、うまくいけば1回の処理で複数トークン進みます。

実測結果（Qwen3.5-2B + qwen3_next_mtp、Long生成）:

構成	tok/s	baseline比
FP16 + MTP n=1	133.47	1.15x
FP8 + MTP n=1	147.34	約1.3倍
AWQ4 + MTP n=1	172.91	1.49x

2B FP8 + MTP n=1で約1.3倍（147 tok/s）。投機トークン数（n）は大きければよいわけではなく、2Bではn=1が最良でした。

重要な実用判断: 4B FP8に投機デコードを足しても、RTX 4070 12GB環境では約70 tok/sが上限です。速度重視なら「2B + MTP n=1（147 tok/s）」のほうが4B系の2倍以上速く、「4Bの品質がほしいなら4B、速度がほしいなら2B+MTP」という棲み分けになります。なお以前出回っていた「4B D-Flashで2.4〜2.6倍」という数字は特殊な計測条件（thinking ON）のもので、通常条件では再現しません。

詳細: Qwen3.5-2B で MTP を試す ① 基礎 / Qwen3.5-4B + D-Flash を 12GB GPU で動かす / 日本語だと D-Flash が伸びない？日英ベンチ比較

手段③ KVキャッシュ量子化 — 長い資料が入りきらないとき

困りごと: 長い資料やドキュメントを読み込ませようとするとエラーになる、または途中で切れる。

対策: 会話の文脈を保持するメモリ（KVキャッシュ）をfp8形式に圧縮すると、同じ12GBにより長い文章を載せられます。

実測結果（Qwen3.5-4B FP8）:

KV dtype	起動できたmax_model_len	速度劣化
auto（16bit）	64kまで	基準
fp8	96kまで	0.4%未満

fp8 KVにしても生成速度はほぼ落ちません（劣化<0.4%）。これは「速くする」手段ではなく、速度を犠牲にせず載せられる長さを伸ばす手段です。長文RAGや長い会話履歴を扱うなら、まずここで「席を確保」してください。

詳細: VRAM 12GB 環境で FP8 KV Cache は実用投入できるか / 長文運用の限界 — FP8 KV Cache でより長い長文を処理する

手段④ エンジン選択 — 複数人で使うと待たされるとき

困りごと: 自分だけで使うときは問題ないのに、複数人で同時に使うと最初の返答が来るまで異常に待たされる。

対策: サーバのソフト（サービングエンジン）を変えると、最初の応答までの待ち時間（TTFT：Time To First Token）が大きく変わります。vLLMとSGLangを比較しました。

実測結果（Qwen3.5-4B FP8、並列8リクエスト同時）:

指標	vLLM	SGLang	差
生成スピード（aggregate tok/s）	277.66	465.35	1.68x
最初の応答待ち（p95 TTFT）	2,295 ms	277 ms	約8倍差
1トークンごとの遅延（p95 ITL）	20.4 ms	17.0 ms	ほぼ同等

生成スピード自体はほぼ互角でも、最初の1文字が返るまでの待ちが約8倍ちがいます。SGLangは並列リクエストの捌き方が効率よく、複数ユーザーが同時に使う環境では体感が大きく変わります。なお、使用するattention backendの差（FlashAttention / FlashInfer / Tritonなど）はこのスケールでは1%以下でほぼ誤差でした。

詳細: vLLM × SGLang 準備編 / attention backend の実測検証 / 並列はどこまでスケールするか

手段⑤ prefix再利用 — RAGで毎回同じ資料を読ませているとき

困りごと: RAGやAgentで毎回同じ長文（system prompt・参照ドキュメント・tool定義）を先頭に積んでいるのに、2回目以降も毎回遅い。

対策: 一度処理したprefixの計算結果（KVキャッシュ）を使い回します。vLLMのprefix cache、SGLangのRadixAttentionがこれにあたります。毎回同じ宿題を渡して最初から読ませる代わりに、前回の答えの途中から再開するイメージです。

実測結果: 同じprefixの2回目以降、最初の応答待ち（TTFT）が最大88%減。prefixが長いほど効果は大きく、RAG / Agent運用に直撃する手段です。詳細はこちら:

prefix cache / RadixAttention の実測記事: 「ローカルLLMでのRAG の回答が遅い。それ、毎回同じ長文を prefill していませんか？ — prefix cache / RadixAttention を RTX 4070 で実測」
vLLM prefix cache と SGLang RadixAttention を cache on/off × prefix 長 ~512〜8k で同条件比較し、2 回目以降の TTFT がどこまで落ちるかを定量化します。

まとめ — 困りごとから手段を選ぶ

こんな困りごと	使う手段	目安
返事が全体的に遅い	① 量子化（2BならAWQ4）	約1.4倍（164 tok/s）
長文生成が遅い	② 投機デコード + ① 量子化	約1.3倍（147 tok/s）、言語とacceptance率に注意
長いコンテキストが載らない	③ KV cache fp8	96kまで、速度ほぼ無劣化
複数ユーザーで体感を上げたい	④ エンジン選択（SGLang）	並列でTTFT約8倍差
同じ長文を毎回投げている（RAG/Agent）	⑤ prefix再利用	2回目TTFT最大88%減（→ 別記事）

5つの手段は排他ではなく、組み合わせられます。土台に量子化を敷き、KV fp8で席を作り、用途に応じて投機デコード・エンジン選択・prefix再利用を足す——RTX 4070 12GBという限られた1枚でも、組み合わせ次第でかなり戦えます。

実験環境: RTX 4070 12GB / Ubuntu / vLLM nightly (v0.21.1rc1.dev243) / SGLang lmsysorg/sglang:latest / モデル: Qwen3.5-2B 系・RedHatAI/Qwen3.5-4B-FP8-dynamic

このブログの関連シリーズ:

量子化 / 投機デコード: MTP ① / MTP ② / D-Flash / 日英ベンチ
KV cache: FP8 KV テキスト性能 / 長文運用の限界
エンジン比較: 準備編 / attention backend / 並列スケール
prefix 再利用: prefix cache / RadixAttention 実測