一张标题卡,用于“Muse Spark 1.2 对决 GLM-5.2——闭源编码器对阵开源通才”,其中 Muse Spark 1.2 展示在关闭的挂锁图标下方,GLM-5.2 展示在打开的盒子图标下方。
Guides & Insights

Muse Spark 1.2 对比 GLM 5.2:封闭式编程模型与开放式通才模型

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型
基准测试:Artificial Analysis · 每日更新
返回全部文章

两个拥有100万token上下文窗口的模型,每百万token的定价相差不到15美分,都面向高强度的编码型智能体工作——但它们几乎再无其他共同点。Muse Spark 1.2由Meta于2026年8月5日发布,同时发布的还有一个联合训练的终端智能体Muse Code;该模型为闭源,每token价格更低,在当前Artificial Analysis Intelligence Index上得分57,且必须先进行推理才能回复。GLM 5.2是Z.ai在6月中旬推出的旗舰开源权重模型,采用MIT许可,可自行托管,首个token的生成速度快约五倍,而且通过我们网关的真实流量仍为其四倍半——过去七天为2.13亿token,而Muse Spark 1.2为4600万token。得分更高、每token更便宜的模型,流量反而更少。开源的那个才是人们真正路由使用的模型。

关于这一事实的诚实版本正是本文的主题。评分和定价的作用,不及模型与你的流水线之间的适配程度来得重要,而这两个模型在决定适配度的每一个维度上都做出了相反的选择。凡有独立数据之处,数据均来自 Artificial Analysis;凡来自 Meta 或 Z.ai 的数据,均标注为供应商自报;延迟和流量数据则是 OrcaRouter 自身的七天生产环境遥测数据。

规格对比,一次一个维度

价格 — Muse Spark 1.2 每百万 tokens 输入 $1.25 / 输出 $4.25,缓存命中 $0.15;GLM 5.2 输入 $1.40 / 输出 $4.40,缓存 $0.26。Meta 在每一行都更便宜。

上下文—— 两者均为 1,048,576 个 token。最大输出:Meta 文档记载 Muse Spark 1.2 的上限为 131,072 个 token;GLM 5.2 宣称 128,000。

推理 — 推理在 Muse Spark 1.2 上是强制的,涵盖五个努力级别(minimal 到 xhigh,默认 medium);GLM 5.2 运行混合推理,由 reasoning_effort 控制,级别为 high 或 max,默认开启深度推理。

输入 — Muse Spark 1.2 宣称支持文本、图像、视频、音频和 PDF 输入;GLM 5.2 是文本进、文本出。

权重 — Muse Spark 1.2 是封闭的,没有代码仓库,也没有自托管路径;GLM 5.2 提供 MIT 许可的开源权重,这是一个 753B 参数的混合专家模型,每个 token 约激活 40B 参数。

年龄——Muse Spark 1.2 在撰写本文时仅发布了三天;GLM 5.2 自6月13日起已投入生产,拥有八周的实际应用经验,以及围绕它构建的整个宿主和工具生态系统。

指数差距为四点。版本陷阱真实存在。

Artificial Analysis当前的Intelligence Index(v4.1.1)将Muse Spark 1.2评为57分,在185个模型中排名第12;GLM 5.2为53分——这是榜单上最高的开源权重得分,但仍落后4分。大多数报道仍引用Muse Spark 1.2的54分,因为那是发布当日评估的结果;v4.1.1重新评分为其增加了2.7分,是那次更新中所有模型里增幅最大的。如果你在任何地方看到“54 vs 51”或“54 vs 53”,在把这个差距当作真实数据之前,先核对每个数字对应的是哪个指数版本。

值得说明的是,这四分的差距意味着什么,又不意味着什么。它意味着,在九项基准的综合指标上,Meta 的闭源模型在相近的投入水平下领先于 Z.ai 的开源模型。它并不意味着 Muse Spark 1.2 在所有方面都胜过 GLM 5.2,因为这两个模型是通过不同路径取得各自分数的。GLM 5.2 是数学和推理方面的异类——AIME 2026 得分 99.2——但众所周知它输出冗长,其弱项是深度的仓库级任务。Muse Spark 1.2 则呈现相反的形态:擅长终端编码和多文件任务,而且每个任务的评估成本显著更低,因为它在思考过程中消耗的 token 少得多。

A two-column scoreboard for Muse Spark 1.2 and GLM-5.2. AA Index (v4.1.1): 57 vs 53. Terminal-Bench 2.1: 80.1 vs 77.9. DeepSWE 1.1: 59.3 (Meta) vs 46.2. Weights: closed vs MIT open. Price in/out: $1.25/$4.25 vs $1.40/$4.40. p50 TTFT: 8.13 s vs 1.55 s.

