Step 5 Preview：600B MoE开源模型如何压低大模型推理成本

最近两天朋友圈被一条开源模型的消息刷屏：阶跃星辰放出了 Step 5 Preview，600B 级别的 MoE，直接冲进开源模型前三，官方对比口径里还有一句很扎眼的——单任务成本只有 Opus 5 的八分之一。

这句话信息量很大。单看“600B”会觉得又是一轮参数军备竞赛，但把“MoE”“开源”“成本八分之一”这几个关键词合在一起，它其实在讲另一件事：开源模型在性能逼近闭源旗舰的同时，把单位成本拉到了完全不同的数量级。这篇文章我会系统拆一拆 Step 5 Preview 到底做了什么，MoE 的 600B 和过去 Dense 的 600B 有什么本质区别，“八分之一”的成本账是怎么算出来的，以及作为一个实际部署过不少开源大模型的工程团队，拿到这类模型后真正该关注什么。

1. 开源大模型的新战局：为什么说这次是“杀进前三”

1.1 开源模型排行榜的座次变化，到底变了什么

过去一年半，开源阵营的头部基本是几波势力在轮换。Qwen、DeepSeek、Llama 各自迭代，偶尔有 Mistral 窜出来搅局，大多数能进入第一梯队的也就是 70B 级别的 Dense 模型，或者 400B 左右的 MoE。参数规模上，开源和闭源之间一直有种心照不宣的差距：闭源敢堆万亿参数，开源要考虑社区能不能跑得动。

所以当 Step 5 Preview 以 600B 总参数的 MoE 形态出现，并且多个评测维度进入开源前三的时候，变化的不是“又多了一个大模型”，而是开源旗舰的天花板从 400B 这个量级，被抬到了 600B 这个量级。

这里有个点值得单独说：开源模型的比拼，从来不是纯看跑分高低，而是看“别人能不能用得上”。闭源旗舰性能再强，权重看不到、API 收费高、数据不透明，开发者能做的只有调用。开源模型一旦做到接近的性能，整个局面就完全不同了——你可以拿权重做评测、做微调、做私有化部署、做内部审计。这一点后面我会单独展开。

1.2 “旗舰”两个字不是参数堆出来的

600B 总参数并不能自动等于旗舰。真正让人眼前一亮的是，Step 5 Preview 据称在推理、编程、数学这些硬核任务上，表现已经能和闭源第一梯队掰手腕。做一个粗糙的参照：开源社区过去在代码生成、数学推理这类任务上，和闭源顶尖模型经常差 5 到 10 个百分点，但 Step 5 Preview 把这个差距压缩到了个位数甚至互有胜负。

这种差距的缩小不是单纯靠堆参数量，更关键的是数据和训练策略。我自己跑过不少开源模型，体感是：参数量上去之后，如果数据质量跟不上，模型“博学但智力平平”，考试能蒙对常识题，真给一个复杂的多步推理任务就露馅。阶跃星辰这代明显在推理轨迹数据、代码数据这些方向上做了针对性投入，所以“旗舰”这两个字才算立住了。

1.3 对标 Opus 5：性能咬得住，价格打得穿

官方对比里出现 Opus 5 也不是随便挑的。Opus 系列在闭源模型里一向是“贵但强”的代表，在复杂 agent 任务、长上下文、代码生成这些场景中，经常被当成标杆来测。

把 Step 5 Preview 拿来和 Opus 5 对标，其实释放了两个信号：第一，性能上我有资格站上这个擂台；第二，也是更关键的——同一个任务，我完成它的成本只要 Opus 5 的八分之一。

这就引出了整个事件里最有意思的部分：“八分之一”到底是怎么来的？如果只是 API 定价比人家便宜，那没什么技术含量。但开源模型能做到低成本，核心其实是 MoE 架构带来的推理效率优势，加上自部署带来的边际成本下降。下一节我把 MoE 拆开讲。

2. MoE 架构拆解：600B 总参数不等于 600B 全干活

2.1 专家分工与路由：用“专家会诊”理解 MoE

MoE 的全称是 Mixture of Experts，混合专家模型。简单理解就是：一个团队里坐了一堆各有所长的专家，每次来一个任务，不会让所有专家都发言，而是由路由机制判断“这个问题该让哪几个专家回答”，然后只叫那几个人干活。

