llama.cppのプロンプト処理が35倍遅い？q5_1 KVキャッシュを修正する

ローカルモデルの回答自体は問題ありませんが、長いプロンプトを送るたびにGPUが何もしていないのに1分半も待たされるようになりました。llama.cppを-fa onとq5_1 KVキャッシュで実行している場合、それが原因である可能性が高いです。デフォルトのCUDAビルドにはそのキャッシュタイプ用のflash-attentionカーネルがないため、attentionステップが黙ってCPUで実行されます。キャッシュをq8_0に切り替えることで、ある報告者はプロンプト処理が38から1348トークン/秒になりました。

以下の数値はllama.cpp issue #28455（2026年9月5日作成、ビルド10791、2026年10月28日確認）によるものです。報告者1人、RTX 4080 1台、27Bモデル1つなので、法則ではなく一つの実例として読んでください。根本原因の分析も報告者によるものです。メンテナーは「既知の問題」と呼び、翌日issueをクローズしました。

画面上でどう見えるか#

セットアップは普通でした。16 GBカード1枚で131072トークンのコンテキストを確保したかったため、KVキャッシュをq5_1に縮小しました:

llama-server -m model.gguf -ngl 99 -fa on -c 131072 -np 4 \
  --cache-type-k q5_1 --cache-type-v q5_1

そして3.6Kトークンのプロンプトを送信しました。プロンプト処理は38.4トークン/秒、デコードは6.5トークン/秒で実行されました。割り算をすると、3,600 ÷ 38.4 = 93.75なので、最初の単語まで約94秒です。q8_0では同じプロンプトが1348トークン/秒で実行されました: 3,600 ÷ 1,348 = 2.67で、3秒未満です。

手がかりはタスクマネージャーにあります。遅い実行中、GPUはほぼ0%のままだった一方、CPUは約930%（9〜10コアがビジー）を示していました。「GPUで実行している」はずなのにGPUがアイドル状態になっているのが、探すべき症状です。

キャッシュを小さくするとこれほど遅くなる理由#

Flash attentionは融合されたGPUカーネルです。デフォルトのCUDAビルドは一部のKVキャッシュタイプのペアにしかそれを同梱していません。q4_0、q4_1、q5_0、q5_1にはカーネルがないため、llama.cppはエラーで停止しません。その操作をCPUに移して続行します。すべては動作しますが、プロンプト処理が約35倍遅くなるだけです（1348 ÷ 38.4 = 35.1）。

その「黙って」が問題のすべてです。回答の中には何も示されません。プロンプト処理が最も低下し（約35倍）、生成も遅くなります。同じissueでq8_0では30.1トークン/秒だったのに対し、6.5トークン/秒です。

2分で確認する#

サーバーで使用しているのと同じキャッシュタイプでllama-benchをバリアントごとに1回実行し、別のターミナルでGPUを監視します:

llama-bench -m model.gguf -ngl 99 -fa 1 -ctk q8_0 -ctv q8_0 -p 512 -n 0
llama-bench -m model.gguf -ngl 99 -fa 1 -ctk q5_1 -ctv q5_1 -p 512 -n 0
nvidia-smi -l 1

報告者のQwen 27B Q5_K_XLでのpp512結果: q8_0/q8_0で1511.92トークン/秒、デフォルトビルドのq5_1/q5_1で約197トークン/秒。2つの行にそのような差があり、2回目の実行中にnvidia-smiでGPUがアイドル状態を示すなら、原因を特定できたことになります。

修正する前に、目にしている症状を考えられる原因と照合してください:

修正1: q8_0を使う（または再ビルドする）#

最も簡単な修正は2つのフラグを変更し、それ以外はすべてそのままにすることです:

llama-server -m model.gguf -ngl 99 -fa on -c 131072 -np 4 \
  --cache-type-k q8_0 --cache-type-v q8_0

このissueでは、プロンプト処理で1348トークン/秒、デコードで30.1トークン/秒（6.5から向上）になりました。代償はメモリです。q8_0キャッシュはq5_1より大きいため、コンテキスト長がまだVRAMに収まるか確認してください。

メモリ上の理由でq5_1を維持する必要がある場合は、すべてのflash-attentionキャッシュの組み合わせをコンパイルして再ビルドします:

cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

そのビルドはpp512でq5_1を1509.70トークン/秒、3.6Kトークンプロンプトで1162トークン/秒、デコードは38.5トークン/秒で実行しました。issueのコメント投稿者は、バックエンド間で処理を移すと数値結果が少し変わる可能性があると指摘し、ビルド間のperplexity比較を提案しました。正確な出力を重視するなら、1回実行してください。

メンテナーの「既知の問題」という返答は、現在のllama.cppバージョンでこれが変わったかどうかを述べていません。正直な確認は上記のllama-benchのペアです。両方の行が近ければ問題ありません。

チューニングが割に合わなくなるとき#

修正が機能したとして、次に何を検討するか: より多くのフラグ、2台目のGPU、より小さい量子化。ジョブが数千トークンのプロンプトでの要約、コードレビュー、抽出であれば、リクエストにかかる時間と手間を考えてください。ワット数だけではありません。

比較用の想定ワークロードを挙げます。要約ジョブが3,600入力トークンを送り、500トークンを受け取るのを1,000回行うとします。CheapTokensでは、DeepSeek-V4-Flash（380Kコンテキスト、回答あたり最大32,768出力トークン、時間帯に関係なく同一価格）で約$0.104、GLM-5.3-Flash（390Kコンテキスト）で約$0.092です。表は入力と出力を合計して数えており、比較用のOpenRouter列も含みます:

APIはキャッシュタイプ、VRAM、ビルドフラグを気にしません。CPUにフォールバックするものは何もありません。まず実際のプロンプトをいくつか送って、回答を自分で判断してください。手順は小さく、エンドポイントはOpenAI Chat Completions形式に対応しているため、ほとんどのローカルクライアントは新しいベースURLを設定するだけで済みます。

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize the text below in 5 bullets: ..."}], "max_tokens": 500}'

完全なセットアップはCheapTokensドキュメントにあり、現在のモデルごとの価格は価格ページにあります。ハードウェアとAPIの比較をより詳しく知りたい場合は、DeepSeekをローカルで実行するかAPIを使うをご覧ください。入力と出力が別々に課金される仕組みを知りたい場合は、入力トークンと出力トークンで説明しています。

取り組む順序#

情報源に関するもう一つの注意: 診断全体は1つの公開issueと1つのGPUに基づいています。1348と38.4はそこで起きたこととして扱い、どちらかを信じる前に自分のカードで測定してください。