夜雨聆风30% 提速没有出现，Qwen3.8-27B-MTP 这次测到了什么？
这次测试原本有一个很明确的期待：把 llama.cpp 换到标注为“0.2”的新 build，Qwen3.8-27B-MTP 应该比老版本快约 30%。
结果却很朴素：旧版 llama-b10472-bin-win-vulkan-x64 的截图速度是14.42 t/s，新版 llama-b10588-bin-win-vulkan-x64 的截图速度是13.57 t/s。两者都属于 10+ token/s 档位，新版反而低约0.85 t/s；不过两组输出长度和截图指标并不完全一致，不能把这一次差异直接当成严格 AB 结论，更不足以宣布新版本不如旧版本。
这次测试最有价值的地方：
MTP 已经工作，不代表 llama.cpp 换版后一定按宣传预期线性变快。
先看结论
在这台 AMD 锐龙 AI MAX+ 395 上，使用相同的 Qwen3.8-27B-MTP-Q8_0 模型、相同的主要启动参数和单并发设置：
新旧 build 的长任务 decode 都处于 10+ t/s 档位； 前 2 张图属于新版 b10588：前端统计 13.57 t/s，上下文面板显示约 7.26K； 后 3 张图属于旧版 b10472：前端统计 14.42 t/s，终端记录 draft acceptance 0.54998，即 4572 / 8313，平均草稿长度约 2.65； 当前证据没有显示稳定的 1.3× 提速； 新版本的输出观感似乎更好，但在 temp=1.0 下，单次输出不能直接证明模型质量发生了确定性提升。
所以，本篇的结论不是“0.2 没用”，而是：
这次机器、这组参数、这批输入，没有复现期待中的 30% decode 提升；要判断版本升级是否值得，必须把 acceptance、目标模型验证耗时、草稿开销和端到端速度一起看。
版本命名说明：b10472、b10588 是 llama.cpp 的 build 编号。本文沿用对 b10588 的“0.2 版本”称呼；发布前建议用 llama-server.exe --version 和启动日志核对实际版本字符串，不要把 build 编号直接等同于官方语义化版本号。
测试平台：AMD 锐龙 AI MAX+ 395 的共享显存路线
本次模型是：
Qwen3.8-27B-MTP-Q8_0.gguf模型文件：约 28G部署方式：llama.cpp + Vulkan + 集成 MTP并发：-np 1，单 slot
截图中的 GPU 为 AMD Radeon(TM) 8060S Graphics。一次运行时，任务管理器显示：
专用 GPU 内存约 35.5 / 63.8 GB； 总 GPU 内存约 38 / 112 GB； GPU 利用率约 85%； 温度约 56℃。
这里的 112 GB 是系统与 GPU 可共享的 GPU memory pool，不能简单写成“112 GB 独立显存”。对本地大模型来说，这个平台的优势是容量宽裕；但容量宽裕不等于每一步都能把计算单元喂满，decode 阶段依然会受到内存带宽、kernel 调度和 Vulkan 后端实现影响。
完整启动命令：两次测试只更换 llama.cpp build
新版 b10588 的命令如下，旧版只把目录名替换为 b10472：
llama-b10588-bin-win-vulkan-x64\llama-server.exe ^-m ”D:\ChatGPT\llama.cpp.demo\models\MTP\Qwen3.8-27B-MTP-Q8_0.gguf” ^-c 262144 -b 2048 -ub 1024 ^--flash-attn on ^--host 0.0.0.0 --port 88 ^--temp 1.0 --repeat-penalty 1.05 --top-p 0.95 --top-k 20 ^--n-gpu-layers 999 --no-mmap -np 1 ^--cache-type-k q4_0 --cache-type-v q4_0 ^--ui-mcp-proxy --reasoning-preserve ^--spec-draft-n-max 3 --spec-type draft-mtp ^--timeout 600000
这条命令里，真正和本次性能主题直接相关的是：
--spec-type draft-mtp：启用模型内置的 Multi-Token Prediction 推测解码。 --spec-draft-n-max 3：每轮最多提出 3 个草稿 token。 -c 262144：上下文上限为 262144，但截图中的实际请求只有约 7.26K～8.95K token，并没有把 262K 上限全部吃满。 -b 2048 -ub 1024：分别影响批处理和物理 batch，换 build 时必须保持一致。 --cache-type-k q4_0 --cache-type-v q4_0：KV Cache 使用 q4_0，降低占用，但也应在真实代码、推理和长文任务中验证质量。 -np 1：单 slot 测试，得到的是单会话 decode 表现，不是多人并发吞吐。
llama.cpp 上游目前把 MTP 作为 draft-mtp 推测解码类型，并提供 --spec-draft-n-max 等参数；是否能获得收益，还取决于模型文件确实包含对应的 MTP/NextN 权重，以及当前 build 的架构实现是否完整。上游推测解码文档也提醒，推测解码的收益依赖草稿频繁被目标模型接受。
新版本 b10588：13.57 t/s，前两张张图显示资源运行正常
前 2 张图片对应新版 b10588：
前端统计：5649 tokens，用时 6 分 56 秒，平均约 13.57 t/s； 上下文面板：约 7.26K / 262.14K，实际请求没有接近 262K 上限； GPU 面板：专用 GPU 内存约 35.5 / 63.8 GB，总 GPU memory 约 38 / 112 GB，利用率约 85%，温度约 56℃。
这组图能够确认新版已经正常加载 Qwen3.8-27B-MTP，并且 MTP 服务可以完成长输出；它没有提供新版对应的完整终端 acceptance 行，因此不能把后面旧版日志中的 0.54998 直接归给新版。
老版本 b10472：14.42 t/s，后三张图给出完整 acceptance
后三张图片对应旧版 b10472。最完整的一段终端日志显示：
prompt eval time = 298546.41 ms / 1611 tokens53.96 tokens per secondeval time = 509030.06 ms / 7342 tokens14.42 tokens per secondtotal time = 538890.47 ms / 8953 tokensdraft acceptance = 0.54998 (4572 accepted / 8313 generated)mean length = 2.65
旧版前端截图记录：7342 tokens，用时 8 分 29 秒，平均约14.42 t/s；上下文面板约8.95K / 262.14K。这比新版前端的 13.57 t/s 高0.85 t/s，但两次生成 token 数、上下文长度和计时窗口不同，适合描述为“本次截图旧版更快”，不适合直接宣布旧版普遍领先。
这些数字说明旧版的 MTP 路径确实在跑，而且长输出阶段达到 14.42 t/s。真正值得注意的是 acceptance：
0.54998 并不低到说明 MTP 失效，但也没有高到足以自然解释 30% 以上的系统级提速。
mean length = 2.65 也很有信息量：在最多 3 token 的草稿窗口下，系统平均每轮实际接受约 2～3 个 token。它说明候选并非全部被拒绝，但目标模型仍然需要频繁参与验证。
新旧版本放在一起：这次截图是旧版更快
模型文件、上下文、batch、KV Cache、MTP 参数、采样参数和单并发设置保持一致。按图片顺序整理后：
按这两张前端速度图，旧版高出新版0.85 t/s，约为 5.9% 的单次截图差异。但两次输出 token 数分别是 5649 和 7342，上下文长度也不同；这个数字只能描述“本次截图旧版更快”，不能证明旧版在所有任务都更快。
因此，现有证据不支持 b10588 出现 1.3× 稳定跃升，也不支持“新版一定慢 30%”。下一轮应该用同一批 prompt、同一输出长度和完整终端日志，才能给出严格的 AB 百分比。
没有同一批 prompt 的完整日志，就没有资格给出精确 AB 百分比。
为什么 acceptance 约 0.54，却没有自动换来 30% 提速？
这是这次测试最值得解释的地方。
MTP 的工作方式大致是：模型内部先提出几个候选，目标模型再并行验证，接受连续正确的前缀。acceptance 越高，通常越有机会减少目标模型的串行步数；但最终每秒输出多少，还要扣除：
MTP 草稿头本身的计算时间； 目标模型批量验证的时间； KV Cache 读写与同步； Vulkan kernel 的调度和内存访问； 采样、服务层和 UI 统计开销。
所以更接近真实情况的判断是：
acceptance 决定“猜对了多少”，系统耗时决定“猜对之后省没省下来”。
这次每轮最多提出 3 个 token，平均草稿长度约 2.65。即使候选大多被接受，单轮减少的目标模型串行次数也有上限。想得到更高加速，必须确认更大的草稿窗口是否被模型训练支持、是否会带来更低 acceptance，以及增加的验证 batch 是否反而拖慢后端。
截图显示 GPU 利用率约 85%，但利用率不是单一的“算力完成度”指标。Q8_0 权重、q4_0 KV Cache、Vulkan 后端和 27B 规模共同决定每一步要搬运多少数据。版本升级即使减少了一部分调度开销，也可能被权重读取和 KV 访问抵消。
本次请求的实际上下文只有约 7K～9K token。把 -c 262144 写进命令，表示服务允许这么长，并不意味着每一步都按 262K 上下文计算。测试时仍要记录真实 prompt 长度，否则很容易拿“上下文上限”解释并不存在的性能差异。
一个新 build 的改动可能改善模型加载、MTP 兼容性、显存管理、输出一致性或异常处理，并不一定全部反映成单用户 decode 速度。若 0.2 版本的输出更符合预期，这可以作为体验反馈，但还需要固定随机种子和同一提示词做回归，不能只凭一次聊天得出“质量更好”的结论。
结语：这次简单的测试没有 30%
Qwen3.8-27B-MTP 在 AMD 锐龙 AI MAX+ 395 上可以正常工作：新版 b10588 的前两张图显示13.57 t/s；旧版 b10472 的后三张图显示14.42 t/s、0.54998 acceptance、2.65 平均草稿长度。按这组截图，旧版反而高出0.85 t/s，但由于输出 token 数和上下文长度不同，不能视为严格 AB 结论。
所以这次测试的结论是：
llama.cpp 换到“0.2”版本后，当前环境没有稳定复现预期的 30% 提速；MTP 路径是有效的，但版本收益必须通过同口径 AB 测试确认。新版输出观感更好属于值得继续验证的线索，暂时不是定论。
如果你也在 Qwen3.8-27B-MTP、Vulkan 或 AMD 平台上测试，欢迎留言提供同样格式的 eval time + draft acceptance + mean length 日志。只有把测试条件对齐，大家才知道这 30% 到底是版本能力、硬件差异，还是一张峰值截图带来的错觉。
