前阵子阶跃星辰把 Step 5 Preview 的权重一放出来我身边做 Agent 应用的朋友几乎都在转这张图600B 总参数每 token 只激活 27B开源榜单位列第一梯队宣传口径还死死咬住“长程智能体”不放。乍一看这像又一个大模型“军备竞赛”的产物但仔细算完账之后我反而觉得它值得单独写一篇长文聊清楚为什么“大而稀疏”的结构会在多轮工具调用这类任务里变成一个意外的帕累托改善为什么单任务成本能砍下来 8 倍而不是吹出来的 8 倍以及作为一个普通开发者和研究者你到底该怎么看懂、怎么部署、怎么用它去跑真正的智能体任务。先说结论Step 5 Preview 不是一个常规意义上的“更大更强的聊天模型”它更像一枚专门为“长任务、多轮调用、高上下文消耗”设计的性价比武器。600B 是所有专家加起来的家底27B 是每次推理真正干活的队伍。这种 MoE 架构决定了它下载时很重、跑起来却很轻也决定了它在长程智能体场景里能把成本优势放大到肉眼可见。这篇文章不打算复述官方 PR我会从 MoE 的原理、智能体任务的成本结构、部署显存的数学题、实测踩坑记录这几个角度把这件事彻底拆开。1. 600B总参只激活27BStep 5 Preview到底是个什么水平1.1 “激活参数”比“总参数”更能定义实际体验传统 Dense 模型里总参数量和激活参数量是同一个数无论输入什么 token整个模型都会跑一遍。可 MoE 不是这样。跟我说句实话两年前我第一次看 MoE 的论文也觉得很反直觉一个模型明明有 600B 参数可每次输入只在若干个专家网络里做路由最后平均只激活 27B。这意味着什么用一句最直白的话说你下载权重的时候要面对的是 600B 的完整体积但每一次生成 token 的计算开销只相当于一个 27B 的 Dense 模型。这个区分很重要因为用户感知到的“快慢”“贵贱”从来不是总参数量决定的而是激活参数、上下文长度、KV Cache 共同决定的。我举个生活化的例子一家 600 人的公司办公楼要按 600 人建房租一分不少但具体接到一个项目只需要 27 人进场干活那工资和项目开销就是 27 人的量级。传统 Dense 模型等于每个项目都让 600 人一起上MoE 则尝试“看菜下饭按单挑人”。Step 5 Preview 的效果之所以在开源社区引起讨论正是因为它在“办公楼很大”的前提下把“项目人力成本”压到了一个非常夸张的程度。当然这个机制也有它的隐性成本路由模块本身需要判断哪个专家适合当前 token专家之间还有通信开销。如果任务本身简单到所有 token 都只需要同一批共性能力那 MoE 反而是浪费。但反过来讲一旦任务需要频繁切换知识域比如既要写代码、又要查文档、还要做数学推演那“每次按需激活”的优势就会被拉满。这也是为什么它一上来就强调“长程智能体”而不是强调通用聊天。1.2 开源前三到底指什么怎么理解这个排名很多人看到“开源前三”四个字第一反应是去问“哪个榜单”。这里必须说清楚目前不存在一个真正意义上的全球官方开源模型排行榜社区里能达成默契的主要是几个参照系比如 Hugging Face 的 Open LLM Leaderboard、Artificial Analysis、LMArena 的开放式评测以及各种代码、数学、Agent 专项榜。Step 5 Preview 能在这些综合维度里进入第一梯队本身说明它不是一个“偏科怪”而是在通用能力、指令跟随、工具调用上都保持住了水准。我的看法是开源模型排名这个东西背后不光是模型权重本身的胜负也是对周边工具链的综合性考核。一个 600B 模型就算再强如果没有 vLLM、SGLang、llama.cpp、GGUF 这些推理框架跟上个人开发者根本不可能把它跑起来。这几年的现实就是开源社区的“基础设施红利”让超大模型不再是大厂的专利Step 5 能登上榜单前列也说明它的部署路径已经足够平滑至少不会让你为了推理环境熬三个通宵。还有一个容易误读的细节榜单排名里如果出现“600B”“27B激活”一类的字眼别急着和其它模型按总参数量横向对比。不同模型的词典大小、层数、专家数量、路由策略都不一样榜单上的得分是端到端的效果衡量和你配置的推理框架、量化精度、采样参数也有关系。真正有价值的不是“排第几”而是这个名次对应的推理成本到底是多少。1.3 为什么偏偏强调“长程智能体”先给不熟悉 Agent 概念的读者补个背景。所谓长程智能体指的是让模型去完成一个需要持续很多步、反复调用外部工具、在长时间内保持目标一致性的任务。比如让模型帮你订一张跨国机票它得先查航班、比价、确认中转、处理证件要求再一步步提交预订请求或者让模型做一个数据分析报告它得反复检索数据、写代码、执行、看结果、再修改。和普通聊天不一样的是这类任务不是一问一答而是“一段马拉松式的多轮协作”。这种场景里token 消耗会指数级膨胀。每多一次工具调用历史记录就要多塞进一段上下文模型下一次推理时又要把整段历史重新过一遍。你可以简单理解为一次对话越长花出去的钱越像滚雪球。传统 Dense 模型在这种场景里最大的问题不是“能力不够”而是“成本扛不住”。Step 5 的设计恰好击中了这个痛点参数总量大代表它有能力处理复杂任务激活参数小代表它每次处理长上下文时不会把所有计算量都压在你钱包上。这就是它和“长程智能体”绑定得如此紧密的原因不是营销话术选得好而是架构本身就长在这条需求曲线上面。2. 为什么说这是长程智能体的“帕累托奇迹”MoE的账其实没那么好算2.1 MoE不是新东西这次赢在训练和工程如果你翻过早期的 NLP 论文会发现“混合专家”这个概念至少能追溯到二十多年前。它不算新技术但过去很长一段时间里MoE 模型在开源社区不受欢迎原因非常现实训练不稳定专家利用率容易坍塌分布式推理的通信开销又大。那时候大家宁愿堆一个又大又笨的 Dense 模型至少好训、好部署。转折点出现在最近两年。一方面研究者设计出了更聪明的负载均衡损失让路由模块不会总把 token 丢给同几个“卷王”专家各专家之间的利用率更健康另一方面训练数据质量和多阶段训练策略的提升让稀疏模型的“学不进去”问题得到了缓解。第三步则是在推理框架层面vLLM 等工具专门为 MoE 做了张量并行和专家并行的混合优化把“600B 权重但只激活 27B”这个说法的可实现性拉到了普通工程师也能触碰的范围。Step 5 Preview 在这个时间点出现确实占了好几个优势叠加的便宜。但把 600B 总参和 27B 激活做到“既能跑又不笨”不是简单地把 Dense 层改成 MoE 层就行。它需要足够多样的数据让专家产生分工需要合适的路由温度避免所有 token 都挤到同一条路上还需要长上下文阶段对大量工具调用记录保持稳定。很多团队做 MoE 做到一半就放弃就是因为这些“看不见的工程”远比论文里那几条公式更磨人。2.2 计算账本27B激活 vs 600B总参差距到底在哪把理想情况下的计算量拉出来算一笔账。自回归生成一个 token 需要的浮点运算量粗略估算大约是2 × 激活参数量 × token 数。如果有一个 600B 的 Dense 模型那它每生成一个 token就要跑几乎全量的 1.2 TFLOPs 级别计算。Step 5 激活参数量只有 27B每 token 计算量大概在 54 GFLOPs 级别。单看这个数字理想差距接近 20 倍。但在真实服务环境里没有人能拿到这 20 倍。原因有三个第一权重文件依然是 600B显存占用和加载开销一点没省第二多专家并行必然引入通信拆的卡越多通信成本越高第三注意力机制的 KV Cache 只跟层数、隐藏维度、上下文长度有关和激活参数没有直接关系长上下文场景下这块开销反而可能成为大头。综合工程损耗能把单位 token 成本做到同等质量 Dense 模型的 1/5 到 1/10已经算是非常漂亮的数字。所以“单任务成本砍 8 倍”这个宣传口径既不夸张但也最好别理解成“所有场景都便宜 8 倍”。我之前帮一个团队估算过一个内部 Agent 项目的推理成本他们从 200B 稠密模型切到稀疏激活的 MoE 模型后在任务成功率基本持平的前提下Prompt 处理阶段的实际吞吐提升了大约 67 倍到了晚上低峰期甚至能到 8 倍以上。原因是智能体任务里最耗时的往往不是 Decode而是把越来越多历史记录塞进上下文的那一次 Prefill。MoE 对这部分计算量的削减几乎是降维打击。2.3 “帕累托奇迹”是个营销词但方向是对的我前面说过所谓帕累托改善本质上是你多了一个选项以前模型能力和推理成本像翘翘板压下一头就抬起另一头现在稀疏激活结构让你有可能“知识很渊博但跑起来很便宜”。在经济学意义上这当然很重要。但做技术的人千万不要被这个词糊住因为 MoE 的收益高度依赖任务分布。什么场景适合 MoE 长程智能体答案是任务确实需要多领域知识、需要长期保持目标一致性、需要频繁工具调用。比如“企业级数据分析助手”“法律文档自动审阅”“复杂流程自动化”这类任务它们往往既需要代码能力又需要领域上下文理解还动不动就要跑几十轮。反过来如果你只想要一个“问一答一”的客服机器人每轮输入很短、输出很短那 MoE 在通信和显存上的额外开销反而会拖低性价比。所以“帕累托奇迹”真正的含义我认为是“在特定任务分布上找到了一组别人没做好的取舍”。它不是模型自己产生了奇迹而是“稀疏架构 长上下文优化 开源部署工具链成熟”三件事在 2025 年这个时间点完美对上了。顺着这个逻辑你就能理解为什么它会叫“Step 5 Preview”为什么它偏偏面向 Agent 任务发布以及为什么关注度这么高。3. 把账算透单任务成本8倍差距是怎么砍出来的3.1 长程智能体的成本结构与传统 Chat 完全不同先不要纠结“8 倍”这个数字本身先把长程智能体任务的成本模型搭出来。任何一个 Agent 任务账单上基本由三块构成输入 token每次调用时发给模型的指令、历史记录和工具返回结果、输出 token模型生成的思考过程和最终答案、以及失败重试带来的额外消耗。传统 Chat 里输入输出往往各几百 token一次会话结束就完事。但长程智能体不是这样假设一个任务要执行 15 轮工具调用每轮新增约 2k token 的工具反馈那么模型累计已经“见过”的上下文会达到几十 k 甚至上百 k token。最反直觉的地方在于输出 token 往往只占很小比例模型可能每轮只回你几十到几百字的文字真正烧钱的是它每次都要把“越来越长的历史记录”重新完整处理一遍。这个特性决定了长程智能体任务中真正决定成本的不是生成速度而是预填充速度。如果你只盯着“生成速度”去选模型很容易被带偏。举个例子一个模型 Decode 速度快但 Prefill 阶段把所有历史都算一遍需要很久另一个模型 Decode 稍慢但 Prefill 在稀疏结构下能省掉大量专家计算。放到 15 轮工具调用的任务里第二个模型的综合表现很可能会反超。Step 5 的优势恰好落在第二个象限里它的激活参数小每次 Prefill 的计算量天然就低。3.2 为什么“激活少”在累积成本场景能放大 8 倍还是把问题拆细。模型服务端处理每个 token 的成本由 Prefill 和 Decode 两段构成。在一个多轮工具调用任务里每一轮你都要把“上一轮的完整对话 工具结果”重新发给模型做一次 Prefill。随着轮次增加输入长度线性增长但每次增长都会重复处理之前的全部历史因此总成本是按轮次的“累计长度”增长的近似 O(n²)。在这种增长模型下激活参数带来的单次优势会被反复乘算。假设 Step 5 每次 Prefill 的计算量是一个 200B 稠密模型的 1/7而智能体任务要重复执行 15 轮那么理想情况下总成本差距会在单次的 1/7 基础上进一步被“轮次”放大。当然实际工程中 KV Cache 和通信开销会吃掉一部分红利不会达到数学上那么夸张的差距但 48 倍的差距完全在合理区间。“单任务成本狂砍 8 倍”背后的逻辑不是某个魔法优化而是长上下文 Prefill 的重复代价被稀疏结构大幅削减之后自然而然体现出来的结果。3.3 算一笔“示范账”一个 15 轮工具调用任务的对比为了让你对“8 倍”有一个直观手感我按一个相对标准的智能体任务来模拟一遍。假设任务总共 15 轮工具调用每一轮新增上下文 2k token初始系统提示和任务描述约 2k token。那么第 1 轮的输入长度约 4k第 2 轮约 6k第 15 轮约 32k。把所有轮次的输入长度累加模型在整个任务里处理的输入 token 总量大约是 270k输出 token 假设总共 20k。同样这个任务如果换成一个激活参数为 200B 的稠密模型单 token 的 Prefill 计算量大约是 Step 5 的 7 倍。虽然通信和工程损耗会让实际差距缩水但别忘了还有失败重试Agent 任务很难一次成功实测量级上 5 次尝试能彻底跑通已经算很优秀。也就是说如果你的模型单价高到让你“不敢多试几次”那成功率就会进一步恶化成本差距反而会拉大。所以“8 倍”并不是一个脱离场景的绝对数字它是“任务复杂度 轮次 重试概率”共同作用的结果。3.4 真正要警惕的隐性成本显存占用与并发话虽这么说我还是要给兴奋的情绪降降温。Step 5 的单任务推理成本低不代表部署成本低。你想本地跑一个 600B 权重显存预算依然是一道很硬的坎FP8 量化后大约 600GB4bit 量化后大约 300GB这还没算 KV Cache。小团队如果只是偶尔跑几个 Agent 任务按云端 GPU 按小时租用可能是更合理的姿势但要支撑高并发线上服务8 卡、甚至更多卡的成本依然非常可观。我常对朋友说看模型成本要分两个口径一个是“单位任务口径”也就是每个成功完成任务花多少钱另一个是“基础设施口径”也就是为了让模型能跑起来你每月最低要付多少 GPU 账单。Step 5 的优势体现在前者但千万不要因为它“便宜”就忽略后者的规划。很多项目死在“以为便宜所以随便上”结果并发一高显存直接顶到天花板加卡的成本瞬间把省下来的推理费全吃回去。4. 本地部署实操显存预算、量化选型与推理配置4.1 先搞清楚三种部署方案别一上来就下载 600B动手之前先梳理清楚你的目标。如果你只是想验证 Step 5 在某个智能体任务上的效果最省事的是直接调用官方 API注册之后把 base_url 换成服务商给的地农民跑通一个 demo 再决定是否自建。如果你想认真做评测和二次开发那就需要本地部署但又可以分成两条路一条是用多卡大显存跑 BF16/FP8 权重尽量复现模型真实能力另一条是用 GGUF/AWQ 做 4bit 量化塞进你手头已有的卡里优先验证“能不能跑”和“亏多少”。我觉得大多数开源玩家会走第二条路因为一张 H100 不是谁都有的。但这里有一个很容易被忽略的坑不同量化方案对 MoE 模型的影响并不一致。有些朋友拿 Dense 模型的量化经验硬套上来就把权重压到 2bit结果路由模块也跟着被压坏模型直接“精神分裂”。对 MoE 模型权重量化的重点不是把每个专家压得多狠而是保证路由层的精度不崩。推荐先跑一遍官方支持列表里最成熟的量化格式比如 AWQ 或 GPTQ 的 4bit再根据任务效果决定要不要往更低 bit 试。GGUF 的好处是生态好、llama.cpp 直接支持但对超大模型来说最好还是确认推理后端对 MoE 的 expert parallelism 支持是否成熟否则你会遇到“量化完跑不动”的尴尬。4.2 显存预算怎么做600B 的数学题显存估算是部署这类模型最不容易出错、又最容易被人忽略的环节。先背下这个公式模型权重显存GB ≈ 总参数量 × 每参数字节数 额外开销约10%。BF16/FP16 是每参数 2 字节600B 模型权重就要 1200GBFP8 是每参数 1 字节大约 600GB4bit 量化约每参数 0.5 字节大约是 300GB。注意这只是权重还没算 KV Cache。长程智能体任务里上下文可能开到 128KKV Cache 又是很大一笔开销一般建议在权重估计算完后直接再加 20%30% 的余量。拿 4bit 的 300GB 来算加上 KV Cache 和中间激活整机显存至少建议 320GB 以上。这意味着一台 8×40GB 的机器勉强够跑4×80GB 会更从容。我见过不少人在这一步踩坑看到别人用 4bit 说“能跑”就以为一张 24GB 显卡也行结果权重加载到一半显存直接爆掉。虽然也有人在 GitHub 上用极端量化在单卡上跑出过 demo但那种方式牺牲了太多质量只适合“装逼截图”不适合真的做 Agent 开发。如果预算有限建议直接租云 GPU按小时计费先把流程跑通再考虑采购。4.3 推荐推理配置vLLM 长上下文参数Step 5 的长程智能体优势严重依赖长上下文能力所以配置推理服务时第一件事是把 max-model-len 调到足够大。如果你只留 8K那基本等于自断一臂。我的建议是至少 32K有显存余量就直接 128K。vLLM 是当前对 MoE 模型支持最好的框架之一启动参数可以这样写python -m vllm.entrypoints.openai.api_server \ --model /path/to/step5 \ --tensor-parallel-size 8 \ --max-model-len 131072 \ --gpu-memory-utilization 0.92 \ --trust-remote-code \ --dtype bfloat16这里有个值得多讲两句的参数是--tensor-parallel-size。很多人以为卡越多越好直接拉满全部 GPU但在 MoE 场景里并不一定最优。MoE 的专家可以放在不同的卡上做 expert parallel而 Attention 部分需要张量并行这两者如果混在一起通信开销可能抵消掉算力收益。实践中最靠谱的做法是先用默认值跑 benchmark再试着拆成两个 TP 组加一个 DP 组对比吞吐变化不要盲目照搬别人的启动参数。4.4 用 OpenAI 兼容接口快速接上智能体框架vLLM 启动之后会提供一个 OpenAI 兼容接口这一步对做 Agent 开发的工程师来说非常友好。你完全不需要修改已有的工具调用代码只需要把base_url改成http://127.0.0.1:8000/v1把 API key 随便填一个非空字符串就能像调用 GPT 一样调用本地模型。唯一要留意的是参数名差异比如有些开发框架习惯用max_tokens个别后端则要求max_completion_tokens好在 vLLM 对前者做了兼容。如果你用的是 LangGraph 这类框架最简单的接入方式就是把 LLM 对象替换成一个指向本地服务的ChatOpenAI实例。跑一个小 demo 时建议先执行一个只有两三轮工具调用的简单任务观察响应时延、token 耗用、上下文截断情况。不要一上来就跑 50 步的长任务否则一旦出问题你很难分清是模型规划能力不行、上下文窗口不够、还是你服务端配置错了。5. 长程智能体任务实测避坑指南5.1 agent 任务最常踩的 5 个坑我拿 Step 5 做过几组不同难度 Agent 实验也和社群里的朋友交流过发现大家踩的坑高度一致。第一个坑是上下文静默截断。模型本身支持长上下文但很多调用代码里默认只取最近 N 条消息或者后端配置没跟上导致第十轮工具返回之后模型“失忆”。排查方法很简单在 prompt 里塞一个需要引用最开始信息的问题如果答不上来基本就是上下文被截了。第二个坑是工具定义不规范。Step 5 对工具调用的支持很完整但如果你的 JSON Schema 写得含糊模型就会陷入“想调用工具但参数永远不对”的循环。建议把所有工具描述写成“什么场景该用、参数具体含义、可接受枚举值”三件套别指望模型自己脑补。第三个坑是失败重试策略太粗暴。Agent 任务失败后很多人直接从头重跑于是成本翻倍式上升。正确做法是引入断点续跑把已完成工具调用的结果序列保存下来失败时只从出错的步骤往后重试这样既节省 token又能明显提高最终成功率。第四个坑是系统提示写得太长。我理解大家都想把任务规则写清楚但对 MoE 模型来说系统提示只是一个正在被 Prefill 的上下文长度和成本直接挂钩。把固定规则放在独立静态 prompt 里每轮只追加动态的 agent scratchpad能省很多没必要的花销。第五个坑是采样参数没调对。工具调用类任务最怕温度太高温度一高模型就可能凭空发明工具参数但温度压到 0又容易陷入重复输出同一套计划。实践下来temperature0.2~0.4是一个比较稳妥的区间既保留了探索性又不至于太飘。5.2 如何判断模型在智能体任务里“真的强”刷 MMLU 和 HumanEval 分数没什么意义想评估一个长程智能体模型得用 agent 类基准。社区里常被拎出来的有 τ-bench、AgentBench、GAIA以及一些自建的真实工具流程。我自己的习惯是先把一个固定任务跑三遍看成功率再手动记录模型每一轮的规划文本看它有没有频繁推翻之前计划、是否记得早期关键信息。Step 5 给我的整体感觉是规划主线的稳定性非常好大多数情况下不会跑偏但遇到那种“之前已经执行完的工具结果突然需要被修正”的边角情况它仍然会多探几步并出现一两次多余的试探性调用。这不算致命伤但如果你把 tools 描述写得不够细这种试探会被放大。最实用的缓解方式是给工具描述加“使用条件”字段明确告诉模型什么情况下千万别调用它。5.3 量化精度对 agent 任务的影响比想象中小很多人一量化就担心“模型变傻”。我在实际的工具调用任务里对比过 4bit 和 BF16 的差距结论是差异远小于 Dense 模型在同等量化下的衰减。这里的原理也不复杂MoE 的路由模块参数量占比小量化对它的影响有限而专家网络本身的误差又会在门控加权平均的过程中被部分对冲。所以如果你只是为了跑 Agent 任务4bit 完全够用。但有一个地方不能省KV Cache。长上下文任务里KV Cache 的精度如果也被压得很低位置编码和键值信息损失会直接破坏长程记忆这种情况比权重量化更致命。省显存可以压权重但对于 KV Cache我建议要么保留较高精度要么直接增加显存余量不要为了省那几十 GB 把模型的长上下文能力废掉。6. 开源模型竞赛的下半场已经换了赛道6.1 从“谁的模型最大”到“谁的每 token 更值”Step 5 Preview 不是一个孤立事件它背后是开源模型竞争逻辑的一次重要切换。以前大家评判模型的口径是“多少 B”似乎参数越大越有面子但长程智能体这类真实应用把这个逻辑颠覆了真正决定产品能不能活下来的是“用可接受的成本把任务跑成功”的概率。换句话说下一个阶段的竞争会被重新定义为“谁的每 token 更值”。如果一个 600B 总参、27B 激活的开源模型能稳定完成复杂工具调用那么它对中小团队的价值可能超过许多闭源 API。因为它意味着你可以把智能体任务的边际成本压到极低可以放心地让模型多试几次可以在真实业务里跑出更高的成功率。这种“可负担的试错能力”才是稀疏架构对应用层最有吸引力的地方。6.2 个人开发者还能做点什么面对这个趋势我觉得个人开发者和研究者的机会不在“再训练一个大模型”而在把长程智能体的基础设施做薄。目前最缺的不是模型本身而是配套工具一个能优雅处理断点续跑的任务状态管理模块一个能在任务即将超预算时自动压缩历史、切换策略的 token 预警系统一套能显著降低模型无效猜测的工具约束模板。这些工具不要求你手里有几百张卡但都需要你真正理解模型在长任务里的行为模式。我在实际使用中还有一个感受模型发布之后周围很多人急于测试它的“智商上限”却忽略了为它设计“稳定的工作环境”。对长程智能体来说一个可靠的提示词框架、一组规范的 tools、一条清晰的中断恢复逻辑带来的成功率提升可能比模型版本迭代还大。从这个角度看Step 5 Preview 不仅让“600B 开源模型跑长任务”这件事变得现实也把开发者的注意力重新拉回到产品工程本身上来。最后再分享一个小技巧如果你打算拿 Step 5 做长程智能体任务不要把它当做一个“单一模型”用试着让它在每一轮工具调用前先只输出非常简短的计划状态而不是长篇思考。短计划不仅省 token还能显著降低长任务里“想太多导致跑偏”的概率。我试过把某条 Agent 流程的中间思考长度砍掉一半任务成功率反而涨了十几个点。这件事在稀疏 MoE 模型身上体现得尤其明显因为它每 token 的成本虽然低但“绕圈子”的时间成本依然非常宝贵。