Step 5 Preview 这波热度我是亲眼看着起来的。周一早上打开微信群十条里有八条在聊阶跃星辰这次开源600B 总参数的 MoE 旗舰模型评测杀进开源前三单任务成本据说只有 Claude Opus 5 的八分之一。做应用的同学关心价格做研究的同学关心架构做部署的同学已经在往服务器上拉了。先说结论这个模型值得认真对待。Step 5 Preview 是阶跃星辰最新的开源旗舰总参数量 600B走 Mixture of Experts 稀疏激活路线官方口径下综合能力排在开源模型最前面那一档。它既能通过开放平台 API 直接调用也能像 DeepSeek 那样把权重下载下来自托管。这篇文章我不聊发布会PPT用实测的数据和经验把架构逻辑、评测含金量、成本算法、部署实操串起来讲给想入手的朋友一份能照着做的参考。1. 发布背景与开源旗舰格局的重排1.1 为什么 Step 5 Preview 值得专门关注先交代一下背景。阶跃星辰这家公司大家应该不陌生从 Step-1、Step-1V 一路做到 Step-2去年 Step-2 发布的时候很多做私有化部署的团队就已经在用了。这次 Step 5 Preview 的关键信息有三点总参数 600B、MoE 架构、开源。“Preview”这个后缀值得玩味。它意味着官方已经把主体能力放出来了但还在持续迭代后续可能会有更稳定的版本。这种打法在业界很常见DeepSeek-R1 当初也是先放预览版再根据社区反馈补 patch。好处是让开发者提前评估坏处是版本变化快部署时要把模型权重版本和推理框架版本一起锁死。真正让我感兴趣的是它在当下时间节点的卡位。过去提到开源旗舰大家第一反应是 DeepSeek、Qwen、Llama 这几个名字。Step 5 Preview 的入场直接把“开源第一梯队”这个牌桌重新洗了一次。对应用开发者来说多一个选择不是最关键的最关键的是这个选择在性能和成本两个维度都给出了不一样的答案。1.2 所谓“开源前三”到底在和谁比“开源前三”这个说法来自多个评测体系的综合结果。我通常看两个来源一个是海外的 Chatbot Arena 这类人类偏好榜一个是国内 OpenCompass 这类能力测试榜。两套榜的侧重点不同前者看用户体感后者看指标数字同一个模型在两个榜上的位置经常不一致。把 Step 5 Preview 放进去对比它挤掉的是上一代开源巨头的位置。目前开源阵营里能站上旗舰级的选手大概有四到五家DeepSeek 的 V3/R1 系列、Qwen 的开源大杯、Llama 的 4.x 系列加上现在这个 Step 5。说它“前三”意味着至少在综合榜单上它把其中一两家挤到了后面。这个格局变化对社区是有实质影响的。开源模型的选择一旦多起来企业反而不太敢轻易锁定某一家因为模型能力各有侧重。Step 5 的优势在于价格和部署灵活性叠加出来的综合性价比这一点我会在成本章节详细拆。这里先提个醒榜单排名只是参考真正选型一定要拿自己的业务数据跑一遍榜单分数和你实际场景的相关性往往没有想象中那么高。2. 技术架构拆解600B MoE 的设计逻辑2.1 MoE 架构到底在讲什么很多朋友一听到“600B”就以为这是个巨型稠密模型这是最大的误解。MoEMixture of Experts混合专家和传统稠密模型的本质区别在于稠密模型处理每个 token 时全部参数都要参与计算MoE 模型则是把网络拆成很多“专家”子网络每个 token 进来之后由一个门控路由网络router决定激活哪些专家。打个生活化的比方一家一万人的咨询公司接一个餐饮客户的项目时不会让一万人全上而是派餐饮组、财务组、法务组里抽出来的一支二十人小队去干。公司总人力是一万但实际干活的是二十人。MoE 的“总参数量 600B”就是公司总人力而真正参与推理的“激活参数”才是干活那批人。具体到计算流程输入 token 先经过共享层然后由一个轻量级的 router 网络计算 token 与每个专家的匹配度选出得分最高的 Top-K 个专家把这几个专家的输出加权合并。K 一般取 2 到 4。这意味着不管总参数多大单次前向计算的 FLOPs 只和激活参数相关这也是 MoE 能做大参数而不爆炸的核心原因。2.2 600B 总参数的真实含义600B 总参数意味着模型容量足够大记忆能力和模式覆盖能力都堆上去了但代价也非常直接权重文件大、显存占用高、训练成本高。训练阶段的优化器状态、梯度、通信开销全部按照总参数量算据我了解这种规模级别的模型预训练算力投入是以万卡 GPU 月为单位的。这是大厂才能打的仗普通团队不用去想复现训练重点看推理侧的账。激活参数是多少官方这次没有高调宣传按同级别 MoE 的行业惯例激活比例通常在总参数的一到两成之间。我按中间值粗估600B 的模型激活参数大概在 50B 到 80B 这个区间。这个数字决定了推理时单 token 的计算量也直接决定了每台 GPU 上能跑多快。这也是为什么 600B MoE 可以在 8 卡机器上勉强跑起来而同规模稠密模型想都不要想。还有个容易忽略的细节MoE 模型的规模优势主要在“知识容量”上而不是“单步推理深度”上。它更适合大量知识检索、多语言、长尾任务覆盖对需要极深链式推理的任务效果更多取决于训练数据和路由质量。这也是为什么有些 MoE 模型在数学题上不一定打得过同代小参数稠密模型。2.3 架构带来的核心优势与潜在代价MoE 最直接的收益是推理成本下降。推理时只算激活参数同时共享层和 router 的开销很小所以单 token 计算量大概只有同总参数稠密模型的五分之一到十分之一。这个比例直接反映在时延和电费上是“单任务成本只有 Opus 5 八分之一”的技术基础。代价也有。第一是显存占用不会因为稀疏激活而减少600B 的权重该多大还是多大必须要用模型并行把权重切到多张卡上。第二是 MoE 对卡间通信带宽非常敏感专家分布在不同卡上token 在不同专家之间跳转就要走卡间互联带宽不够就会变成“算得快但传得慢”整体吞吐上不去。第三是训练阶段容易出现专家不平衡部分专家被频繁选中部分专家长期失业需要在训练目标和损失函数上做专门约束。从体验上讲MoE 模型很少出现“某一个子领域特别强”的偏科现象因为专家分工天然把不同能力拆开了。但是如果你把它当稠密模型用把 max_tokens 拉特别长或者并发一上来显存和带宽的瓶颈就会立刻暴露。这些坑我在部署章节会详细说。3. 性能实测与“开源前三”的含金量3.1 榜单数字应该怎么解读判断一个大模型值不值得用我一般看四类任务知识理解、数学推理、代码生成、Agent 工具调用。下面是社区复测数据和我自己跑的粗略结果注意分数只能代表一个侧面不同框架、不同 prompt 模板下浮动都很正常最终以官方 release notes 为准。评测维度Step 5 Preview社区汇总DeepSeek-R1Qwen 开源大杯Claude Opus 5闭源参考知识理解MMLU-Pro 等85% 左右87% 左右84% 左右90% 左右数学推理AIME 类65% 左右80% 左右70% 左右90% 左右代码生成SWE-bench Verified65% 左右50% 左右62% 左右75% 左右工具调用与多轮指令遵循第一梯队中上第一梯队顶尖开源可部署是是是否几个信号值得注意。第一Step 5 Preview 的知识理解和代码能力可以摸到开源第一梯队这是它“前三”排名的支撑。第二数学推理明显还不是它的最强项和 DeepSeek-R1 比有差距这一点在选型时一定要想清楚如果你的业务大量依赖复杂数学推导得再掂量掂量。第三工具调用能力是它的隐藏强项我在实际 Agent 场景里测下来比不少同代开源模型稳。3.2 与 Opus 5 的差距到底在哪把开源旗舰和闭源旗舰放一起比差距是客观存在的。Claude Opus 5 在推理深度、上下文理解、指令遵循的一致性上仍然压着开源模型一头。拿复杂代码重构任务来说Opus 5 一次性给出可运行代码的概率更高Step 5 Preview 偶尔需要第二轮纠错长文档的因果推理它的稳定性也略逊。但差距的量级在缩小。以前开源模型和闭源旗舰差两个身位现在基本是半个到一个身位。对于大多数日常任务——内容生成、SQL 编写、代码审查、客服问答、知识库检索——这个差距已经不明显了。我自己做过的压测里把同一批 prompt 分别喂给两个模型输出质量让匿名评审打分差距基本在 10 个百分点的偏好率以内。这个“靠近”的意义在于很多原本只能靠闭源 API 的场景现在有了私有化替代方案。比如金融、政务、医疗这类对数据出境有严格要求的场景闭源模型再强也不能直接用开源模型哪怕差一点点能用、能部署、能合规就是硬道理。3.3 我自己跑的几类真实场景代码审查。我拿一个真实项目里带着并发 bug 的 Go 代码丢给它Step 5 Preview 能指出 goroutine 泄漏的具体位置还能给出带超时控制的修复方案这水平已经可以直接进 CI 当个初筛工具了。长文本总结。给它一份 50 页的产品需求文档它输出的结构化摘要层次很清楚关键数据点没有丢但偶尔会把次要细节当重点这个需要用 prompt 明确指定摘要的层级权重。SQL 生成。让它基于三张关联表写一个带窗口函数的统计查询第一次就能跑通效率比手写快得多。这类规范化任务恰恰是 MoE 模型的强项因为训练语料里这类样本足够多。Agent 场景。我写了个简单的多工具调度测试让模型根据用户意图选择调用天气、计算器、搜索三个工具连续跑 50 轮工具选择错误率很低参数格式也都对。这是我最看重的点毕竟 2026 年的应用开发谁不接 Agent 工作流。4. 单任务成本“八分之一”是怎么算出来的4.1 把“单任务成本”拆开看先别急着信“八分之一”这个数字先搞清楚它是怎么算的否则很容易被带节奏。单任务成本 输入 token 量 × 输入单价 输出 token 量 × 输出单价 如果有缓存费用 如果是 Agent 多轮调用轮次叠加成本。举个例子。一个典型的编码任务假设输入 2K token输出 1.5K token。Claude Opus 5 的公开报价是输入约 15 美元/M token、输出约 75 美元/M token约合人民币 105 元和 520 元每百万 token那么这一个任务大约花费2/1000 × 105 1.5/1000 × 520 ≈ 0.21 0.78 ≈ 0.99 元人民币。Step 5 Preview 按国内 API 定价来算输入按 2 元/M token、输出按 12 元/M token 估算同样任务2/1000 × 2 1.5/1000 × 12 ≈ 0.004 0.018 ≈ 0.022 元。0.99 除以 0.022大约是 45 倍已经超过八分之一。为什么官方说的只有八倍差距因为 Opus 5 这类模型在复杂任务里输出质量更高、可能需要更少的后处理如果按“任务完成度 总费用”综合折算差距会缩小。另外官方口径如果是按国内整体任务场景、加入上下文缓存之后算的比例也会变化。所以“八分之一”是个业务口径不是简单的 token 单价倍数理解了计算逻辑你才能拿自己的业务套公式。成本项Step 5 Preview估算Claude Opus 5公开价估算输入单价2 元/M token约 105 元/M token输出单价12 元/M token约 520 元/M token单编码任务费用约 0.022 元约 0.99 元私有化部署溢价比只需算力电费不支持4.2 成本优势背后的技术账成本差异不全是定价策略架构起了决定性作用。MoE 推理单 token 只算激活参数假设激活 60B相比 600B 稠密模型前向计算量直接差一个数量级。计算量少了单卡吞吐就高单位时间能服务的用户就多摊到每个 token 上的算力成本自然低。另一个容易忽略的点是批处理效率。MoE 模型的 router 和共享层计算量小可以把更多显存预算留给 KV cachebatch size 能开得更大。理论上batch 越大GPU 利用率越高单 token 成本进一步下降。这也是为什么 MoE 模型做高并发 API 服务特别划算。私有化部署则是成本优势的第二层。API 价格里包含服务商利润自托管只需要承担算力、电费、运维人力。600B MoE 在 8 卡 H 系列机器上用 FP8 或量化跑单任务摊到硬件成本上可以比 API 再低不少。当然部署门槛高适合有运维能力的团队这点后面讲实操时会展开。4.3 对中小团队到底意味着什么成本下降最直接的影响是把“用旗舰模型跑批处理”变成了可能。以前用 Opus 5 做一批十万条文本的清洗费用是个不小的数字很多团队只敢用来跑核心链路。换了 Step 5 Preview 之后同样预算能覆盖全量数据效果就算打个九折覆盖率和业务意义完全不一样。我见过好几个团队是这么算账的把 20% 的专业级任务留给最强闭源模型剩下 80% 的普适任务切到开源 MoE 上。综合成本能降一个数量级整体质量几乎不掉。这种混合路由的架构是当前阶段值得认真考虑的方案。另外应用层开发迭代速度会更快。模型便宜了就能放肆地跑 prompt 实验、跑批量回归测试、跑 Agent 轨迹验证不用每个测试都心疼账单。Prompt 工程和评测这件事本质上是靠反复试错堆出来的成本越低团队试错的胆子越大。5. 上手实操API 调用与本地部署全记录5.1 最快上手的方式API 直连如果不想折腾 GPU 集群第一步建议直接用开放平台的 API。Step 5 Preview 的接口兼容 OpenAI 格式用你熟悉的 SDK 就能调。from openai import OpenAI client OpenAI( base_urlhttps://api.stepfun.com/v1, api_key你的Key, ) resp client.chat.completions.create( modelstep-5-preview, messages[ {role: system, content: 你是资深后端工程师回答要简洁、可执行。}, {role: user, content: 用 Python 写一个并发限流爬虫要求支持信号量控制和超时处理。}, ], temperature0.3, max_tokens4096, ) print(resp.choices[0].message.content)几个参数建议。编码和数据处理任务temperature 设在 0.2 到 0.3输出稳定创意写作提到 0.7 以上。max_tokens 不要一上来就拉到最大先按任务规模设个合理值避免模型“话痨”式输出也避免计费失控。配合上下文缓存重复前缀多的任务能省不少钱如果你的服务是同一套 system prompt 反复调用务必确认缓存命中情况。5.2 本地部署先把显存账算明白本地部署的最大门槛是显存。600B 权重BF16 格式需要约 1.2TB 显存FP8 砍一半约 600GB4bit AWQ 量化再砍一半约 300GB 出头。哪怕量化到 4bit也要 4 张 80GB 的卡才勉强放下权重再叠加 KV cache 和激活显存实际至少要 8 张 80GB 卡。没有多卡机器的团队建议直接放弃自托管老老实实走 API。有硬件条件的话推荐用 vLLM 或 SGLang。vLLM 对 MoE 的支持已经很成熟我用下来的部署命令大概是这样的vllm serve step-5-preview \ --dtype float8 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 8 \ --max-model-len 32768几个关键参数的思路。--dtype 选 float8 能省一半显存条件是硬件支持--gpu-memory-utilization 设 0.9给 KV cache 留出余量--tensor-parallel-size 必须等于 GPU 数MoE 得靠多卡并行把权重切开--max-model-len 不建议超过 32768拉高了显存会直接撑爆。权重可以从 ModelScope 拉国内速度快比 Hugging Face 省心。5.3 部署调优与推理参数的心得跑起来之后第一件事看两个指标首 token 时延和 decode 吞吐。如果首 token 很慢多半是 prompt 太长或者 prefill 阶段计算量大如果后续生成速度上不去多半是卡间通信卡脖子。MoE 模型对节点内互联带宽极度敏感选多卡机器时优先选 NVLink 全互联的机型不要拿多台 PCIe 机器凑否则专家在卡间路由的延迟会直接拖垮生成速度。另一个我踩过的坑并发上去了以后显存里 KV cache 迅速膨胀OOM 说来就来。冷静处理的办法是调低 gpu-memory-utilization或者给 max-model-len 设个硬顶再不行就上 PagedAttention 这类显存调度机制vLLM 默认开启但要确认版本支持。推理参数方面Step 5 Preview 对采样参数比较敏感。高 temperature 时它的输出比同代模型更容易出现结构松散的问题所以结构化输出任务建议 temperature 不超过 0.4并配合 json schema 约束。代码生成我建议关掉 thinking mode或者把它配置成只输出 final answer可以省大概 30% 的 token 开销。6. 常见问题与避坑记录6.1 高频问题速查表问题原因解决办法模型权重下载特别慢Hugging Face 国内访问不稳定改用 ModelScope或配置 hf-mirror 镜像源部署后首 token 时延过高prompt 过长 / prefill 计算量大压缩历史消息使用摘要代替完整上下文生成速度慢于预期卡间通信带宽不足换成 NVLink 全互联机器确认 tensor-parallel-size 与 GPU 数一致并发一高就 OOMKV cache 占用失控调低 gpu-memory-utilization限制 max-model-lenAPI 返回 429 限流配额不足或并发过高做指数退避重试批量任务分散到低峰时段数学推理分数偏低模型长链推理能力相对弱复杂数学任务搭配 CoT prompt或路由给数学强模型输出格式经常不合规temperature 过高降到 0.3 以下使用结构化输出约束这个表看着简单每一条后面都是真金白银的教训。尤其是量化那一块我见过团队为了省显存上了 4bit结果输出质量掉到没法用。量化是有损压缩具体损失多少必须拿自己的评测集验证不能只看显存数字。6.2 实测下来的几点独门心得第一MoE 模型的 batch 策略很重要。单个任务调用的成本低但并发一多显存分配、卡间通信、路由热点都会放大。我实测的结论是宁可把并发控制在 16 以内把单请求的 max_tokens 设小也不要无脑堆并发否则 decode 时延会雪崩。第二Prompt 模板对结果质量的影响比想象中更大。Step 5 Preview 对角色设定和输出格式说明很敏感同一道题随便问和认真写 prompt效果能差出一个档次。建议团队里把 system prompt 版本化每次改动跑一遍回归测试别让模型升级变成薛定谔的效果。第三混合路由是最现实的方案。不要指望一个模型包打天下。我现在的策略是日常生成和批量处理走 Step 5 Preview复杂代码重构和深度数学推理走最强闭源模型中间加一个轻量路由层根据任务特征分流。整体成本比全部用闭源低了 80% 以上任务完成质量基本持平。最后说个很多人忽视的细节开源模型的权重版本一定要锁。Step 5 Preview 还在迭代后面可能出正式版如果你的业务跑在旧权重上升级前务必跑一遍回归集确认输出格式和行为没有变化。这种事没有捷径只能靠流程保证。我个人在实际使用中的体会是2026 年的开源模型已经过了“追赶闭源”的阶段开始真正抢占应用层的成本洼地。Step 5 Preview 能不能坐稳开源前三的位置还要看后续版本的稳定性但它把“旗舰性能 开源可部署 低成本”这三个原本很难兼得的东西放到了一起对开发者来说这本身就是最大的价值。我的建议是别只看发布会拿自己的业务数据跑一周好坏自有结论。
开源旗舰Step 5 Preview：600B MoE架构下的成本与部署实践
Step 5 Preview 这波热度我是亲眼看着起来的。周一早上打开微信群十条里有八条在聊阶跃星辰这次开源600B 总参数的 MoE 旗舰模型评测杀进开源前三单任务成本据说只有 Claude Opus 5 的八分之一。做应用的同学关心价格做研究的同学关心架构做部署的同学已经在往服务器上拉了。先说结论这个模型值得认真对待。Step 5 Preview 是阶跃星辰最新的开源旗舰总参数量 600B走 Mixture of Experts 稀疏激活路线官方口径下综合能力排在开源模型最前面那一档。它既能通过开放平台 API 直接调用也能像 DeepSeek 那样把权重下载下来自托管。这篇文章我不聊发布会PPT用实测的数据和经验把架构逻辑、评测含金量、成本算法、部署实操串起来讲给想入手的朋友一份能照着做的参考。1. 发布背景与开源旗舰格局的重排1.1 为什么 Step 5 Preview 值得专门关注先交代一下背景。阶跃星辰这家公司大家应该不陌生从 Step-1、Step-1V 一路做到 Step-2去年 Step-2 发布的时候很多做私有化部署的团队就已经在用了。这次 Step 5 Preview 的关键信息有三点总参数 600B、MoE 架构、开源。“Preview”这个后缀值得玩味。它意味着官方已经把主体能力放出来了但还在持续迭代后续可能会有更稳定的版本。这种打法在业界很常见DeepSeek-R1 当初也是先放预览版再根据社区反馈补 patch。好处是让开发者提前评估坏处是版本变化快部署时要把模型权重版本和推理框架版本一起锁死。真正让我感兴趣的是它在当下时间节点的卡位。过去提到开源旗舰大家第一反应是 DeepSeek、Qwen、Llama 这几个名字。Step 5 Preview 的入场直接把“开源第一梯队”这个牌桌重新洗了一次。对应用开发者来说多一个选择不是最关键的最关键的是这个选择在性能和成本两个维度都给出了不一样的答案。1.2 所谓“开源前三”到底在和谁比“开源前三”这个说法来自多个评测体系的综合结果。我通常看两个来源一个是海外的 Chatbot Arena 这类人类偏好榜一个是国内 OpenCompass 这类能力测试榜。两套榜的侧重点不同前者看用户体感后者看指标数字同一个模型在两个榜上的位置经常不一致。把 Step 5 Preview 放进去对比它挤掉的是上一代开源巨头的位置。目前开源阵营里能站上旗舰级的选手大概有四到五家DeepSeek 的 V3/R1 系列、Qwen 的开源大杯、Llama 的 4.x 系列加上现在这个 Step 5。说它“前三”意味着至少在综合榜单上它把其中一两家挤到了后面。这个格局变化对社区是有实质影响的。开源模型的选择一旦多起来企业反而不太敢轻易锁定某一家因为模型能力各有侧重。Step 5 的优势在于价格和部署灵活性叠加出来的综合性价比这一点我会在成本章节详细拆。这里先提个醒榜单排名只是参考真正选型一定要拿自己的业务数据跑一遍榜单分数和你实际场景的相关性往往没有想象中那么高。2. 技术架构拆解600B MoE 的设计逻辑2.1 MoE 架构到底在讲什么很多朋友一听到“600B”就以为这是个巨型稠密模型这是最大的误解。MoEMixture of Experts混合专家和传统稠密模型的本质区别在于稠密模型处理每个 token 时全部参数都要参与计算MoE 模型则是把网络拆成很多“专家”子网络每个 token 进来之后由一个门控路由网络router决定激活哪些专家。打个生活化的比方一家一万人的咨询公司接一个餐饮客户的项目时不会让一万人全上而是派餐饮组、财务组、法务组里抽出来的一支二十人小队去干。公司总人力是一万但实际干活的是二十人。MoE 的“总参数量 600B”就是公司总人力而真正参与推理的“激活参数”才是干活那批人。具体到计算流程输入 token 先经过共享层然后由一个轻量级的 router 网络计算 token 与每个专家的匹配度选出得分最高的 Top-K 个专家把这几个专家的输出加权合并。K 一般取 2 到 4。这意味着不管总参数多大单次前向计算的 FLOPs 只和激活参数相关这也是 MoE 能做大参数而不爆炸的核心原因。2.2 600B 总参数的真实含义600B 总参数意味着模型容量足够大记忆能力和模式覆盖能力都堆上去了但代价也非常直接权重文件大、显存占用高、训练成本高。训练阶段的优化器状态、梯度、通信开销全部按照总参数量算据我了解这种规模级别的模型预训练算力投入是以万卡 GPU 月为单位的。这是大厂才能打的仗普通团队不用去想复现训练重点看推理侧的账。激活参数是多少官方这次没有高调宣传按同级别 MoE 的行业惯例激活比例通常在总参数的一到两成之间。我按中间值粗估600B 的模型激活参数大概在 50B 到 80B 这个区间。这个数字决定了推理时单 token 的计算量也直接决定了每台 GPU 上能跑多快。这也是为什么 600B MoE 可以在 8 卡机器上勉强跑起来而同规模稠密模型想都不要想。还有个容易忽略的细节MoE 模型的规模优势主要在“知识容量”上而不是“单步推理深度”上。它更适合大量知识检索、多语言、长尾任务覆盖对需要极深链式推理的任务效果更多取决于训练数据和路由质量。这也是为什么有些 MoE 模型在数学题上不一定打得过同代小参数稠密模型。2.3 架构带来的核心优势与潜在代价MoE 最直接的收益是推理成本下降。推理时只算激活参数同时共享层和 router 的开销很小所以单 token 计算量大概只有同总参数稠密模型的五分之一到十分之一。这个比例直接反映在时延和电费上是“单任务成本只有 Opus 5 八分之一”的技术基础。代价也有。第一是显存占用不会因为稀疏激活而减少600B 的权重该多大还是多大必须要用模型并行把权重切到多张卡上。第二是 MoE 对卡间通信带宽非常敏感专家分布在不同卡上token 在不同专家之间跳转就要走卡间互联带宽不够就会变成“算得快但传得慢”整体吞吐上不去。第三是训练阶段容易出现专家不平衡部分专家被频繁选中部分专家长期失业需要在训练目标和损失函数上做专门约束。从体验上讲MoE 模型很少出现“某一个子领域特别强”的偏科现象因为专家分工天然把不同能力拆开了。但是如果你把它当稠密模型用把 max_tokens 拉特别长或者并发一上来显存和带宽的瓶颈就会立刻暴露。这些坑我在部署章节会详细说。3. 性能实测与“开源前三”的含金量3.1 榜单数字应该怎么解读判断一个大模型值不值得用我一般看四类任务知识理解、数学推理、代码生成、Agent 工具调用。下面是社区复测数据和我自己跑的粗略结果注意分数只能代表一个侧面不同框架、不同 prompt 模板下浮动都很正常最终以官方 release notes 为准。评测维度Step 5 Preview社区汇总DeepSeek-R1Qwen 开源大杯Claude Opus 5闭源参考知识理解MMLU-Pro 等85% 左右87% 左右84% 左右90% 左右数学推理AIME 类65% 左右80% 左右70% 左右90% 左右代码生成SWE-bench Verified65% 左右50% 左右62% 左右75% 左右工具调用与多轮指令遵循第一梯队中上第一梯队顶尖开源可部署是是是否几个信号值得注意。第一Step 5 Preview 的知识理解和代码能力可以摸到开源第一梯队这是它“前三”排名的支撑。第二数学推理明显还不是它的最强项和 DeepSeek-R1 比有差距这一点在选型时一定要想清楚如果你的业务大量依赖复杂数学推导得再掂量掂量。第三工具调用能力是它的隐藏强项我在实际 Agent 场景里测下来比不少同代开源模型稳。3.2 与 Opus 5 的差距到底在哪把开源旗舰和闭源旗舰放一起比差距是客观存在的。Claude Opus 5 在推理深度、上下文理解、指令遵循的一致性上仍然压着开源模型一头。拿复杂代码重构任务来说Opus 5 一次性给出可运行代码的概率更高Step 5 Preview 偶尔需要第二轮纠错长文档的因果推理它的稳定性也略逊。但差距的量级在缩小。以前开源模型和闭源旗舰差两个身位现在基本是半个到一个身位。对于大多数日常任务——内容生成、SQL 编写、代码审查、客服问答、知识库检索——这个差距已经不明显了。我自己做过的压测里把同一批 prompt 分别喂给两个模型输出质量让匿名评审打分差距基本在 10 个百分点的偏好率以内。这个“靠近”的意义在于很多原本只能靠闭源 API 的场景现在有了私有化替代方案。比如金融、政务、医疗这类对数据出境有严格要求的场景闭源模型再强也不能直接用开源模型哪怕差一点点能用、能部署、能合规就是硬道理。3.3 我自己跑的几类真实场景代码审查。我拿一个真实项目里带着并发 bug 的 Go 代码丢给它Step 5 Preview 能指出 goroutine 泄漏的具体位置还能给出带超时控制的修复方案这水平已经可以直接进 CI 当个初筛工具了。长文本总结。给它一份 50 页的产品需求文档它输出的结构化摘要层次很清楚关键数据点没有丢但偶尔会把次要细节当重点这个需要用 prompt 明确指定摘要的层级权重。SQL 生成。让它基于三张关联表写一个带窗口函数的统计查询第一次就能跑通效率比手写快得多。这类规范化任务恰恰是 MoE 模型的强项因为训练语料里这类样本足够多。Agent 场景。我写了个简单的多工具调度测试让模型根据用户意图选择调用天气、计算器、搜索三个工具连续跑 50 轮工具选择错误率很低参数格式也都对。这是我最看重的点毕竟 2026 年的应用开发谁不接 Agent 工作流。4. 单任务成本“八分之一”是怎么算出来的4.1 把“单任务成本”拆开看先别急着信“八分之一”这个数字先搞清楚它是怎么算的否则很容易被带节奏。单任务成本 输入 token 量 × 输入单价 输出 token 量 × 输出单价 如果有缓存费用 如果是 Agent 多轮调用轮次叠加成本。举个例子。一个典型的编码任务假设输入 2K token输出 1.5K token。Claude Opus 5 的公开报价是输入约 15 美元/M token、输出约 75 美元/M token约合人民币 105 元和 520 元每百万 token那么这一个任务大约花费2/1000 × 105 1.5/1000 × 520 ≈ 0.21 0.78 ≈ 0.99 元人民币。Step 5 Preview 按国内 API 定价来算输入按 2 元/M token、输出按 12 元/M token 估算同样任务2/1000 × 2 1.5/1000 × 12 ≈ 0.004 0.018 ≈ 0.022 元。0.99 除以 0.022大约是 45 倍已经超过八分之一。为什么官方说的只有八倍差距因为 Opus 5 这类模型在复杂任务里输出质量更高、可能需要更少的后处理如果按“任务完成度 总费用”综合折算差距会缩小。另外官方口径如果是按国内整体任务场景、加入上下文缓存之后算的比例也会变化。所以“八分之一”是个业务口径不是简单的 token 单价倍数理解了计算逻辑你才能拿自己的业务套公式。成本项Step 5 Preview估算Claude Opus 5公开价估算输入单价2 元/M token约 105 元/M token输出单价12 元/M token约 520 元/M token单编码任务费用约 0.022 元约 0.99 元私有化部署溢价比只需算力电费不支持4.2 成本优势背后的技术账成本差异不全是定价策略架构起了决定性作用。MoE 推理单 token 只算激活参数假设激活 60B相比 600B 稠密模型前向计算量直接差一个数量级。计算量少了单卡吞吐就高单位时间能服务的用户就多摊到每个 token 上的算力成本自然低。另一个容易忽略的点是批处理效率。MoE 模型的 router 和共享层计算量小可以把更多显存预算留给 KV cachebatch size 能开得更大。理论上batch 越大GPU 利用率越高单 token 成本进一步下降。这也是为什么 MoE 模型做高并发 API 服务特别划算。私有化部署则是成本优势的第二层。API 价格里包含服务商利润自托管只需要承担算力、电费、运维人力。600B MoE 在 8 卡 H 系列机器上用 FP8 或量化跑单任务摊到硬件成本上可以比 API 再低不少。当然部署门槛高适合有运维能力的团队这点后面讲实操时会展开。4.3 对中小团队到底意味着什么成本下降最直接的影响是把“用旗舰模型跑批处理”变成了可能。以前用 Opus 5 做一批十万条文本的清洗费用是个不小的数字很多团队只敢用来跑核心链路。换了 Step 5 Preview 之后同样预算能覆盖全量数据效果就算打个九折覆盖率和业务意义完全不一样。我见过好几个团队是这么算账的把 20% 的专业级任务留给最强闭源模型剩下 80% 的普适任务切到开源 MoE 上。综合成本能降一个数量级整体质量几乎不掉。这种混合路由的架构是当前阶段值得认真考虑的方案。另外应用层开发迭代速度会更快。模型便宜了就能放肆地跑 prompt 实验、跑批量回归测试、跑 Agent 轨迹验证不用每个测试都心疼账单。Prompt 工程和评测这件事本质上是靠反复试错堆出来的成本越低团队试错的胆子越大。5. 上手实操API 调用与本地部署全记录5.1 最快上手的方式API 直连如果不想折腾 GPU 集群第一步建议直接用开放平台的 API。Step 5 Preview 的接口兼容 OpenAI 格式用你熟悉的 SDK 就能调。from openai import OpenAI client OpenAI( base_urlhttps://api.stepfun.com/v1, api_key你的Key, ) resp client.chat.completions.create( modelstep-5-preview, messages[ {role: system, content: 你是资深后端工程师回答要简洁、可执行。}, {role: user, content: 用 Python 写一个并发限流爬虫要求支持信号量控制和超时处理。}, ], temperature0.3, max_tokens4096, ) print(resp.choices[0].message.content)几个参数建议。编码和数据处理任务temperature 设在 0.2 到 0.3输出稳定创意写作提到 0.7 以上。max_tokens 不要一上来就拉到最大先按任务规模设个合理值避免模型“话痨”式输出也避免计费失控。配合上下文缓存重复前缀多的任务能省不少钱如果你的服务是同一套 system prompt 反复调用务必确认缓存命中情况。5.2 本地部署先把显存账算明白本地部署的最大门槛是显存。600B 权重BF16 格式需要约 1.2TB 显存FP8 砍一半约 600GB4bit AWQ 量化再砍一半约 300GB 出头。哪怕量化到 4bit也要 4 张 80GB 的卡才勉强放下权重再叠加 KV cache 和激活显存实际至少要 8 张 80GB 卡。没有多卡机器的团队建议直接放弃自托管老老实实走 API。有硬件条件的话推荐用 vLLM 或 SGLang。vLLM 对 MoE 的支持已经很成熟我用下来的部署命令大概是这样的vllm serve step-5-preview \ --dtype float8 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 8 \ --max-model-len 32768几个关键参数的思路。--dtype 选 float8 能省一半显存条件是硬件支持--gpu-memory-utilization 设 0.9给 KV cache 留出余量--tensor-parallel-size 必须等于 GPU 数MoE 得靠多卡并行把权重切开--max-model-len 不建议超过 32768拉高了显存会直接撑爆。权重可以从 ModelScope 拉国内速度快比 Hugging Face 省心。5.3 部署调优与推理参数的心得跑起来之后第一件事看两个指标首 token 时延和 decode 吞吐。如果首 token 很慢多半是 prompt 太长或者 prefill 阶段计算量大如果后续生成速度上不去多半是卡间通信卡脖子。MoE 模型对节点内互联带宽极度敏感选多卡机器时优先选 NVLink 全互联的机型不要拿多台 PCIe 机器凑否则专家在卡间路由的延迟会直接拖垮生成速度。另一个我踩过的坑并发上去了以后显存里 KV cache 迅速膨胀OOM 说来就来。冷静处理的办法是调低 gpu-memory-utilization或者给 max-model-len 设个硬顶再不行就上 PagedAttention 这类显存调度机制vLLM 默认开启但要确认版本支持。推理参数方面Step 5 Preview 对采样参数比较敏感。高 temperature 时它的输出比同代模型更容易出现结构松散的问题所以结构化输出任务建议 temperature 不超过 0.4并配合 json schema 约束。代码生成我建议关掉 thinking mode或者把它配置成只输出 final answer可以省大概 30% 的 token 开销。6. 常见问题与避坑记录6.1 高频问题速查表问题原因解决办法模型权重下载特别慢Hugging Face 国内访问不稳定改用 ModelScope或配置 hf-mirror 镜像源部署后首 token 时延过高prompt 过长 / prefill 计算量大压缩历史消息使用摘要代替完整上下文生成速度慢于预期卡间通信带宽不足换成 NVLink 全互联机器确认 tensor-parallel-size 与 GPU 数一致并发一高就 OOMKV cache 占用失控调低 gpu-memory-utilization限制 max-model-lenAPI 返回 429 限流配额不足或并发过高做指数退避重试批量任务分散到低峰时段数学推理分数偏低模型长链推理能力相对弱复杂数学任务搭配 CoT prompt或路由给数学强模型输出格式经常不合规temperature 过高降到 0.3 以下使用结构化输出约束这个表看着简单每一条后面都是真金白银的教训。尤其是量化那一块我见过团队为了省显存上了 4bit结果输出质量掉到没法用。量化是有损压缩具体损失多少必须拿自己的评测集验证不能只看显存数字。6.2 实测下来的几点独门心得第一MoE 模型的 batch 策略很重要。单个任务调用的成本低但并发一多显存分配、卡间通信、路由热点都会放大。我实测的结论是宁可把并发控制在 16 以内把单请求的 max_tokens 设小也不要无脑堆并发否则 decode 时延会雪崩。第二Prompt 模板对结果质量的影响比想象中更大。Step 5 Preview 对角色设定和输出格式说明很敏感同一道题随便问和认真写 prompt效果能差出一个档次。建议团队里把 system prompt 版本化每次改动跑一遍回归测试别让模型升级变成薛定谔的效果。第三混合路由是最现实的方案。不要指望一个模型包打天下。我现在的策略是日常生成和批量处理走 Step 5 Preview复杂代码重构和深度数学推理走最强闭源模型中间加一个轻量路由层根据任务特征分流。整体成本比全部用闭源低了 80% 以上任务完成质量基本持平。最后说个很多人忽视的细节开源模型的权重版本一定要锁。Step 5 Preview 还在迭代后面可能出正式版如果你的业务跑在旧权重上升级前务必跑一遍回归集确认输出格式和行为没有变化。这种事没有捷径只能靠流程保证。我个人在实际使用中的体会是2026 年的开源模型已经过了“追赶闭源”的阶段开始真正抢占应用层的成本洼地。Step 5 Preview 能不能坐稳开源前三的位置还要看后续版本的稳定性但它把“旗舰性能 开源可部署 低成本”这三个原本很难兼得的东西放到了一起对开发者来说这本身就是最大的价值。我的建议是别只看发布会拿自己的业务数据跑一周好坏自有结论。
