★ FEATURED ARTICLE 这几年我一直盯着开源模型的一个指标激活参数。跑分看多了你就会发现同一个体量的模型真正决定你推理账单的不是那串总参数字而是每次前向计算到底要动多少参数。阶跃星辰 Step 5 Preview 放出600B 参数、仅激活 27B的时候我确实停下来多看了一眼——总参和激活参的比例接近 22:1这种稀疏度放在整个开源阵营里都属于非常激进的设计。官方宣传里还有一句更吸引做 Agent 的人的话单任务成本砍掉 8 倍。这不是一个单纯的跑分新王故事。Step 5 Preview 真正有意思的地方在于它把 MoE 的稀疏性和长程智能体Long-Horizon Agent这种又长又贵的任务类型结合起来了任务越长模型调用次数越多单次推理成本下降带来的总账收益就越夸张。再加上它在多个第三方榜单上的开源排名冲进了前三很多人在问这到底是营销话术还是工程上真的出现了成本和效果的帕累托奇迹这篇文章不打算复述发布会上的跑分表。我更想把做 Agent 选型时拆解 Step 5 的思路、部署判断和踩坑记录完整写出来给同样在做长程智能体、主攻开源模型落地的团队一个参考。1. 600B 只激活 27B的架构拆解MoE 激进稀疏度背后的工程逻辑1.1 先搞清楚 MoE 到底靠什么省钱先给新接触 MoE 的朋友补个背景。MoEMixture of Experts混合专家和普通稠密模型最大的区别在于稠密模型每次推理必须把全部参数都算一遍MoE 模型则把网络拆成很多专家子网络每次推理由一个路由网络决定只派出其中少数几个专家干活。拿公司举例子稠密模型是一个 600 人的公司每次开会 600 人全部到场MoE 是一个 600 人的公司每次开会只有 27 个人被点名参加其余人继续做自己的事。总人数决定了这个公司的知识储备上限实际开会的人数决定了每次会议的成本和速度。600B 总参、27B 激活的含义就在这里模型中虽然存了 600B 参数的知识但每一步推理只会真正计算 27B 参数对应的那部分网络。每次计算的开销大致和一个 27B 稠密模型相当而知识容量和表达能力的天花板却接近 600B 模型。这就是 MoE 省钱的第一层原理。1.2 22:1 的稀疏比例有多激进不过MoE 也不是把稀疏比例做得多高都行。专家太多、激活太少路由网络就要在数百个专家里做非常精准的选择一旦选错专家模型输出的质量会明显下降。我整理了一下目前开源阵营里几个代表性 MoE 模型的总参/激活比例模型总参数量激活参数量稀疏比例总/激活DeepSeek V3671B37B约 18:1阶跃 Step 5 Preview约 600B约 27B约 22:1Qwen3-30B-A3B约 32B约 3B约 10:1Mixtral 8x7B约 47B约 13B约 3.6:1这样对比就很直观Step 5 Preview 的稀疏比例在开源大模型梯队里是最激进的一档。DeepSeek V3 已经很激进了Step 5 在此基础上又把激活参数往下压了约 10B。这意味着它的单次推理 FLOPs 比 DeepSeek V3 更低但对路由精度、专家分工质量和训练稳定性的要求也更高。这里有两件事值得注意。第一MoE 的性能上限主要取决于总参数量承载的知识密度和路由的选择质量而推理成本下限主要取决于激活参数量和 attention 开销。Step 5 把激活参数压到 27B相当于把成本下限压得很低。第二这种激进稀疏通常需要配合更细粒度的专家切分、更高质量的训练数据和更长时间的路由收敛训练不然专家的利用率会很不均衡经常出现少数专家累死、多数专家摸鱼的情况。1.3 为什么以前没人把稀疏做得这么狠其实业界不是不想把稀疏比例拉高而是做过尝试之后发现存在收益递减。专家切得越碎、激活得越少路由网络的选择就越容易出错。8 个专家里你只激活 1 个稍微分心一下答案就飘了。所以早几年的 MoE 模型往往保持在 1:3 到 1:10 左右的稀疏度兼顾速度和稳定。Step 5 敢把比例拉高到 22:1说明它在训练阶段大概率做了三件事一是大幅提升路由网络的分配精度让开会点名更聪明二是用更强的基座模型做冷启动而不是从随机初始化硬训三是在后训练阶段用大量推理任务做了针对性对齐把长程推理的短板补回来。这些方向虽然没有被官方逐条明说但从架构选择和公开发布的技术文档里能看出端倪。理解这一点很重要激进稀疏不是简单的省钱工程它背后其实是一整套训练策略的取舍。1.4 从 FLOPs 角度看真实收益为什么说激活参数决定了推理成本的大头在一个典型的 Transformer MoE 层里前向计算主要分两块attention 部分和 FFN/专家部分。FFN 部分的计算量与激活参数强相关你激活多少专家就计算多少参数attention 部分主要跟序列长度和头数有关和激活专家数基本没关系。考虑到长程智能体任务通常要处理很长的上下文attention 在总 FLOPs 中占比也不小所以 27B 激活带来的实际推理加速并不能达到600/27 约等于 22 倍这么理想。但综合下来单次前向成本比同量级稠密模型低一个数量级是能达到的。官方宣传单任务成本砍 8 倍从量级上看逻辑是成立的。2. 长程智能体的账单单任务成本 8 倍下降是怎么被放大的2.1 先算一笔长任务的总账我们要先理解长程智能体和普通单轮问答的区别。单轮问答你只调用一次模型成本再高也就是一次的钱但长程智能体任务可能是先让模型制定计划再让它搜索资料然后让它写代码验证中途可能还有多轮自我反思、工具返回结果解析、失败重试。我做过一个从零搭建一份数据分析报告的 Agent 演示单次完整任务下来模型被调用了 47 次生成的总 token 数在 10 万上下。如果这个模型单次推理价格贵 8 倍整个任务下来就是差 8 倍的真金白银。如果你在做的是每天跑几千次这种长任务的业务系统这个差距换算成年账单是非常恐怖的。这里的8 倍还有另一层放大效应长程任务的失败成本。任务越长中途任何一步模型犯迷糊都可能导致整个链路重来或者更糟——带着错误结论继续往下跑。所以长程智能体对底座的稳定性要求极高需要的是每一步都不掉链子的稳健模型而不只是单点能力爆表的模型。这也是为什么长程智能体场景特别看重推理稳定性和上下文一致性Step 5 这种激进 MoE 架构要是能把稳定性和成本同时做好确实很有吸引力。2.2 成本降低的三个物理来源单任务成本降下来物理来源可以拆成三块计算量下降激活参数从几百亿降至 27B单次前向的 FLOPs 大幅下降推理时延和算力成本同步降低。吞吐提升同样的 GPU 集群单位时间可以并行处理更多请求均摊到每个任务的固定成本电力、部署、运维也降了。KV Cache 管理效率长上下文任务中KV Cache 的大小往往成为瓶颈。Step 5 这类模型的上下文记忆管理如果在架构上做了优化可以在不损失信息的前提下缓解显存压力进一步放大长任务的吞吐优势。这三个来源叠加长任务的整体账单确实能达到接近一个数量级的下降。我自己的体感是单看单次推理 API 价格可能只有 2-3 倍差异但到了长程任务这种高频调用 长上下文的场景综合成本差可以拉得非常开8 倍不是夸张描述。2.3 帕累托奇迹的成立边界聊帕累托之前先给不熟悉这个概念的同学解释一下如果一种改变能让至少一方变好同时不损害任何其他方的利益那它就是一种帕累托改进。放在模型选型语境里通常我们默认能力和成本是一对矛盾想要更强的模型就要付更高的推理成本。但一个模型如果用更低的成本提供接近顶级模型的能力在成本维度上就是巨大的帕累托改进——用户不需要牺牲效果直接省下预算。Step 5 Preview 被说成帕累托奇迹在我看来是有前提条件的它相对的是同量级的稠密模型或者同等能力档位的云端大模型。它并没有在所有任务上都超过纯稠密的千亿头部模型在特别需要极致复杂推理的某些任务上可能还有差距。但它的意义恰恰在于长程智能体这类高频调用、长序列、容错率要求高的任务往往不需要极限知识记忆而更需要稳定、快速、便宜的持续推理。在这种任务画像下Step 5 的能力和成本确实同时优于很多旧选项帕累托改进是成立的。任务画像典型例子Step 5 适用性短问答、简单任务单轮问答、翻译优势不明显可能不如小模型长上下文阅读多文档问答、报告生成很合适长上下文 低成本多轮工具调用网页搜索、API 调用型 Agent非常合适推理稳定性和成本兼顾极限数学/代码竞赛高难度竞赛题要看具体评测和顶级推理模型有差距高并发批处理大规模数据清洗很合适吞吐优势明显3. 开源前三的含金量Step 5 到底在跟谁比3.1 先搞清楚榜单在排什么开源前三这个说法不同榜单口径差很多。有的榜单看综合能力比如 LMArena 这种人类偏好投票有的看纯数学代码能力比如 AIME、LiveCodeBench有的看 Agent 场景表现。Step 5 Preview 发布后在多个第三方综合榜单上确实进入过开源模型的前三——通常是和 DeepSeek、Qwen 系列并列。但这里有个容易被忽略的点如果你点进去看细分维度它可能数学不如某些专攻推理的模型代码也不一定每个专项都第一真正拉高它综合排名的是均衡稳定、以及长文本和多轮指令跟随表现。所以我的建议是不要只盯着前三这个名次要看名次背后的能力结构。如果某个榜单把多轮指令跟随、长文档问答、结构化输出都算进综合项那 Step 5 的高排名是有含金量的因为长程智能体要的就是这些能力。如果只是单点跑分参考价值就有限。3.2 和 DeepSeek、Qwen 的定位差异我把目前最常拿来对比的几个开源模型列了个对照表从做 Agent 的视角看更实用模型架构长上下文工具调用综合推理部署门槛DeepSeek R1 / V3671B MoE、37B 激活128K 级别良好推理极强高Qwen3 系列混合含 MoE 小模型128K-256K 级别很强均衡中Step 5 Preview约 600B MoE、27B 激活256K 级别针对 Agent 优化强高GLM-4.5大参数稠密/混合长文本强强均衡中做 Agent 选型时我一般会这样判断如果任务重点是复杂推理链、允许较高成本DeepSeek 的推理盘面依然有优势如果任务是多样化的通用 Agent且调用频次高、预算敏感Step 5 的27B 激活就体现出明显性价比如果任务需要很强的中文生态配套Qwen 系列会更顺。Step 5 的核心竞争力是在长程智能体高频调用场景下用更少算力维持住高阶模型的稳定度。3.3 我在 Agent 场景里的实际观察我不完全按照公开榜单下结论。自己在一些长程任务上做了简单对比后我的体感是Step 5 在中长程多 Agent 协作任务里指令跟随的稳定性和格式输出的规范程度是最突出的两个点。长任务跑下来部分模型会出现中途丢任务目标工具调用返回格式乱掉的问题Step 5 在这些环节上的容错率明显好一些。这跟它的后训练方向是吻合的——它明显不是奔着难倒人类专家去的而是奔着在真实生产环境里长时间不犯错去的。当然我也遇到一些相对短板。比如在某些非常高难度的代码推理题上它不如专攻推理的模型直接在少样本学习类的任务上它的发挥不如同体量稠密模型稳定。这就要回到你的任务画像来判断没有哪个模型适合所有场景但 Step 5 确实把长程稳定 低成本这个组合拳打到了开源模型的第一梯队。4. 部署与选型我实测下来的工程判断4.1 600B 模型部署的真实门槛先说一个最常见的误区很多人看到27B 激活以为它可以用一张 80G 显卡跑起来。实际上权重加载是按总参数量走的600B 参数意味着完整的权重文件非常庞大所有专家都必须放进显存才能动态路由。我做了一个粗略的显存估算FP8 量化版本约 600GB 权重推荐至少 8 卡 H100/H200单卡 80G 以上或者 16 卡 A100 80G。INT4/INT8 混合量化权重可以压到 300GB 左右但 MoE 模型的量化对路由和专家精度更敏感需要谨慎压位宽。再加上 KV Cache处理长上下文时KV Cache 本身可能就会吃掉几十到上百 GB 显存这部分很容易被低估。所以如果你想本地部署 Step 5预算门槛基本在 8 卡 H100 这个量级如果没有这个条件优先考虑 API 服务而不是想在消费级设备上强行跑起来。做长程智能体项目资源规划一定要把权重 KV Cache 推理引擎 overhead三块都算进去只算权重会吃大亏。4.2 API 调用还是私有部署做这个选择题我一般会按四象限来判断任务频次低、数据隐私要求高可以用 API 加私有加固或者专有云实例。任务频次高、数据敏感、需要内部审计私有部署投入硬件成本。任务频次高、数据不敏感、要快速上线API 优先先验证业务价值再考虑迁移。任务频次低、数据不敏感直接 API别折腾运维。对于长程智能体团队我的建议永远是先 API 跑通再私有化。长程任务的问题通常不在单次推理质量而在整个链路的稳定性。先用 API 把链路逻辑调通采集真实的成本数据和错误分布再决定要不要花大价钱私有化。盲目一步到位私有部署 600B 模型最后很容易死在一堆工程细节上比如推理引擎版本兼容、多卡通信优化、专家负载均衡等等。4.3 接入 Agent 框架时值得提前设计的配置细节如果决定上 Step 5接入 LangGraph、自研框架或者直接裸调 API有几个配置细节值得提前设计上下文预算管理长程任务很容易把上下文撑爆。我会在代码里维护一个对话窗口压缩器当上下文超过阈值时主动摘要旧内容再继续而不是把几千条历史全部塞给模型。工具调用格式Step 5 对结构化工具调用支持得不错但不同框架的 function calling schema 和模型训练时用的格式可能不一致。我建议先用官方文档里的 prompt 模板做 warmup 测试确认解析结果稳定后再接入自己的解析层。重试和降级策略MoE 大模型在高并发下可能出现偶发的不稳定输出Agent 链路里一定要设计重试机制。我一般设置 2 次自动重试 1 次降级切换到小模型完成兜底步骤这样任务成功率能稳定在 95% 以上。4.4 长程智能体任务里的成本优化习惯多轮调用时如果每次都让模型重新读一遍上下文成本会直线上升。我的习惯是把长任务拆成短期内存 长期存储工具返回结果先落地到本地结构化缓存不要全部塞回 prompt。保留一份任务目标摘要和一份已完成步骤日志每次只把增量内容和摘要发给模型。使用 prefix caching 能力如果推理服务支持把重复前缀缓存住长任务的 token 成本能再降一档。这些实践不绑定特定模型但如果你把 Step 5 当作长程底座配合这些优化单任务成本会比裸调再低不少。长程智能体项目拼到最后往往不是模型能力问题而是成本工程问题。5. 三个容易踩的坑以及我的应对方式5.1 激活参数少不等于显存占用少前文已经提过一次但值得单独拿出来强调600B 总参、27B 激活指的是计算时的参数参与情况不是存储时的精简。部署时所有专家权重都必须驻留在显存中否则每次路由都要去外部存储加载专家延迟会高到不可接受。我做资源评估时都会直接按总参数量乘以字节数来估算底线显存再往上加 KV Cache 余量而不是按激活参数算。这一点如果搞错预算偏差会非常夸张。5.2 MoE 路由在高并发下的波动性MoE 模型在消费级单卡上的输出不一定稳定因为 expert 的选择会在不同 batch 间出现负载不均衡极端情况下同一个 prompt 连续调用两次结果差异可能比稠密模型更明显。这在高并发推理集群里尤其常见。我吃过一次亏批量任务跑到一半发现某些请求的响应质量突然下降排查半天才发现是请求被路由到了过载的专家分片。后来我做了两件事一是加请求级重试二是在 Agent 链路里给关键步骤设计交叉验证——同一目标任务用不同 prompt 表述跑两次结果一致才继续。虽然多花了点 token但长任务整体成功率提升明显。5.3 别在所有任务上都套大而稀疏的模板最后想提醒的是Step 5 的性价比优势是有边界的。在纯短问答、简单分类、轻量信息抽取这类低难度高频任务上一个 7B-14B 的小模型反而更快更稳成本也低得多。把 600B 级模型用在简单任务上就像开大卡车去巷子里买菜油耗高还不好调头。做项目选型时最科学的方式是分层调度复杂长程步骤用 Step 5 这类高阶模型简单步骤用中小模型兜底这样才能把成本优势真正放到最大。我在实际项目里的做法是三层路由先用一个轻量分类器判断任务难度简单问题直接交给 7B 级小模型中等复杂度的工具调用交给中型模型只有那些需要长程推理、多轮工具联动、上下文跨度大的任务才真正落到 Step 5 这种 600B 级底座上。这样跑下来整体账单比全链路都用大模型低 3 到 5 倍而任务成功率几乎没有下降。模型选型这件事终究不是选最强的那个而是选最合适的那组。
阅读完成 · 觉得有帮助？
