这几天开源AI圈最热的新闻几乎都集中在阶跃星辰的 Step 5 Preview 上。600B 总参数的 MoE 架构、开源权重直接进入开源模型前三、官方给的单任务成本只有 Opus 5 的八分之一——这三个信息放在一起早就不是一次例行版本更新而是把“大模型能不能既开源、又够强、还便宜到愿意私有化部署”这个问题重新摆在了台面上。我身边不少团队都在问同一个问题这个模型到底值不值得接成本优势是从哪来的自部署又会踩到哪些坑。这篇内容就不复述发布稿了只从一个持续在折腾开源模型的从业者角度把它拆开来看600B MoE 到底意味着什么开源榜单的“前三”怎么读八分之一的成本是怎么算出来的以及真要把这套东西跑起来需要做哪些准备。1. 600B 总参数和 MoE 架构先搞懂这一步后面才不会算错账1.1 为什么总参数 600B 不等于显存要装 600B很多朋友第一次看到 600B 参数第一反应是“这得多少张卡才能跑起来”。这句话对也不对。对的地方在于模型权重确实是 600B 的总量按 BF16 精度算就是 1.2TB 的权重文件单卡 80G 显存想一次放下至少得 16 张卡。不对的地方在于MoE 架构里600B 是所有专家的总参数之和每次处理一个 token 时并不是所有参数都在参与计算。门控网络会先看当前输入的类型然后把 token 分发给少数几个“专家”子网络。说人话就是一个公司里挂了六百个顾问的名号但每个具体问题只会叫醒其中十几个人来开会其余人该干嘛干嘛。Step 5 Preview 的具体专家配置和激活参数官方 README 里没有给出特别详细的路由表但按目前开源 MoE 的常见做法激活参数一般控制在总参数的几十分之一到三分之一之间。也就是说它的实际计算强度远低于同规模稠密模型。这一点非常重要显存占用看总量计算成本看激活量。1.2 稀疏激活是怎么同时省计算又省钱的一个稠密的 600B 模型每个 token 都得过一遍全部 600B 参数FLOPs 高得吓人。MoE 的思路是在每一层放很多小专家路由器只需要挑几个专家出来算。带来的直接收益是同样一张 GPU 上单位时间能处理的 token 数比同参数量稠密模型多得多这就是“稀疏激活”的威力。也因此MoE 模型在推理时对显存容量的需求仍然和总参数挂钩但是对算力的需求只和激活参数挂钩。于是会出现一个很反直觉的现象600B MoE 的“显存贵”但“算力便宜”。这也是为什么很多团队敢自部署 600B 级别的模型——他们买的不是 16 张卡的全部算力而是那张卡上的大容量和高速显存带宽。理解了这一层再看后面的成本账会顺很多。1.3 显存估算的公式和一张表先给出一个通用的显存估算公式所有开源模型都可以套用权重显存(GB) ≈ 总参数量(以10亿为单位) × 单参数位宽(字节) 激活/KV Cache 另计按这个公式600B 模型在不同精度下大概是这个量级精度单参数占用600B 权重总显存大致需要的 80G 卡数BF16/FP162 字节约 1200 GB16 卡FP81 字节约 600 GB8 卡INT4/NF40.5 字节约 300 GB4-5 卡这里还没算 KV Cache。上下文越长、并发越高KV Cache 占的显存越夸张。所以我在实际部署时一般先把权重显存抠出来再按 20% 的余量预留 KV Cache。如果 16 卡跑 BF16长上下文场景下也得把max-model-len往下压否则照样 OOM。1.4 “全部参数常驻显存”的常见误区回到热门问题MoE 架构要全部参数进显存吗从原理上说路由是动态的任何专家都可能被分发到所以部署时所有参数都必须“可访问”。但这个“可访问”不一定是“常驻 GPU 显存”。可以把不常用的专家权重放到 CPU 内存需要时再换入显存也可以把不同专家切到不同 GPU 上用专家并行解决单卡装不下的问题。这样做有一个代价Offload 和跨卡传输都会带来额外延时。如果你的场景是实时 API我不建议用 CPU offload 硬撑但如果是离线批量任务牺牲一点速度换显存容量完全可以接受。我踩过的坑是有人只把权重 offload 到内存结果并发一上来路由器疯狂换入换出服务直接卡死。Offload 适合离线不适合对抗性的并发压力。2. “开源前三”是怎么排出来的榜单位置只说明下限不说明上限2.1 主流开源模型榜单有哪些口径“开源前三”这个说法来自哪份榜单官方没有在标题里点名。我这边跟踪到的几个主要口径是Arena 类 ELO 盲测、Artificial Analysis 的智能指数、以及一些综合基准榜单。不同榜单的侧重不同盲测榜单偏向对话体感和综合智力基准榜单偏向代码、数学、指令跟随等具体能力Artificial Analysis 这类还会把价格和推理速度加进去做性价比排名。所以看到一个“排名前三”我第一件事不是截图发群而是先看它的具体口径。Step 5 Preview 能在多个口径下都进开源前三说明它至少没有明显短板这是个非常不错的信号。不过任何榜单都只能代表评测环境里的表现你真正业务里的数据分布跟榜单的题目分布很可能相差很远。2.2 从榜单到具体任务还是要回到自己的场景测我自己的测试流程比较老派先准备 20 个跟业务强相关的真实任务覆盖长文总结、代码生成、结构化 JSON 输出、多轮工具调用这几个维度然后把 Step 5 Preview 和当前线上基座在同一批输入上各跑一遍只对比结果质量、稳定性和耗时。这次跑下来的整体感觉是它的指令跟随和代码能力对得上“第一梯队开源模型”的描述尤其是复杂指令拆解方面比不少同体量开源模型要细。但我要提醒一句这种“感觉”不能作为选型依据你的任务集跟我的任务集不一样必须自己跑一遍。榜单的意义是帮你圈定候选范围而不是替你写结论。2.3 开源旗舰横向对比表为了方便选型我整理了一份当前开源 Mixture-of-Experts 旗舰模型的简表这里就不写具体榜单分数了因为不同口径分数变动太快容易误导人模型总参数/激活参数是否开源第一梯队位置主要部署门槛Step 5 Preview约 600B MoE开源综合前排权重较大至少 8 卡起步DeepSeek 系列 MoE数百 B / 几十 B 激活开源中文与数学强项多卡通信要求高Qwen 系列旗舰 MoE数百 B 级开源中文与工具调用强看具体版本有些支持量化部署Llama 系列旗舰405B 稠密开源通用英语生态好稠密模型算力开销大这张表的价值不在于“谁排第一”而在于让你注意到有的模型是总参数大但激活小有的模型是纯稠密但总参数也大部署门槛和单 token 成本完全不同。选型时不能只看总参数排名要看激活参数和你的任务类型是否匹配。2.4 不要看到排名就换基座换基座是一个系统工程不只是把 API 地址换掉那么简单。Prompt 要重调、后处理逻辑要重测、真实业务指标要灰度对比。我的建议是如果现有系统稳定不着急换。先把新模型挂在旁路跑一周记录 bad case 和成本数据等它明显胜出再切。另外也别忘了看一眼开源协议对商业使用的限制这一步虽然枯燥但真到上线时能省很多麻烦。3. 成本差距的八分之一是怎么来的按 token 价格和硬件折旧各算一遍3.1 先把“单任务成本”拆成三项官方说的“单任务成本为 Opus 5 的八分之一”这里的“单任务成本”不是一个抽象的广告词而是可以拆成三个部分的单任务成本 输入 token 费用 输出 token 费用 固定开销分摊固定开销包括服务部署、上下文缓存、出错的回退重试等。如果两个模型完成的是同一个任务输入输出 token 数量接近那么差距主要来自单价和算力成本。Opus 5 这类商业闭源旗舰价格里已经包含了推理集群、调度、客服以及利润而 Step 5 Preview 因为开源给了团队第二个选择按 API 用或者干脆自部署。3.2 API 计费场景的价格估算先看按 token 计费的情况。假设一个任务平均需要 5K 输入 token产生 10K 输出 token。Opus 5 如果按输入约 15 美元/百万 token、输出约 75 美元/百万 token 的水平来算单任务的 API 费用是输入费用 5000 × 15 / 1000000 0.075 美元 输出费用 10000 × 75 / 1000000 0.75 美元 单任务合计 ≈ 0.825 美元Step 5 Preview 如果用官方 API价格一般会明显低于这个水平如果走自部署那就是硬件成本而非 token 单价。官方给到“八分之一”说明在同样的任务质量目标下它的端到端成本能做到 Opus 5 的 0.125 倍左右。我自己拿业务数据回算不同任务结构下这个比例会在六分之一到十分之一之间波动但量级是对的。3.3 自部署场景的硬件成本估算自部署的成本要按设备折旧和运维分摊来算。拿 16 卡 H100 的服务器举例机器、网络、机房、电费、运维加在一起按月成本约 15 万元人民币算一个月按 730 小时就是约 205 元/小时。如果单任务需要在这台机器上跑 30 秒硬件分摊成本大概是205 元/小时 × 30 秒 ÷ 3600 秒 ≈ 1.7 元同样一个任务如果交给 Opus 5 的 API按标准价折算成人民币大约十几元。两边一除确实能压到八分之一上下。当然真实环境里还要考虑并发如果一台 16 卡机器同时跑多个任务单任务成本会继续下降反过来如果任务很短但固定开销很高比例就会上浮。3.4 为什么 MoE 比同等总参的稠密模型更容易压低成本成本优势的本质来自稀疏激活。600B 的 MoE虽然每个 token 也要访问全部权重所在的内存空间来准备路由但实际参与矩阵乘法的参数只有激活的那一小部分。这意味着同样的显存容量下MoE 能换来远高于稠密模型的 token 吞吐。再加上开源模型不需要你为每次调用支付 API 加价算力成本就直接落到硬件价格上。这里有个容易忽略的点MoE 的减速带在通信。专家分布在多张卡上token 要被路由到对应专家所在的计算卡这个过程叫 All-to-All它消耗的是网络带宽而不是算力。如果你的集群只有千兆以太网多卡 MoE 的实际吞吐会很难看有了 NVLink 或 InfiniBand才谈得上成本优势。3.5 一个可以自己套用的成本测算模板想验证“八分之一”适不适用于你的业务可以按下面这个模板填数项目你的数值平均单任务输入 token 数例如 5000平均单任务输出 token 数例如 10000商业旗舰 API 总价填入最新刊例价自部署机器月成本包含折旧和运维机器同时并发的任务数影响单任务分摊单任务平均耗用时长用压测拿到有了这组数就能算出你自己的“单任务成本比例”。我强烈建议不要只抄官方结论因为长上下文任务和短任务、高并发和低并发算出来的比例可能差出好几倍。4. 从下载到跑通Step 5 Preview 部署实操记录4.1 获取权重的合规渠道与镜像加速按开源模型一贯的发布方式Step 5 Preview 的权重会同步到主流模型社区。国内网络环境下我一般优先走 ModelScope 社区下载速度稳定断点续传也方便如果用 Hugging Face 官方源感觉慢可以配置HF_ENDPOINT指向镜像站再把模型文件拉到本地目录。下载完第一件事是做完整性校验对照官方仓库给的 SHA256 值核对一遍。大模型权重的文件动辄几百 GB转链下载很容易出现静默损坏加载时报错不直观排查起来反而更费时间。路径方面建议保持一个固定的模型目录比如/data/models/Step-5-Preview/后续启动命令、量化转换、缓存管理都会省心不少。4.2 用 vLLM 起服务的最小配置如果你的显存足够最简单的启动方式是用 vLLM 起 OpenAI 兼容服务。假设你有 8 张 80G 卡模型按 FP8 精度加载一个可用的启动命令大概长这样vllm serve /data/models/Step-5-Preview/ \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --trust-remote-code参数解释一下--tensor-parallel-size表示用几张卡做张量并行--max-model-len是最大上下文长度直接决定 KV Cache 上限--gpu-memory-utilization表示允许程序占用的显存比例我一般留 10% 给驱动和应急开销--trust-remote-code是因为部分模型仓库里带有自定义代码必须显式信任才能加载。如果机器是 16 卡 80G并且想跑 BF16 原始精度就把--tensor-parallel-size改成 16。显存不足时先不要急着加卡可以优先看量化方案是否支持。4.3 显存不够时的三套备选方案显存不够时按性价比从高到低排我的建议是量化到 FP8权重显存直接从 1.2TB 降到 600GB大多数 MoE 模型在 FP8 下质量损失很小。注意检查推理引擎是否原生支持这个模型的 FP8 权重不要自己在网上找第三方转换脚本。降低--max-model-len比如从 128K 降到 32KKV Cache 会成倍收缩。很多业务其实用不到超长上下文砍下来效果立竿见影。改用 SGLang同样条件下SGLang 对 MoE 的调度和显存管理在某些场景下比 vLLM 更细实测偶有 10% 以上的吞吐提升。它和 vLLM 的启动参数类似可以互相切换做对比。最后一招才是 CPU offload前面也说了它适合离线任务不适合在线服务。4.4 多卡通信与 MoE 负载均衡的坑MoE 部署中最隐蔽的坑是 All-to-All 通信。启动时你看到tensor-parallel-size 8以为是简单切分模型实际上 token 每经过一层都要根据路由结果在卡之间交换数据。这个通信量跟激活规模成正比带宽不够就全部卡在网络上。单机 8 卡用 NVLink 还好跨节点就要求 RDMA 网络。我见过团队用普通万兆网卡跑 MoE吞吐只有 NVLink 环境的三分之一第一反应是“模型有问题”查了半天才发现瓶颈在网络。另一个值得了解的是负载均衡。MoE 训练时会加入负载均衡损失让路由器不要把所有 token 都丢给同一个专家。部署时推理引擎也会做类似的调度优化避免某张卡上的专家过热、其他卡闲着。如果你自己写路由或魔改加载代码可能会破坏这种均衡表现就是部分卡利用率 100%、部分卡吃不满。所以在没有明确必要的情况下不要魔改路由逻辑用官方推理框架的默认调度就好。5. 开源旗舰之后选型、落地与后续值得盯的事5.1 这类模型到底适合谁用Step 5 Preview 这种 600B 级别的开源 MoE并不适合所有团队。它最适合的是那些对数据隐私非常敏感、同时对模型质量要求很高的业务内部知识库问答、代码审查助手、长文档分析、高质量合成数据生成。私有化部署意味着你的 Prompt、员工提问、业务上下文都不需要经过第三方 API这一点在不少行业里是硬要求。它也适合作为 Offline 批处理引擎晚上跑一批任务把结果落库第二天早上再加载。这种场景对时延不敏感可以把 16 卡机器的吞吐榨干单任务成本能压得很低。反过来说如果你只是一个几十并发的小应用大部分请求都是简单问答直接上一台 16 卡 MoE 反而是浪费。5.2 大多数业务用不到 600B小模型的分工近一年开源小模型进步非常快像 Qwen 系列的小 MoE 模型激活参数只有几十亿但处理日常任务已经非常够用。一个务实的架构是双轨制先让一个小模型做“哨兵”快速判断请求复杂度简单问题直接回答复杂问题再转发给 Step 5 Preview 这类大模型。这样既能保证复杂任务的回答质量又能控制绝大多数请求的延迟和成本。我在实际项目里就是这么做的整体成本大致能再降一半。小模型负责效率大模型负责上限两者不是替代关系而是分工关系。很多团队一听到 600B 旗舰开源立刻打算把全部流量切过去这是最容易被成本反噬的做法。5.3 怎么验证模型值不值得换最后给一个稳妥的验证路径按这个顺序做基本不会出大错先准备 100 到 200 条真实业务数据覆盖典型场景和边界情况。用当前线上模型跑一遍把结果留存作为基线。用 Step 5 Preview 跑同样的数据逐条对比质量和格式稳定性。对明显有优势的场景做小流量灰度比如 1% 的线上请求切过去。观察一周对比业务指标和成本账单再决定是否逐步放大流量。这个方法看起来慢但能帮你避开“换了基座之后才发现某个边缘场景崩了”的尴尬。大模型项目的成败往往不在平均分而在最差的那几个 bad case。最后分享一个我操作中的体会600B 开源 MoE 带来的真正变化不是某一个基准分数涨了多少而是让团队第一次有了“自己掌控旗舰模型成本”的可能性。建议先别急着把整个业务迁过去拿它做数据生成、做评测、做第二条推理链路等跑通了再逐步放量。这种节奏通常比一上来就大规模替换要稳得多。