基准测试实际分歧之处

在 Terminal-Bench 2.1 上,两者的差距比指数差距所显示的要小,而且数据来源比平时更重要。在同一 Artificial Analysis 评估框架下,Muse Spark 1.2 得分为 80.1,GLM 5.2 得分为 77.9。Meta 声称 Muse Spark 1.2 在其自有框架上的得分为 82.9;Z.ai 报告的最佳成绩是 GLM 5.2 的 82.7,这使其成为该基准上首个超过 80 分的开放权重模型。同一个基准,四个不同的数字——评估框架的搭配会将这些分数向两个方向推动数分,因此任何单一的 Terminal-Bench 声称值都应视为一个范围。

需要关注的差异点是{{1}}DeepSWE 1.1{{/1}},这个基准测试强调在长智能体循环中进行深度、多文件、仓库级推理。Meta报告{{2}}Muse Spark 1.2{{/2}}的分数为59.3——这是厂商数据,还没有第三方复现过。{{3}}GLM 5.2{{/3}}公布的DeepSWE成绩为46.2,其前代{{4}}GLM-5.1{{/4}}为18.0,所以这就是Z.ai{{5}}进步最大却依然落后的维度。如果你的工作负载是"{{6}}协调一致地修改五十个文件{{/6}}",那么这一差距就是问题的全部;如果你的工作负载是终端命令和搭建脚手架,那它几乎可以忽略不计。

还有一个发现颠覆了显而易见的定调。独立的 Vals AI 套件按领域运行智能体工作负载,将 Muse Spark 1.2 排在总体第五名(71.88%)——同时分别在 Finance Agent、TaxEval 和 Harvey 的 Legal Agent 基准上排名第一,对比的模型数量分别为 44、136 和 31 个——而 Terminal-Bench 2.1 只是它在五十个领域中的第十四佳表现。Meta 把这款模型当作编程模型来卖,但独立评估机构发现它最强的其实是金融、税务和法律文档智能体。如果你的团队负责撰写合同或核对账目,那就是本文中最有价值的一个数字。

开放权重问题才是真正的分岔点。

上述内容都是关于能力的。而这个决定主要关乎所有权,在这一点上,两者相差甚远。

GLM 5.2 是采用 MIT 许可的开放权重模型。这改变的不仅是账单,更是议价格局:如果工作负载涉及敏感数据或规模很大,你可以自行托管;由于权重归你所有,你可以把它在不同服务商之间迁移而无需重新集成;任何提供托管服务的厂商都必须在价格和延迟上竞争,这正是开放权重产品线会随时间推移越来越便宜的原因。753B 的 MoE 不是能在笔记本电脑上跑得动的模型——大多数团队仍会选择租用而非自行运行——但离开的选项,或者以固定成本在内部运行同一套权重的选项,为任何人对你的收费设定了下限。

Muse Spark 1.2 选择了相反的捆绑组合。权重是封闭的,唯一的第一方接入方式是 Meta 的 Model API,我们现在也已接入该 API。作为交换,你得到的是一个联合训练的产品:Muse Code——这款随模型发布的终端 Agent 在经拒绝采样筛选的测试轨迹上完成调优,并在可精确重放的事件日志运行时上运行持久、可安全重启的子代理,同时带有/plan/grill/goal 技能。这与“把好模型接入自己的测试框架”截然不同——它是一个开箱即用的 Agent。代价是它只能以 Meta 的方式、在 Meta 的工具中、在 macOS 或 Linux 上运行;目前没有 Windows 客户端、没有 MCP,也没有 IDE 插件。

Screenshot of the Meta AI Research announcement 'Introducing Muse Code and Muse Spark 1.2', dated August 5 2026.

每个令牌的价格,每个任务的价格

按 token 计,Muse Spark 1.2 在输入和输出上都要更便宜,而在单个任务上它依然更便宜,因为它的输出也更简洁。Artificial Analysis 的测试显示,GLM 5.2 在发布时仅运行 Intelligence Index 就消耗了 1.41 亿个输出 token,其中 95% 是推理 token——是榜单上输出最冗长的一线模型。Muse Spark 1.2 在同样的测试中消耗了 9500 万个 token,每个任务仅 0.40 美元。更多 token 乘以更高费率,意味着 GLM 5.2 的每任务成本会以标价看不出来的方式持续放大。而这才是比较推理模型的正确方式:按完成的任务来定价,而不是按百万 token 的费率。

