Muse 对 Qwen3.8：更快的反而更慢？

一台 M5 Pro、六十四 GB 统一内存，同一道中文问答题，只换一边。Muse Glimmer 30B 每秒吐 16.7 个 token，Qwen3.8 27B 只有 12.8 个 —— 前者快了将近三成。但把答案完整交到手上，前者花了 24.8 秒，后者只用 7.3 秒。

两份答案的长度几乎一样：171 字对 166 字。同样多的字，一个等二十五秒，一个等七秒。如果只看跑分表上那一列 tok/s，你会挑错。

差距在第三张图里：Muse 每写 100 字正文要消耗 243 个 token，Qwen3.8 只要 57 个。多出来的部分没有消失，它们进了思考链——一段用户看不见、但要照常花时间生成的内容。

先说清楚这两位是什么来路。Muse Glimmer 30B 出自 Meta Superintelligence Lab，August 2026 发布，Apache 2.0 协议。

它从更大的 Muse Spark 蒸馏而来，目标写得很直白：让自主 agent 跑在消费级硬件上。知识截止日期是 2026 年 1 月 4 日。

Qwen3.8 27B 是通义 Qwen3.8 系列里的稠密款。官方描述里，它在编码、专业工作、研究和长程 agent 任务上相对前代有整体提升，原生支持图片和视频理解，从 STEM 图表、文档一直到小时级的视频。

※ 两边数字均取自各自的官方模型页。参数量口径不同：Muse 的 29.6B 含视觉编码器，Qwen3.8 的 27B 指语言模型本体。

上下文那一栏值得单独拎出来。Qwen3.8 原生 26 万 token、可扩到 100 万，Muse 是 13 万起步。但标称窗口和你能安心用的窗口是两回事，这一点后面会用一个具体数字说明。

Meta 给 Muse Glimmer 公布了一组对照数据，参照系是 Gemma4-31B 和 Qwen3.6-27B。挑几条最能说明定位的：

※ 数据出自 Muse Glimmer 官方模型页，Muse 一列为 High Reasoning 档。对照的是 Qwen3.6 而非本文实测的 Qwen3.8。

MCP Atlas 这一项拉开了二十分，那是衡量工具调用的。反过来在 OSWorld 和 SWE-Bench Verified 上它并不领先。把两组数字放在一起看，取向就很清楚：它是为「拿着工具把一件事做完」优化的，不是为「单轮答得漂亮」优化的。而思考链正是这条路线的代价。

第一轮测试时我给了 420 token 的输出预算——对一道三句话的问答题绰绰有余。结果它在这道题上正文输出零个字符，420 个 token 一个不剩全花完了。

把 llama.cpp 返回的完整结构拆开才看明白：token 全进了 reasoning_content 字段，整整 1222 个字符的思考过程，然后预算用尽，正文一个字没写。换成 `Reasoning strength: low` 再跑，同样的题，思考降到 953 字符，正文出来了 154 字符。

这就是为什么本地跑 agent 时经常出现「它不会调工具」的错觉。工具调用要求模型吐出一段 JSON，而思考链会把 JSON 挤出预算之外。表现是功能缺失，根因是预算分配。这类故障最难查，因为日志里什么错都没有。

上面这些结论我花了四轮测试才摸清。而一个普通用户下载完点「启动」，不该需要知道 reasoning_content 是什么。本地部署这件事的门槛从来不在模型本身，而在这些没人写进文档的参数细节。这正是我做「方寸智匣」这个自制软件的原因，当前版本 0.3.89，免费下载。

它给不同 GGUF 模型配的上下文窗口是不一样的：Muse 给 81,920，其余给 32,768；机器内存低于 48 GB 时压到 24,576，低于 24 GB 压到 12,288。而且刻意只把总窗口的约七成留给聊天历史，剩下的留给系统提示、附件、工具结果和输出。

为什么不按标称窗口拉满？因为本地的统一内存是共享的。KV 缓存、视觉投影、工具进程抢的是同一块。塞满标称窗口的直接后果不是慢，是第二轮请求时整个服务退出。这跟云端「窗口越大越好」的直觉正好相反。

模型下载这件事在国内单独是个坑。它把三个源摆出来——魔搭、HF 国内镜像、HuggingFace 官方——点一下测速并自动选最快的那个。十八 GB 的文件，源选错和选对之间是几十分钟的差别。

运行环境也是一键装好的：llama.cpp 约 11 MB，语言/语音/视频的基础组件约 1.7 GB，图像组件约 0.8 GB，全部装在应用自己的目录里，不碰系统 Python。换机器时导出一个迁移包，新机导入后会自动恢复下载清单。

参数和跑分说到底是间接证据。直接证据是这个：给它一句「搜索最新三条 AI 新闻并制作一个 PPT」，然后看它自己走完。

执行记录是逐步写出来的。先是产物约束——把「做一个 PPT」解析成只允许生成 PPTX；接着联网检索，两组互补查询去重后拿到十二条结果；然后来源核验，批量读取其中四个来源页；最后才轮到内容规划，由本机的 Qwen3.8 输出结构化 JSON。

底部那行状态值得看一眼：温度 0.7、上下文最近 48 条约 24K token、输出上限 6144、思考自动。这些不是默认值堆出来的，是按机器内存和模型类型算出来的——前面说的那些坑，都在这一行里被提前处理掉了。

还有一句话在左下角：会话仅保存在这台电脑，不会上传。这句话之所以成立，是因为从检索到生成没有一步离开过本机。

先说一个容易被忽略的参照。Meta 官方给出的速度是 Apple M5 Max 基线 26.6 tok/s，开启 DFlash 推测解码后 50.2 tok/s，提升 1.8 倍。

我在 M5 Pro 上、用 llama.cpp 且未启用那个草稿模型，测到 16.7 tok/s——量级是对得上的。说明差距来自配置，不是它本身慢。

当年 Intel 把 Pentium 4 的主频推到 3.8GHz，后来 Core 架构用更低的主频跑赢了它，靠的是每个周期做更多事。同一个误判换了单位：当年是 MHz，今天是 tok/s。区别在于主频好歹是硬件确定值，而 tok/s 还受采样参数和思考开关影响，更容易失真。

还有一条不在跑分表里：两个模型都是 4-bit 量化。Meta 公布的量化损失表显示，K-Quant-Dynamic 档的精度下降是 0.2%，17GB 档是 1.0%。为了塞进 24 GB 机器多付的那 0.8 个百分点，是笔明账。