600B参数仅激活27B，激进MoE如何降低长程智能体成本？

这几年我一直盯着开源模型的一个指标：激活参数。跑分看多了你就会发现，同一个体量的模型，真正决定你推理账单的不是那串总参数字，而是每次前向计算到底要动多少参数。阶跃星辰 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 的朋友补个背景。MoE（Mixture of Experts，混合专家）和普通稠密模型最大的区别在于：稠密模型每次推理必须把全部参数都算一遍；MoE 模型则把网络拆成很多"专家"子网络，每次推理由一个路由网络决定只派出其中少数几个专家干活。

拿公司举例子：稠密模型是一个 600 人的公司，每次开会 600 人全部到场；MoE 是一个 600 人的公司，每次开会只有 27 个人被点名参加，其余人继续做自己的事。总人数决定了这个公司的"知识储备"上限，实际开会的人数决定了每次会议的成本和速度。

"600B 总参、27B 激活"的含义就在这里：模型中虽然存了 600B 参数的知识，但每一步推理只会真正计算 27B 参数对应的那部分网络。每次计算的开销大致和一个 27B 稠密模型相当，而知识容量和表达能力的天花板却接近 600B 模型。这就是 MoE 省钱的第一层原理。

1.2 22:1 的稀疏比例有多激进

不过，MoE 也不是把稀疏比例做得多高都行。专家太多、激活太少，路由网络就要在数百个专家里做非常精准的选择，一旦选错专家，模型输出的质量会明显下降。我整理了一下目前开源阵营里几个代表性 MoE 模型的总参/激活比例：

这样对比就很直观：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 的能力和成本确实同时优于很多旧选项，帕累托改进是成立的。

3. 开源前三的含金量：Step 5 到底在跟谁比

3.1 先搞清楚榜单在排什么

"开源前三"这个说法，不同榜单口径差很多。有的榜单看综合能力，比如 LMArena 这种人类偏好投票；有的看纯数学代码能力，比如 AIME、LiveCodeBench；有的看 Agent 场景表现。Step 5 Preview 发布后，在多个第三方综合榜单上确实进入过开源模型的前三——通常是和 DeepSeek、Qwen 系列并列。

但这里有个容易被忽略的点：如果你点进去看细分维度，它可能数学不如某些专攻推理的模型，代码也不一定每个专项都第一，真正拉高它综合排名的是"均衡稳定、以及长文本和多轮指令跟随表现"。所以我的建议是：不要只盯着"前三"这个名次，要看名次背后的能力结构。如果某个榜单把多轮指令跟随、长文档问答、结构化输出都算进综合项，那 Step 5 的高排名是有含金量的，因为长程智能体要的就是这些能力。如果只是单点跑分，参考价值就有限。

3.2 和 DeepSeek、Qwen 的定位差异

我把目前最常拿来对比的几个开源模型列了个对照表，从做 Agent 的视角看更实用：

做 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 倍，而任务成功率几乎没有下降。模型选型这件事，终究不是选最强的那个，而是选最合适的那组。