llama.cpp应该及时更新版本和调整参数了😄

[joker_chang]

上午一个长任务直接卡死了，很郁闷，然后开始研究怎么搞。

最后决定升级 llama.cpp 的版本，使用官方编译版本：

llama-b10534-bin-win-cuda-13.3-x64

同时重新调整 llama-server 的启动参数。

llama-server 启动参数

--reasoning off ^
--n-gpu-layers -1 ^
--ctx-size 196608 ^
--flash-attn on ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--spec-type draft-mtp ^
--spec-draft-n-max 2 ^
--spec-draft-n-min 1 ^
--temp 0.7 ^
--parallel 1 ^
--kv-unified ^
--load-mode mlock ^
--jinja ^
--no-warmup

先上效果截图

与之前的配置比较

这次主要做了三个调整：

1. 上下文长度从 128K 增加到 192K。

2. 移除了 --batch-size 4096 和 --ubatch-size 2048 两个参数，直接交给 llama-server 自己处理。不删除它们的话，跑推理时会加载 CPU 和内存，速度暴跌。

3. --spec-draft-n-max 从 3 改成 2，实际使用下来，命中率和推理速度都有稍许增加。

[Jioyzen]

我用的turbo3的KV Cache 比 q4_0 省显存 性能也更好

[terry]

@joker_chang 提交之前发给AI整理成markdown格式，我帮你整理了。

[joker_chang]

有哪位大神可以指点一下，就改这么一个小bug，结果跑了49分5s。
webui前端已经设置成medium了

[Xiaote]

49分5s 这个数字很典型，先算一笔账：你的 --ctx-size 196608，如果前端每轮把完整历史重发、llama-server 又没复用 cache，就是全量重 prefill——196608 tokens ÷ ~67 t/s ≈ 49 分钟，和你实测几乎完全对上。优先查这三点：

1. 打开 /health 看 slots_state 和 n_past：如果每个请求 n_past 都归零，就是每轮全量重算。保持同一 slot、别让前端清上下文，llama.cpp 同 slot 会自动复用前缀缓存；
2. 把 --ctx-size 降到实际够用（比如 128K），196K 的 KV 和 prefill 代价都不小；
3. 开了 --reasoning 且 effort 高的话，小改动也可能触发超长 CoT——关掉 reasoning 或降到 low 跑一次同样的请求，区分是 prefill 慢还是 decode/思考慢。

另外 q4_0 KV 在 196K 下不小，显存放不下会 spill 到内存，速度直接崩——/health 里看 kv_cache 是否全在 GPU。MTP 投机解码只加速 decode，对 prefill 没帮助，别指望它。