Muse-Glimmer 30B 与 Qwen3.8 27B——同为「本地 agent 模型」，一份是蒸馏，一份是原生

2026 年 8 月的两件事挨得很近：Meta Superintelligence Labs 在 8 月 10 日放出 Muse-Glimmer 30B，阿里 Qwen 团队在 8 月 14 日放出 Qwen3.8-27B。两者都是开源权重、都是 Apache 2.0、都是稠密架构、都带视觉、都以「本地跑 agent」为核心卖点，参数还差得不多。任何一张把它们并排放的功能表都会得到两列几乎一样的勾，而这样的表格没有任何用处。

真正的区别不在功能表里。它写在两边的发布说明里，各一句话。

Muse-Glimmer：

通过 logit 蒸馏，使用 Muse Spark 的输出训练——用一个远大于它自身的教师模型，把 agent 推理转移过来。

Qwen3.8：

在 Qwen3.5 的架构基础上构建，首次把 Qwen-Max 级别的模型带进开源发布。

一个是压缩出来的能力，一个是生长出来的能力。这个区别会一路传导到架构、上下文长度、速度优化和你该在什么时候选谁。

先说清楚数字该信到什么程度

这篇最核心的部分会用到基准分数，所以在看任何一张表之前，有一件事必须说在前面：

两边的模型卡都把对方列在了自己的基准表里，而且用的都是对己方有利的 harness。

Qwen 的模型卡里有一列叫「Muse Glimmer-30B」，SWE-bench Pro 上 Muse 得 51.2、Qwen 得 61.7，OSWorld-Verified 上 65.9 对 84.3。Meta 的模型卡里同样有一列「Qwen3.6-27B」（注意是上一代的 3.6，不是 3.8），SWE-bench Verified 上 Qwen3.6 得 77.2、Muse 得 76.0，OSWorld 上 75.6 对 65.9——Muse 输了。

这两份表各自挑了对自己最有利的对比对象与评测条件：Qwen 拿当前代对 Meta 的模型，Meta 拿对手上一代对当前代；harness、温度、上下文窗口也都各自声明。这不是谁造假——两边的脚注都写得很清楚——但意味着任何跨表比较，你比较的都不只是模型，还有评测配置。

所以本文处理分数的原则是：同一张表内的相对差距可以读，跨表读绝对值要打折；两边的自家数字（Meta 的 76.0、Qwen 的 61.7）都只作为「该厂商声称的水平」引用。真正能直接比的是那些两边都用公开 harness 跑出来的项目，比如 SWE-bench Pro 用 Claude Code harness 的那一组。

架构：一个纯注意力，一个混合

这是两个模型最底层的分歧，也是理解后面一切差异的钥匙。

Muse-Glimmer-30B 是教科书式的稠密因果 Transformer：52 层、hidden 6656、[Local, Local, Local, Global] 循环的注意力模式、2048 的滑动窗口、GQA 比例 16:1。视觉走一个独立的约 1.8B 参数 ViT-G/14 感知编码器，冻结在图里。整个 LM 29.6B。

Qwen3.8-27B 是混合架构：64 层里，每 4 层有 3 层用 Gated DeltaNet（线性注意力），只有 1 层用真正的 Gated Attention。视觉直接融进语言模型（HF 上标的是 qwen3_5 架构，AutoModelForMultimodalLM），没有独立编码器。另外它带一个 MTP 头（多 token 预测），训练时就为推测解码留了位置。

这两个选择的实际后果：

• 混合架构的长上下文成本更低。 DeltaNet 的线性注意力让 262K 的上下文在推理时不用为每个 token 付二次方代价。Qwen 原生支持 262,144 上下文，用 YaRN 可扩展到 1M；Muse-Glimmer 标的是 131,072+，没有官方扩展路径。
• 纯注意力的架构更「标准」。 任何推理框架都认识它，不需要特殊适配。Muse-Glimmer 在 llama.cpp、MLX、ExecuTorch 上的支持是发布时就承诺的；Qwen3.8 的混合架构需要框架支持 DeltaNet 路径，vLLM / SGLang / TokenSpeed 都列了 recipe，但生态覆盖还在铺开。
• MTP 头与 DFlash drafter 是同一件事的两种做法。 Qwen 把推测解码能力训进主模型，社区已经有人靠一个 llama.cpp flag 解锁 +33–39% 的解码速度；Meta 则单独发了一个 5 层的 DFlash drafter，一次前向预测 16 个 token 的整块，官方实测 RTX 5090 上 3.1 倍、M5 Max 上 1.8 倍。前者是「模型自带」，后者是「模型附带」，最终效果取决于你的推理栈认哪一个。