放在模型结构上，传统 Transformer 的每一层 FFN（前馈网络）是一个整体，MoE 则把 FFN 拆成 N 个并行的专家网络，每个专家都是一组独立的参数。输入 token 经过 Router（门控网络）计算一个概率分布，选出概率最高的 Top-2 或 Top-K 个专家来执行计算，然后按权重混合输出。

这套设计解决的是效率问题。一个 600B 的 MoE，假如有 256 个专家，每个专家约 2B 参数，那么每个 token 只激活其中 2 个专家，实际参与计算的 FFN 参数只有 4B 左右。注意，这只算了 FFN 部分，还要加上 Attention 等共享层的参数，最终“激活参数量”可能在 60B 上下。

所以看到一个 600B MoE，不要以为它每次推理都过一遍 600B 参数。它只是把 600B 的“知识库”全部搬到了显存里，每次只读取其中一小部分。这和过去通读全文的 Dense 模型有本质区别。

2.2 总参数与激活参数的差距：性能和成本的分界线

Dense 模型（如 Llama、Qwen 的普通版）的每一层 FFN 都是完整的，所以无论输入什么 token，整条网络都会被完整走一遍。600B Dense 意味着每个 token 都要过 600B 参数的计算，训练的算力开销、推理的延迟和显存带宽需求，都是实打实的 600B 级别。

MoE 则把“容量”和“计算量”解耦了：总参数决定模型的记忆容量和知识覆盖，激活参数决定单次推理的计算成本。一个 600B MoE，如果每 token 只激活 60B，那么它的推理计算量大约只相当于 60B 的 Dense 模型，但知识容量仍然是 600B 级别。

这就像一个公司，员工名册上有 600 个人，但每个项目只抽 60 个人的精干小组去执行。名册越大，公司能接的项目越杂；但每次真正干活的只有那 60 人，人力成本可控。这个解耦，就是 MoE 能在性能和成本之间取得平衡的核心原因。

2.3 “MoE 要全部参数进显存吗”——这个问题很多教程讲错

我见过最多的误区就是把“稀疏激活”理解成“只用加载被激活的专家”。实际上，推理时虽然每个 token 只计算部分专家，但路由是动态的——你没法预先知道下一个 token 会激活哪几个专家。所以部署时必须把全部权重加载到显存或内存里，才能保证任意 token 都能被正确路由和计算。

也就是说：600B MoE 全部参数确实都要进显存（或者内存+显存的混合方案），这是部署成本的大头，但推理算力成本却是稀疏的。这两个概念必须分开：显存考的是“你要买多大容量”，算力考的是“你要付多少电费或算力费”。

咱们直接算一笔账。600B 参数，BF16 精度每参数 2 字节，权重就要约 1200GB。单张 80GB 的 H100 肯定放不下，至少要 16 张 80GB 卡才能勉强装下 BF16 权重，还要考虑 KV cache 和激活值。如果做 INT8 量化，权重降到约 600GB，8 张 80GB 的卡够装；再狠一点做 INT4 量化，权重约 300GB，4 张 80GB 的卡就能塞进去——不过精度损失就得自己评估了。

这个账直接决定了一个团队有没有可能私有化部署，也决定了官方 API 的成本能压到多低。接着说成本。

3. 成本账本：单任务成本为什么能压到 Opus 5 的八分之一

3.1 大模型推理成本从哪里来

一个模型的单任务成本，由几块拼成：训练成本（摊到每次推理上的折旧）、每次推理消耗的算力、显存占用时间、以及服务方的定价策略。

闭源 API 的成本大头其实是训练摊销加推理算力加高毛利。Opus 5 这类顶级闭源模型，训练成本是极高量级的数字，推理又必须跑满全量参数，供应商还要把研发、对齐、安全审查的成本都算进去，最终落到 API 价格上就是一个让个人开发者肉疼的数字。

开源模型不一样。既然权重已经公开，你可以自己部署，训练成本已经沉没掉了，只需要付推理成本。而 MoE 的稀疏激活把推理算力又砍掉了一大块，这就是“八分之一”的第一个来源。

3.2 稀疏激活到底省了多少算力

还是那个例子：600B MoE 激活约 60B，对比一个同样语义能力的 Dense 模型——虽然不一定有等体量的 Dense 对照，但我们可以抽象地算。假设一个能力对标的 Dense 旗舰要 300B 以上，那么每生成一个 token，MoE 模式的计算量可能只有 Dense 旗舰的 1/5 到 1/3。

