第 5 步预览对比 Muse Glimmer：前沿 API 与笔记本电脑模型

在排行榜上，Step 5 Preview和Muse Glimmer的差距并不小：在 Artificial Analysis Intelligence Index 上分别是 44 与 17——在这条当前榜首位于五十多分高位的量表上，相差二十七分——这是再多调优也无法弥合的。而在团队真正必须回答的那个问题上——我的 token 到底在哪里运行——它们却是直接的竞争对手。Step 5 Preview 是 StepFun 的旗舰模型，于 2026 年 9 月 20 日发布，总参数量约 6000 亿、激活参数 270 亿，上下文长度 100 万 token，定价为每百万输入 token 1.00 美元、每百万输出 token 2.70 美元，且只能通过网络访问。Muse Glimmer 是 Meta Superintelligence Labs 的 300 亿参数开放权重智能体模型，于 2026 年 8 月 10 日以 Apache 2.0 许可发布，以 4 位量化形式交付，因此可装入 20 GB 以下内存，在一台消费级 GPU 上、拔掉网线即可运行。解读这一对模型的正确方式不是“哪个更聪明”，而是“能力与边界这两项约束之中，哪一项是你的工作负载无法移动的”。

这一比较也有助于纠正这个市场养成的一个习惯：把综合指数得分当作模型价值的全部。27分的差距真实存在，而且它并不是这份文件里唯一的数字。在长上下文检索上，同一家独立榜单显示，Muse Glimmer 与来自大得多量级的开放权重模型相差不到半分，而 Meta 自家的智能体基准成绩，对于一款能在笔记本电脑上运行的模型来说也相当体面。与此同时，Step 5 Preview 被提及最多的弱点根本不是能力，而是冗长，并且在承诺的权重于10月15日发布之前，它仍是闭源的。

两个模型，两种截然不同的对象

Step 5 Preview 是一个由 StepFun 基础设施提供服务的混合专家系统：总参数量约 600B，每个 token 激活 27B，支持文本和图像输入，上下文窗口为 1M token，在独立的 Intelligence Index 评测中得分为 44，而同类模型的得分中位数为 26。其输出速度为每秒 87 个 token，而同一榜单的平均值为 78；在整套指数评测任务中，它生成了约 1.6 亿个输出 token，而中位数模型仅生成约 8200 万个——按单位工作量计算的文本量大约是其两倍，计费为每百万 token 2.70 美元。BF16 权重原定于 2026 年 10 月 15 日发布，但目前尚未出现在代码仓库中，因此眼下这个模型对你来说只以 API 的形式存在。

Muse Glimmer 则是截然相反的存在。它是一个 30B 参数模型，通过从 Meta 更大的 Muse Spark 教师模型进行 logit 蒸馏训练而成，随后在长上下文智能体数据上微调，并针对工具使用进行了强化。Meta 以 4 比特量化形式发布它，将全精度下超过 55 GB 的内存占用降至 20 GB 以下——可容纳于 24 GB 或 32 GB 的显存范围之内——Meta 还在 Nvidia RTX 5090 以及 Apple M4 Max 和 M5 Max 芯片上对其进行了测试。它支持一百多种语言的文本和图像输入，支持 131,072 个 token 的上下文并可扩展至 262,144,其设计目标是接收一个目标、将其拆解为步骤、调用工具，并在调用失败时重试而不是就此停止。它采用 Apache 2.0 许可，并且可离线运行。

• 独立评分 — Step 5 Preview：44，而其所在级别的中位数为 26；相比之下，Muse Glimmer 在高配置下的同一指数上为 17。

• 规模——Step 5 预览版：约 600B 总参数量，StepFun 每步激活 27B；而 Muse Glimmer：总参数量 30B，在 20 GB 以下量化至 4-bit。

• 上下文窗口 — Step 5 Preview：1M tokens，对比 Muse Glimmer：131,072，可扩展至 262,144，据 Meta 称。

• 价格 — Step 5 Preview：每百万 token 输入 $1.00 / 输出 $2.70，已公布，对比 Muse Glimmer：不按 token 收费；你需要自备 GPU。

• 运行位置 — 第 5 步预览：供应商的服务器，通过 HTTP vs Muse Glimmer：你自己的硬件，离线。

• 许可证 — Step 5 Preview：封闭预览，权重承诺于 2026 年 10 月 15 日提供；对比 Muse Glimmer：Apache 2.0，现已可下载。

• 长上下文检索——Muse Glimmer 在 index board 的长上下文推理评测中取得 80.0 分，与价格高出自身上数倍的模型相差不到半分，且与 Step 5 Preview 的成绩足够接近，这一差距对于查找事实类工作而言并不具有决策意义。

二十七点，以及它们未能衡量之处