上下文与思考控制

	Muse-Glimmer 30B	Qwen3.8 27B
上下文	131,072+	262,144 原生，YaRN 扩至 1,000,000
视觉	独立 ViT-G/14 编码器（约 1.8B，冻结）	融合进 LM（原生视觉-语言，含视频）
思考开关	系统提示里写 Reasoning strength: low / medium / high / xhigh	API 参数 reasoning_effort：xhigh（默认）/ medium / low
多轮推理保留	—	preserve_thinking，默认开，跨轮保留历史思考块
知识截止	2026-01-04	未标注
语言	100+ 语言训练	201 语言与方言（Qwen3.5 系声明，3.8 延续）

preserve_thinking 是 Qwen 这边值得单独说的一条。在多轮 agent 任务里，它让模型看到自己之前几轮的推理过程，官方文档同时给了一句冷静的提醒：低 reasoning effort 并不总是降低总耗时——单轮响应更快，但分析不足会导致更多失败与重试，总延迟和 token 消耗反而上升。这是把旋钮做出来了之后才写得出的文档，两边在这个维度的成熟度不在一个层面上：Meta 的 Reasoning strength 是写在系统提示里的约定，Qwen 的是推理框架层面的 API 参数。

基准：同一张表里读差距

下面是 Qwen 模型卡里的官方表（2026-08 发布），Muse-Glimmer 那一列由 Qwen 团队评测：

基准（harness 见脚注）	Qwen3.8-27B	Muse-Glimmer-30B
Terminal Bench 2.1（Terminus）	73.0	51.7
SWE-bench Pro（Claude Code harness）	61.7	51.2
IFBench	79.5	77.0
GPQA Diamond	89.2	83.5
HLE	30.8	22.0
OSWorld-Verified	84.3	65.9
OmniDocBench 1.5	91.1	75.8

同一张表里的差距是清晰的：在 Qwen 团队搭的评测条件下，Qwen3.8-27B 在每个可比项目上都领先，差距最大的在 agentic 编码与计算机操作（Terminal Bench 差 21.3 分、OSWorld 差 18.4 分）。

但要把这个读法反过来也成立一遍：Meta 的模型卡里，Muse-Glimmer 对 Qwen3.6-27B（上一代）的 SWE-bench Verified 是 76.0 对 77.2，OSWorld 是 65.9 对 75.6。 也就是说，在 Meta 自己选的对比里，Muse 与上一代 Qwen 大体相当，而 Qwen 自己说 3.8 相对 3.6 是「substantial gains」。三代之间到底谁压谁，目前没有任何一方给出过同条件下的 3.8 对 Glimmer 的完整表——这正是前文说的「跨表读绝对值要打折」的具体落点。

有一行值得单独记下来：Meta 表里 Muse-Glimmer 在 SWE-bench Pro 上是 51.2，Qwen 表里也是 51.2——同一个数字出现在两家表里，说明这一项是用了同一套公开 harness（Claude Code），是目前两边唯一能直接对齐的编码数字。在这个数字上，Muse 落后 Qwen3.8 10.5 分，也略低于 Qwen3.6 的 53.5。

本地部署：两家都在卖 24–32GB，卖法不同

这是这两个模型真正面对同一群买家的地方。

Muse-Glimmer 的官方口径：约 4-bit 量化后 LM 小于 20GB，加上 KV cache、感知编码器与 DFlash drafter，落在 24GB 或 32GB 的内存包络内。官方给出三档量化与实测退化：全精度（64GB VRAM）、K-Quant-Dynamic（32GB，退化 0.2%）、K-Quant-17GB（24GB，退化 1.0%）——退化是 15 个常见基准的准确率均值。速度方面，K-Quant-17GB 加量化 drafter 的实测：RTX 5090 从 74.9 tok/s 提到 233.4（3.1 倍），M4 Max 从 23.7 提到 37.8（1.5 倍），M5 Max 从 26.6 提到 50.2（1.8 倍）。

