ローカルLLMの遅さの正体
0.5Bの小さなモデルでも、16kトークンを読み込むだけで約47秒かかった。遅さの正体は生成ではなく、毎ターン送る量にある。CPUで測った。
Claude Code をローカル LLM に向けると、返事が来るまでが長く感じます。編集部でも、システムプロンプトの読み込み（prefill）だけで3分かかったことがあります。この記事では、何が遅さの原因なのかを、手元の CPU で測った数字で説明します。
ローカルかクラウドかの前に、エージェントのタイプの違いは「コーディングエージェントの選び方」で整理しました。
Claude Code はローカルのモデルにもつなげる
Ollama の公式ドキュメントには、Claude Code をローカルのモデルにつなぐ手順があります。ANTHROPIC_BASE_URL=http://localhost:11434 などの環境変数を設定して、claude --model <モデル名> で起動します（出典：https://docs.ollama.com/integrations/claude-code 、2026-10-16確認）。
同じページは、ローカルのモデルには 64k 以上のコンテキストウィンドウ を設定するよう勧めています（同出典）。Claude Code が1回に送る量が多い、ということです。
prefill を測った
GPU のない編集部の検証環境（8コア、メモリ 15GB）で、llama.cpp（build 11671）の llama-bench を使い、0.5B の小さなモデル（Qwen2.5-0.5B-Instruct、Q4_K_M、約463MiB）を測りました（2026-10-16）。
./llama-bench -m qwen2.5-0.5b-instruct-q4_k_m.gguf -p 512,4096,16384 -n 64 -r 1 -t 8| テスト | 速度（トークン/秒） | 読み込みにかかる時間（計算） |
|---|---|---|
| prefill 512トークン | 607.90 | 約0.8秒 |
| prefill 4,096トークン | 652.20 | 約6.3秒 |
| prefill 16,384トークン | 345.42 | 約47.4秒 |
| 生成 64トークン | 142.95 | 約0.4秒 |
1回だけの計測なので、ばらつきは取れていません。編集部で同じコマンドをもう一度流すと、4,096トークンは648.70、16,384トークンは343.78、生成は138.03で、ほぼ同じでした。512トークンだけは888.01と大きく揺れました。短い入力の数字は、あてにしないでください。それでも傾向ははっきりしています。
- 長い入力では、1トークンあたりの読み込みも遅くなります。16kトークンでは、4kトークンのときの約半分の速度でした。
- 生成そのものは速く、64トークンが1秒もかかりません。
遅さの正体は、答えを書く時間ではなく、毎ターン送る文脈を読む時間です。 これは、ここで測った0.5Bのモデルの話です。実用的な大きさのモデルでは、1トークンあたりがもっと重くなります。
だから「何トークン送るか」で選ぶ
ハーネス（Claude Code や、ほかのエージェント CLI）を選ぶときは、機能の数よりも、1ターンにどれだけ送るかを見ます。システムプロンプト、組み込みツールの定義、会話の履歴は、毎ターン送られます。MCP のツール定義は既定で遅延読み込みになっていて、使うまではツール名とサーバーの説明だけが入ります（同出典の公式ドキュメント）。
Claude Code では、/context で何が文脈を占めているかを確認できます。使わない MCP サーバーは /mcp で無効にできます（出典：https://code.claude.com/docs/en/costs 、2026-10-16確認）。クラウドの API なら料金で済む差が、ローカルでは、そのまま待ち時間になります。
クラウドで払う場合の料金は「Claude Codeの料金、実際いくら？」にまとめました。
投機デコードは既定値を疑う
生成を速くする投機デコードでは、小さなドラフトモデルが先に何トークンか書き、本体のモデルがまとめて検証します。llama.cpp では、ドラフト長の上限を --spec-draft-n-max で指定します。既定は3です（llama-server --help、build 11671 で確認）。
編集部の環境では、2にしたときが最速で、既定より65%速くなりました。4以上にすると、逆に遅くなりました。最適な値は、モデルの組み合わせとハードウェアで変わります。必ず自分の環境で測ってください。
思考モデルは max_tokens を絞りすぎない
思考（thinking）するモデルで max_tokens を小さく切ったら、content が空で返ってきました。出力の枠を、思考のトークンが使い切っていたためです。ローカルで速くしようとして上限を絞るときは、思考の分を見込んでおきます。
まとめ
- ローカル LLM の遅さは、生成ではなく、毎ターンの prefill から来る。
- 長い文脈ほど、1トークンあたりも遅くなる（手元では16kで4kの約半分の速度）。
- ハーネスは「1ターンに何トークン送るか」で選び、使わない MCP は外す。
- 投機デコードのドラフト長は、既定の3のままにせず測る。
製品ごとの違いは「AIコーディング3製品を運用で比較」で比べています。