Muse Spark 1.2刚发布，Meta又把模型权重交出来了：Muse-Glimmer-30B来了

几天前，Meta 才刚刚带着 Muse Spark 1.2 杀进 AI 编程赛道。

Meta 推出 Muse Code，一款由 Muse Spark 1.2 驱动的 AI 编程 Agent。它不只是补几行代码，而是瞄准长时间、复杂的软件工程任务，可以规划修改、编写和调试代码、验证结果，同时并行调用多个子 Agent。

但更值得关注的事情紧接着发生了。

Meta 又拿出了一款完全不同定位的新模型：Muse-Glimmer-30B。

这一次，Meta 没有只把模型藏在 API 后面，而是直接把模型权重放到了 Hugging Face。BF16 完整权重、4-bit 量化版本、视觉编码器乃至用于推测解码的 DFlash drafter 都对外提供，并采用 Apache 2.0 License。

如果把时间线拉长一点，这次发布就更有意思了。

从 Llama 时代长期押注开放权重，到 Muse Spark 转向强大的闭源前沿模型，再到今天重新推出可以下载、修改并本地运行的 Muse Glimmer，Meta 的 AI 路线正在出现一个非常明确的信号：

开放模型，又重新回到了牌桌中央。

Part.01 不是“小号 Muse Spark”，而是一款专门为 Agent 做的 30B 模型

Muse Glimmer 最容易被误解的一点，是把它看成 Muse Spark 的简单缩水版。

实际上 Meta 给它的定位非常明确：

一款可以运行在消费级设备上的 autonomous agentic model。

Muse Glimmer 约有 296 亿参数，采用 Dense Causal Transformer 架构，同时加入约 18 亿参数的 ViT-G/14 Perception Encoder，用来理解图像、截图、图表和文档。上下文长度达到 131,072+ tokens，支持文字和图片输入、文字输出，并接受超过 100 种语言的训练数据。

更关键的是，它并不是单纯为了“聊天效果”训练。

Meta 把很多过去需要由 Agent 框架完成的能力，进一步训练进了模型本身：

• 能够把一个复杂目标拆成多个步骤持续执行；
• 能在长任务里稳定调用不同工具和函数；
• 工具执行失败后，可以分析原因并重新尝试；
• 可以直接理解网页截图、图表和文档；
• 支持 OpenClaw、Hermes Agent 等 Agent scaffold；
• 可以调整 reasoning strength，在速度和推理深度之间取舍。

这意味着 Muse Glimmer 的重点不是“问它一道题能不能答对”，而是：

给它一个任务之后，它能不能自己把事情做完。

这也是 Meta 这两代 Muse 模型越来越明显的方向。

4 月发布的第一代 Muse Spark 已经强调工具调用、多 Agent orchestration 和原生多模态；7 月的 Muse Spark 1.1 又进一步增强 computer use、Coding 和 Agent 工作流；8 月的 Muse Spark 1.2 则直接和 Muse Code 结合，进入真实软件工程环境。

Muse Glimmer 延续了同一条路线，只不过它试图回答另一个问题：

这些 Agent 能力，能不能不依赖云端超大模型，而是直接跑在自己的电脑上？

Part.02 30B 模型塞进 24GB 显存，Meta这次花了不少力气

30B 参数并不算小。

如果直接按照 BF16 权重计算，普通个人电脑显然很难轻松部署。因此 Muse Glimmer 一个很重要的技术重点，就是本地运行优化。

Meta 为它提供了约 4-bit 的量化方案。

其中 K-Quant-17GB 可以把语言模型权重压缩至大约 17GB 级别，目标就是让整个系统能够放入 24GB 显存环境；另一个版本面向 32GB 环境。Meta 给出的测试结果显示，相比全精度版本，两种量化方案在 15 个常见 Benchmark 上的平均性能下降约为 1.0% 和 0.2%。

这就让 RTX 4090、RTX 5090 这类 24GB 消费级显卡成为了实际部署目标。

但 Meta 还解决了另外一个问题：速度。

传统大模型生成文字时基本按照 Token 一个一个向后生成，模型越大，速度压力越明显。