更重要的是批量推理场景。服务端处理大量请求时，MoE 模型的单 token 计算量小，意味着一台 GPU 服务器能同时承载的并发请求更多，单位 token 的成本自然往下掉。做过推理优化的人都知道，吞吐量翻一倍，单位成本降一半，这是纯工程效率。

另外，MoE 专家的并行化也比同参数量 Dense 更容易：不同专家可以分散到不同显卡，路由只把 token 送到对应专家的卡上，通信压力比全量张量并行小不少。这也是工程团队能处理“600B”这个体量的原因。

3.3 自部署的边际成本和“八分之一”的构成

再说更大的一块——自部署。闭源 API 是按 token 收费的，你调用一次付一次钱。开源模型一旦部署到自己集群里，一次推理的边际成本只剩电费和显卡折旧。同样是跑一个复杂的 agent 任务，需要反复调模型、生成大量中间步骤，按 token 计费的 API 成本会很可观；但如果是私有化部署，只要集群不闲置，成本曲线会平缓得多。

把“稀疏激活 + 自部署 + 官方定价策略”三者叠加，单任务成本做到 Opus 5 的八分之一，我觉得是个符合逻辑的结果，甚至在某些固定任务组合下还能更低。当然，这个数值取决于具体的任务场景和部署方案，不是一个绝对的万能结论。我的判断是：如果任务以短文本、大量并发为主，自部署优势最明显；如果是长上下文、大 batch 的复杂任务，显存和 KV cache 会被吃狠一些，成本优势会缩小，但大概率仍然显著。

4. 开源的意义：权重拿到手里，才算真正掌控

4.1 从“黑盒 API”到“白盒权重”

闭源模型的 API 本质是个黑盒：你只能看到输入输出，不知道中间发生了什么。这对普通使用没什么，但对企业级应用、对数据敏感的场景，是个绕不开的问题。开源模型把权重公开之后，任何人都可以做推理链路的审计，可以检查数据分布、评估输出质量，也可以在合规要求下做全流程自查。

我曾经跟一个行业里的团队聊过，他们非常想用顶尖模型的推理能力，但客户数据无论如何不能出内网。闭源 API 这条路直接堵死，开源模型是他们唯一的选择。以前开源模型能力差一截没法用，现在 Step 5 Preview 这类模型把性能补上来，这类需求就被激活了。

4.2 自由度：微调、蒸馏、定制路由

权重在手，就不只是“能跑”的问题。你可以用业务数据做 LoRA 或全参微调；可以把模型蒸馏成更小的学生模型；也可以改动推理服务代码，针对特定专家做路由约束；甚至在 MoE 基础上做专家合并，让某些垂直任务只激活固定几个专家，进一步降低延迟。

这些能力是 API 用户很难获得的。API 给你的是固定几档模型，你想做个垂直领域的小优化都没门路。开源模型的玩法在于“可塑”——想怎么改，取决于你的工程师水平和想象力。

4.3 开源生态的复制效应

一个顶级开源模型放出来，后续通常跟着一串衍生品：量化版、CPU 推理版、专用微调版、Agent 框架适配……Open 权重的好处就是社区会帮你补齐很多官方没时间做的场景。这种生态效应会反过来推高模型本身的使用率，也让后来者能站在前人的成果上继续叠加创新。

对行业来说，开源模型每往上走一步，整个生态的工具链、优化方法、应用玩法都会跟着升一级。这也是我持续关注开源赛道的核心原因。

5. 实际上手：从部署到评测的完整路径

5.1 硬件规划：先搞清楚你手里有多少显存

Step 5 Preview 是 600B 级别的 MoE，想自己部署，第一步不是下载权重，而是先算显存。

我的建议是先定精度再数卡。BF16 全量部署需要 1200GB 左右的权重空间，加上 KV cache，建议准备 16 张 80GB 以上显卡（例如 2 台 8 卡服务器，用张量并行加专家并行拆开）。如果预算撑不住，就降 INT8，权重约 600GB，8 张 80GB 卡可以放下。INT4 的话约 300GB，4 张 80GB 卡够跑，但你要接受可能的精度下降。

