重要なポイント
- ログ/デバッグ無効化（簡単）：~10%の速度向上。
- Q4量子化使用（簡単）：同じ速度でVRAM削減。
- バッチサイズ最適化（中級）：バッチ処理で2–3×速度向上。
- OllamaからvLLMへ切り替え（上級）：並行リクエストで2–5×速度向上。
- GPUメモリ使用率90%+（中級）：15–20%速度向上。
- 全手法の組み合わせ：~2–3×の総合高速化。
GPUメモリ使用率は速度にどう影響するか？
多くのツールはデフォルトでGPU VRAMの70–80%のみ使用し、残りを未使用のままにしています。 90–95%に増やすと、エンジンがKVキャッシュを多く事前確保できるため速度が15–20%向上します：
# vLLM: increase GPU memory utilization
vllm serve meta-llama/Llama-2-7b-hf \
--gpu-memory-utilization 0.95
# Ollama: environment variable
export OLLAMA_GPU_THRESHOLD=0.95 # Use 95% of GPU
ollama run llama3.2:3b
# LM Studio: Settings → GPU acceleration slider (move to 100%)スループットを最大化するバッチサイズは？
バッチ処理（複数プロンプト同時処理）では、バッチサイズを1から32に増やすと2–4×のスループット向上が得られます。
単一リクエスト = パイプライン利用率が低い。バッチ32リクエスト = 2–4×スループット。
トレードオフ：個別リクエストの遅延が増加（バッチ完了まで待機）。
| バッチサイズ | スループット | レイテンシ/リクエスト | ユースケース |
|---|---|---|---|
| 1（単一） | 50 tok/sec | 最小 | リアルタイムチャット |
| 8 | 120 tok/sec | 許容範囲 | 軽度の並行処理 |
| 32 | 200 tok/sec | 高 | バッチAPI |
| 64+ | 250+ tok/sec | 非常に高い | オフラインバッチ |
最速の推論エンジンは？vLLM vs Ollama vs llama.cpp
vLLM：並行リクエストでOllamaより5–10×高速 — 複数ユーザーを抱える本番APIに最適。
llama.cpp：コンシューマーハードウェアでの単一リクエストが最速 — 個人ローカルセットアップに最適。
Ollama：単一ユーザー向け最高の開発者体験；単一リクエストではllama.cppと同等。
Text-Generation-WebUI：最も低速だが機能豊富 — 実験用のみ、本番環境には不適。
量子化は推論を高速化するか？
現代のGPU（RTX 40シリーズ）では、Q4とQ5はFP16と同じ速度で動作します — 速度向上ではなくVRAM削減のために量子化してください。
量子化の間接的な速度メリット：
- 小さいモデルファイル = ディスクからの起動時読み込みが速い
- メモリ帯域幅の削減 = 古いメモリ制限ハードウェアでわずかに高速（10–15%）
量子化は主にVRAM削減のためで、生のトークンスループット向上ではありません。
現実的に得られる速度改善は？
例：RTX 4090で7Bモデルを最適化 — ステップバイステップ：
| 変更 | 速度 | 累計ゲイン |
|---|---|---|
| Ollamaデフォルト（ベースライン） | 120 tok/sec | — |
| デバッグログ無効化 | 132 tok/sec | +10% |
| GPUメモリ → 95% | 150 tok/sec | +25%合計 |
| vLLMへ切り替え（バッチ） | 300 tok/sec（バッチ） | +2.5×（バッチ） |
| 全最適化組み合わせ | 300 tok/sec | +2.5×スループット |
よくある速度最適化の間違い
- GPUメモリを100%に設定。 メモリ不足クラッシュのリスク。安全な最大値は90–95%。
- 速度のためにバッチサイズを下げる。 バッチサイズは単一リクエストの遅延に影響しません。スループットにのみ効果あり。
- 速度のために過度に量子化。 Q4はFP16とほぼ同じ速度です。VRAMのために量子化し、速度のためではありません。
- デプロイ途中で推論エンジンを切り替え。 Ollama → vLLM → llama.cppへの切り替えはバグを引き起こします。一つを選んで最適化してください。
よくある質問
ローカルLLM推論を高速化する最も効果的な方法は？
並行リクエストにOllamaからvLLMへ切り替えると最大の高速化が得られます — バッチ処理で5–10×のスループット向上。単一リクエストでは、GPUメモリ使用率を70%から90–95%に増やすと15–20%の速度向上。デバッグログ無効化でさらに10%。
バッチ処理は単一リクエストの遅延を改善するか？
いいえ — バッチサイズはスループット（全リクエストのtoken/sec）に影響しますが、単一リクエストの遅延には影響しません。遅延を下げるにはGPUメモリ使用率を最適化し、より高速なエンジン（vLLMまたはllama.cpp）を使用してください。
vLLMはOllamaより何倍速いか？
単一リクエストでは両者は同様（RTX 4090で7Bモデル使用時に両方とも~120–150 tok/sec）。並行リクエストでは、Continuous BatchingとPagedAttentionによりvLLMが5–10×高速。
量子化は推論を高速化するか？
量子化の主なメリットはVRAM削減で、速度向上ではありません。現代のNVIDIA GPU（RTX 40シリーズ）では、Q4とQ5はFP16と同じ速度で動作します。間接的な速度メリット：小さいQ4モデルはディスクからより速く読み込まれます。
最大速度のためにGPUメモリ使用率は何%に設定すべきか？
vLLMで90–95%に設定（--gpu-memory-utilization 0.92）。これによりエンジンがKVキャッシュ用により多くのメモリを事前確保できます。100%は避けてください — OOMクラッシュを引き起こします。
なぜ最初のプロンプト後にローカルLLMが遅くなるのか？
最初のプロンプトはモデルをVRAMにロードします（コールドスタート）。これには10–30秒かかる場合があります。セッション間でサーバーを起動したままにしてください。Ollamaでは、非アクティブ後のモデルアンロードを防ぐためOLLAMA_KEEP_ALIVE=24hを設定。
CPUのみの推論を意味のある形で高速化できるか？
限定的な改善が可能です：llama.cppで-tフラグを使用して物理コア数（論理コア数ではなく）に設定、AVX2/AVX-512命令セットを有効化、Q4_K_M量子化を使用。現実的な上限：最新i9で8–12 tok/sec。インタラクティブチャットにはGPUハードウェアが唯一の選択肢。
コンテキスト長は推論速度にどう影響するか？
Attentionメカニズムがコンテキスト長に対して2次的にスケールするため、長いコンテキストウィンドウは推論を遅くします。4Kコンテキストのプロンプトは1Kより~4×遅い。システムプロンプトは500トークン未満に保ってください。
PagedAttentionとは何か、なぜvLLMを高速化するのか？
PagedAttentionはvLLMのKVキャッシュ管理システムです。リクエストごとに固定メモリブロックを事前確保する代わりに、OSの仮想メモリのようにメモリを動的にページングします。これによりVRAMの断片化が解消され、GPU利用率が~55%から90%+に向上します。
GGUFとsafetensorsモデル形式の速度差はあるか？
はい。GGUF（llama.cppとOllamaが使用）は組み込み量子化付きのCPU/コンシューマーGPU推論に最適化。Safetensors（vLLMとHuggingFaceが使用）は全精度GPU推論に高速。RTX 40シリーズでFP16を実行する場合、safetensors + vLLMは通常GGUF + Ollamaより10–20%優れています。
ソース
- vLLM最適化ガイド -- docs.vllm.ai/en/dev_guide/performance_tuning.html
- Ollamaパフォーマンスヒント -- github.com/ollama/ollama/blob/main/docs/troubleshooting.md