llama.cpp prompt processing 35x slower? Ayusin ang q5_1 KV cache

Ang iyong lokal na modelo ay sumasagot nang maayos, ngunit ang bawat mahabang prompt ay tumatagal na ngayon ng isang minuto at kalahati habang walang ginagawa ang GPU. Kung pinapatakbo mo ang llama.cpp gamit ang -fa on at isang q5_1 KV cache, malamang iyon ang dahilan: ang default na CUDA build ay walang flash-attention kernel para sa uri ng cache na iyon, kaya tahimik na tumatakbo ang attention step sa CPU. Ang pagpapalit ng cache sa q8_0 ay nagdala sa isang reporter mula 38 hanggang 1348 tokens/s sa prompt processing.

Ang mga numero sa ibaba ay mula sa llama.cpp issue #28455 (binuksan noong 5 Setyembre 2026, build 10791, sinuri noong 28 Oktubre 2026). Isang reporter, isang RTX 4080, isang 27B model, kaya basahin ang mga ito bilang isang halimbawa, hindi bilang batas. Ang kanilang root-cause analysis ay kanila rin: tinawag ito ng isang maintainer na "isang kilalang isyu" at isinara ang isyu kinabukasan.

Ano ang hitsura sa screen#

Ang setup ay ordinaryo. May gustong magkaroon ng 131072-token context sa isang 16 GB card, kaya pinaliit nila ang KV cache sa 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

Pagkatapos ay nagpadala sila ng 3.6K-token prompt. Ang prompt processing ay tumakbo sa 38.4 tokens/s at ang decoding sa 6.5 tokens/s. Gawin ang dibisyon: 3,600 ÷ 38.4 = 93.75, kaya mga 94 segundo bago ang unang salita. Sa q8_0 ang parehong prompt ay tumakbo sa 1348 tokens/s: 3,600 ÷ 1,348 = 2.67, wala pang tatlong segundo.

Ang palatandaan ay nasa task manager. Sa mga mabagal na run, ang GPU ay halos 0% habang ang CPU ay nagpapakita ng mga 930% (siyam o sampung core ang abala). Ang GPU na walang ginagawa habang "nagpapatakbo ka sa GPU" ang sintomas na dapat hanapin.

Bakit ang mas maliit na cache ay nagpapabagal nang ganito#

Ang flash attention ay isang fused GPU kernel. Ang default na CUDA build ay nagbibigay lamang nito para sa ilang pares ng uri ng KV cache. Para sa q4_0, q4_1, q5_0 at q5_1 walang kernel, kaya hindi tumitigil ang llama.cpp sa isang error. Inililipat nito ang operasyong iyon sa CPU at nagpapatuloy. Gumagana pa rin ang lahat, mga 35 beses lang mas mabagal sa prompt processing (1348 ÷ 38.4 = 35.1).

Ang "tahimik" na iyon ang buong problema. Walang sinasabi ang sagot. Ang prompt processing ang pinakamalaki ang pagbaba (mga 35×), at bumabagal din ang generation: 6.5 tokens/s kumpara sa 30.1 sa q8_0 sa parehong isyu.

Suriin ito sa dalawang minuto#

Patakbuhin ang llama-bench gamit ang parehong mga uri ng cache na ginagamit mo sa server, isang beses bawat variant, at panoorin ang GPU sa ibang terminal:

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

Ang pp512 na resulta ng reporter sa isang Qwen 27B Q5_K_XL: 1511.92 tokens/s para sa q8_0/q8_0, mga 197 para sa q5_1/q5_1 sa default build. Kung ang iyong dalawang linya ay may ganoong agwat at ang nvidia-smi ay nagpapakita ng GPU na walang ginagawa sa pangalawa, natagpuan mo na ito.

Bago mo ayusin ang anuman, itugma ang nakikita mo sa malamang na dahilan:

Ayusin 1: gamitin ang q8_0 (o i-rebuild)#

Ang pinakamabilis na ayos ay baguhin ang dalawang flag at panatilihin ang lahat ng iba pa:

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

Sa isyu, nagbigay ito ng 1348 tokens/s sa prompt processing at 30.1 tokens/s sa decoding (mula sa 6.5). Ang kapalit ay memory: ang q8_0 cache ay mas malaki kaysa sa q5_1, kaya tiyakin na kasya pa rin ang haba ng context mo sa VRAM.

Kung kailangan mong panatilihin ang q5_1 dahil sa memory, i-rebuild na kasama ang lahat ng kombinasyon ng flash-attention cache:

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

Ang build na iyon ay nagpatakbo ng q5_1 sa 1509.70 tokens/s sa pp512 at 1162 tokens/s sa 3.6K-token prompt, na may decoding sa 38.5 tokens/s. Itinuro ng isang komentarista sa isyu na ang paglipat ng trabaho sa pagitan ng mga backend ay maaaring bahagyang magbago ng numerical results at nagmungkahi ng paghahambing ng perplexity sa pagitan ng mga build. Kung mahalaga sa iyo ang eksaktong output, magpatakbo ng isa.

Ang sagot ng maintainer na "kilalang isyu" ay hindi nagsasabi kung binago ito ng kasalukuyang mga bersyon ng llama.cpp. Ang tapat na pagsusuri ay ang pares ng llama-bench sa itaas: kung malapit ang dalawang linya, maayos ka.

Kailan hindi na sulit ang pag-tune#

Sabihin nating gumana na ang ayos, at ngayon ay tinatimbang mo ang susunod na round: mas maraming flag, pangalawang GPU, mas maliit na quant. Kung ang trabaho ay mga summary, code review o extraction sa mga prompt na ilang libong token, itanong kung magkano ang oras at pagsisikap na ginugugol ng isang request, hindi lang watts.

Narito ang isang nakasaad na workload na maihahambing. Sabihin nating ang isang summarization job ay nagpapadala ng 3,600 input tokens at nakakakuha ng 500 pabalik, 1,000 beses. Sa CheapTokens, mga $0.104 iyon sa DeepSeek-V4-Flash (380K context, hanggang 32,768 output tokens bawat sagot, isang presyo sa anumang oras) at mga $0.092 sa GLM-5.3-Flash (390K context). Binibilang ng table ang input at output nang magkasama, may OpenRouter column para ihambing:

Walang pakialam ang API sa uri ng cache mo, sa VRAM mo o sa build flags mo; walang babalikan sa CPU. Magpadala muna ng ilang totoong prompt mo at ikaw mismo ang humatol sa mga sagot. Maliit lang ang hakbang: nagsasalita ang endpoint sa OpenAI Chat Completions format, kaya karamihan ng lokal na client ay kailangan lang ng bagong base 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}'

Ang buong setup ay nasa CheapTokens docs, at ang kasalukuyang presyo ng bawat modelo ay nasa pricing page. Para sa mas mahabang pagtingin sa hardware kumpara sa API, tingnan ang Run DeepSeek locally or use an API. Kung gusto mong makita kung paano hiwalay na sinisingil ang input at output, saklaw ito ng input vs output tokens.

Ang pagkakasunod-sunod na dapat sundin#

Isa pang babala tungkol sa mga source: ang buong diagnosis ay nakasalalay sa isang pampublikong isyu at isang GPU. Ituring ang 1348 at 38.4 bilang kung ano ang nangyari doon, at sukatin ang sarili mong card bago ka magtiwala sa alinman.