Muse Glimmer 因此附带了一个 DFlash drafter。

简单来说，可以把它理解成一个“先打草稿的小模型”。

它会一次预测一整个 Token Block，再让主模型批量验证。官方配置中，一个 Block 包含 16 个 Token，通过这种 speculative decoding 方式减少主模型逐 Token 推理的压力。

效果非常直接。

在 RTX 5090 上，官方测试的基础生成速度为74.9 token/s；加入 DFlash 后，平均达到233.4 token/s，约为原来的 3.1 倍。

Apple M4 Max 从23.7 token/s提升到37.8 token/s；M5 Max 则从 26.6 提升到50.2 token/s。

所以 Muse Glimmer 真正值得注意的不是“Meta 又发布了一个 30B 模型”，而是：

Meta 开始认真考虑如何让一个能够调用工具、看屏幕、写代码、执行长任务的 Agent 模型，真正落到个人电脑上。

Part.03 性能到底怎么样？Agent任务才是它真正的主场

从 Meta 公布的 Benchmark 来看，Muse Glimmer 并不是要在所有测试里全面碾压同尺寸模型。

它真正突出的部分，是 Agent 和工具使用。

• 在 MCP Atlas 上，Muse Glimmer 得分75.5，Gemma4-31B 为 54.2，Qwen3.6-27B 为 62.5。
• DeepSearch QA 上，Muse Glimmer 为74.6，Gemma4-31B 为 61.7，Qwen3.6-27B 为 71.1。
• SWE-Bench Pro 上，Muse Glimmer 达到51.2，超过 Gemma4-31B 的 36.9，也略高于 Qwen3.6-27B 的 50.2。
• 在 SciCode 上，它拿到 43.6，同样略高于另外两款对比模型。

多模态也没有被牺牲。

CharXiv Reasoning 达到78.8，ScreenSpot Pro 为75.4，MMMU Pro 为74。

而在 AIME 2026 中，Muse Glimmer 得分达到94.7。

当然，这张成绩单也不能只挑漂亮的数据来看。

比如 OSWorld-Verified 上，Muse Glimmer 的 65.9 仍明显低于 Qwen3.6-27B 的 75.6；TerminalBench 2.1 上，Muse Glimmer 的 51.7 也低于 Qwen 的 60.7；GPQA Diamond 上它也没有领先。

Muse Glimmer 并不是一个追求所有 Benchmark 第一的 30B 通用模型，而是一款明显向 Agent、Tool Use、Coding 和本地执行倾斜的模型。

这和它的产品定位是高度一致的。

Meta 的独立评测说明也显示，Muse Glimmer 的测试覆盖了 MCP 工具服务器、浏览器搜索、Docker 隔离环境、GUI Computer Use、SWE-Bench 和复杂文档理解等真实 Agent 场景，而不是只用传统问答题评价模型。

Part.04 有意思的是：Muse Spark 1.2 才刚刚发布

Muse Glimmer 的发布时间，让这件事显得尤其有意思。

今年 4 月，Meta 推出了 MSL 成立后的第一款重要模型 Muse Spark。

到了 7 月 9 日，Muse Spark 1.1 发布，并首次通过 Meta Model API 向开发者开放。和过去的 Llama 不同，这一次开发者主要通过 API 使用模型，而不是把完整权重下载回自己的机器。

8 月 5 日，Meta 又推出 Muse Code。

它背后的模型已经升级到 Muse Spark 1.2。

Muse Code 被设计成一个完整的软件工程 Agent，可以处理长时间编程任务、调用多个子 Agent、修改代码并验证结果；Muse Spark 1.2 和 Muse Code 甚至是在训练阶段就被针对彼此进行联合优化。

换句话说，当很多人还在讨论 Meta 会不会彻底离开 Llama 时代的开放权重路线时，Meta 一边做出了越来越强的闭源前沿模型，一边突然又发布了 Muse Glimmer。

而且这可能还只是开始。

Reuters 在 8 月 10 日的报道中提到，Meta 不仅发布了 Muse Glimmer，还计划进一步释放 Muse Spark 1.2 的模型权重。

如果这一计划最终落地，那么 Muse Glimmer 就不只是一个孤立的 30B 开放模型。

