AREX Feed Article
Simon Willison 实测 Qwen3.8-27B：MTP 草稿解码提速约 72%，默认推理却过度思考
开发者 Simon Willison 8 月 16 日发布了对 Qwen3.8-27B 的：在 NVIDIA DGX Spark 上启用 llama.cpp 的 --spec-type draft-mtp 草稿投机解码后，服务端比 LM Studio 默认 GGUF 快约 72%。同一篇评测还量化了默认推理档的"过度思考"：一个骑自行车的鹈鹕 SVG 任务消耗 22,276 个推理 token、跑了 21 分钟，最终只输出 3,223 token。
Qwen3.8-27B 是阿里 Qwen 研究实验室 8 月 14 日（周五）发布的 27B 参数视觉模型，Apache 2.0 许可。8 月 16 日， 宣布它已成为 Hugging Face 排名第一的热门模型。
22,276 个推理 token，换一只骑自行车的鹈鹕
Willison 在 128GB M5 Max MacBook Pro 和 NVIDIA DGX Spark 两台机器上，都通过 LM Studio 跑 17GB 的 Q4_K_M 量化版。Willison 转述的官方自报基准显示，该模型相对前代 Qwen 3.6 27B 与闭源 Qwen 3.7-Plus 均有提升；他在文首说独立基准会怎么说值得关注，然后自己动手测了。
Qwen 官方文档写明，模型默认 reasoning_effort 为 xhigh，定位是"为需要彻底分析的复杂任务设计"，另有 medium 与 low 两档；LM Studio 的 GGUF 保留了这个默认。他的评价是："这是个搞笑的默认值，绝对不是运行这个模型的好方式，尤其在消费级硬件上。"
他先撞上 LM Studio 默认 8,192 token 的上下文上限：Qwen 会把 token 全花在"思考"最普通的问题上。把上下文拉到 262,144 的模型上限后，问题消失，换来的是那只 21 分钟的鹈鹕。
那是他第一次在拉满上下文后生成"骑自行车的鹈鹕"SVG：耗时 21 分钟，消耗 22,276 个推理 token，产出 3,223 token。
Willison 承认这是他在本地模型上见过的最好的鹈鹕 SVG，车架形状正确、鹈鹕两侧都有腿（"非常罕见"）、翅膀伸到车把上、动线画在身后，但"值得为它等 21 分钟吗？绝对不值（Absolutely not）"。
同一个 prompt 关掉推理再跑：输出 3,715 token，耗时 137 秒，刚过两分钟。
过度思考在一个更简单的测试里暴露得更彻底。提示词只有一句 "draw an svg of a circle"，xhigh 档的推理轨迹却这样开头："用户想要一个圆的 SVG。简单的请求，但我想把它做成一件精心打磨的作品。"几分钟后，模型交出一个精美的动画圆，"完全不是我要的东西（entirely not what I had asked for）"。
他的建议很直接：先别管那个默认值，用 low 甚至完全关闭推理来跑 Qwen3.8-27B。"这是个好模型，但默认设置是个很糟的起点。"
draft-mtp 的 72% 提速是怎么测出来的
速度是评测的另一条线。LM Studio 默认 GGUF 下，Willison 测得约 15–30 token/s；他援引 Artificial Analysis 的数据对照，OpenAI 5.6 Sol 为 74 token/s，5.6 Luna 为 184 token/s。这个速度还不足以把他从响应快得多的托管 API 模型那里拉回来。
提速的机制内建在模型本身。Qwen 支持 Multi-Token Prediction（MTP）：一个更便宜的机制先猜出后面若干 token，主模型再快速验证猜测对不对。llama.cpp 作者 Georgi Gerganov 在模型发布当天给出用法，简单模式是 ，进阶模式再追加 。
Willison 依据这条推文，在 Spark 上直接用 llama serve 跑：Q4_K_M 主模型加 Q4_0 草稿模型，参数为 --spec-default --spec-type draft-mtp --reasoning-preserve。然后他让 GPT-5.6（跑在 Codex 里）代跑一组对比基准，结论是 draft-mtp 服务端比 LM Studio 默认 GGUF 快约 72%。
这个数字有自己的边界：单一机器、单一配置的对比，基准由跑在 Codex 里的 GPT-5.6 代跑。它回答的是"draft-mtp 在这台机器上相对默认 GGUF 能快多少"，不是模型整体速度的系统测试。Willison 预计接下来几周围绕如何更快地 serve 这个模型还会有大量创新，"MLX 社区多半也在酝酿什么"。
关掉推理，边界框和 Pi agent 依然能打
默认推理档的问题之外，模型的视觉与编码能力得到正面验证。视觉测试里，Willison 让模型对一张鹈鹕照片返回 0-1000 比例的 JSON 边界框，模型给出两组坐标 [195, 290, 370, 780] 与 [445, 320, 675, 850]，标签均为 pelicans。叠加到照片上后，他的评价是"太贴合了（such a good match）"。
渲染这张叠加图的工具，就是 Qwen3.8-27B 在笔记本电脑上离线写出来的：一个 prompt 生成完整 HTML 页面，支持输入图片 URL、粘贴 JSON、按 0-1000 比例换算坐标并渲染标注框。因为示例标签是 "pelicans"，模型还自己画了两只鹈鹕当演示数据，一个没被要求的 feature。Willison 自嘲，有点担心模型们被自己的鹈鹕基准"训练"得逮到机会就画鹈鹕。
推理在这里并非全无用处：关掉推理后，同一个任务生成的工具"几乎能用，但框画错了位置"。他判断不靠推理没法一次写出能用的工具，多轮提示也许能改对，"但这正是推理能带来差异的好例子"。
编码 agent 是本地模型的必考题。Willison 把 Pi（系统提示更短的 agent，更适合小模型）接上 LM Studio 里的 Qwen3.8-27B，在自己的 datasette 仓库里问 "how does auth work?"。模型经过一串推理和工具调用、读取多个文件后，给出的回答"非常扎实（very solid）"。他接着让模型写脚本把 Pi 会话的 JSONL 转成 Markdown，模型写出并测试了 pi_jsonl_to_md.py；他在文中发布的会话转录，就是用这个工具生成的。
#1 热门之后，性能是最后一块短板
同一天，@Alibaba_Qwen 发文感谢社区，宣布 Qwen3.8-27B 成为 Hugging Face 排名第一的热门模型，邀请用户试用反馈。Willison 的评测则指向剩下的问题：默认 xhigh 让简单问题也烧掉大量推理 token，默认 GGUF 的 15–30 token/s 离日常主力还差一口气。他的原话是，唯一挡住这个模型成为 daily driver 的是性能。
他给出的解释是稠密架构的通病：这类非 MoE 模型吃内存带宽，而他的 M5 Mac 和 DGX Spark 都不是带宽上的顶尖选手。出路至少有一条已经验证：draft-mtp 带来约 72% 的提速，只是需要用户自己改启动参数。
他在结尾写道：一个 17GB 的文件，装下了开放权重、长上下文、可用的工具调用、不错的视觉能力和称职的代码生成。"这个尺寸的模型还在以惊人的速度变好。要跑一个称职的模型，我们不需要花 50 万美元买数据中心级硬件。"