深度拆解Muse Glimmer，24 GB显存跑30 B Agent，Meta到底做了什么？
128K 长上下文与 3.1 倍推理加速背后，Meta 正在重构本地 Agent 的底层逻辑。
作者丨 郑佳美
编辑丨 岑 峰
昨天，Meta 发布了 Muse Glimmer。这是一款约 30B 参数的多模态 Agent 模型，支持 128K 级上下文，可以调用工具、执行代码，也能处理图片和屏幕信息。
这个模型采用 Apache 2.0 许可证开放，同时还有两套 4 bit 量化版本、独立视觉编码器和 DFlash 推理加速组件，并提供 llama.cpp、MLX、ExecuTorch 等本地部署方式。
虽然 30B 的参数规模和 128K 的上下文在今天看来并不稀奇，但 问题在于，Meta 想让它干的不是普通聊天 ，而在于 建立一套完整的本地 Agent 运行范式 。
Muse Glimmer 面向的长期运行的本地 Agent ，会面临着苛刻的工程约束：它必须在有限的 24GB 显存里，一边处理不断产生的屏幕截图，一边维持长达几十步的任务逻辑。 一次任务跑上几十步以后，前面的工具结果、代码日志、页面状态和推理过程会不断留在上下文里。
这时候，很多在聊天场景里不明显的问题会迅速放大。128K 上下文怎么塞进有限 显存，截图越来越多以后怎么管理历史状态，工具调用失败后模型怎么接着往下走，大量 Reasoning Token 又会把 Decode 拖慢到什么程度。
Muse Glimme r 的技术设计，基本就是围着这些问题展开的。它没有靠某一个特别显眼的新架构解决所有事情，而是在 Attention、KV Cache、训练方式、量化和 Decode 上 进行了激进的 取舍。
如果说以前的本地模型是“能跑起来”，Muse Glimmer 的目标是“能像云端一样好用且连续工作”。
把这些部分连起来看，比单看 30B 或 128K 更容易理解 Meta 为什么会把它做成现在这个样子。
01
128K 上下文怎么压进 24GB 显存
Muse Glimmer 使用 52 层 Dense Transformer，Hidden Size 为 6656，有 32 个 Query Head，但只有 2 个 KV Head。
Attention 也不是每层都处理完整上下文，而是采用三个 Local Attention 接一个 Global Attention 的循环方式。
Local Attention 只处理附近 2048 个 Token，Global Attention 才负责更远距离的信息交换。
这两个设计其实在同时压长上下文的成本。模型生成新 Token 时，会缓存前面 Token 的 Key 和 Value，也就是 KV Cache。Context 越长，这部分占用越大。
Muse Glimmer 每层只有 2 个 KV Head，每个 Head Dimension 为 128。按照 BF16 粗略计算，一个 Token 在一层里的 KV 大约占 1024 Byte。雷峰网 (公众号：雷峰网)
如果 52 层全部保存完整 128K Context，KV Cache 大约需要 6.5 GiB。但 Muse Glimmer 实际有 39 个 Local 层和 13 个 Global 层。Local 层只需要维护约 2048 Token 的滑动窗口，只有 Global 层需要保存完整的长上下文。
按同样方式估算，KV Cache 可以下降到约 1.7 GiB 的量级。这不是官方公布的运行时显存，只是根据公开架构参数做的理论估算，但已经能说明这套结构为什么会这样设计。
如果它不用 2 个 KV Head，而是像传统 MHA 那样给 32 个 Head 都保存独立 KV，同样条件下，KV Cache 理论上还会扩大约 16 倍，直接来到 20 多 GiB。
单独 KV Cache 就已经超过一张 24GB 显卡。这里实际上用了两种办法。GQA 减少每个 Token 需要保存多少 KV，Local Attention 则减少需要长期保存完整 KV 的层数。雷峰网
做完这一步以后，权重量化才有意义。Muse Glimmer 的 K Quant 17GB 权重大约 16.8GB，视觉模块约 1.4GB，DFlash 约 1.6GB，几部分加起来已经接近 20GB。这个版本面向 24GB 显存设备，另一套约 20GB 的 Dynamic K Quant 则面向 32GB 设备。
两套量化也不只是文件大小不同。Meta 给出的 15 项 Benchmark 平均精度损失里，Dynamic K Quant 约为 0.2%，K Quant 17GB 约为 1.0%。
也就是说，24GB 版本进一步压低显存，占用更小，但需要接受稍微明显一点的能力损失。32GB 版本则尽量保留原模型表现。
Muse Glimmer 的 128K Context 就是在这种组合下成立的。Attention 先降低计算量，GQA 再降低 KV Cache，最后通过量化压低模型权重。
这种方案也有代价。39 个 Local 层只能直接访问附近 2048 个 Token，远距离信息需要经过 Global 层传播。因此，能够输入 128K 和能够稳定利用整个 128K 仍然不是一回事。
Meta 的 Beam128K 结果说明这种 Local 和 Global 混合结构仍然具备不错的长距离信息利用能力，但它解决的是 Long Context，并不是长期 Memory。哪些信息应该保存，哪些已经过期，什么时候更新状态，仍然需要 Agent Runtime 处理。
这个问题到了视觉 Agent 上会更加明显。
02
128K 也不是无限空间
Muse Glimmer 另外带有一个约 1.8B 参数的 ViT G 14 Perception Encoder，用来处理截图、网页、图表和文档。一张图片最多可以转换成 4096 个 Visual Token。
它目前是文本和图片输入、文本输出，并不是把所有模态都放进同一个生成模型。
放在 Agent 工作流里，这种视觉能力主要负责读取环境状态。Computer Use Agent 先看到当前屏幕，判断页面、按钮和文字的位置，然后执行一次操作。页面变化以后，它再读取新的截图，继续决定下一步。
于是视觉输入会不断进入 Context。如果几十步任务里的所有截图都完整保留，即使有 128K，上下文也很快会被 Visual Token 占满。旧截图还可能和当前状态冲突。页面已经变化了，但之前的按钮和窗口仍然留在 Context 中，模型需要额外判断哪个才是最新状态。
Meta 在 OSWorld Verified 的评测里也没有无限保留 Screenshot History，而是只留下最近一部分截图。这说明 Perception Encoder 和 Context Management 是两个不同的问题。
前者负责把当前屏幕转换成模型能理解的信息，后者要决定哪些历史状态还有价值，哪些应该删除。因此 128K 更像是给 Agent 提供了更大的工作空间，而不是取消状态管理。
而当 Agent 不断和环境交互以后，问题也开始从模型看到了什么，转向模型刚才做了什么。
这就进入 Muse Glimmer 的训练部分。
03
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 的输出会直接改变下一步输入。
假设 Teacher 的正确轨迹是 A 到 B，再到 C，最后到 D。如果 Student 永远只学习 Teacher 的数据，它会反复看到 A 到 B、B 到 C。但真正运行时，Student 可能第一步就走到了另一个 B 状态。
从这一刻开始，环境已经变了，训练集里的 B 到 C 并不能直接告诉它现在应该怎么处理。On Policy Distillation 就是在这里发挥作用。Student 先自己 Rollout，进入它真实会产生的状态，然后再在这些状态上接受更强模型的监督。
训练数据里因此不只有 Teacher 的理想路线，也开始覆盖 Student 自己会制造出来的错误状态。这和 Muse Glimmer 强调的 Failure Recovery 是连着的。
参数填错以后，模型如果能读懂报错，再修改一次 Tool Call，任务仍然可以继续。网页走错以后，只要能识别当前状态不对，也可以回退或者换路径。真正麻烦的是模型没有意识到错误，而是继续基于错误状态执行，让偏差一路积累。
所以 Agent 的能力不能只看某一次 Tool Call 是否正确，还要看整个任务最终能不能完成，以及中间出错以后能不能恢复。这也解释了 Muse Glimmer 为什么在一些长流程 Agent Benchmark 上表现更好。
不过任务能够完成，并不代表本地运行已经没有问题。如果一次复杂任务要生成大量 Reasoning Token，新的瓶颈很快就会变成 Decode。
04
一前一后的两个问题
Muse Glimmer 支持 low、medium、high、xhigh 四档 Reasoning Strength。这个设置可以理解成运行时推理预算。
更高的档位通常会让模型生成更多 Reasoning Token，在复杂 Coding 和 Agent 任务上可能得到更高成功率，但代价也很直接。Context 增长更快，Decode 时间也更长。
Meta 在公开 Benchmark 中使用的是 high Reasoning Strength。这就引出了 DFlash。
Transformer 的 Decode 是自回归的。第 2 个 Token 必须等第 1 个 Token，第 3 个又依赖第 2 个。对于几百 Token 的回答还可以接受，但 Agent 一次任务可能累计产生几千甚至上万个 Token。
Speculative Decoding 的做法，是增加一个更小的 Drafter。Drafter 先预测未来的一段 Token，再让主模型一次性验证。如果有多个候选可以连续接受，就能减少 30B 主模型执行 Decode Step 的次数。
传统方案的问题在于，Drafter 自己通常也是自回归模型。如果它要 Draft 16 个 Token，仍然需要一个一个生成。
DFlash 把这一段换成了 Block Diffusion。
Muse Glimmer 的 DFlash Block Size 是 16，可以并行预测一组候选 Token。但 Drafter 只快还不够。如果猜得不准，主模型大量拒绝候选，前面的速度优势很快就会消失。
因此 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，后面的逐渐降低。它优化的是尽可能长的可接受前缀，而不是简单追求 16 个位置的平均准确率。Meta 给出的 K Quant 17GB 数据中，RTX 5090 上 Decode Speed 从约 74.9 Token/s 提升到 233.4 Token/s。