llama.cpp目前有重大性能BUG:checkpoint的巡回逻辑对于混合模型(比如qwen3.6-27B)无效,从而导致大概率每次对话都要prefill全文,严重拖慢速度
-
在昨天研究qwen3.6-27B的优化时,看到了这个问题:server: fix context checkpoint restore for hybrid/recurrent models (DeltaNet/Mamba
大概意思就是,因为llama.cpp的缓存巡回逻辑有问题,导致你n次调用大模型(n>1)时,大概率llama.cpp找不到之前的对话,会从头再次prefill你的对话全文。
翻译成大白话讲,就是你对一个人,每多说一句话,就要从第一句开始重复一遍。
更为悲惨的是:
在5月份,llama.cpp制作组引入了另外一个checkpoint逻辑,使得缓存巡回性能再次下降:Commit e98cb51
经过此帖中大神实测,NVIDIA RTX PRO 6000 Blackwell在运行qwen3.6-27B Q8时,上下文50K的长度下,每次请求LLM都会浪费40秒:
3 consecutive full re-processings logged: ┌───────────┬────────────────────┬───────┐ │ Turn │ Tokens reprocessed │ Time │ ├───────────┼────────────────────┼───────┤ │ Task 2795 │ 67,608 │ 38.4s │ ├───────────┼────────────────────┼───────┤ │ Task 3241 │ 71,211 │ 41.0s │ ├───────────┼────────────────────┼───────┤ │ Task 3401 │ 71,105 │ 41.4s │ └───────────┴────────────────────┴───────┘ Root cause visible in logs: The new prompt is ~19k tokens, but all checkpoints sit at positions 39k–71k (from previous longer requests). Every checkpoint is checked against 19340 and rejected because they're all beyond the new prompt length. Result: 0 usable checkpoints → full reprocess from BOS.结论是,目前的llama.cpp+qwen3.6-27B这个组合,在Agent工具这个场景下,性能不可用。
目前此issues还是open状态,待修复。@terry @tony-wang
@kop-wang 我在 7900xtx 上用 llama-server (vulkan, b9553) +
unsloth/Qwen3.6-27B-MTP-GGUF+ hermes 配 262144 context, 问题的症状和这个不一样. 我可以一个 session 顺利到达 >200K 的上下文结束. 中间没有这里提到的 prefill 重填的问题(或者我没有注意到?). 我碰到的问题是, 任务结束以后, gpu还在运行, llama-server log 显示收到了一堆任务, 然后最后导致 ~200K 的 prefill 全部失效 且重新 prefill. 让 hermes 自己调查了一下 (让它直接监控 llama-server 的日志, 它再和自己的日志对比), 它说是creation_nudge_interval和nudge_interval导致的, 并建议我把它们置0 (disable). -
是的,这个问题困扰我挺久了,严重影响任务节奏,前几天换成VLLM后,目前感觉还挺不错,开启前缀缓存,hit百分之八九十,开MTP后推理速度跟llama相差无几,而且可以多任务并行,如果不想折腾推荐先用vllm。SGLANG运行Qwen3.6 INT4时目前兼容度还不是很好,有bug,注意避坑。
-
是的,这个问题困扰我挺久了,严重影响任务节奏,前几天换成VLLM后,目前感觉还挺不错,开启前缀缓存,hit百分之八九十,开MTP后推理速度跟llama相差无几,而且可以多任务并行,如果不想折腾推荐先用vllm。SGLANG运行Qwen3.6 INT4时目前兼容度还不是很好,有bug,注意避坑。
-
@kop-wang 大神不敢当,小学生而已,共同进步。你的情况我没有遇到,也许可以先关闭cuda-graph或前缀缓存启动一次试试,实在不行用我现在这个模型试下:shawnw3i/Qwen3.6-27B-AWQ-MTP,参考启动参数:
vllm serve /path/to/models/Qwen3.6-27B-AWQ-MTP
--tensor-parallel-size 2
--max-model-len 262144
--gpu-memory-utilization 0.88
--kv-cache-dtype fp8
--max-num-seqs 2
--reasoning-parser qwen3
--enable-auto-tool-choice
--tool-call-parser qwen3_coder
--port 9527 --host 0.0.0.0
--trust-remote-code
--served-model-name Qwen3.6-27B-AWQ-MTP
--max-num-batched-tokens 16384
--enable-prefix-caching
--speculative-config '{"method":"mtp","num_speculative_tokens":3}'
另外如果要用turboguant(跟MTP有兼容性问题),现在的版本需要先合并issues里的两个补丁,或者等0.23版本,以上希望可以帮到你。 -
@kop-wang 我在 7900xtx 上用 llama-server (vulkan, b9553) +
unsloth/Qwen3.6-27B-MTP-GGUF+ hermes 配 262144 context, 问题的症状和这个不一样. 我可以一个 session 顺利到达 >200K 的上下文结束. 中间没有这里提到的 prefill 重填的问题(或者我没有注意到?). 我碰到的问题是, 任务结束以后, gpu还在运行, llama-server log 显示收到了一堆任务, 然后最后导致 ~200K 的 prefill 全部失效 且重新 prefill. 让 hermes 自己调查了一下 (让它直接监控 llama-server 的日志, 它再和自己的日志对比), 它说是creation_nudge_interval和nudge_interval导致的, 并建议我把它们置0 (disable).@laobenxiong hermes每个N轮对话,会自动运行一个background_review,总结对话中的记忆和skill,在单slot中会导致system prompt与之前的不一致,所以prefill全部失效,而且hermes硬编码这个任务必须主模型亲自来完成,对于目前的llama.cpp版本来说确实不太友好。
-
这个问题也困扰我很久,目前用chat template 补丁,还是有不少改善:
https://lcz.me/post/5404 -