作者丨郑佳美
编辑丨岑峰
昨日，Meta 正式发布 Muse Glimmer。这是一款参数量约 30B 的多模态 Agent 模型，支持 128K 级上下文，具备工具调用、代码执行及图像屏幕信息处理能力。
该模型基于 Apache 2.0 许可证开源，提供两套 4 bit 量化版本、独立视觉编码器及 DFlash 推理加速组件，并支持 llama.cpp、MLX、ExecuTorch 等多种本地部署方案。
尽管 30B 参数规模与 128K 上下文在当前技术背景下并非孤例，但 Meta 的核心意图在于建立一套完整的本地 Agent 运行范式，而非仅服务于普通聊天场景。
面向长期运行的本地 Agent，Muse Glimmer 需应对严苛的工程约束：在有限的 24GB 显存内，既要处理持续生成的屏幕截图，又要维持长达数十步的任务逻辑。随着任务推进，工具结果、代码日志、页面状态及推理过程将不断累积至上下文中。
此时，聊天场景中不显著的问题将被放大：如何将 128K 上下文塞入有限显存？如何管理激增的截图历史？工具调用失败后如何延续任务？大量 Reasoning Token 又将如何影响解码速度？
Muse Glimmer 的技术设计正是围绕上述痛点展开。它未依赖单一新架构，而是在 Attention 机制、KV Cache 管理、训练策略、量化方案及解码加速上进行了激进的取舍。
若说以往的本地模型目标是“能跑起来”，Muse Glimmer 则致力于实现“像云端一样好用且能连续工作”。
128K 上下文如何压进 24GB 显存
Muse Glimmer 采用 52 层 Dense Transformer 架构，Hidden Size 为 6656，配置 32 个 Query Head 但仅保留 2 个 KV Head。
其 Attention 机制并非每层都处理完整上下文，而是采用"3 层 Local Attention + 1 层 Global Attention"的循环模式。Local Attention 仅处理附近 2048 个 Token，Global Attention 负责远距离信息交换。
这两项设计旨在同步降低长上下文的成本。模型生成新 Token 时需缓存前序 Token 的 Key 和 Value（即 KV Cache），上下文越长，占用越大。
Muse Glimmer 每层仅 2 个 KV Head，每个 Head Dimension 为 128。按 BF16 粗略估算，单 Token 单层 KV 约占 1024 Byte。若 52 层全量保存 128K Context，KV Cache 需约 6.5 GiB。但实际上，模型包含 39 个 Local 层和 13 个 Global 层。Local 层仅需维护约 2048 Token 的滑动窗口，仅 Global 层需保存完整长上下文。
据此估算，KV Cache 可降至约 1.7 GiB 量级。虽非官方运行时数据，但足以解释架构设计的合理性。若采用传统 MHA 为 32 个 Head 均保存独立 KV，同等条件下 KV Cache 将扩大约 16 倍，超过 20 GiB，单此项便超出 24GB 显卡承载极限。
因此，方案结合了 GQA（减少单 Token 需保存的 KV 量）与 Local Attention（减少需长期保存完整 KV 的层数）。在此基础上，权重量化才具备实际意义。
Muse Glimmer 的 K Quant 17GB 版本中，权重大约 16.8GB，视觉模块约 1.4GB，DFlash 约 1.6GB，总计接近 20GB，面向 24GB 显存设备；另一套 Dynamic K Quant 版本约 20GB，面向 32GB 设备。
两套量化版本不仅文件大小不同，精度表现亦有差异。Meta 数据显示，在 15 项 Benchmark 平均精度损失中，Dynamic K Quant 约为 0.2%，而 K Quant 17GB 约为 1.0%。这意味着 24GB 版本以轻微能力损失换取了更低的显存占用，32GB 版本则尽量保留原模型表现。
综上，Muse Glimmer 通过 Attention 降低计算量、GQA 压缩 KV Cache、量化压低权重，共同实现了 128K Context 的本地运行。当然，39 个 Local 层仅能直接访问附近 2048 Token，远距离信息需经 Global 层传播，因此“能输入 128K"与“能稳定利用整个 128K"仍有区别。
Meta 的 Beam128K 结果表明，这种混合结构具备不错的长距离信息利用能力，但其解决的是 Long Context 而非长期 Memory。信息的保存、过期判断及状态更新，仍需依赖 Agent Runtime 处理，这一问题在视觉 Agent 场景中尤为突出。
128K 并非无限空间
Muse Glimmer 内置约 1.8B 参数的 ViT G 14 Perception Encoder，用于处理截图、网页、图表及文档，单张图片最多可转换为 4096 个 Visual Token。
目前该模型采用文本和图片输入、文本输出模式，并未将所有模态融入同一生成模型。在 Agent 工作流中，视觉能力主要负责读取环境状态：Computer Use Agent 先观察当前屏幕，定位页面元素后执行操作；页面变化后再次读取截图以决定下一步。
由此，视觉输入会不断涌入 Context。若几十步任务中的所有截图均完整保留，即便拥有 128K 上下文，也很快会被 Visual Token 占满。此外，旧截图可能与当前状态冲突，模型需额外判断最新状态。
Meta 在 OSWorld Verified 评测中并未无限保留 Screenshot History，仅留存最近部分截图。这说明 Perception Encoder 与 Context Management 是两个独立问题：前者负责将屏幕转换为模型可理解的信息，后者则需决策历史状态的存续价值。因此，128K 更像是为 Agent 提供了更大的工作空间，而非取消状态管理。
随着 Agent 与环境交互的深入，核心问题从“模型看到了什么”转向“模型刚才做了什么”，这引出了 Muse Glimmer 的训练策略。
Agent 走偏以后如何继续
Muse Glimmer 源自更大的 Muse Spark 模型蒸馏。Meta 将训练分为 Pre Training、Mid Training 和 Post Training 三个阶段：Pre Training 使用 Logit Distillation；Mid Training 增加长上下文、Reasoning Trace 及 Agent 数据；Post Training 加入 SFT、On Policy Distillation 和 RL。
Logit Distillation 与传统蒸馏有所不同：Teacher 预测下一 Token 时会给出整个 Vocabulary 的概率分布，Student 学到的不仅是最终选中的 Token，还包括 Teacher 对其他候选项的相对判断。这对 Agent 至关重要，因为许多场景不存在唯一动作，概率分布隐含了 Teacher 对不同行动的偏好。
进入 Mid Training 阶段，训练重心从单次回答转向完整任务轨迹。工具执行会改变环境状态（如搜索结果更新、代码报错、GUI 页面变化），Agent 的输出直接影响下一步输入。
若 Student 仅学习 Teacher 的理想轨迹（A→B→C→D），一旦运行时第一步偏离至其他 B 状态，后续路径将无法直接复用。On Policy Distillation 在此发挥作用：Student 先自行 Rollout 进入真实产生的状态，再在这些状态下接受强模型监督。
因此，训练数据不仅包含理想路线，也覆盖了 Student 可能制造的错误状态，这与 Muse Glimmer 强调的 Failure Recovery 紧密相连。
参数填错后，若模型能读懂报错并修正 Tool Call，任务仍可继续；网页走错后，若能识别状态异常并回退或换路，亦可挽救。真正的风险在于模型未察觉错误，基于错误状态继续执行导致偏差累积。
因此，Agent 能力评估不能仅看单次 Tool Call 的正确性，更要关注任务最终完成度及出错后的恢复能力。这也解释了 Muse Glimmer 在部分长流程 Agent Benchmark 上的优异表现。
然而，任务可完成不代表本地运行无瓶颈。若复杂任务生成大量 Reasoning Token，新的瓶颈将迅速转移至 Decode 阶段。
一前一后的两个问题
Muse Glimmer 支持 low、medium、high、xhigh 四档 Reasoning Strength，可视作运行时推理预算。更高档位通常生成更多 Reasoning Token，虽能提升复杂任务成功率，但也导致 Context 增长更快、Decode 时间更长。
Meta 在公开 Benchmark 中使用 high Reasoning Strength，由此引出 DFlash 技术。
Transformer 的 Decode 是自回归过程，第 N 个 Token 依赖前 N-1 个。对于几百 Token 的回答尚可接受，但 Agent 任务累计可能产生上万 Token。
Speculative Decoding 通过引入更小的 Drafter 模型，先预测未来一段 Token，再由主模型一次性验证。若多个候选被连续接受，即可减少主模型执行 Decode Step 的次数。
传统方案中，Drafter 本身也是自回归模型，Draft 16 个 Token 仍需逐个生成。DFlash 则将此过程替换为 Block Diffusion。
Muse Glimmer 的 DFlash Block Size 为 16，可并行预测一组候选 Token。但仅快不够，若猜测不准导致主模型大量拒绝，速度优势将荡然无存。
为此，DFlash 直接读取 Muse Glimmer 第 1、13、25、37、49 层的 Hidden Feature，注入仅 5 层的 Drafter。这样 Drafter 无需重新理解完整 Context，而是直接利用 30B 主模型的内部表示。这些 Feature 持续注入 Drafter 各层的 Key 和 Value，避免随网络加深而衰减。
训练细节上，一个 16 Token Block 中，前序 Token 比后序更重要。若第 1 个 Token 错误，后续即使猜对，连续接受长度也会很短。因此 DFlash 对 Block 前部 Token 赋予更高 Loss Weight，优化目标是尽可能长的可接受前缀，而非平均准确率。
数据显示，在 RTX 5090 上，K Quant 17GB 版本的 Decode Speed 从约 74.9 Token/s 提升至 233.4 Token/s，加速达 3.1 倍。
若一次 Agent Task 累计生成 10000 个 Token，仅看 Decode 耗时，前者约需 134 秒，后者约 43 秒。真实任务虽包含 Prefill、工具执行及网络等待，但对于高 Reasoning Strength 的 Agent，这一差距已显著影响体验。
总结而言，高 Reasoning Strength 增加生成 Token，DFlash 缩短耗时；长 Context 增加 KV Cache，GQA 和 Local Attention 压低内存；量化则将模型权重控制在消费级显卡范围内。
在 MCP Atlas、DeepSearch QA、Gaia2 等需长执行链的 Agent Benchmark 上，Muse Glimmer 表现不俗。但在 OSWorld Verified、TerminalBench 和 SWE Bench Verified 上优势不明显，例如 OSWorld Verified 得分 65.9（Qwen3.6 27B 为 75.6），TerminalBench 2.1 得分 51.7（对方为 60.7）。
其能力分布清晰：在 Research Agent、工具协同及长流程状态任务上更强，而在纯 GUI、终端及部分 Coding Agent 场景仍有提升空间。需注意，Agent Benchmark 结果受 System Prompt、Tool Definition、Scaffold 等多因素影响，第三方模型未必经过最佳优化。
进入 Agent 阶段，单纯比较 Checkpoint 已难说明全貌，安全问题同样如此。本地运行虽减少了数据上云，但 Prompt Injection、错误 Tool Call、权限越界等风险依然存在。Meta 建议真实部署时增加 Guardrail 及 Human in the Loop 机制。
一条明确的能力路线
Muse Glimmer 的技术路径清晰连贯：将模型规模控制在 30B，利用 GQA 和 Local Attention 压低 128K Context 显存成本，通过量化适配 24GB/32GB 设备，借助 Perception Encoder 读取视觉环境，采用 On Policy Distillation 覆盖长任务偏离状态，设定 Reasoning Strength 控制推理预算，最后由 DFlash 解决大量 Reasoning Token 带来的 Decode 延迟。
Muse Glimmer 虽未证明本地 30B 模型可完全替代云端 Frontier Model，但它证明了30B 本地模型的终局不在于单纯规模，而在于系统级工程对各种硬约束的综合对冲。它成功将显存、上下文、环境状态感知和推理速度这四项最难处理的约束纳入同一套系统设计。
尽管尚不能全面取代云端旗舰，Muse Glimmer 已为“人人都有私有 Agent"的目标铺就了一条可工业级落地的路径。
参考链接：
https://developer.meta.com/ai/models/muse-glimmer/
https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model
