Muse Spark 1.1以88.1%登顶MCP-Atlas榜,超越Claude Opus 5;Glimmer 30B为Apache 2.0开源模型,4-bit量化后可在24GB显存运行,但TerminalBench和OSWorld弱于Qwen3.6。两款模型均未公开tool-calling协议文档。
Muse Spark 1.1 在 Scale AI 的 MCP-Atlas 排行榜上以 88.1% 排名第一——领先于 Claude Opus 5(85.8%)和 Claude Fable 5(83.3%)。
Muse Glimmer 30B 采用 Apache 2.0 协议,支持本地运行——4-bit 量化下体积在 20GB 以内,可运行在 24GB 显存的机器上。
Glimmer 通过 logit 蒸馏从 Spark 蒸馏而来。师生关系,不是同一个模型的两种规格。
Meta 报告 Glimmer 在 MCP-Atlas 上得分 75.5 对比 62.5(Qwen3.6-27B)和 54.2(Gemma4-31B)——这是厂商数据,不是排行榜正式条目。
Glimmer 在终端和桌面控制上表现极差。Qwen 在 TerminalBench 2.1 以 60.7 战胜 51.7,在 OSWorld-Verified 以 75.6 战胜 65.9。
两个模型都没有公开文档化的 tool-calling wire format。通过 OpenRouter 访问时,两者都是 OpenAI 风格的 function caller。
Meta 在 2026 年 8 月间隔一周发布了两款模型,它们之间的关系才是真正的故事。Muse Spark 1.2 是闭源、仅 API 模式,支持百万 token 上下文。Muse Glimmer 30B 采用 Apache 2.0、开源权重、从 Spark 蒸馏而来——可运行在单张消费级 GPU 上。
如果你基于 MCP 构建,Student 模型是更有意思的发布。来说说为什么,以及营销在何处与数据不符。
大多数发布只给你 MMLU 和一个编程分数。这些都不能预测模型在调用 MCP server 时会不会把参数搞乱。
MCP-Atlas 不同。它是 Scale AI 的基准,专门为 Model Context Protocol 工具使用设计:36 个真实 MCP server 和 220 个工具上的 1,000 个任务,每个任务 3-6 次工具调用。模型需要从一个限定集合中发现正确的工具、用正确的参数调用它、处理错误、跨 server 协调、并综合出答案。
在 Scale 的公开排行榜上:
两个注意事项,都是关键性的。排行榜最近一次更新是 2026 年 4 月,所以排名条目是 Spark 1.1,不是 1.2。而 8 月发布的 Glimmer 根本没上榜。这说明 Muse 系列在 MCP 任务上表现强劲——但不是你今天实际调用的那个版本的验证分数。
Glimmer 的数字来自 Meta 自己的发布表格,当作厂商对比来看。条件很重要:Glimmer 开启 High Reasoning,竞品在 Thinking Mode。全都是尽力而为的配置,不是默认设置。
模式比"Glimmer 赢了"更尖锐。
Glimmer 的优势在于协议形状的 agentic 工作——发现工具、在长流程中正确调用 schema、执行故障恢复。在 MCP-Atlas 上领先 Qwen 13 分;在 τ²-Banking 上则是一场碾压。
但 Qwen3.6-27B 拿下了 SWE-Bench Verified、TerminalBench 2.1 和 OSWorld-Verified,最后两项差距很小但确实存在。客观解读:Glimmer 专精于通过协议调用工具,而不是驱动终端或桌面。强大的 MCP 结果不能迁移到 computer use。
Meta 也发布了安全结果。在 prompt-injection 基准 Siren AgentDojo 上,Glimmer 记录了 28.4% 的攻击成功率,效用得分 94.2。Gemma4-31B 表现更好是 25.6%;Qwen3.6-27B 更差是 40.3%。
越低越好,而且没有哪个数字让人安心。三个模型中最好的那个,大约四分之一的注入尝试也会成功。
如果你的 MCP server 返回的内容源头不在你控制范围内——搜索结果、文件内容、第三方 API 响应——这些内容会到达模型,而这些是它能引导模型的实证概率。模型选择能移动边界,但不能消除问题。真正起作用的控制在你这一侧。
一个稠密的 causal transformer——不是 MoE——约 296 亿参数,包含一个 18 亿参数的 ViT-G/14 感知编码器。52 层,hidden dim 6,656,SwiGLU 中间宽度 19,968。
如果你计划运行它,有两个选择值得注意:
GQA 配比 16:1——32 个 query heads 对 2 个 KV heads。很激进,但这正是保持 KV cache 足够小、能在消费级内存上运行长 agentic 会话的原因。
一个重复的 [Local, Local, Local, Global] 注意力模式,2,048 token 的滑动窗口。三个廉价的 local 层配一个 global 层。
默认上下文 131,072 tokens,可扩展到 262,144。采样默认值 temperature 1.0,top_p 0.95,top_k 64——从别家厂商沿用 temperature 0.2 的习惯是"它在我这里表现更差"的真实来源之一。
全精度需要 55GB+。量化到约 4-bit 降到 20GB 以内,在 24-32GB 显存 envelope 里为 KV cache 和感知编码器留出余量。Meta 报告"在 agentic 任务上从该压缩中获得的降解微乎其微到可以忽略"。
DFlash 推测解码随附:一个轻量级 drafter 提出 token block,主模型并行验证。输出质量由构造保证相同;实测加速在 RTX 5090 上 3.1x,M5 Max 上 1.8x,M4 Max 上 1.5x。
发布时支持的运行时:Ollama、LM Studio、llama.cpp、MLX、ExecuTorch、vLLM、SGLang。
Meta 描述了三个训练阶段——预训练阶段从 Spark 进行 logit 蒸馏,中训练阶段用推理轨迹做扩展上下文 agent 数据,然后 SFT 混合 on-policy 蒸馏和 RL。
其中埋藏了发布材料里最可证伪的说法:
"当工具调用失败或返回意外结果时,模型被训练成诊断错误并重试,而不是中止。"
这才是区分能放手让它运行和每次端点出点小问题就需要人工介入的模型的行为。一个测试就能验证:把模型指向一个故意返回错误的 server,看它是读取错误并调整参数,还是道歉并停止。
闭源权重、仅 API。1,048,576 token 上下文,约 131,072 输出。接受 text、images、video、audio 和 PDF。
对于 agent 构建者:结构化输出、并行 function calling、可配置推理 effort,以及明确的多 agent 支持,可担任主 planner 或并行 subagent。它依赖 planning、goal conditioning 和 context compaction 在长任务中保持方向。
定价每百万 token $1.25 / $4.25。注意成本结构:大多数模型,成本跟随模型做多少工作。而 1M 上下文的模型,成本跟随你选择发送多少上下文——200k token 的 prompt 在它写一个字之前就已经花了 $0.25。压缩是一项功能,原因在此。
Meta 没有为任何一个模型文档化 tool-calling wire format。模型卡和开发者页面声称可靠的工具使用和精确的 schema 调用,但没有指定序列化方式。参考运行时只是暴露了一个 OpenAI 兼容的表面。
所以:通过 provider 路由,两个模型都表现为 OpenAI 形状的 function callers,与每个非 Anthropic 模型走的是同一条路。你读到的任何关于 Muse 具体如何处理深度嵌套参数的说法,目前是未经测试的,而非有文档的。
这让你自己的 server 成为唯一权威。
Glimmer 当你想 self-host 一个模型、当工具调用必须留在你自己的硬件上、或者当你测试一个开源 30B 是否足够好来替代你工具上的 frontier 模型时。
Spark 1.2 当任务确实需要上下文或并行 function calling——全仓库工作、长调试会话、多 agent 编排。
蒸馏关系是心智模型:Glimmer 在一个你能在家运行的包中继承了 Spark 的 agentic 行为;Spark 保留了那些塞不进笔记本的规模、上下文和模态。
你可以在浏览器里运行两个 Muse 模型测试你自己的 MCP server——无需安装、无需 Meta 账号:用 Meta Muse 测试你的 MCP server
完整报告含完整基准表格:Muse Spark 1.2 and Muse Glimmer 30B for MCP
来源:Meta AI Research — Introducing Muse Glimmer · Scale AI MCP-Atlas leaderboard · Muse Glimmer on Hugging Face · Muse Spark 1.2 on OpenRouter