它更像是一个信号：

Meta 正在尝试重新建立“前沿闭源模型 + 可本地运行开放权重模型”的双线体系。

Part.05 从 Llama 到 Muse，Meta 为什么又重新强调“开放”？

这次变化很重要。

Meta 给 Muse Glimmer 使用 Apache 2.0，并直接释放 BF16、4-bit 量化权重、Perception Encoder 和 DFlash drafter，本质上已经让开发者获得了非常高的模型控制权。

它与云 API 最大的区别，也就在这里。

模型可以部署在自己的机器上，应用数据不必每次发送到云端；开发者能够针对具体硬件优化推理，可以把模型塞进已有 Agent 框架，也能够进一步微调和研究。

对于真正开始大量使用 Agent 的团队而言，这些因素正在变得越来越重要。

因为 Agent 与过去的聊天机器人不同。

它可能需要读取本地代码、操作文件、访问内部文档、调用数据库，甚至持续操作浏览器和桌面环境。一旦 Agent 开始接触这些高权限数据，“模型在哪里运行”就不仅是成本问题，也开始变成架构和安全问题。

而 Muse Glimmer 给出的答案非常直接：

让 Agent 留在本地。

Part.06 Muse Glimmer真正值得关注的，可能不是30B

如果只看参数，30B 已经不是什么令人惊讶的数字。

如果只看 Benchmark，Muse Glimmer 也没有在每一个项目里拿到第一。

但把它放进 2026 年 Meta 整条 Muse 产品线里看，意义就不一样了。

• Muse Spark 在冲击前沿智能和个人超级智能；
• Muse Spark 1.2 与 Muse Code 在进入复杂软件工程；
• Muse Image 和 Muse Video 在负责生成式媒体；
• 而 Muse Glimmer，则第一次非常明确地把 Agentic AI + Multimodal + Local Deployment 放到了一起。

30B 参数、131K+ Context、24GB 显存部署、图片理解、工具调用、失败重试、Coding Agent，再加上 Apache 2.0。

这些单独看都不是第一次出现。

真正值得关注的是，它们现在出现在了同一个可以下载到自己电脑里的 Meta 模型上。

去年大家讨论的还是：

“大模型能不能在本地运行？”

今年的问题正在快速变成：

“一个真正能替你做事的 Agent，能不能直接运行在本地？”

Muse Glimmer 给出的答案，已经越来越接近“可以”。

而如果 Meta 下一步真的兑现计划，将更强大的 Muse Spark 1.2 权重进一步开放，那么这场从“闭源前沿模型”重新回到“开放权重模型”的转向，可能才刚刚开始。

Part.07

OpenCSG社区：

opencsg.com/models/AIWi

Hugging Face社区：

huggingface.co/meta-mod

Part.08 OpenCSG vs 魔搭：如何选择？

模型部署和推理使用在魔搭、OpenCSG 等模型社区中均可实现，但OpenCSG/CSGHub 的核心在于，它不只是让模型“跑起来”，而是进一步支持企业把模型、数据集、代码和应用等 AI 资产放到本地、内网或离线环境中统一管理。它解决的不只是“模型怎么部署、怎么调用”的问题，更是“模型进入企业后如何被安全管理、版本沉淀、权限控制和持续运营”的问题。

对于企业来说，CSGHub 可以帮助构建自己的私有模型资产中心，降低对外部平台的依赖；对于个人开发者来说，也可以用更系统的方式管理模型、实验项目和 AI 应用流程。相比更偏向模型发现、体验和使用入口的魔搭，CSGHub 更适合那些希望把 AI 能力真正沉淀下来，并长期维护、持续迭代的用户。

关于OpenCSG

OpenCSG 是全球领先的开源大模型社区平台，致力于打造开放、协同、可持续生态，AgenticOps是人工智能领域的一种AI原生方法论，由OpenCSG（开放传神）提出。AgenticOps是Agentic AI的最佳落地实践也是方法论。核心产品CSGHub提供模型、数据集、代码与 AI 应用的 一站式托管、协作与共享服务，具备业界领先的模型资产管理能力，支持多角色协同和高效复用。