Meta 超级智能实验室公开了 Muse Glimmer 30B 的技术报告：这款从 Muse Spark 蒸馏而来的开放权重模型，能看图、调用工具、执行多步任务，目标是让个人电脑也能运行自己的 Agent。
Glimmer 的权重已在 8 月开放。这次报告展开了从预训练到后训练的蒸馏路线，也解释了架构和量化怎样配合，让学到的能力留在本地。
结果挺有意思。它在工具调用和多步任务的一组评测中超过了 Gemma4-31B、Qwen3.6-27B；量化后的最小权重约 17GB，配合推测解码，在 RTX 5090 上测得约 233 token/s。
先看它能做什么
Meta 把定位说得很清楚：面向消费级硬件上的 Agent 任务，重点是工具使用和多步规划。
论文拿 Glimmer 与同规模的 Gemma4-31B、Qwen3.6-27B 做了对比。Glimmer 使用 high 推理档，另外两款使用 thinking 模式。
在涉及 20 多种工具服务的 MCPAtlas 中，Glimmer 得到 75.5，另外两款分别为 54.2 和 62.5。搜索任务 DeepSearchQA 的 F1 为 74.6，也高于对照模型的 61.7 和 71.1。
更接近连续执行任务的 GAIA2 中，它得到 43.3，对照为 36.4 和 40.0。这里的任务会引入随时间出现的新事件，Agent 得根据变化继续行动。
论文表2局部：Agent、编码、工具使用及推理评测，保留三款模型的列头
但表里也没有一个包打天下的冠军。
桌面操作 OSWorld Verified 上，Qwen3.6-27B 为 75.6，Glimmer 为 65.9；TerminalBench 2.1 上，前者为 60.7，后者为 51.7。SWE-bench Verified 则是 77.2 对 76.0。
先划出 32GB，再选架构
本地 Agent 的内存账，比“模型有多少参数”多一项。
模型要读任务、调用工具，再把工具返回的网页、代码、截图接进上下文。任务越往后，KV cache 越大。权重刚好塞满显存，后续会话就没地方放了。
Glimmer 团队先设下一个约束：整套设计要能在 32GB 显存预算内可靠运行。
团队固定推理内存占用，比较了稠密模型与两种 MoE 配置，再按训练预算推算效果，最终选择 30B 稠密架构。
论文给出的结论是：在这组内存和训练预算约束下，稠密方案的训练计算效率比 MoE 对照高约 2–2.5 倍。图里绿色曲线对应稠密模型，在相同训练计算量附近取得更低的损失。
论文图1左侧：固定推理内存条件下，稠密与两种MoE方案的文本损失缩放曲线
MoE 每次只激活一部分专家，但没被激活的权重通常也得占用内存。
为控制会话缓存，Glimmer 采用 GQA，每层只保留 2 个 KV head；注意力层按“三层局部、一层全局”交替，局部窗口为 2048 token。
局部层控制缓存增长，全局层保留跨较长上下文的信息联系。团队还试过进一步压缩缓存的简化 MLA 变体，但在 RULER 等长上下文测试中不及标准 GQA，最终没有采用。
这款模型接收文本和图像，原生上下文达到 128K 以上。截图、图表、多轮工具结果，都在它要处理的输入范围内。
蒸馏不只发生在最后一步
Glimmer 的老师是 Muse Spark，但蒸馏贯穿了不同训练阶段。
预训练阶段，团队保存老师的 top-256 token 分布，用它训练学生。后面再接领域数据、Agent 轨迹与长上下文训练，把上下文从 32K 拉到 128K。
后训练包括监督微调、on-policy 蒸馏和强化学习。关键是学生先自己生成轨迹，老师再逐步给出细粒度反馈。
只模仿老师走通的轨迹，学生看到的往往是“每一步都走对以后，下一步该做什么”。真正运行时，它可能选错工具、误读返回值，或者沿着不太好的计划走了几步。
On-policy 蒸馏让老师沿着学生自己生成的轨迹提供反馈，帮助学生学会在偏离后继续调整。论文发现，加入这一步，再进入强化学习，效果持续好于从监督微调直接进入强化学习。
训练环境也不是零散的函数调用题。
Meta 构建了模拟的数字生活：邮件、日历、文档、聊天、代码仓库和命令行。一个环境里有虚构用户、10–14 位联系人，以及跨数周的往来记录。
这些内容有生成顺序。先有用户和联系人，邮件才能引用他们；日历参与者、文档和记忆再与前面的信息对应。任务建立在已有工具、联系人与环境状态上，还可以让时间继续推进，模拟跨数日的工作。
生成的轨迹也要过滤。虚构执行成功、缺乏依据的判断和错误工具调用，会被排除，或对其中的不良片段屏蔽训练损失。
17GB 权重之后，还有一笔速度账
Glimmer 的 BF16 权重约 55.7GB。要进入 24GB 或 32GB 设备，压缩空间得留得更实在一些：除了权重，还有 KV cache、视觉编码器和用于加速的小模型。
因此，团队给语言模型权重定下的目标是 20GB 以下，提供约 17GB 的 Q4KM 方案，以及约 19.65GB 的 EvoPress 方案。
EvoPress 没有把所有权重一律压成 4-bit。它会把较高精度留给更敏感的部分，在不同权重单元间分配 4、5、6-bit 精度。
论文图3左侧：不同量化方法的语言模型权重大小与验证损失变化，虚线为20GB目标
压完以后，Agent 能力还剩多少？论文又用 15 项下游任务做了复测。
BF16 的平均准确率为 75.7，EvoPress 为 75.6，约 17GB 的 Q4KM 为 74.8。对应的平均下降分别是 0.1 和 0.9 个百分点；平均回答长度也没有明显膨胀。
论文表3：量化版本在15项下游任务上的平均准确率及回答长度
推理加速用的是 DFlash。一个轻量的 5 层草稿模型，一次预测 16 个 token 的候选块，再由主模型并行验证，减少主模型逐个生成 token 的开销。
模型卡列出了约 17GB K-Quant 配置的实测数据：
这些是 batch size 为 1、贪心解码、多个提示取平均的生成速度。Mac 使用 ExecuTorch，RTX 使用 llama.cpp。
本地助手也会替你向外发消息
推理留在电脑里，工具调用依然可能把信息发出去。
替用户处理邮件时，模型可能需要分享部分背景才能完成任务；但同一段上下文里，也可能夹着与收件人无关的私人信息。把所有内容都发出去、或者一律拒绝分享，都不算一个好助手。
Glimmer 专门用模拟用户及任务轨迹训练这种取舍：完成任务需要的信息可以分享，无关的敏感内容应留下。间接提示注入、不可逆操作确认和工具权限边界，也进入了训练。
论文的 CIMemories 隐私违规指标中，Glimmer 为 26.4，低于 Qwen3.6-27B 的 53.4，但高于 Gemma4-31B 的 12.1。
权重已按 Apache 2.0 开放，量化版本和 DFlash 草稿模型也能取得。对于想做本地 Agent 的开发者，报告给出了可以继续试的硬件配置和训练路线。
参考链接
Muse Glimmer 30B 技术报告 v2：https://arxiv.org/abs/2610.24628v2 Meta 模型卡与权重：https://huggingface.co/meta-models/Muse-Glimmer-30B