这里还有第三种价格,而且这些模型中只有一款提供。Muse Spark 1.2 的贡献者层级定价为输入 $0.10 / 输出 $0.20——比标准层级低一个数量级,也比 GLM 5.2 的标价低出类似幅度。代价是允许 Meta 用你的流量训练未来模型,再加上每分钟 60 次的请求上限,这排除了生产环境下的扇出调用。请把它视为附带折扣的法律审查,而不是更便宜的 SKU;对于符合条件的团队,只要在该上限内工作,价格对比就不再接近。

延迟:两个模型发生逆转

如果索引差距有利于 Meta,那么在延迟表现上,GLM 5.2 在体验上取得了决定性胜利。在过去七天 OrcaRouter 的真实流量中,Muse Spark 1.2 的首 token 时间 p50 为 8.13 秒,p95 为 10.00 秒,然后以每秒 576 个输出 token 的速度疾驰,错误率为零。GLM 5.2 的 p50 为 1.55 秒——首 token 快五倍以上——但每秒仅输出 78.5 个 token,错误率为 0.16%。在实验室最大努力下,差距进一步扩大:Artificial Analysis 测得 Muse Spark 1.2 在 xhigh(其最昂贵的推理设置)下首 token 时间为 26 秒。

所以,一个模型让你先等待,然后快速交付;另一个模型则立即开始,但慢慢来。对于任何人类在等待观看的事情——一次聊天回合、一次交互式终端会话——GLM 5.2 感觉更好,也正因如此,它主导了我们网关的交互式流量。对于长文本生成、大型补丁或文档草稿,Muse Spark 1.2 一旦开始就会最先完成,因为它的输出速率是 GLM 5.2 的七倍。衡量错了指标,你就会因为错误的原因而选错模型。

尝试两者而无需第二份合同。

两种模型都在OrcaRouter目录中,按供应商标价提供——Muse Spark 1.2为1.25美元和4.25美元,GLM 5.2为1.40美元和4.40美元——因为OrcaRouter以0%加价传递供应商费率。这使得定价部分高于发票而非标签,也意味着在两者之间切换只需在同一密钥下修改模型字符串中的一行,而无需新的集成。如果供应商降价,降价会在同一天落到我们这边。

路由层在这里恰恰能体现出价值,正因为这两个模型是互补的。Muse Spark 1.2 的弱点是首 token 延迟慢,规模化后价格偏高;GLM 5.2 的弱点是输出冗长和深度仓库推理能力不足。一个将规划阶段分派给 Muse Spark 1.2、将并行 worker 扇出分派给 GLM 5.2——或在 Muse Code 端点响应缓慢时自动故障转移到 GLM 5.2——的路由规则,构建起来不需要额外成本,因为两者都位于同一个端点后面。而对于一个上线仅三天的模型,自动故障转移正是你在不把生产路径押在它身上的前提下试水它的方式。

Screenshot of the OrcaRouter model page for GLM-5.2 (z-ai/glm-5.2), showing $1.40 per million input tokens, a 1M-token context window, 128K max output and an OpenAI-compatible endpoint.

谁应该选择哪个

选择Muse Spark 1.2当工作单元是一个大型、连贯的工件,并且有人能等它几秒钟才能启动时:多文件重构、整个代码仓库的生成、长时间的智能体循环,以及——根据 Vals AI 的说法——金融、税务和法律文档工作。DeepSWE 领先地位、高输出率和贡献者层级都指向同一方向。您接受的是封闭权重、Meta 的工具链和较慢的首个 token,并且应将 Meta 的 82.9 和 59.3 视为声称,而非事实。

选择GLM 5.2——当自主权和体验比综合指标更重要时:你可以自行托管或迁移的开放权重、适合交互式工作的快速首 token、已经能与其配合的框架和工具生态系统,以及目前可用的最强开放权重通用能力。接受它的冗长、46.2 DeepSWE,以及即使不考虑 token 数量差异也更高的每 token 标价。

大多数团队会发现,诚实的答案不是单纯二选一。开放的那个是主力,你把大部分流量都导向它;封闭的那个是专家,你让它去处理深层任务和敏感文档。在综合指数上只差四个点,在权重归属上却天差地别——这才是真正的选择,而且比分数清晰得多。

本文中的对比1

根据本文内容识别 · 基准测试:Artificial Analysis · 每日更新

© 2026 OrcaRouter

推理服务商

运营推理平台?让您的模型上线 OrcaRouter。

providers@orcarouter.ai

加入我们的社区

Discordsupport@orcarouter.aiXGitHubYouTube