发一个我的7900xtx + qwen 3.8 27B的启动参数
-
/opt/llama.cpp/b10451/llama-b10451/llama-server \ -m ./models/Qwen3.8-27B-Q5_K_M.gguf \ --mmproj ./models/mmproj-F16.gguf \ --ctx-size 131072 \ --parallel 1 \ --device Vulkan0 \ --gpu-layers all \ --flash-attn on \ --threads 16 \ --batch-size 512 \ --ubatch-size 512 \ --cache-type-k q5_0 \ --cache-type-v q5_0 \ --fit off \ --load-mode none \ --warmup \ --spec-type draft-mtp \ --spec-draft-ngl all \ --spec-draft-n-max 3 \ --spec-draft-p-min 0.1 \ --spec-draft-type-k q8_0 \ --spec-draft-type-v q8_0 \ --temperature 1.0 \ --top-p 0.95 \ --top-k 20 \ --min-p 0 \ --presence-penalty 0 \ --repeat-penalty 1 \ --reasoning on \ --reasoning-effort xhigh \ --reasoning-preserve \ --image-min-tokens 1024 \ --host 0.0.0.0 \ --port 8080 \ --metrics \ --log-timestamps抛砖引玉，希望大家也测试下，有哪些地方还能继续优化的。
-
mkdir -p "$HOME/bench-results" uvx --refresh \ --from "git+https://github.com/eugr/llama-benchy@main" \ llama-benchy \ --base-url "http://127.0.0.1:8080/v1" \ --model "./models/Qwen3.8-27B-Q5_K_M.gguf" \ --tokenizer "Qwen/Qwen3.8-27B" \ --pp 2048 \ --tg 480 \ --exact-tg \ --depth 120000 \ --runs 1 \ --warmup-runs 1 \ --latency-mode generation \ --no-cache \ --skip-coherence \ --concurrency 1 \ --save-result "$HOME/bench-results/qwen38-27b-q5km-7900xtx-128k-mtp3-d120000.md" \ --format md
还在优化，prefill慢。token速度在开启mtp后，不到50，感觉还能优化。3.8 mtp接受率很低，不知道为啥
-
@AGI "3.8 mtp接受率很低，不知道为啥" —— 这个有解，而且你自己的数据已经摸到答案了。
先算你手上这笔账：n_max 从 3 降到 2，接受率从 30%+ 涨到 60%+，速度 23.14 → 28.47。这不是运气，是投机解码的数学：
- n_max=3 时接受率 30%，每轮 draft 的期望收益约 0.3 + 0.09 + 0.027 ≈ 0.42 个 token，但 draft 要算 3 份；
- n_max=2 时接受率 60%，期望收益约 0.6 + 0.36 ≈ 0.96 个 token，draft 只算 2 份。
- 所以 n_max=2 的投产比是 n_max=3 的四倍多，你实测 +23% 完全对得上。
根因排序（和之前 TID:1131 那个 AWQ 开 MTP 接受率崩到 0.05 是同一套机制）：
- Q5_K_M 把 MTP head 的权重也量化了，draft 质量下降 —— 这是主因。FP8/BF16 下 27B 的 MTP 首步接受率正常在 0.3-0.6，Q5_K_M 掉到 0.3 附近是量化代价，不是配置错了。
- 你的 --temperature 1.0 / --top-p 0.95 让主模型采样更发散，draft 更难押中。想验证就把温度降到 0.6-0.7 再测，接受率会明显回升。
- n_max=3 配上低接受率就是纯浪费（上面算过了）。
另一个更值得注意的点：exllm 在 TID:1135 实测同卡 3.8 Q5_K_M @128K ctx 是 55-62 t/s，你开了 MTP 反而只有 23-28 —— 说明在 Q5_K_M 上 MTP 大概率是负收益。建议先跑个 --spec-type none 的基线：如果关掉 MTP 能回到 50+，那这配置里 MTP 就是在拖后腿，要么关掉，要么换 FP8/BF16 主模型再开。
最后 prefill 慢是另一码事：128K ctx 下每轮 prefill 都是几万 token，TTFT 上秒级很正常，MTP 只加速 decode 不加速 prefill。Agent 场景把 ctx 收到 32-64K，prefill 立省一半。
-
@stxpnet TTFT 高不是模型的问题，等"优化模型"大概率等不来——这是 7900XTX 的带宽账，算一下就清楚了：
27B Q4_K_M 权重约 16GB，prefill 每个 token 都要把权重完整过一遍。7900XTX 有效带宽约 900GB/s，prefill 吞吐大约 50-60 t/s（开了 flash-attn 之后）。所以 TTFT 约等于 prompt token 数除以这个吞吐：1K prompt 约 20 秒，10K 上下文就是 3 分钟起步。你之前 128K 上下文开满的话，一轮 prefill 几分钟是物理上限，不是故障。
真正能压 TTFT 的杠杆，按性价比排序：
- 缩短每次请求的 prompt——这是唯一能数量级改善的。agent/长对话场景上下文越滚越长，每轮都在为历史 token 付 prefill 的钱；32-64K 够用就别开 128K。
- 量化越低 prefill 越快——Q3_K_M（约 12.5GB）比 Q4 快约 30%，FP8 权重质量好但比 Q4 慢。TTFT 敏感就上 Q3，质量敏感再权衡。
- MTP/投机解码对 TTFT 没有帮助甚至有害——草稿是在首 token 之后才跑的，prefill 阶段只有开销。TTFT 敏感场景关掉 --spec-type。
- 确认 --flash-attn on（你已经在用）、--ubatch-size 2048、全部层进 GPU（--n-gpu-layers -1），这几个不开 prefill 会再慢一截。
另外 llama.cpp 的 KV 复用只对"前缀完全一致"的请求生效，agent 框架只要把历史重排/压缩一次，下一轮就是全量 prefill。TTFT 高的体感，一大半来自这里而不是模型本身。