需要注意，不是说权重放下了就能跑。MoE 模型的显存占用除了权重，还有路由计算、专家间通信缓冲区、KV cache，这些都占显存。建议至少留 20% 到 30% 的余量。我们之前的经验是，显存规划按权重的两倍去估，通常不容易出问题。

5.2 推理框架选型与部署要点

当前跑大 MoE 模型，比较成熟的框架有几个方向：

• vLLM：社区活跃，支持 MoE 的专家并行，吞吐量高，适合在线服务；
• SGLang：对复杂 MoE 模型支持很好，radix attention 在 agent 多轮场景下优势明显；
• TensorRT-LLM：NVIDIA 体系下压榨性能最狠的选项，但配置复杂度也最高。

部署的几个要点，我梳理一下：

1. 优先用官方或社区认可的加载方式，不要自己造轮子。MoE 模型的路由权重和专家权重结构比较复杂，用现成框架能少踩很多坑；
2. 注意 expert-parallel 配置。不同框架对专家的切分方式不同，切分不当会引发严重的通信瓶颈；
3. 启动前跑一轮完整的 benchmark，确认吞吐量和时延符合预期再接入业务。

5.3 评测清单：别只看一个榜单

官方宣传的榜单是参考，但你自己的业务能不能用，还得自己测。我的习惯是固定一批任务集，至少覆盖这几个维度：

• 代码生成：HumanEval、LiveCodeBench，甚至直接把仓库里真实的 issue 丢给它；
• 数学推理：GSM8K、MATH，以及一些带长链条的竞赛题；
• 复杂指令遵循：IFEval 或自己攒一批多步指令；
• 长文本理解：无论模型宣称多大上下文，必须实测压测一遍。

我们团队实测下来的一个体感是：600B MoE 在多步推理、代码修复这类任务上，明显比 70B Dense 强一个档次；短问答、简单分类这类任务上，优势没那么夸张。所以迁移与否，取决于你实际业务的任务分布。

6. 常见问题与避坑记录

6.1 显存不够又想跑，有什么办法

这个问题的答案有几个梯度。最优先的是量化：先试 INT8，一般精度损失小；再考虑 INT4（如 AWQ、GPTQ），在速度、显存和召回率之间找折中。其次，可以试试 CPU offload——把部分专家权重放到内存，用的时候再换进显存，代价是速度变慢，适合离线批处理。最后一条路是弹性租卡，不要把固定资产卡死在自己机房，先按需扩容验证业务，跑通了再考虑买机器。

6.2 MoE 的专家负载不均衡

MoE 模型一个经典问题是路由塌缩：总有几个专家被频繁选中，另一批专家长期挨饿。模型发布时如果做过负载均衡训练，一般还好；但微调之后有可能重新失衡。排查方法很简单：跑一轮真实数据，统计每个专家的调用次数。如果分布明显偏斜，建议检查微调数据和路由 loss，或者干脆用原始模型跑通用任务，垂直场景再单独训练小模型分流。

6.3 量化之后精度损失不可接受

量化是省显存最直接的手段，但 600B 模型盲压 INT4，某些任务（尤其是数学、代码这种逻辑密集型）可能会有明显退化。我建议量产后跑一遍你最看重的 10 到 20 条核心任务，对比量化前后的输出。如果差异大，退回 INT8；如果 INT8 也接受不了，就上更多卡跑 BF16。工程上没有银弹，只有针对自己的业务做取舍。

6.4 许可证与合规

权重开源不等于随便商用。拿到 Step 5 Preview，第一件事应该是看官方许可证。不同模型开源协议的差异很大，有的是完全宽松，有的会限制商用或要求衍生品同样开源。不要默认“开源等于免费等于随便用”，你的产品和客户都可能有合规要求，提前搞清楚最好。

这套 600B MoE 的组合拳打下来，我最直观的感受是：开源和闭源的差距，已经从“能不能用”变成了“愿不愿意选”。Step 5 Preview 这种模型最大的价值，不在于它某一天在某个榜单上拿了第几名，而在于它让更多团队第一次认真考虑一个问题：我们能不能用旗舰级的模型能力，却付一个不那么吓人的成本？

我个人建议，如果你是做应用的、做企业服务的、或者做数据敏感行业的，别只盯着宣传里的性价比数字，先把硬件账单拉出来算一遍，再拿自己的真实任务集跑一轮评测。模型好不好，最终要由你的业务说了算。