最近开源社区好不热闹，各路人马都在把头部的开源模型往"最强底座"的位置上推。但说实话，我第一眼看到"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），而是采用了混合专家架构，也就是 MoE（Mixture 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 参数如何只激活 27B
2.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"的发布，会更有历史感。
