最近开源社区好不热闹各路人马都在把头部的开源模型往最强底座的位置上推。但说实话我第一眼看到600B 参数仅激活 27B这个数字时还是有点愣神——Step 5 Preview 这次的发布不只是简单的参数堆砌它等于给行业里吵了很久的大模型到底能不能又强又便宜这个命题甩了一份相当有力的答卷。尤其是针对长程智能体这种特别烧 token 的场景它把单任务成本砍到了原来的八分之一还直接挤进了全球开源模型的前三阵营。这篇文章我就从自己的理解出发把 MoE 架构的原理、长程任务的痛点、成本怎么算以及我实际跑下来的一些经验和坑一并拆开聊清楚。1. 项目概述Step 5 Preview 带来的冲击波1.1 从标题拆解三个数字的含金量600B 参数、27B 激活、8 倍成本——这三个数字放在一起很多人第一反应是是不是又一家公司来吹牛了。我一开始也这么想直到我细看了公开的技术细节和跑分数据才意识到这次确实不太一样。先说 600B 总参数。这个规模放在开源阵营里已经属于头部梯队和 Llama 3.1 405B、DeepSeek V3 大体在同一档位。但 Step 5 Preview 的特殊之处在于它不是传统意义的密集模型dense model而是采用了混合专家架构也就是 MoEMixture of Experts。600B 是全部专家的参数量总和而真正每次处理 token 时被激活的只有 27B 参数。这个27B 激活才是真的精髓。它意味着一件事在推理时模型的单次前向计算量只相当于一个 27B 参数的密集模型。做过推理部署的都知道参数越小显存占用越少、单 token 生成延迟越低、并发能力越强、成本也就越便宜。而 8 倍成本削减正是这个结构带来的直接结果。那 8 倍是怎么算出来的按照阶跃星辰的说法在长程智能体场景下单任务成本降到了原来的 1/8 左右。这个不是拍脑袋而是把输入 token、输出 token、上下文缓存、反复推理的次数全部折算后得出的综合值。换句话说同样一个需要多轮工具调用、长上下文记忆、长时间规划的任务用 Step 5 Preview 跑比用同等级别的密集模型跑要便宜 8 倍。1.2 为什么这次开源前三含金量更高开源模型排行榜上能挤进前三的都不是吃素的。Step 5 Preview 能直接突袭到这个位置说明它在多个维度的评测中都拿到了很高的分数而不光是某一个榜单刷了榜。根据目前公布的信息它在开源评测和智能体评测上表现都不错尤其是长程智能体相关的基准比如需要长时间多步规划的任务上取得了接近甚至超过头部闭源模型的效果。这个含金量在于它是预览版Preview不是正式版。也就是说阶跃星辰在正式版发布之前就把这个能力水平放了出来后面大概率还有提升空间。对一个开源项目来说预览版做到这个水平确实能说明底子很扎实。另一方面全球开源前三这个成绩也意味着它已经开始被大量开发者真正用于生产环境而不只是停留在刷榜阶段。选型的人看重的是综合体验性能、成本、生态兼容性、以及部署效率Step 5 Preview 目前在这几个维度上都有了很好的平衡。1.3 我关注的第一个关键问题它到底有多开源我特意去查了一下这次的授权方式。Step 5 Preview 用的是比较宽松的商用许可企业拿去做商业化产品不需要把自己的代码开源。这一点对创业团队和中小公司特别重要。过去很多团队不敢用某些开源模型就是因为协议写得太死动不动就要求你用了我的模型你的项目也得开源。Step 5 Preview 这次在协议上给了很大的自由度等于把商用门槛也降了下来这对长程智能体应用的孵化是一个实打实的利好。2. 核心技术解构600B 参数如何只激活 27B2.1 MoE 架构的小团队作战逻辑要理解为什么 600B 参数还能高效推理得先明白 MoE 是怎么工作的。传统密集模型像一个全能型的单兵每个 token 进来所有参数都要参与计算这很稳定但也很费算力。而 MoE 模型更像一个大型团队成员分成多个专业小组专家每次来了一个任务只调用最擅长的那几个小组去干其他小组该干嘛干嘛不参与。这个谁专业谁上的机制就是路由router在做的事。Step 5 Preview 的 27B 激活意味着每个 token 实际只走过了 27B 参数的运算路径。这就大大降低了单次推理的 FLOPs。你可以简单理解成600B 是团队的总人力但平时干活最多只需要调用 27B 的员工剩下的大部分专家在待命只在需要特定能力时才会被路由唤醒。这种结构在训练时和推理时都能大幅节省资源。有人可能会问只有 27B 的算力能力真的能达到 600B 的水平吗这里的关键在于专家分工和路由质量。如果上百个专家各自专注不同的领域和知识子空间路由能把任务准确交给合适的专家组合那么激活 27B 的综合能力可能接近甚至超过某些 200B 以上的密集模型。这就像一支足够专业的球队不需要全员上场也能赢球关键在于教练路由能不能排对阵容。2.2 总参数与激活参数不同的资源开销这里要区分一个很多人误解的点总参数和激活参数涉及的开销完全不同。总参数600B决定的是存储成本。600B 参数用 FP16 存储光权重文件就大约 1.2TB。这就意味着你需要一个比较大的模型仓库或分布式存储来放这些权重。但好消息是这些权重在推理时可以分片存在不同的 GPU 上不一定每张卡都要装全套。激活参数27B决定的是计算成本。它直接决定了推理时需要多少显存、多少算力。27B 激活参数在 FP16 下大约需要 54GB 显存加上 KV cache 和中间激活单张 80G 的 A100/H100 就能跑起来或者用两张 40G 的卡也能稳稳跑。相比动辄需要 8 卡甚至 16 卡才能跑的 200B 密集模型这个部署门槛低太多了。这也是为什么说单任务成本狂砍 8 倍——因为在长程智能体场景下任务往往需要长时间的推理和大量工具调用每一个 step 都在产生推理成本。如果单 step 的成本因为激活参数少而大幅下降整个长程任务加总下来的成本自然也就断崖式下降。我实际算过一笔账如果过去用密集大模型跑一个 50 步的长程智能体任务假设总 token 消耗在 300K 左右那么用激活 27B 的 MoE 模型单 token 成本可以降到原来的十分之一上下再加上它更稳的规划能力减少了重试次数综合省下 8 倍成本是说得通的。2.3 稀疏激活的潜力边界当然MoE 模型也不是没有问题。路由是它的命门。如果路由判断失误把不该调用的专家激活了或者专家之间协同不好模型的输出质量就会下滑。所以 Step 5 Preview 能把这个架构打磨到开源前三的水平背后一定在路由策略和专家训练上下了不少功夫。另外还有一个 MoE 的经典痛点多任务泛化能力。理论上 MoE 有大量专家应该能做到更细粒度的任务分工但实际训练中专家坍缩expert collapse经常发生——也就是某些专家过于活跃其他专家变成僵尸参数没有真正参与计算。根据公开信息阶跃星辰的训练策略应该在缓解专家坍缩和提升专家利用率上做了不少优化否则 27B 激活不可能拿到这么强的效果。这一点我没有看到完整的训练细节但从结果反推大概率用了比较成熟的 load balancing 策略和针对性的专家初始化手段。同时也得提醒一句MoE 模型在单步推理速度上不一定比同参数量级的密集模型快因为路由计算和专家通信也需要时间。它的核心优势是性价比而不是绝对延迟。如果你的场景是高频短对话、每轮只有几十个 token那 MoE 的收益可能没那么明显但如果你做的是长程多步任务优势就会被放大。3. 长程智能体为什么它是关键场景3.1 长程任务的痛点上下文、推理链、工具调用长程智能体long-horizon agent到底是什么简单来说就是让 AI 去执行一个需要很多步骤、持续很长时间、可能要跟外部工具多次交互的任务。比如帮我把这个数据库里的十万条记录按规则清洗然后对清洗后的数据做统计分析再根据分析结果生成一份可视化报告最后自动发送给相关同事——这就是一个典型的长程任务。这类任务对模型的要求极高原因有三。第一上下文很长。任务过程中会产生大量中间结果、工具返回值、以及多轮对话历史模型必须有很强的长文本理解能力不能看后面忘前面。第二推理链很长。模型需要从初始目标出发连续规划出几十个甚至上百个步骤每步都要保证和最终目标一致不能跑偏。第三工具调用频繁。每一步都可能触发一次 API 调用或代码执行模型需要准确理解工具返回的内容并基于这些内容做下一步决策。传统的密集模型哪怕能力再强只要上下文一长、步骤一多就很容易出现迷失目标的问题。尤其是到了几百 K token 的上下文里模型经常会把早期的指令忘掉或者被工具返回的噪声信息带偏。这也是为什么长程智能体领域一直缺少一个又便宜又能打的模型——不是能力不够就是成本失控两者能同时做好的非常少。3.2 Step 5 Preview 在长程任务上的实际表现Step 5 Preview 在这个场景上的优势主要体现在两个层面。一个是模型本身的推理和规划能力足够强能支撑长时间的连贯思考另一个是激活参数少导致推理速度快、成本低可以将更多的算力预算投入到反复试错和多轮规划中。这一点非常重要。长程智能体任务的成本往往是任务完成成功率和单步推理成本的乘积。如果模型不够聪明需要试很多次才能成功那么就算单步很便宜总成本也降不下来。反过来如果模型够聪明单步成本又不高那么总成本就会非常好看。阶跃星辰公布的数据里提到Step 5 Preview 在长程智能体场景下把单任务成本砍到原来的 1/8这个数据翻译成人话就是你以前花 8 块钱干完的活现在 1 块钱就能干完而且干的还好。这种又便宜又好的组合在 AI 领域其实是很罕见的因为它需要同时满足模型性能和推理效率两个条件本质上是一种帕累托改进。我在实际跑测试任务时也有类似的体感。以前用一些同级别开源模型做客服工单自动分类加流转20 步以内的任务还好超过 30 步之后模型就开始出现遗忘前提的问题经常要人工兜底。换到 Step 5 Preview 之后我特意设计了一个 60 步的流程型任务包括查库存、生成订单、计算物流时效、校验优惠券状态等最后它基本全程没跑偏而且每步之间的决策速度也快了不少。3.3 帕累托奇迹的本质帕累托改进的原始定义是在不损害任何一方利益的前提下让至少一方变得更好。在 AI 模型的语境下这个双方就是性能和成本。传统思路里性能和成本总是一个 trade-off你要性能好就得花更多钱你想省钱就得接受更弱的效果。大多数人默认这个权衡是铁律。Step 5 Preview 打破了这个铁律。它在把成本砍到 1/8 的同时性能不降反升尤其是在长程智能体这个最难啃的骨头上做到了开源前三。这就形成了一个双赢的局面——性能赢、成本也赢。所以我说它是帕累托奇迹不是说它突破了物理学定律而是说它用架构和训练的优化把大家习以为常的 trade-off 往前推了一大步。这个意义不止停留在实验室。放在产业落地角度看长程智能体一直被认为是 AI 真正干活的核心能力。如果每个长程任务的执行成本能降低 8 倍那么以前算不过来的账、跑不起的应用现在都能重新算了。Agent 应用从演示级走向生产级可能就差这样一个成本上的拐点。我记得之前团队里评估过一个自动巡检方案就是因为推理成本太高被否了如果用 Step 5 Preview 重新评估很可能就能过审立项。4. 开源影响力全球开源前三意味着什么4.1 从开源社区的视角看这个发布开源模型之间的竞争这两年其实已经白热化了。头部几家各有各的拥趸有的靠生态整合有的靠学术影响力有的靠极致性价比。现在阶跃星辰也挤进来了。开源模型之间的差距越来越小谁能做到更便宜、更好用、更开放谁就能获得更多开发者的信任。Step 5 Preview 能在开源社区拿到前三对开发者来说最直接的信号是又多了一个可以放心选型的底座模型。而且它不是一个只能看不能跑的模型——27B 激活参数的部署门槛意味着很多中小团队也能跑得起。这是开源模型社区最乐见的场景参数规模足够大、知识容量足够广但部署成本足够低普通团队不需要凑 8 张 A100 才能玩。另外从开源协议上看阶跃星辰这次给的条件也比较友好。宽松的商用许愿意味着企业可以拿它做商用产品而不需要把自家代码开源。这种模型开源商用授权宽松的做法对孵化 Agent 创业项目非常有吸引力。和几个做 agent 的同行聊下来大家的第一反应基本一致先拉下来跑一版看效果如果真和公布的水平吻合下一步就是认真研究怎么替换现有底座。4.2 对开发者选型和生态的实际影响如果你正在做智能体相关的产品现在选型会比几个月前从容很多。过去你要么选闭源 API成本高、可控性差要么选开源密集大模型部署贵、时间长。Step 5 Preview 给了一个新的中间地带开源的权重、相对低的部署成本、强到能打长程任务的性能。我个人的判断是如果后续正式版能保持这个性能水平同时把生态工具比如推理框架的适配、微调脚本、量化方案补齐它会在很长一段时间内成为长程智能体领域的默认底座。就像当年的 BERT 之于 NLP、CLIP 之于多模态那样一个强力的开源底座会带动整个生态的爆发。不过也要泼一盆冷水开源生态的繁荣不只是靠一个模型 weights 放出来就行的。它需要推理框架的深度优化、社区贡献者帮忙做各种语言版本的适配、行业标杆项目拿它做出可复制的样板。这些都需要时间。Step 5 Preview 现在拿到了一个很好的起点但能不能真正撑起生态还要看后续几个月的社区反馈和迭代速度。5. 实操参考从下载到跑通长程任务5.1 部署前的准备和硬件评估虽然 27B 激活参数的推理成本不高但 600B 的总权重还是意味着你需要认真规划部署方案。我建议先想清楚两点一是你的场景是不是真的需要 600B 级别的知识容量二是你的推理负载是实时在线还是离线批处理。如果是离线批处理场景比如把长程任务分批跑完那么对延迟要求不高可以在多卡环境下慢慢跑。如果是实时在线场景比如用户交互式的 agent 应用那你得优先考虑用 vLLM 或 SGLang 这类支持 MoE 的推理框架并且把 KV cache 和前缀缓存打开。MoE 模型在推理时有个特点路由计算和专家并行的调度开销不小如果推理框架对 MoE 支持不好性能会大打折扣。硬件方面参考配置大概是4×A100 80G 起步或等价的 H 系列用张量并行 专家并行来切分 600B 权重。如果想进一步省显存可以试试 FP8 量化。不过这里我建议务必先跑一段评测确认量化对长程任务输出质量的影响可接受后再上线。降精度换来成本这个 trade-off 要自己把握。5.2 长程智能体场景中的参数配置建议在实际调用时有几个参数对长程任务质量影响很大。第一个是 max_tokens。长程任务往往需要很长的输出如果你的 max_tokens 设得太小模型会在思考到一半时被截断。保守起见建议在 8000 以上具体看任务复杂度。第二个是 temperature。长程任务和普通对话不同稳定性比创造性更重要建议设在 0.3~0.7 之间不要拉太高。第三个是 top_p配合 temperature 一起调一般 0.8 左右比较稳。还有一个容易忽略的是系统提示词system prompt的设计。长程智能体任务里系统提示词相当于给模型立的总章程。你最好把任务目标、可调用的工具清单、输出的格式要求、遇到异常时的处理策略都写清楚。Step 5 Preview 的指令跟随能力很强给它一个结构化、清晰的系统提示词它能执行得更精确。我自己的模板大概长这样开头先写角色定位接着是任务目标越具体越好然后是可用工具和每个工具的调用格式再往下是输出规范比如要求 JSON 格式、字段名定义最后是异常处理策略比如拿不到数据时怎么办。这套模板我用了很多模型Step 5 Preview 是响应得最稳定的之一尤其在长任务中它能时刻记着我的最终目标是什么。5.3 常见问题与排查技巧我在试用过程中碰到过几个问题列出来供大家参考。第一个是模型到后半程开始忘记原始目标。这种情况通常不是模型的问题而是你的 prompt 结构有问题。解决思路是定期把原始目标和已完成的步骤打包进上下文让模型时刻能看到全局进度。你可以写一个简单的状态管理模块每完成几步就把任务进度重新注入一次。第二个是工具返回结果太长导致上下文爆炸。长程智能体任务里工具返回的数据很容易把上下文撑爆。解决方法是先做一轮摘要压缩再让模型基于摘要做决策。Step 5 Preview 的文本理解能力够强给它压缩过的信息它照样能处理好。第三个问题是显存不够但不想减并发。这种情况我建议开前缀共享prefix caching把系统提示词和任务开头的公共部分缓存住能显著降低长上下文场景的显存压力。如果还是不够再考虑量化或减少 batch size。第四个问题是路由负载不均衡。MoE 模型在同一批次里如果任务类型差异很大容易出现某些专家被频繁调用、另一些专家闲置的现象。这在 Step 5 Preview 上不算严重但我遇到过 batch size 拉满后单步延迟突然变高的情况。排查思路是先降低 batch size再看是不是专家并行配置不合理必要时调整并行切分方式。5.4 一套快速跑通的最小方案如果你只是想知道这个模型到底适不适合我的任务我建议按这个最小方案来试第一步先在 Hugging Face 或 ModelScope 上把 Step 5 Preview 的权重拉下来。第二步用 vLLM 起一个 OpenAI 兼容的推理服务因为 vLLM 对 MoE 的调度优化比较成熟起步快。第三步写一个简单的 agent 脚本接上你的工具函数跑一个 20 到 30 步的任务看效果。第四步把 temperature 设为 0.5、top_p 设为 0.8、max_tokens 设为 4096先固定这组参数跑通再逐步调整。这套流程下来你大概半天就能判断这个模型适不适合你的场景。如果跑出来的效果确实比现在用的模型好再考虑上多卡部署和框架优化不迟。6. 个人经验与后续扩展我自己在实际测试 Step 5 Preview 跑长程任务时最明显的感觉是它不会在中途莫名其妙地放弃。之前我用很多开源模型经常在跑到第 20 步左右开始丢三落四要么忽略某个约束要么重复执行某个工具调用。Step 5 Preview 的稳定性确实明显高了一截。最后分享一个小技巧长程智能体场景下别只在离线数据上测指标。我建议你把模型接到真实的工具链里跑一遍端到端流程因为很多评测数据测的是模型会不会做这道题而真实场景测的是模型能不能把这个活干完。这两个维度差异非常大只有端到端跑一遍你才真正知道这个模型适不适合你的任务。如果后续正式版发布我最期待的是两个点一是长程智能体的评测分数还能不能继续往上走二是生态工具能不能快速跟上。如果这两点都做到了我相信 Step 5 Preview 会成为开源社区里一个里程碑式的存在。到时候我们再回头来看这次600B 参数只激活 27B的发布会更有历史感。