Meta发布Muse Glimmer，这是一款约30B参数的多模态Agent模型，支持128K级上下文，可在24GB显存设备上运行。该模型采用Apache 2.0许可证开放，通过GQA减少KV Cache占用，结合Local与Global Attention混合架构降低长上下文计算成本，并提供两套量化版本适配不同显存设备。视觉模块配备独立ViT Perception Encoder处理截图和屏幕信息，训练阶段引入On Policy Distillation覆盖长任务偏离状态。DFlash推理加速组件采用Block Diffusion并行预测Token，在RTX 5090上实现约3倍解码速度提升。模型在MCP Atlas、DeepSearch QA等Agent Benchmark表现优异，但在OSWorld Verified等纯GUI场景中仍有提升空间。
文章作者、来源：雷峰网
昨天，Meta发布了Muse Glimmer。这是一款约30B参数的多模态Agent模型，支持128K级上下文，可以调用工具、执行代码，也能处理图片和屏幕信息。
这个模型采用Apache 2.0许可证开放，同时还有两套4bit量化版本、独立视觉编码器和DFlash推理加速组件，并提供llama.cpp、MLX、ExecuTorch等本地部署方式。
虽然30B的参数规模和128K的上下文在今天看来并不稀少，但问题在于，Meta想让它干的不是普通聊天，而在于建立一套完整的本地Agent运行范式。
Muse Glimmer面向的长期运行的本地Agent，会面临着苛刻的工程约束：它必须在有限的24GB显存里，一边处理不断产生的屏幕截图，一边维持长达几十步的任务逻辑。一次任务跑上几十步以后，前面的工具结果、代码日志、页面状态和推理过程会不断留在上下文里。
这时候，很多在聊天场景里不明显的问题会迅速放大。128K上下文怎么塞进有限显存，截图越来越多以后怎么管理历史状态，工具调用失败后模型怎么接着往下走，大量Reasoning Token又把Decode拖慢到什么程度。
Muse Glimmer的技术设计，基本就是围着这些问题展开的。它没有靠某一个特别显眼的新架构解决所有事情，而是在Attention、KV Cache、训练方式、量化和Decode上进行了激进的取舍。
如果说以前的本地模型是“能跑起来”，Muse Glimmer的目标是“能像云端一样好用且连续工作”。
把这些部分连起来看，比单看30B或128K更容易理解Meta为什么会把它做成现在这个样子。
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上会更加明显。
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的训练部分。
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。
一前一后的两个问题
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。
如果一个Agent Task累计生成10000个Token，只看Decode，前者大约需要134秒，后者约43秒。真实任务还会包含Prefill、工具执行和网络等待，但对于高Reasoning Strength的Agent，这种差距已经会明显影响完整任务体验。
高Reasoning Strength会增加生成Token，DFlash负责缩短这部分时间。长Context会增加KV Cache，GQA和Local Attention负责压低内存。量化则继续把模型权重控制在消费级显卡能够承受的范围内。
除此之外，Muse Glimmer在MCP Atlas、DeepSearch QA、Gaia2等Agent Benchmark上表现不错。这些任务都需要较长的执行链。
MCP Atlas要模型在多个MCP Server之间选择和调用工具。DeepSearch QA需要不断搜索、打开页面、查找信息，再根据新结果继续执行。Gaia2则模拟邮件、日历、联系人等有状态应用，环境本身还会在任务过程中发生变化。
这些任务和Muse Glimmer的训练方式比较吻合。但到了OSWorld Verified、TerminalBench和SWE Bench Verified，它并没有保持同样优势。例如OSWorld Verified上Muse Glimmer得分65.9，Qwen3.6 27B是75.6。TerminalBench 2.1上Muse Glimmer是51.7，对方达到60.7。
它的能力分布因此比较清楚。Research Agent、工具协同和长流程状态任务更强，纯GUI、终端和部分Coding Agent场景还有明显提升空间。这些分数也不能完全按照传统模型榜单理解。
Agent Benchmark的结果还会受到System Prompt、Tool Definition、Scaffold、最大执行步数、Sampling参数甚至Judge Model的影响。Meta自己也说明，第三方模型使用的Agent Tools和System Prompt不一定针对它们做过最佳优化。
所以到了Agent阶段，单独比较Checkpoint已经越来越难说明完整情况。安全也是类似的问题。
本地运行确实可以减少文件、截图和私人Context频繁发送到云端，但这解决的是数据路径。Prompt Injection、错误Tool Call、权限越界和不可逆操作仍然存在。Meta也单独评估了Agentic Risk、Privacy和Prompt Injection，并建议真实部署继续增加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本地模型的终局，不在于单纯的规模，而在于系统级工程对各种硬约束的综合对冲。它已经把本地Agent里最难处理的显存、上下文、环境状态感知和推理速度这四项约束放进了同一套系统设计中。
Muse Glimmer虽然还不能全面取代云端旗舰模型，但已经为“人人都有私有Agent”的目标，铺好了一条可以工业级落地的路径。