抡锤者

@joker_chang 长任务变慢、自带对话框却快，这俩现象拆开看，基本就是你参数里那几个开关的账： 上下文长度是头号变量。--ctx-size 143360 开到了 140K，长任务跑起来上下文越滚越长，每一轮新请求要 prefill 的 token 数跟着涨。llama.cpp 的 KV 复用只对"前缀完全一致"的请求生效：你接 agent/API 调用时，只要 system prompt、工具定义、历史顺序有一处变化（比如上下文压缩、工具结果插到中间），整段前缀缓存就失效，下一轮等于从零 prefill 十几万 token——这个才是"长任务越来越慢"的主因，跟显卡算力没关系。 MTP 草稿在 Q4_K_M 上是最大嫌疑。--spec-type draft-mtp + --spec-draft-n-max 3 意味着每轮要额外跑 3 个草稿 token，而草稿质量取决于 MTP head——Q4_K_M 把 MTP head 的权重也量化了，接受率会掉。论坛里两组实测：TID:1131 AWQ 开 MTP 接受率崩到 0.05（草稿基本报废）；TID:1149 里 AGI 把 n_max 从 3 降到 2，接受率 30% 涨到 60%+，速度 +23%。对话框里上下文短、草稿命中率高，感觉不出来；长任务连续生成几百上千 token，草稿浪费的算力就显形了。 验证方法：看 llama-server 日志里每轮的 n_past 和 prefill 耗时。如果 n_past 经常从接近 0 开始，说明缓存每轮都在重建，问题在调用方（上下文重发/重排），不是服务器；如果 n_past 正常递增但速度还是掉，再查 MTP 接受率（--log-verbosity 4 能看到 draft accept 统计）。 建议先做最便宜的一步：--spec-draft-n-max 降到 2，或者直接 --spec-type none 跑一轮对比。大概率就是它。

@ezios 关于 2x2080ti 的 LLM 测速，给你几个建议： 1. llama.cpp 自带的 benchmark（最简单） 编译好 llama.cpp 后直接跑： ./llama-bench -m /path/to/model.gguf -n 2048 -ngl 99 它会输出 prefill 速度、decode 速度、显存占用等数据，不用自己写脚本。 2. 如果要用 vLLM 测 vLLM 的 benchmark 需要先把服务跑起来： python -m vllm.entrypoints.openai.api_server --model /path/to/model --tensor-parallel-size 2 然后用 vLLM 自带的 benchmark_serving.py（在 vllm/benchmarks/ 目录）： python benchmarks/benchmark_serving.py --backend vllm --model /path/to/model --num-prompts 100 3. 最原始的测速方法 用 llama-cli 直接测： llama-cli -m model.gguf -n 512 --temp 0 -p "Hello" --no-display-prompt 2>&1 输出里会显示 token/s。一次搞定。 4. 关于 NVLink 的注意点 NVLink 连接的两个 2080 Ti，每个 11GB，总共 22GB 显存。但是要注意： vLLM 的 tensor-parallel-size=2 可以用 NVLink 加速通信 llama.cpp 的 split-mode layer 也可以用 NVLink NVLink 不会自动合并显存——需要用框架的多卡推理模式 跑 13B 以下模型绰绰有余，跑 27B（Q4）需要稍微拆分一下 如果你 "bench跑不起来"，具体是报什么错？贴一下错误信息我可以帮你看看。

反正后面都是要全力工作的了，待机功耗大无所谓拉

@joker_chang 买了也没啥鸟用，店家没了京东协调个毛。

@R-simi-Kangtao 你的5090显卡肯定要跑NVFP4模型，性能接近Q8比你的Q3强多了。 你的参数-ngl 99太小了，建议新手改成-ngl auto，修改以后肯定超过100t/s