看到 Step 5 Preview 这个名字我第一反应是又有人在刷榜。但把标题里的信息逐条拆开——600B 总参数、27B 激活参数、单任务成本降 8 倍、长程智能体、开源、全球前三——我觉得这条消息不能当普通新闻看。600B 和 27B 是一个跨度极其夸张的数字组合放在半年前这种规模的模型想跑起来没有一屋子高显存卡根本别想。现在它顶着开源的身份把成本拉到了原先的八分之一左右而且目标场景还是最难伺候的长程智能体。这就值得坐下来认真算一笔账了。这篇文章不打算复述新闻稿而是想把这几个问题讲透600B/27B 这套架构到底是怎么省钱的、为什么长程智能体特别吃这套设计、所谓开源前三的含金量怎么看以及你真打算把它接进自己的业务时钱该怎么花、坑在哪里。不管你是做 Agent 应用的技术负责人还是在评估下一代开源模型选型的大模型爱好者应该都能从里面找到点能直接抄作业的东西。1. 600B 总参数里只有 27B 被激活这不是参数缩水是结构调整1.1 从稠密模型到 MoE把 600 人的公司拆成按需调用的专家池先说一个最基础但最容易被忽略的点普通大模型是稠密架构你输入一段话几乎所有参数都要参与计算。一个 600B 的稠密模型你问它今天天气怎么样这 600B 权重全部得跑一遍计算量大概是 2 × 600 × 10^9 FLOPs/token。这是硬成本省不掉。Step 5 Preview 这种设计走的是混合专家路线英文叫 Mixture of Experts简称 MoE。它不是让所有参数都对每个 token 起作用而是把模型拆成两个部分一部分是路由器Router另一部分是大量专家网络Experts。每个 token 进来路由器先判断这个 token 需要哪些领域的能力然后只挑最相关的几个专家参与计算。600B 总参数意味着整个专家库很大但处理单个 token 时真正被调到台前的只有 27B 左右。我习惯用一个类比解释这件事一家公司有 600 名员工但日常处理具体事务时从来不需要 600 个人同时围过来。接到需求后项目经理路由器判断一下这次要财务、法务、技术各派几个人组成一个临时项目组就好。剩下的人待在各自的专业部门待命。专家池越大能覆盖的领域越广但真正干活的永远只是被点名的那些人。MoE 就是这个思路。这里要提醒一句MoE 不是新东西两三年里已经有好几个开源模型靠这条路验证过了。但把总参数堆到 600B 级别、同时把激活参数控制在 27B 左右这个组合在开源阵营里仍然属于激进操作。它说明技术团队赌的是知识覆盖广度可以用大参数解决响应速度和成本必须用小激活解决。1.2 别把激活 27B误读成只有 27B 权重需要落地这是我最想强调的一个点。很多朋友一看到仅激活 27B第一反应是那部署起来是不是就跟 27B 模型一样轻——完全不是一回事。激活参数决定的是单次前向计算量、推理延迟和 KV cache 压力但 600B 总参数意味着模型的权重文件还是 600B 的量级。哪怕其中 573B 的参数在推理时没被激活它们也得躺在显存或者内存里等着被路由器随机点到。按 FP16 精度算600B 权重大约 1.2TBINT8 量化后约 600GBINT4 量化后也要 300GB 左右。这个存储成本是藏不掉的。我把两类架构的关键成本项列个表看完就清楚了对比项稠密 600BMoE600B 总参 / 27B 激活单 token 计算量约 1.2T FLOPs约 54G FLOPs约低 22 倍权重存储FP16约 1.2TB约 1.2TB权重存储INT4约 300GB约 300GBKV cache 压力取决于层数、注意力头配置取决于实际层数与注意力头配置和总参数无直接线性关系单次推理延迟高明显更低所以 MoE 的真实价值不是让你用更小的硬盘而是让你把火焰烧在刀刃上——计算资源花得更少但知识储备依然保留大模型的广度。这一点是理解后续所有成本账的基础。1.3 单任务成本狂砍 8 倍是怎么算出来的既然单 token 计算量理论上差了 22 倍为什么官方说单任务成本只省了 8 倍这中间的差值去哪了原因在于真实业务里的单任务成本从来不是单纯的 FLOPs它由好几块拼成权重存储的摊销成本、KV cache 占用的显存成本、路由器的额外计算、批处理效率、推理框架的调度开销以及量化后精度损失带来的重试成本。Agent 场景下还要算上工具调用失败后模型重新规划的那几轮 token。所以 22 倍的纯理论差距落到任务层面被各种工程开销摊薄到 8 倍这个量级是合理的。换个角度想更直观假设你原来用一个效果接近的稠密大模型处理一批长程任务跑完要花 100 块钱算力。现在换 Step 5 Preview 这类 MoE 模型在差不多的效果下可能只需要 12 块钱左右。省下的 88 块钱一部分来自激活参数变小一部分来自推理框架对 MoE 的调度优化还有一部分来自模型针对长程任务的定向训练减少了无效尝试。对做 Agent 业务的人来说这 8 倍不是账面数字是真金白银的边际成本下降。2. 长程智能体为什么是检验模型成色的炼狱级考场2.1 长程任务到底长在哪里长程智能体和常见的聊天机器人完全不是一类东西。聊天是问一句答一句最多带点多轮记忆长程任务则要求模型像一个人事专员一样把一个复杂的、多步骤的、需要反复调用外部工具的目标从头干到尾。举个例子企业采购审批流程。模型需要先查库存系统再比价三家供应商然后按公司预算红线过滤选项生成采购申请单调用审批 API收到审批结果后再更新库存台账最后给相关人员发通知。这中间每一步都可能调用不同的工具每一步的输出都是下一步的输入而且全程不能丢掉预算不超过 5 万元这个硬约束。再比如行程规划订机票、订酒店、租车、查天气、预估总花费、预留时间余量。普通人做这件事都容易乱更别说模型。长程任务的长体现在四个维度链条长度单次任务几十步工具调用模型要连续维持目标不漂移状态依赖每一步结果都影响后续决策模型得记住自己执行到哪了外部反馈解析需要理解工具返回的 JSON、报错信息、页面内容并从中提取有用信号硬约束保持预算、时间、合规规则等限制条件从头到尾不能丢。2.2 通用模型长程跑不动的四大死因我过去用普通开源模型做 Agent 原型时被坑过太多次。总结下来通用模型在长程任务里最容易死在四个地方第一个是上下文漂移。执行到第 20 步时模型已经忘了第 1 步提出的预算约束开始选超预算的方案。根本原因是长序列里模型对早期信息的注意力衰减不是简单把上下文拼长就能解决。第二个是工具调用格式漂移。前 10 次调用格式都很规范后面开始出现字段名拼错、 JSON 括号不闭合、参数类型写错之类的问题。长链条会让模型对格式的记忆逐渐糊掉最后引擎直接解析失败。第三个是规划不闭环。子任务失败后通用模型经常不会主动调整策略而是反复用同一个失败方案重试或者干脆编造一个成功结果让整个任务在错误的状态上继续往下跑。第四个是成本爆炸。每次工具调用后模型都要把前面的历史重新纳入上下文token 消耗随步骤数线性甚至超线性增长。一个看似简单的任务可能跑出几十万 token账单直接失控。这四个问题不是换个更大模型就能自动解决的它们需要专门的训练目标和数据配比去针对性优化这也是为什么模型要单独强调自己是为长程智能体优化。2.3 为什么少参数反而可能在长程上更稳这里存在一个反直觉的地方激活参数少能力反而更聚焦。MoE 架构里每个专家可以看作一个领域的能手。长程任务需要的恰恰是频繁切换能力——上一秒还在规划下一秒就要调 API再下一秒要解析结果。如果路由器的分配策略训练得好27B 激活参数可以在每次切换时精准调用对应领域的专家效果不一定比 600B 稠密模型差反而因为少了很多无关参数的干扰指令遵循可能更稳定。更重要的是工程侧长程智能体落地时延迟和成本往往是生死线。27B 激活规模意味着单次推理可以做到较低的延迟推理引擎也更容易做并发调度、请求缓存和动态批处理。对线上 Agent 服务来说这比单纯堆模型效果更实在。说句不好听的很多所谓效果更强的稠密巨无霸真跑到 Agent 生产环境里一次工具调用等十秒出结果用户早就走了。3. 开源前三的含金量榜单可以看但不能只看3.1 榜单评测的维度在变工具调用和 Agent 能力权重上升现在开源模型排名已经不是早年只看语言理解、数学推理那几个老 benchmark 的时代了。模型要进全球开源前三通常要看几类综合表现通用能力、代码与数学、工具调用准确率、长程任务完成率。尤其是工具调用类评测模拟的就是真实 Agent 环境里模型能不能正确地把意图转成一次 API 调用这个维度跟 Step 5 Preview 的主打方向高度重合。但我想提醒一句榜单排名只能说明这个模型在评测集覆盖范围内表现优秀不能直接等同于你的业务效果好。很多 benchmark 存在或多或少的数据污染模型如果在训练阶段见过类似题目分数会虚高更隐蔽的问题是合成评测任务的模式比较固定模型可能形成对评测集的过拟合到你真实业务里遇到没见过的工具、不规则的返回结果马上就露馅。所以看开源榜单的正确姿势是先看排名确认这个模型属于第一梯队再把它当作候选对象拿到自己的真实任务集上去验证而不是把前三直接写成采购结论。3.2 开源权重才是真正的帕累托放大帕累托最优这个概念本质上讲的是不牺牲一个目标的同时提升另一个目标。传统大模型选型里效果和成本是一对矛盾想效果好就得堆参数堆参数就得烧钱。Step 5 Preview 这类模型声称实现的是效果往顶尖模型靠拢、成本往开源小模型看齐两个通常对立的目标同时改善所以叫帕累托奇迹。听起来有点玄但放到开源生态里这句话的真实含义反而更朴素。开源权重真正带来的是决定权的下放。API 调用模式下数据要经过第三方服务长程任务的 token 成本随轮次线性放大你连模型内部的行为细节都改不了。拿到开源权重之后你可以私有化部署、做领域微调、压成 INT4 量化版本、用自己的评测集做第三方审计。对于跑长程智能体业务的中小团队来说这个价值可能比模型本身效果提升还大。不过这里必须泼一盆冷水开源不代表完全免费。你需要看 License 条款确认商用限制、微调后的再分发规则你需要自建推理基础设施这意味着运维成本你还要自己处理长程任务特有的稳定性问题。开源降低的是使用门槛不是维护成本。4. 真把它接到业务里这些账和坑得提前算清楚4.1 显存估算先泼冷水别以为 27B 激活就能单卡随便跑我在前面已经强调了权重落地的硬成本。这里直接给出不同方案下的显存需求估算帮大家建立一个真实的心理预期部署方案权重大小量化精度大致需要的显存配置FP16 全精度约 1.2TB最高16 张以上 80GB 卡基本是超大集群玩法INT8 量化约 600GB较高8 张左右 80GB 卡仍需多机协同INT4 量化约 300GB中等4~6 张 80GB 卡单机勉强可行权重 offload 到 CPU/NVMe约 300GB中等2~4 张卡加高速 NVMe性能打折但可跑你可能会问既然每个 token 只激活 27B能不能只加载部分专家理论上可以做专家动态加载实际上除非推理框架支持非常成熟的 offload 机制否则路由器随时可能点到没加载的专家任务就卡住了。稳妥的部署方式仍是把全部权重放进可访问的存储层再配合调度优化。4.2 KV cache 是长上下文里隐藏的第二张账单长程智能体几乎必然伴随长上下文而 KV cache 的膨胀速度比想象中快得多。计算公式不复杂KV cache 大小约等于 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 单元素字节数。按一个典型的 60 层模型、128 维注意力头、8 个 KV 头来算处理 128K 上下文时FP16 精度下的 KV cache 大约需要 30GB如果把 KV 头数换成 32 个直接飙到 120GB。也就是说长任务跑到一半模型对历史信息的记忆缓存可能比权重文件还吃显存。这是很多人部署长程智能体时翻车的隐藏原因——算好了权重没算 KV cache。应对思路一般有几种启用 GQA分组查询注意力机制减少 KV 头数、对 KV cache 做 INT8 或 FP8 量化、结合上下文压缩技术把历史摘要化。但最有效的还是从业务层面控制上下文长度别让模型每次都把完整历史翻出来读一遍。4.3 单任务成本的真实账本假设一个长程 Agent 任务平均调用模型 30 次每次输入加输出合计约 2000 token一个任务的总 token 消耗大约是 6 万。如果模型还会重读长历史这个数字可能翻倍甚至更多。在这种情况下单 token 成本哪怕只降一半任务级账单也会出现明显差异。而 Step 5 Preview 这类 MoE 模型的优势在于它每个 token 的计算量约等于 27B 激活规模实际部署中配合 INT4 权重和框架级调度单 token 成本能压到和主流开源小模型差不多的量级。一个任务 6 万 token如果按高性价比开源模型的单价算成本可能就是几毛钱到几块钱的水平而如果用同等效果的全量稠密大模型费用要按接近 8 倍去估。跑一百万个任务这个差距就是几十万的真金白银。我个人的建议是做成本测算时别只按模型单次推理价格算要把工具调用失败率、重试次数、人工干预成本都算进去。Agent 任务里模型第一次就给对答案和反复试错才给对答案成本能差出好几倍。4.4 部署避坑清单最后把我在实际部署类似大参数 MoE 模型时踩过的坑整理一下别只看激活参数就乐观。权重加载、存储带宽、多卡通信都是硬约束先算总量再谈优化。监控路由均衡。MoE 在真实流量下容易出现部分专家被持续高频选中形成热点导致某几张卡过热、其余卡空闲。要留意推理框架的负载均衡策略。端到端评测必须建立。通用 benchmark 分数再高也要自己准备三五十个真实长程任务记录任务完成率、工具调用成功率、平均耗时、平均成本这四个指标。没有这套数据模型选型就是拍脑袋。量化精度要实测。INT4 对格式漂移的影响不可忽视有些量化版本对话效果挺好但工具调用输出格式开始出错。建议在目标任务的轨迹上做一次量化前后对比。短链任务别用大模型。如果任务只需要三五步工具调用27B 稠密模型可能更省事毕竟不用背 600B 权重和 MoE 调度的运维负担。提示以上估算基于主流 MoE 部署的通用规律具体表现会因推理框架、量化方案和业务场景不同而浮动但账本的量级和思考框架是通用的。5. 我在实际选型和落地时的几点体会5.1 先跑通流程再谈成本优化我刚接触这类大参数 MoE 模型时犯过一个典型错误第一版方案就想着把成本压到最低直接用 INT4 加专家 offload结果工具调用格式频繁出错返工成本比省下的算力还高。后来我换了思路先用标准精度的推理把端到端流程跑通拿到任务成功率、平均耗时、成本分布三条基线然后逐项做优化——先量化权重、再优化 KV cache、最后才考虑专家 offload。每一步都保持评测集对齐优化才不是瞎调。这个顺序背后的逻辑很简单成本和效果是耦合的你不先确认效果基线就不知道成本优化到底牺牲了什么。5.2 不是所有任务都值得大马拉小车我现在选型时习惯把 Agent 任务分三档短链任务几步工具调用直接用 20B~30B 稠密模型部署简单、延迟低中长链任务涉及状态依赖和多工具切换优先考虑 Step 5 Preview 这类大参数 MoE因为它兼顾能力覆盖和成本只有真正需要顶级复杂推理、且预算充足的场景才会上更大规模的模型。很多人容易被600B 总参数吸引觉得越大越好。但真实业务里一套模型的评估成本、运维成本、监控成本都是隐性负担。帕累托奇迹听上去很美本质上是让你用更少的资源办成同样的事——前提是你得知道自己要办的那件事到底有多难。对我来说这个模型最大的价值不是开源前三这个排名而是给了 Agent 场景一个中间档位以前要么用小模型硬撑然后频繁翻车要么上大模型然后看着账单心跳加速现在的选择空间明显大了。最后分享一个实操中很管用的小技巧在内部评测集里把每个任务按首次尝试成功率和最终完成率分开统计。两者差距越小说明模型一次做对的能力越强差距越大说明模型依赖重试兜底。做成本测算时这个差值就是你最需要优化的空间——多试几次就会发现不少模型能力问题其实可以通过更细的工具描述和更严格的状态校验解决不一定要换更大参数。