最近两天朋友圈被一条开源模型的消息刷屏阶跃星辰放出了 Step 5 Preview600B 级别的 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 专家分工与路由用“专家会诊”理解 MoEMoE 的全称是 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 量化权重降到约 600GB8 张 80GB 的卡够装再狠一点做 INT4 量化权重约 300GB4 张 80GB 的卡就能塞进去——不过精度损失就得自己评估了。部署方案权重精度权重占用最少卡数建议适用场景BF16 全量BF16约 1200GB16 张 80GB追求最佳精度的研究场景INT8 量化INT8约 600GB8 张 80GB精度与成本平衡INT4 量化INT4约 300GB4 张 80GB预算有限但想先跑起来这个账直接决定了一个团队有没有可能私有化部署也决定了官方 API 的成本能压到多低。接着说成本。3. 成本账本单任务成本为什么能压到 Opus 5 的八分之一3.1 大模型推理成本从哪里来一个模型的单任务成本由几块拼成训练成本摊到每次推理上的折旧、每次推理消耗的算力、显存占用时间、以及服务方的定价策略。闭源 API 的成本大头其实是训练摊销加推理算力加高毛利。Opus 5 这类顶级闭源模型训练成本是极高量级的数字推理又必须跑满全量参数供应商还要把研发、对齐、安全审查的成本都算进去最终落到 API 价格上就是一个让个人开发者肉疼的数字。开源模型不一样。既然权重已经公开你可以自己部署训练成本已经沉没掉了只需要付推理成本。而 MoE 的稀疏激活把推理算力又砍掉了一大块这就是“八分之一”的第一个来源。3.2 稀疏激活到底省了多少算力还是那个例子600B MoE 激活约 60B对比一个同样语义能力的 Dense 模型——虽然不一定有等体量的 Dense 对照但我们可以抽象地算。假设一个能力对标的 Dense 旗舰要 300B 以上那么每生成一个 tokenMoE 模式的计算量可能只有 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权重约 600GB8 张 80GB 卡可以放下。INT4 的话约 300GB4 张 80GB 卡够跑但你要接受可能的精度下降。需要注意不是说权重放下了就能跑。MoE 模型的显存占用除了权重还有路由计算、专家间通信缓冲区、KV cache这些都占显存。建议至少留 20% 到 30% 的余量。我们之前的经验是显存规划按权重的两倍去估通常不容易出问题。5.2 推理框架选型与部署要点当前跑大 MoE 模型比较成熟的框架有几个方向vLLM社区活跃支持 MoE 的专家并行吞吐量高适合在线服务SGLang对复杂 MoE 模型支持很好radix attention 在 agent 多轮场景下优势明显TensorRT-LLMNVIDIA 体系下压榨性能最狠的选项但配置复杂度也最高。部署的几个要点我梳理一下优先用官方或社区认可的加载方式不要自己造轮子。MoE 模型的路由权重和专家权重结构比较复杂用现成框架能少踩很多坑注意 expert-parallel 配置。不同框架对专家的切分方式不同切分不当会引发严重的通信瓶颈启动前跑一轮完整的 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 这种模型最大的价值不在于它某一天在某个榜单上拿了第几名而在于它让更多团队第一次认真考虑一个问题我们能不能用旗舰级的模型能力却付一个不那么吓人的成本我个人建议如果你是做应用的、做企业服务的、或者做数据敏感行业的别只盯着宣传里的性价比数字先把硬件账单拉出来算一遍再拿自己的真实任务集跑一轮评测。模型好不好最终要由你的业务说了算。