一个被蒸馏到可在 20 GB 内存中运行的 30B 模型，在通用智能指数上必然会输给 600B 的旗舰模型，Meta 自己的材料也没有声称相反——其中一种表述直言不讳地指出，Glimmer 并非旨在匹敌全规模云端模型的原始推理能力。因此，17 分并不是对工程的评判；它是权衡另一个目标后的预期结果。正确的问题是，这一差距实际上覆盖了你哪些任务。

长上下文阅读正是两者最接近的地方，也是直觉开始失灵的地方。Muse Glimmer 在该榜单的长上下文推理评测中拿到 80.0 分——这个分数对前沿模型而言平平无奇，对运行在消费级 GPU 上的模型却非同寻常。如果你的工作负载是在长文档上做检索、摘要或抽取，那么一个达到这一水平的本地模型显然不算错误的选择，而且请求始终不离开你的机器这一点，是任何 API 无论出价多高都买不来的特性。

然后是 Meta 的数字没有展示出的那部分比较。一项关于多智能体编排的同行评审研究在受控环境中测试了 Muse-Glimmer-30B——相同任务、相同测试框架、相同顾问——发现它未能找回更大前沿模型产出的任何候选方案，在每种设置下三次尝试全部失败。那只是针对一种配置的单项研究，而这正是模型页面从不呈现的那类证据。对于较弱的编排器必须从更强模型的失败中恢复的智能体流水线而言，这是本文中最具决策相关性的结果，值得在任何 Meta 厂商报告的基准之前阅读。

为完整起见，这些基准都是 Meta 自己的，且未经复现：SWE-Bench Verified 上 76.0%，SWE-Bench Pro 上 51.2%，TerminalBench 2.1 上 51.7%，OSWorld-Verified 上 65.9%，GPQA Diamond 上 83.5%，Humanity's Last Exam 上 22%，MCP-Atlas 上 75.5。它们是对标与其自身同一规模级别的模型来衡量的，并且它们描述的是一个有能力的本地智能体，而非前沿推理模型。

边界实际上落在哪里

Step 5 Preview 的结构性优势在于，它能完成你在本地无法完成的工作。100 万 token 的上下文、图像输入、经实测的接近前沿的得分，以及每秒 87 个输出 token，且无需购买任何硬件：对于起草、规划、跨大型代码仓库的代码审查，或任何模型能力上限成为瓶颈的场景，API 胜出，而这二十七分就是全部论据。其代价与 Muse Glimmer 的恰好相反：提示词会离开你的边界，价格会在每个 token 上重新计算，而模型的冗长使长输出工作负载比 $2.70 的费率所暗示的更加昂贵。

Muse Glimmer 的优势在于，它做的是那些无法离开本地的工作。如果数据受到监管，如果延迟预算只有几毫秒，如果机器处于离线状态，或者如果第一百万次请求的边际成本必须为零，那么任何 API 都不在候选之列——不是这个，也不是任何一个。为此付出的代价是能力：你是在存在 44 的情况下选择了 17，而在智能体编排中，你可能选择的是一位无法从更强模型所犯错误中恢复的协调者。

对大多数团队来说，答案不是二选一，而是一种拆分，而这种拆分需要有地方落脚。OrcaRouter 将超过 200 个模型置于一个 API 密钥和一张账单之后，0% 加价，并按供应商标价原样透传，外加自动故障转移，以及一个路由 DSL，可按任务、成本或延迟来分流。Step 5 Preview 和 Muse Glimmer 都不在该目录中——StepFun 的旗舰模型不由我们路由，而 Glimmer 是本地下载——因此所提供的价值并不在于能访问其中任一模型。它是你会用来对它们进行基准测试的那组模型，今天用一个密钥即可调用，从而让本地与远程的取舍由你自己的任务分布来决定，而不是由你最后读到的那家供应商页面来决定。

如何决定

当上限才是真正的约束时，选择 Step 5 Preview。如果你的任务属于开放式、多模态、长上下文，或是那种需要有能力出众的规划器的智能体任务，那么 API 模型是二者中唯一能胜任的，而它的价格在其同类中足够低，以至于试用它只是一笔预算条目，而不是一个项目。要为冗长留出预算，做好 10 月 15 日权重发布日延后的准备，并把那些绝不能离开本机构的工作负载排除在外。

当边界成为约束条件时，选择 Muse Glimmer。如果你的数据无法外发，如果你需要在飞机上或工厂里运行，或者如果你的用量规模让按 token 计价变得荒唐，那么一个能装进 20 GB 的 30B Apache-2.0 模型就是务实之选，而且它的长上下文检索结果足够好，能力差距不会在每一种工作负载中都显现出来。在把编排任务托付给它之前，先在编排场景中测试它，因为那正是独立证据最薄弱的地方。

如果两个约束同时生效，那就两者都用：无法移动的数据留在本地，需要更大模型的任务走 API，并让路由决策成为一次配置变更，而不是一次迁移。真正重要的比较不是 44 对 17，而是你的哪些请求可以承受离开这台机器，而这个问题只有你自己的流量才能回答。