Step 5 Preview深度解析：600B MoE架构、百万上下文与部署实践

1. Step 5 Preview 的定位600B 规模、MoE 架构与“开源前三”的说法从哪来1.1 怎么理解“600B 参数”和“Step 5 Preview”这个层级阶跃星辰这半年在开源圈里的存在感一直不低但这次 Step 5 Preview 的动静明显更大。标题里的几个关键词值得先拆开看600B 总参数量、MoE 架构、百万级上下文支持以及最容易被拿来当话题的“冲击全球开源模型前三梯队”。先说“600B 参数”这个概念。600B 也就是 6000 亿参数放在开源模型里属于绝对的大体量。但这个数字本身需要区分两个维度一个是模型总参数另一个是单次推理时真正参与计算的参数。总参数是“家底盘”参与计算的是“干活的人”——MoE 架构存在的意义本质上就是把这两者拉开距离。“Preview”这个名字也说明一些问题。它不是常规的正式版命名更像是在完整版之前放出来给社区试水的一个版本。这类 Preview 版本通常意味着核心训练管线已经跑通但评测数据还没完全整理完毕或者有些长尾能力仍在收尾。对开发者来说Preview 版反而有个好处——可以提前进场做适配等正式版出来的时候周边工具链基本已经就绪。1.2 “全球开源模型前三梯队”目前的玩家是谁要讨论这个 Windows 市值是不是合理先得把参照系摆出来。过去两年大家默认的开源第一梯队大致包括 Llama、DeepSeek、Qwen再往上有 Mistral、Mixtral 系列作为有争议的替代候选。到这轮新的焦点是充满安全合规性意义的模型有必要的背景。目前考虑范围顺序上有争议但大体会包含面向代码的专用模型、长上下文 agent 型模型、以及能跑端到端推理的大 MoE比如 DeepSeek V3 系列的持续迭代。Step 5 Preview 想挤进前三梯队它的底气主要在于两个指标一是 600B 加 MoE 的组合证明训练工程能力已经到位能压住大规模混合专家训练的稳定性二是百万级上下文如果真的可用那它在长文档、超长代码库、多轮 Agent 场景里会有一个别人不容易追的差异化长板。但话说回来参数大、上下文长都只是入场券。真正的第一梯队得看推理效率、工具链成熟度、生态适配和实际业务落地的多少。这一块我会在后面几章详细拆这也是整篇文章想重点讲清楚的事情。2. 从 Dense 到 MoE为什么到了 600B 这个体量架构必须先换2.1 Dense 模型的收益递减和训练成本上限先讲一个反直觉的现象模型参数越多按理说能力越强但 Dense 架构下这个收益是边际递减的。Dense 模型每加一层参数所有 token 都要过一遍全部权重训练成本和推理成本都按线性甚至超线性上升。到了 500B 这个级别想要靠堆 Dense 参数继续提升几个点的评测分数投入产出比已经非常难看。600B 的 Dense 模型意味着在训练时每个 token 都要更新 6000 亿个参数在推理时每个 token 也要计算 6000 亿次浮点运算。这个数字不是不能做但对卡的数量、互联带宽、显存容量都有极高的要求。绝大多数团队根本没有这个资源就算有训练一个 600B Dense 模型的电费也会让人冷静下来。所以像 DeepSeek V3、Mixtral 这些模型才会转向 MoE。Step 5 Preview 用 600B 总参数 MoE 方案本质上也是同一套逻辑用更多总参数来储备知识但每次只激活一部分让推理成本维持在可控范围。2.2 总参数 600B 不等于推理负担 600B激活参数的意义这里要重点区分“总参数”和“激活参数”。MoE 模型内部有多个专家网络每个 token 进模型时路由器只选择其中一小部分专家来计算。比如一个大体量 MoE 模型可能包含 256 个专家但每个 token 只激活 top-4 或 top-6加上共享专家真正参与计算的参数量可能只有总参数的十分之一左右。用通俗一点的方式理解600B 总参数相当于一个公司有 6000 名员工但处理单个任务时只抽调其中 400 人组队干活。员工的档案都保存在公司数据库里但现场出勤的只有那一小撮。这就是为什么 MoE 能用更低的推理成本去支撑更大的知识容量。打个比方类似结构的模型通常会做到 600B 总参数、60B 左右激活参数。这 60B 的激活参数决定了一次推理需要多少 FLOPs也就决定了单卡能跑多快、需要多大的显存。总参数 600B 决定的是模型的“知识天花板”激活参数 60B 决定的才是“跑起来多累”。2.3 MoE 架构带来的隐忧显存占用并没有减少看到这里可能有人会兴奋MoE 推理成本低那是不是 600B 模型也能像小模型一样随便部署恰恰相反MoE 最大的陷阱在于总参数虽然不全部参与计算但权重文件一个都不能少。因为每个专家都可能被路由到哪怕是那些在当前 batch 里没有被选中的专家它们的权重也必须在显存里等着。你不能说“这批 token 没走专家 12那我把专家 12 的权重先挪到硬盘上”因为下一个 token 可能就走专家 12。频繁换入换出性能会直接崩掉。所以 MoE 对显存的压力其实和 Dense 模型是同一级别的。600B 总参数FP16 精度下光权重就是 1.2TB 左右这个体量单卡根本装不下需要多卡张量并行或者 CPU offload。很多人看到“MoE 省显存”的说法其实是被“节省计算量”和“节省显存”这两件事搞混了。这里单独把显存账本算清楚对后面部署部分的理解非常有帮助项目Dense 600BMoE 600B激活60B权重存储全部参数都需要全部参数都需要激活参数600B约 60B单 token 计算量极高低约一个数量级显存压力高高没本质缓解推理吞吐低高因为计算量小这就是为什么我看一个 MoE 模型从来不看它说自己“多大”而是看两个数字总参数多少、激活参数多少。这两个数字能直接告诉我它在什么显卡上能跑、吞吐能做到多少、推理成本大概是什么量级。Step 5 Preview 的 600B 也一样评测再好看最终考验的是部署侧怎么把这 1.2TB FP16 权重安排明白。3. 百万级上下文位置编码、KV Cache 和推理基础设施的三重挑战3.1 从 128K 延长到 1M不是简单把长度参数调大百万级上下文很多人的第一反应是把 RoPE theta 改大一点训练时把序列长度拉长不就行了吗如果真这么简单那大家早就全部 1M 了。实际上从 128K 扩展到 1M要解决的问题是成体系的三层结构位置编码的外推能力、注意力计算的成本控制、KV Cache 的存储空间。位置编码这一层RoPE 类方案在长文本上会遇到高频维度衰减的问题。简单改 theta 参数短文本内插容易崩长文本外推也容易崩。常见解法有分段位置编码、层次化位置编码、或者混合局部注意力——让每个 token 在局部窗口内用精确位置编码在远程依赖上用粗粒度信息替代。这是一套系统工程不是某个位置编码函数一改就完事。从模型结构的角度看百万级上下文的真正瓶颈往往在注意力机制本身。标准 Full Attention 在序列长度变长时计算复杂度是平方级增长的。为了撑住 1M 长度模型通常要配合稀疏注意力、局部注意力窗口或者类似 MLA 的低秩压缩方案把长距离部分的计算成本压下来。这也是为什么不能只看上下文长度数字而得看它用了什么注意力结构来支撑这个长度。3.2 KV Cache 的显存账本1M tokens 需要多大空间这一节我想把计算公式拉出来让大家对“百万级上下文”到底意味着什么有个直观感受。KV Cache 的大小取决于三个变量层数 L、每层 KV 头的维度 D、以及精度。粗略估算每 token 的 KV 显存占用为层数 × 每个 token 的 KV 字节数用常见配置举例假设 60 层左右每层 KV 压缩后约 128 维FP16 精度下每 token 大约需要 30KB。看着不多但乘上 100 万 tokens 呢大概 30GB。如果模型没有做 KV 压缩KV 维度翻倍到 256 维那就是 60GB。这还只是单份 KV Cache做并发推理时每路请求各占一份。显存再大的卡也扛不住几次并发请求。所以百万级上下文要真正实用只能走两条路一是注意力结构本身够省比如类似 MLA 的方式把 KV 大幅压缩二是推理时支持高效的 KV 管理比如 PagedAttention、KV 换出换入把不活跃前缀的 KV 先挪到 CPU 甚至硬盘上等需要时再载回。Step 5 Preview 敢把百万级上下文当卖点说明它在注意力结构和推理框架上应该是有备而来的。但实际效果如何还得看部署后的压力测试。3.3 实测推理中的“有效可用上下文”长文本测试比规格文档更重要这里我想多说一句个人经验规格文档里的“1M”和实际能用的“1M”经常是两个宇宙。所谓有效可用上下文是指在长文本中部和尾部模型还能保持稳定的注意力分配、不丢失关键信息、不出现幻觉并且还能在合理时间内完成推理。很多模型号称支持长上下文但你在中段塞进去一个关键前提它照样忘了。这种情况在长文档问答、代码仓库理解里非常致命。我建议拿到 Step 5 Preview 之后第一时间做三件事写一段 800K tokens 的虚构产品文档中间埋 10 个必须精确引用的数字在末尾问模型这些数字。把前端代码库整个拼接成一个超长文件让模型在中间修改某个函数看它会不会误伤别处。连续多轮对话并把全部历史接在上下文里在第 20 轮时回问第一轮的细节。这三个测试可以用来验证长上下文的“可用性”。规格文档告诉你模型能看多长只有实测才能告诉你它看了能记住多少。长上下文模型的门槛在“记住”和“引用”不在“塞进去”。4. 部署实践MoE 要不要把全部参数塞进显存量化档位怎么选4.1 直接回答热搜问题主流部署确实要加载全部权重“MoE 架构要全部参数进显存吗”——我搜了一下这是很多人搜的热门问题直接给结论主流的推理框架里是。Claude 等这类做法虽然 MoE 单次只激活一部分专家但推理框架不会把“非活跃专家”从显存里剔除。原因有两个第一下一个 token 可能路由到任何专家你无法预判哪个专家接下来会用到。把某个专家留在硬盘上等它被路由到的时候再加载一次加载可能要几十毫秒这个延迟在批量推理里会拖垮整卡吞吐。第二多请求并发时不同请求路由到的专家集合完全不同专家 A 对这个请求是冷门对另一个请求可能是热门。为了吞吐量框架必须把所有专家的权重常驻显存。所以 600B 总参数FP16 下权重约 1.2TB这就是显存的基本盘。现实一点说少于 8 张 H100 80G 你很难跑全 FP16 权重。这也解释了为什么很多人聊 MoE 部署一定会同时聊量化因为不量化根本跑不起来。4.2 如果显存不够CPU offload、非活跃专家卸载的取舍严格来说确实有框架支持把 MoE 的非活跃专家放在 CPU 内存里推理时只在 GPU 上保留共享专家和当前活跃专家。这类方案在小 batch、单请求场景下能做到“能跑”但代价是显著的不可控延迟波动。为什么每个 token 都要做路由路由结果一旦指向当前不在显存里的专家就得等着从内存搬权重。这种情况在长上下文场景尤其麻烦因为长上下文的 token 数量巨大专家切换频繁搬权重的开销会被放大得很厉害。所以我的建议是如果想让 Step 5 Preview 这种体量的模型真正稳定服务线上流量还是按“全部权重进显存”来规划用卡。省下来的显存预算不如留给 KV Cache 和并发请求的余量。追求“勉强能跑”和追求“稳定好用”之间是真的差了一个量级的硬件规划。4.3 量化档排名FP16、INT8、INT4 对 MoE 的实用评估说到量化先给一张参考表。600B 总参数在不同精度下的权重体积精度每参数占用600B 权重体积建议显存FP162 字节约 1.2TB多卡并行降低延迟INT81 字节约 600GB8×80G 卡可跑INT40.5 字节约 300GB4×80G 起步量化档位的选择逻辑不只取决于显存够不够还得看模型的能力损耗比。INT8 在大多数模型上损失很小尤其在 MoE 模型上因为路由决策和专家计算对低比特的耐受度比稠密模型更高。INT4 就有意思了近年量化社区里 INT4 模型比如带 AWQ、GPTQ 等量化的模型系列的评测热度非常高。但对 600B 这种体量的 MoEINT4 之后个别专家的输出差异会被路由机制放大导致某些 token 的生成质量突然劣化。我个人对使用者的建议是先跑 FP16 或 INT8 看效果再考虑 INT4。如果 INT4 下评测掉点不明显再直接上 4bit 部署。注意不是所有层都值得同档量化MoE 里路由器的一层如果被压到 INT4路由偏差带来的影响往往比专家内部权重偏差更大。有条件的话优先保住路由相关层级的精度。5. 负载均衡是 MoE 的命门直观理解与诊断代码5.1 专家得分分化不均衡时为什么会出现“死专家”聊 MoE 永远绕不开负载均衡。600B 总参数意味着专家数量非常多少则几十多则上百。如果路由器学歪了可能 90% 的 token 都路由给前几个专家后面大部分专家长期得不到训练梯度就成了“死专家”。死专家带来的问题是连锁反应一方面大部分专家权重形同虚设模型实际能力退化总参数量成了摆设另一方面少部分专家承受巨大流量负载过高导致推理延迟集中在个别头节点上整个集群的利用率被拖垮。更隐蔽的是这种分化会在训练后期逐渐加速。一开始只是轻微偏差越到后期越是赢者通吃少数专家越练越强、越强越容易被选中形成一个正反馈循环。要打断这种循环光靠“希望路由自己学好”是不够的必须从训练目标层面加约束。5.2 常见机制辅助损失、专家容量、Top-K 路由目前主流的拉平手段有三个一是在训练目标里加辅助损失对“专家接收 token 的概率分布”做惩罚让它尽量接近均匀分布。这个惩罚项通常带一个权重系数权重太小压不住分化权重太大又会损伤模型本身的收敛质量是个典型的经验调参项。二是设置专家容量。也就是给每个专家规定一个最大 token 处理上限超出部分直接丢给残差连接或旁路处理倒逼路由器把流量打散到更多专家头上。这个机制的副作用是容量设太小会损失模型表达能力有些 token 得不到正牌专家处理。三是 Top-K Top-K 选取。比如每个 token 路由到 Top-2 或 Top-3前面的一个稍弱的头部再增加共享专家的保障。Top-K 越大专家覆盖度越好但每个 token 的计算成本也会上涨。所以 Top-K 本质上是在“表达能力”和“推理成本”之间做平衡。5.3 从负载均衡代码可以看出的门道我做了几年模型工程看了很多 MoE 框架的负载均衡模块想说一个观察判断一个开源 MoE 模型靠不靠谱先看它负载均衡的辅助损失实现得干不干净。这个细节非常能暴露团队的真实积累。一份好的负载均衡代码通常会暴露这些信息辅助损失是否按专家、按 batch 分开统计还是直接算个全局均值。分开统计说明团队debug过知道要观察分布形状。有没有容量相关逻辑的注释和回调钩子。有这些说明训练流程里真的遇到并处理过溢出现象。是否提供路由分布的日志可视化接口。不提供的话你训练时出了分发问题只能两眼一抹黑。我的习惯是拿到一个 MoE 权重后先跑几百条真实 prompt 做推理统计路由分布。具体做法可以这么来# 伪代码统计每个专家的路由次数 from collections import Counter routing_counter Counter() for batch in dataloader: with torch.no_grad(): outputs model(batch, output_router_logitsTrue) top_k_indices outputs.router_logits.topk(k2, dim-1).indices routing_counter.update(top_k_indices.flatten().tolist()) max_count max(routing_counter.values()) min_count min(routing_counter.values()) print(极差:, max_count - min_count) print(变异系数:, (max_count - min_count) / (sum(routing_counter.values()) / len(routing_counter)))这种距离统计测出来的结果比任何官方评测都更能揭示模型的训练质量。如果新增的路由次数明显集中在十几个专家上说明这个模型在推理阶段有潜在严重的惰性专家问题。那后续微调时可以用做参考选择性地重启或重训练部分闲置专家。这也是为什么我想强调看一个 MoE 模型关注的不是头上有几个光环而是有没有死专家、有几个、死在哪儿。6. 开源模型格局观察Step 5 Preview 带来的思考6.1 竞争梯队里的判断维度回到开头那句话说冲击全球开源模型前三梯队。要验证这个说法不能只看分数应该看四个维度通用能力的评测分MMLU、GPQA、HumanEval 这类基线推理吞吐和部署成本也就是能不能用相对低的成本把服务开起来长文本和 Agent 场景的实际可用性生态适配度包括 vLLM、SGLang、TensorRT-LLM 这些推理框架的支持情况前两项是“入场券”第三项是“差异化”第四项往往被忽略但恰恰是开发者愿不愿意长期用的关键。再好的模型如果主流的推理框架适配慢、量化工具配合差、微调链路不顺畅社区耐心是有限的。过去不少开源模型死就死在“评测很强、工具链不行”上。6.2 我们能实际使用的产品形态对行业用户来说Step 5 Preview 这类模型大概有三个层面的用法第一层直接调用官方 API验证业务效果。这个门槛最低适合做 PoC。长上下文和代码能力是不是真如宣传所说先跑几个内部用例就知道。第二层本地部署加量化。如果你有 GPU 资源可以把 INT8 或 INT4 版跑起来做私有化服务。特别适合数据敏感的行业比如法律、金融、医疗需要保证文档不出内网。第三层底座 微调。如果你有垂直领域的标注数据可以在模型基础上做 LoRA 微调或全参微调。MoE 模型的微调和 Dense 模型有个区别除非做全参微调否则只有被激活的专家会收到梯度容易出现部分专家被更新、其他专家没动的“微调断层”现象。做 LoRA 的时候需要留意路由层是否也被冻结否则下游任务很可能学不进去。6.3 我的判断前三是“体系”的竞争不只是“模型”的竞争说实话我对评测榜单本身没那么在意。Step 5 Preview 能引发这么大的讨论真正的价值在于它把 MoE 超大模型、百万级上下文、开源权重这三件事同时摆到桌面上把之前属于闭源大厂的部分能力边界给拉到了开源的射程之内。但要守住前三梯队的位子单靠这一次发布还不够。第一梯队从来不是一个静态名单它由持续训练、快速迭代、开源治理和社区运营共同构筑。模型开源只是起点如何让开发者能低成本部署、能稳定微调、能在各自业务里跑起来才是能不能长久留在前三的关键。就我个人体验来说拿到 Step 5 Preview 之后大概率会先跑一遍路由分布统计再看长文本中段信息保持能力然后才轮到传统评测集。这三个步骤做完我心里基本就能有数它到底是发布会上的“参数刺客”还是真正能上场干活的“生产力工具”。希望阶跃星辰这一次能给出一个惊喜的答案。