Qwen3.8 的官方口径：没有给量化档位表，也没有给目标硬件包络。模型卡只说「紧凑的、部署友好的稠密模型」，部署建议全部指向 SGLang / vLLM / TokenSpeed 的 recipe，量化留给社区——HF 上已经有 1,035 个量化版本。官方采样参数分 thinking 与 instruct 两套，并对 agent 任务给出了明确的输出长度建议（1M 上下文内：推理内容最大 262,144，最终回答最大 131,072）。

把两家的口径放在一起看，差异不是「谁更好」，而是「谁把最后一公里做完了」：

• Meta 交付的是一个完整配方：哪个量化档位、多大内存、多快的速度、退化多少，全部是官方数字。你拿到的是「照着做就能跑」，代价是配方之外的组合（比如 M3 Max、Linux 上的 ROCm）要自己补。
• Qwen 交付的是一个更通用的模型：架构更现代（混合注意力 + MTP），上下文更长，生态更宽（201 语言、官方 Qoder / Qwen Code / Qwen Studio 产品线），但「在我的机器上到底怎么跑最顺」这个问题，官方答案比 Meta 薄。

HF 的下载量把这种差异量化了：截至 2026-09-10，Qwen3.8-27B 月下载 671 万，Muse-Glimmer-30B 月下载 66.5 万。发布只差 4 天，下载量差 10 倍——这是 Qwen 既有生态（Qwen3.5 / 3.6 的社区惯性）在起作用，也是「更通用」与「更配齐」两种交付方式在真实市场里的投票。

怎么选

选 Muse-Glimmer 30B，如果你的核心约束是「在一台特定的 24/32GB 机器上，今天就要跑起来，而且速度要有保证」——Meta 给的量化档位、内存包络与 tok/s 数字是目前这个品类里最完整的官方部署契约；如果你的 agent 需要处理大量图像且不需要视频，独立的 ViT 编码器路径在成熟度上有优势；或者你需要一个知识截止明确（2026-01-04）、行为可预期的本地裁判模型（Meta 把 LLM-as-a-judge 列为官方用途）。

选 Qwen3.8 27B，如果你的任务需要长上下文（262K 原生、可扩 1M）；如果视觉任务里包含视频；如果你已经在一个更大的 Qwen 生态里（Qoder、Qwen Code、Qwen Studio、ModelScope）；如果你的团队需要 201 种语言；或者你愿意用一点部署上的摸索时间，换一个架构更新、能力上限更高的模型。

两个都不选，如果「本地」这个约束其实不成立——你有一张 24GB 以上的卡又不在乎数据出不出机器，那直接上 API 模型，这两个 30B 量级的本地模型都打不过 2026 年闭源的旗舰。这一页的对比是真实的，但只有在「离线、数据不出本机、单卡 24–32GB」是硬约束时，这场对决才值得打。

这篇是怎么写出来的

本文关于架构、上下文、思考控制与部署口径的每一条陈述，都取自两家自己的发布材料：Meta 的 research 博客（2026-08-10）与 Hugging Face 模型卡（meta-models/Muse-Glimmer-30B），Qwen 的 GitHub 仓库 README 与 Hugging Face 模型卡（Qwen/Qwen3.8-27B）。基准数字全部引自两家各自的模型卡，跨表比较的局限已在前文单独说明，没有在表格里做任何换算或插值。

下载量来自 2026-09-10 的 Hugging Face API，之后会漂移。

有一处容易被漏掉的事实值得记下来：Qwen 模型卡里的对比列写的是「Muse Glimmer-30B」，Meta 模型卡里的对比列写的是「Qwen3.6-27B」——两家都没有在发布时给出与对方当前代的完整同条件基准表。在任一方补出这样的表之前，本文「Qwen 全面领先」与「Muse 与上一代 Qwen 大体相当」这两个结论都只成立在各自的评测条件下。

作者对两个模型都还没有做长期实际试用。本文凡是给判断而非陈述事实的地方，依据的是发布材料里写明的设计决策与官方数字，并且已经标明。

两张图解是生成的，不是拍出来的。每张都从上述事实的结构化规格编译成自包含的可交互 HTML（Archify），静态图与它出自同一份规格——因此图里没有任何正文没有做出的声明。