はじめに
ローカルで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 実測