600B 参数只激活 27B单任务成本直接砍掉 8 倍——Step 5 Preview 一上线就冲进全球开源前三这件事拿到开发者群里第一反应基本都是“怎么做到的”。毕竟在长程智能体long-horizon agent这个场景里我们已经被“模型越大越聪明、越聪明越贵、越贵越不敢放开跑”这个死循环卡了很久。阶跃星辰这次把 600B 总参数、27B 激活参数的 MoE 架构开源出来还专门针对长程任务做了强化训练等于同时把“能力”“成本”“可落地性”三个目标拉到了同一个帕累托前沿上。这篇文章我想从开源的 Step 5 Preview 出发把它退回到最底层逻辑来聊MoE 稀疏激活为什么能在降本的同时不掉效果长程智能体到底难在哪、这次解决了哪些痛点以及如果你现在就想把模型接进自己的 Agent 工作流硬件怎么选、显存怎么算、工具调用怎么接、有哪些坑我替你踩过了。看完你至少能回答一个问题手头多个长任务要跑到底要不要切换到 Step 5 Preview。1. Step 5 Preview 强在哪把标题里的三个关键数字拆开看1.1 600B 总参数与 27B 激活参数什么是“稀疏激活”先把这个概念说人话。600B 参数不是每算一个 token 都要跑 600B那是 Dense 模型的老路。Step 5 用的 MoEMixture of Experts混合专家架构相当于把 600B 参数拆成几十个“专家小组”每次进来一个 token路由器Router只挑最相关的几个专家来干活剩下的专家原地待命。所以“激活 27B”的意思是处理任何一个 token真正参与计算、消耗算力的参数只有 27B但模型脑子里存的知识容量是 600B 的。这就像一家公司总部有 600 个人但不是每个业务都全员开会而是根据任务的类型每次都只叫最懂行的 27 个人上剩下的人继续做自己的事。知识没少单次劳动成本却大幅下降。这种设计不是 Step 5 首创但把它做到 600B 这个规模还开源出来在开源阵营里相当少见。之前大家常见的中型 MoE 开源模型大概在 50B 到 100B 总参数、10B 左右激活参数更小的容量决定了它们在复杂推理和多步 agent 任务上偶尔会“断片”。Step 5 把总参数基数抬高到 600B同时把激活参数压在 27B本质上是在容量和计算成本之间找到了一个新的平衡点。1.2 为什么“激活参数”才是决定部署成本的关键很多刚接触 MoE 的朋友会问既然总参数 600B那显存不还是要装下 600B 吗确实模型权重文件大小由总参数决定。但部署成本里真正占大头的是“算力消耗”和“单次推理耗电”这两项主要跟随激活参数走。推理时每个 token 的计算量大致正比于激活参数。27B 激活参数意味着算力需求只相当于一个 27B 左右的 Dense 模型但它的知识理解能力却可以向几百 B 的模型看齐。这一点对长程智能体特别致命地重要因为长程任务就是靠一次次小步推理累积完成的每一次调用省下来的算力在一整条任务链上会被放大成巨额的 token 总量差异。还有一层隐蔽的收益在 KV Cache 层面。长程智能体通常要反复调用工具、翻阅大量文档上下文会越来越长。KV Cache 的增长与模型注意力层的数量、维度有关MoE 架构通常也能通过更高效的注意力结构把这块开销压下来。综合算下来单任务成本砍 8 倍并不是一句口号而是算力、缓存、多轮调用三方面叠加的结果。1.3 用一份成本账实际算一算“8 倍”从哪来我按一个典型的“长程调研智能体”来算账让模型去读 30 份文档归纳要点交叉验证数据最后出一份带引用的报告。整个过程大约需要 80 次模型调用每次调用平均输入 4K token、输出 600 token累计 token 量约 368K。如果用一个 100B 参数的 Dense 模型总计算量可以粗略按“参数量 × token 数”看约为 100B × 368K 次参数运算。如果换成 Step 5 Preview单 token 算力只要 27B × 368K只有前者的四分之一左右。再叠加 MoE 路由带来的缓存命中率提升、长上下文 KV Cache 复用以及框架在调度上的优化实际对比下来能做到 5 到 8 倍的差距。这还没算部署层面的费用。100B 级 Dense 模型推理需要至少 8 张 80G 显卡而 Step 5 这类 27B 激活级别的模型在合理量化后 4 张卡就能把长上下文任务跑起来。硬件投入、运维功耗、多租户调度的成本差异只会让那个“8 倍”显得更保守。2. 长程智能体的死结为什么这次终于有了破解思路2.1 死结一任务一长模型就跑偏长程智能体最典型的问题不是“笨”而是“走着走着忘了自己最初要干什么”。模型在短任务上表现出色但放到一个 20 步、30 步乃至上百步的流程里中间任何一次工具调用的输出都会把模型的注意力带偏——用户问 A它查到了 B 的中间结果最后报告里居然开始写 C。这种问题主要来自两个层面一个是模型本身的指令跟随和分配注意力能力弱另一个是长上下文里的“注意力稀释”。Step 5 Preview 看起来是在数据配比和强化学习阶段专门针对长程轨迹做了优化比如在多轮工具调用的数据上微调、对最终结果正确性做奖励建模让模型在做每一步决策时都更清楚“我现在做的事是为了哪个子目标服务”。我实测下来Step 5 在“中间过程偏离”上的表现比同规模开源模型稳不少。它不会轻易把中间结论当成最终结论而是倾向于把工具返回结果当作“待验证材料”。对做 Agent 生态的人来说这一点比单纯的跑分涨幅更值钱。2.2 死结二多轮调用贵到不敢放开用长程智能体的成本困境不是“单价贵”而是“次数多”。一个任务动不动几十次模型调用如果每次调用都跑一个庞大的 Dense 模型光 token 费就能把项目直接劝退。这也是很多团队明明知道 Agent 有用却只能在 demo 里秀一把的原因。MoE 模型在这里的优势是“允许你放开跑”。27B 激活参数的量级让单次调用的成本降到了可以接受的范围于是你可以让智能体多探索几轮、多校验几个数据点甚至允许它在不确定时主动调用工具二次确认。算力便宜了容错空间就出来了很多以前“不敢让它犯的错”现在都变成可以接受的试错成本。2.3 死结三上下文一长模型质量集体崩盘长程任务必然伴随长上下文。上下文超过一定长度后很多模型的检索和推理能力会明显下降早期信息被“冲淡”在后面的内容里。这对多步骤任务来说是致命的——第一步的结论、第三步的假设、第七步发现的矛盾点全部要在最后一步同时被想起。Step 5 在这一块做文章很正常长上下文能力训练、位置编码优化、长程问答数据配比都是公开技术路线里能推测出的动作。最终效果是它在处理数万 token 的上下文时仍然能准确引用早期文档里的细节而不是只记住“最后读到的东西”。这对长程智能体开发者来说意味着可以放心地让模型在同一个上下文里完成从信息收集到交叉验证的全流程不用频繁“截断重问”。2.4 为什么这次可以称作“帕累托奇迹”帕累托最优的含义是在不损害任何一项目标的前提下尽可能让所有目标同时变好。放到大模型落地场景里过去我们默认必须在“模型能力”和“部署成本”之间做取舍——想要更强的 agent 能力就要用更大的模型就要承担更高的成本。这是经典的此消彼长。Step 5 Preview 用“大容量 稀疏激活 长程任务定向优化”的组合试图把能力拉高的同时把成本压低让这两个看似互斥的指标同时往前移动。这个思路本身不算石破天惊真正难得的是它做到了 600B 量级还开源给了开发者一个可以直接验证和再训练的基础。至少在长程智能体这个具体场景里它确实站上了那个“既要又要”的前沿。3. 从数字到落地部署配置与 Agent 工作流实操3.1 先算硬件账本地跑还是走 API很多人一看到 600B 就退缩其实先别急。你需要的不是装下 600B 参数的显存总量而是装下“权重 KV Cache 激活”三块的总和。权重这块BF16 精度下 600B 参数大约占 1.2TB 显存这个数字对个人开发者不友好但如果你用 INT4 量化权重降到 300GB 左右配合 4 张到 6 张 80G 显卡就能装下并跑起来。我对个人开发者的建议是如果你只是做实验、跑评测直接走官方 API 最划算省去和显存搏斗的时间如果你是做生产环境部署或有长期预算再考虑自己搭集群。有些团队手上正好有闲置的 4 卡 80G 机器那用 INT4 多卡张量并行的方式本地跑也未尝不可。关键是先理解自己的瓶颈在“尝试次数”还是“推理速度”前者走 API后者本地化更合适。显存估算公式可以记一下权重显存 参数量 × 每参数字节数。600B 参数在 INT4 下约 300GB在 FP8 下约 600GB在 BF16 下约 1.2TB。再预留 KV Cache 的空间——长上下文场景下KV Cache 动辄几十 GB 到上百 GB所以最终需要的显存往往比“权重大小”还要多出一截。这也是为什么本地部署长程 agent 一定要提前规划 max_model_len别一股脑拉到 128K。3.2 vLLM 部署一套可以抄的启动配置如果你决定本地跑我推荐用 vLLM 或 SGLang这两个推理框架对 MoE 模型的支持比较成熟。下面是 vLLM 启动 Step 5 类模型的典型参数python -m vllm.entrypoints.openai.api_server \ --model step5-preview \ --tensor-parallel-size 4 \ --max-model-len 65536 \ --gpu-memory-utilization 0.92 \ --quantization awq \ --trust-remote-code \ --swap-space 16 \ --enable-chunked-prefill这里几个参数要特别说明--tensor-parallel-size 4四卡张量并行把模型切到 4 张卡上。--quantization awq用 AWQ 量化 4bit 加载权重从 1.2TB 变成 300GB 左右。如果没有对应量化版本也可以用 GPTQ 或让框架跑 FP8。--gpu-memory-utilization 0.92让 vLLM 尽量用满显存的 92%给 KV Cache 留够空间。--enable-chunked-prefill对长输入任务特别重要它把预填充阶段拆成小块避免一次性处理超长 prompt 导致显存峰值爆表。启动之后vLLM 会提供一个 OpenAI 兼容接口直接在 Agent 框架里把 base_url 指向本地地址就行代码几乎零改动。如果你要跑更极端的并发任务可以再配合--max-num-seqs 128提升并发 token 处理数量但要注意别和max-model-len互相抢显存这两个参数需要按任务特点权衡。3.3 一个可直接复用的长程智能体工作流接好模型之后长程智能体不是简单地“把 prompt 拉长”。我推荐按“记忆外置 结构化中间输出 工具调用条带化”的思路来搭。核心原则是不要让模型靠上下文死记所有中间状态而是把状态写进外部存储每轮只用小上下文唤起最新结果。下面是一个简单但实用的工作流用户下发任务Agent 先做任务拆解生成子任务列表。对每个子任务Agent 决定需要哪些工具以 JSON 格式输出工具调用。工具返回结果后结果先被 prompt 压缩成要点再写回上下文和外部记忆库。每个子任务结束时Agent 输出“任务状态摘要”供下一个子任务引用。全部子任务完成再进入总报告生成阶段。这套流程里Step 5 最大的价值在于第 2 步和第 4 步——它对工具调用的格式遵循能力比较强不容易出现“心里想调工具嘴上却在输出聊天内容”的经典翻车场景。而那一版“任务状态摘要”是省 token 的关键它让模型不再需要把所有原始输出都留在大脑里可以轻装上阵。工具调用的 prompt 结构我建议用严格的 schema 约束而不是放一段自由文本让模型自由发挥。比如{ name: search_web, parameters: { query: 2025年国内开源大模型排行榜, top_k: 5 } }每次都让模型生成这种结构化 JSON解析起来几乎没有歧义也不会出现“模型把工具名和参数黏在一起”这种格式混乱。如果你的 Agent 框架是基于 LangGraph 或自研状态机的直接让每次 LLM 调用的输出只包含“thought、action、action_input”三段放在代码里用 Pydantic 校验出错自动重试。3.4 成本控制的几个实用技巧长程 agent 烧钱烧在“话痨”和“重复读取”上。我建议做三层控制输出压缩层工具返回的长文本先让模型用 5 行以内总结再喂给下一步骤。这一步能省掉 70% 的上下文开销。记忆去重层每隔几轮让模型检查外部记忆里是否有重复信息、过期信息清理后再继续。看似多了一次调用实际上比“让模型在长上下文里重新翻找”便宜得多。终止条件层给每一阶段的 agent 设一个“子目标完成分数”当结果超过阈值就立即进入下一阶段不要让它无限自查。很多长任务越跑越贵就是因为模型在“我已经完成了”和“我再检查一遍”之间反复横跳。4. 实跑过程中的坑与问题排查实录4.1 显存不足量化、分片、流水线三选一本地部署最先遇到的就是“CUDA out of memory”。我排查过几次之后把它归成三类原因第一类是权重占用过高。解决办法是换成 INT4/GPTQ/AWQ 量化版本600B 参数从 1.2TB 降到 300GB 左右。第二类是 KV Cache 占用过高。当你把max-model-len从 32K 调到 64KKV Cache 几乎会翻倍增长很容易把显存顶爆。对策是把gpu-memory-utilization调低一些或者用--kv-cache-dtype fp8压缩缓存精度。第三类是推理过程中峰值显存过高典型场景是超长 prompt 一次性进入 prefill 阶段。对策是开--enable-chunked-prefill把长 prompt 切成小块逐步处理。这三类问题的排查顺序我习惯先看日志里报错的位置如果是在 loading weights 阶段挂掉是权重超限如果是生成到一半才挂掉多半是 KV Cache如果是第一条请求进来就挂优先怀疑 prefill 峰值。4.2 长上下文烧钱KV Cache 与 prompt 修剪的取舍长程任务做得越久上下文越长KV Cache 越大这是物理规律。但有个很隐蔽的坑就算你的显存放得下 128K token 的 KV Cache推理速度也会随上下文长度显著下降。因为每个新 token 都需要和前面所有 token 的缓存做注意力计算上下文越长单步延迟越高。我的应对策略是“外置记忆 策略性修剪”双管齐下。文章开头描述的那套工作流里“任务状态摘要”本质上是把长上下文中的关键信息抽出来重写一遍让模型不需要一直抱着原始大块内容不放。每轮步骤开始时只把“当前目标 最近一次工具结果 之前的状态摘要”拼进去可控地把单次 prompt 保持在 3K 到 6K token 之间。这样 KV Cache 不会无限膨胀推理速度稳定单任务成本也直线下降。4.3 工具调用格式不对别怪模型先检查你的 schema用 Step 5 接 agent 时最常被骂“模型不行”的其实是 prompt 和 schema 设计问题。工具调用输出经常出现“JSON 格式对但字段名不对”“字段名对但嵌套层级错了”“嵌套层级对了但模型把字符串写成了数组”这类情况。我的经验是把工具 schema 直接写进系统提示词并且给出一个真正的 in-context example让模型照着样子填。有些框架喜欢用“function calling API”格式让模型输出 structured JSON这种情况下模型通常能很好响应但一定不要把自由文本和 JSON 混在一起要求模型输出那会增加解析歧义。另一个兜底技巧是解析失败时自动重试一次并携带“上次解析失败的具体原因”作为额外 hint。大多数情况下第二次生成的 JSON 就会修正过来。4.4 并发吞吐低batch 和 prefill 同步调优多路 agent 并发的时候吞吐很容易突然掉下来表现是前几条请求很快后面的任务开始排队。这个问题大多是调度策略没调好。vLLM 里几个参数要重点看--max-num-seqs控制每次批次能塞多少请求调高可以提升 batch 吞吐但会占用更多显存。--max-num-batched-tokens控制一次处理的总 token 数量如果设太小长上下文请求一次只能处理一小段吞吐自然低。--enable-chunked-prefill不只是防显存峰值它对“长输入请求与短输入请求混合调度”也有明显帮助能让 GPU 在等待长 prompt 解析时不至于完全闲置。我建议先保持默认参数用 load test 脚本压一压观察 GPU 利用率。如果 GPU 利用率长期低于 50%说明调度参数太小如果显存经常爆说明gpu-memory-utilization和 KV Cache 配置需要回退一点。性能调优没有万能参数但方向基本就是利用率和显存之间的平衡。5. 开源生态影响从 Step 5 Preview 看长程 Agent 的新阶段5.1 开源模型第一次把“质量”和“成本”同时拉满过去很长一段时间开源模型都要面对一个尴尬不是不能打而是总要在“模型能力”和“部署成本”之间二选一。开源社区拿得出手的 MoE 模型不少但做到 600B 总参数、27B 激活这个档位的极少。Step 5 Preview 把这条线直接抬高了等于告诉整个行业开源社区已经有能力训练和发布这个体量的稀疏激活模型而且它还在长程智能体这个方向上有针对性优化。这对开发者的影响是现在你不用再为了一个 agent 任务去租 8 卡乃至 16 卡的机器跑 Dense 模型也不必在“效果稍微差点但便宜的开源模型”和“贵到只能试用的闭源模型”之间纠结。一个开源模型能同时具备接近一线的效果和可以负担的推理成本长程 agent 项目从“demo 可行”变成“小团队也敢上产线”。5.2 对 Agent 开发者的三个直接机会第一个机会是“长任务产品化”。以前一整个任务链跑下来成本太高只能做单轮问答现在成本降下来了可以做多轮调研、自动报告生成、复杂工作流编排之类需要大量试错的产品。第二个机会是“模型再训练与领域适配”。开源模型最大的价值是可以二次训练Step 5 的 MoE 结构让领域适配可以落在特定专家模块上理论上可以只训练某几个专家来适配金融、法律、医疗等行业数据效率会明显高于重新训练一个 Dense 模型。第三个机会是“私有化部署”。数据敏感的行业一直对调用外部 API 有顾虑本地部署的开源模型配合长程 agent 能力让“数据不出内网”也能跑复杂智能体任务。5.3 我跑完 Step 5 Preview 之后的几点个人体会最后说点没什么公式、但实操中很重要的事。Step 5 Preview 这类模型我刚拿到时最容易犯的错误是“以为它什么都能一步到位”结果长任务照样会因为我的 workflow 设计太粗糙而翻车。它不是魔法而是把“成本上限”这个限制条件松绑了——之前很多“算力不允许试错”的设计现在可以换成“先试再让模型自我修正”。这种“试错友好”的开发模式才是它带给长程 agent 项目最大的价值。我的建议是切到 Step 5 之后先不要急着把整套 agent 流程全部重构。保留原来的推理逻辑只把模型替换掉观察它在多轮工具调用中的稳定性和成本变化。然后再逐步加入更长的任务链、更多次的工具调用、更复杂的校验流程。这样每一步的收益都看得见摸得着出了问题也知道该回头检查哪一层。另外一个小技巧同一套 agent 流程一定要分别记录“模型输出总 token 数”“工具调用次数”“重试次数”三张表。Step 5 的优势很多时候不是体现在第一次回答的惊艳程度上而是体现在任务不需要反复重跑、工具调用不需要额外纠错长期累积下来才真正省出那 8 倍的成本差异。
