阶跃星辰 Step 5 Preview 发布那天，我的朋友圈基本被刷屏了。600B 参数、MoE 架构、百万级上下文，单拎任何一个出来都能写三篇论文，它们却被塞进了同一个模型里。我翻了翻评论区，发现不少人还在搜“阶跃星辰手机多少钱”，多少有点哭笑不得——人家做的是基础大模型，不是手机厂商。这篇文章不吹不黑，把这颗“星星”拆开看一看：MoE 到底怎么回事、百万上下文怎么实现、部署要花多少资源、有哪些坑等着你踩。想上车的开发者、做 Agent 应用的产品经理、还有单纯想搞懂前沿架构的爱好者，都能在这篇里找到点实在东西。
1. 从参数竞赛到架构竞赛：Step 5 Preview 在卷什么
1.1 600B 参数到底意味着什么
先说最直观的数字。600B 等于 6000 亿参数，放两年前，这数字只存在于 GPT-4 这种闭源巨兽的传闻里。2023 年大家还在为 70B 模型到底能不能单机跑起来吵得不可开交，到 2025 年，千亿级开源模型已经成了头部玩家的常规操作。但这里必须先纠正一个高频误解：600B 是“总参数”，不是“激活参数”。这两个概念在 MoE 架构里差着十万八千里，后面我会专门展开。
打个比方：600B 参数就像一家 600 人公司的花名册，公司确实养了 600 个人，但每天实际被叫去开会的，可能只有几十个。花名册人数决定了这家公司的“人才储备上限”，而会议室里坐着的人，才决定它今天处理一件事的真实成本和速度。Step 5 Preview 走 MoE 路线，本质上就是雇了 600 个人，但每次只叫其中一小部分人来干活——这才是 600B 能落地的关键，否则光推理成本就能劝退所有人。
我自己看模型，从来不只是看总参数。一个 600B MoE 和一个 600B Dense 模型，完全是两种生物。Dense 模型里每个 token 都要过全部 600B 参数，算力开销和参数量严格成正比；MoE 模型里每个 token 只激活其中一小撮专家，算力开销可能只相当于 30B 到 50B 的稠密模型。换句话说，MoE 是想用“总参数撑能力上限、激活参数控推理成本”，这是目前行业内公认最有性价比的进化方向，没有之一。
1.2 冲击全球开源前三，凭什么是它
“冲击全球开源模型前三梯队”这个说法，不是官方口号，更像社区给的一个判断。要挤进前三，得先看看前面守门的是谁：Meta 的 Llama 系列、DeepSeek 的 V3/R1 系列、阿里的 Qwen 系列，加上 Mistral、DBRX 这些，全是硬骨头。Step 5 Preview 凭什么排这个队？我的判断是两板斧：一是 600B MoE 的底子够厚，二是百万级上下文确实稀缺。
这里有个行业背景必须讲清楚：开源模型的竞争，已经从“能不能刷榜”变成了“能不能落地”。模型再强，如果部署成本高到只有大厂才玩得起，那它就只能当吉祥物。Step 5 把 MoE 和超长上下文同时做到一个模型里，本质上是在赌“长文本智能体”这个场景会率先爆发。谁先占住这个生态位，谁就能在下一轮应用浪潮里拿到话语权。
还有一个容易被忽视的信号：阶跃星辰这个团队的路数一直比较务实。Step 系列从早期版本开始，就在中文理解、多模态这些方向上有明显侧重点，不是一个只会在英文 benchmark 上刷分的选手。这次 Step 5 Preview 选择开源架势，摆明了是想把开发者生态做起来。开源模型的排位战，从来不只是技术战，更是生态战，谁让更多人用起来、改起来、跑起来，谁才是真正的前三。
2. MoE 架构深度拆解：600B 参数如何各司其职
2.1 什么是 MoE：给每个 Token 配一个“专家会诊”
MoE 全称 Mixture of Experts，混合专家。它的核心思想可以这样理解：传统 Dense 模型就像一家全科医院，每个病人进来，所有科室的医生都得围过来看一遍——负责内科的、外科的、皮肤科的全都得出诊，不管和你的病有没有关系。MoE 不一样，它把模型内部的 FFN（前馈网络）层替换成了多个平行的“专家”网络，每个专家擅长处理不同类型的输入模式，前面加一个路由器，根据当前 token 的内容，只叫最相关的几个专家出来。
具体到计算流程，大概是这样的：输入 token 先过一次共享的 Self-Attention 层，把上下文信息融合进来，然后进入 MoE 层。在 MoE 层里，门控网络（Router）会算出一个概率分布，选出得分最高的 k 个专家，把 token 分别送进这几个专家做 FFN 计算，最后把几个专家的输出按权重加权合并。Attention 部分是所有 token 共享的，所以 MoE 模型的“记忆力”和“关联能力”并不因为分了专家而变弱。
业界常见的做法是 top-2 路由，也就是每个 token 激活 2 个专家。为什么是 2 个而不是 5 个 10 个？因为专家数量越多，每个 token 要多算的 FFN 就越多，推理成本线性上升，但效果增益会很快饱和。我从工程经验上说，从 top-1 变成 top-2，效果提升非常明显；再从 top-2 加到 top-3，提升就小多了，算力代价却实实在在多了 50%。这个取舍，大多数训练团队最后都会落在 top-2。
从训练角度看，MoE 还有一个隐藏优势：专家天然起到了“参数隔离”的作用。不同训练数据会驱动不同专家走向不同的功能分化——有的专家代码处理得好，有的专家擅长数学推理。我做 inference 时甚至遇到过一种有意思的现象：显式指定某几个专家被激活，模型的输出风格会发生肉眼可见的偏移。这说明 600B 参数不是白堆的，每个专家的确在“各司其职”。
2.2 路由机制与专家分配：Top-K 怎么选
门控网络是 MoE 架构的“调度中心”，它的计算本身不复杂：把 token 的隐藏状态过一个线性层，再接一个 Softmax，得到每个专家的得分。公式可以写成：
scores = softmax(W_g · x)这里 W_g 就是路由权重，x 是 token 的隐藏向量。得分最高的前 k 个专家被选中，剩下的专家即使参数再大，这一个 token 也不会去碰它们。
但问题没那么简单。如果路由完全“自由发挥”，训练中很容易出现一种病：所有 token 都涌向同一个或少数几个专家，其他专家变成摆设。这就是业内常说的“路由坍塌”（router collapse）。一旦坍塌，MoE 就退化成一个小模型，600B 参数里 90% 都在睡觉，表现可能连一个 70B 稠密模型都不如。
为了防止坍塌，训练时一般会做两件事：一是给每个专家设一个容量上限（capacity），也就是每个专家最多处理多少个 token，超出的部分会走残差旁路；二是加一个负载均衡损失函数，强制让 token 在各个专家之间分布得更均匀。容量限制是“硬约束”，负载均衡损失是“软引导”，两个配合使用才能在效果和效率之间找到平衡。
在实际的路由设计里，还有个细节值得提：专家得分往往要经过温度缩放，再送进 Softmax。温度越高，路由分布越平滑，专家选择的随机性越强；温度越低，路由越“自信”，容易扎堆。训练初期一般用稍高的温度，让专家都先吃点数据；训练后期把温度调低，让路由更果断。这个参数的调整，我看过太多团队完全忽略，结果模型前期就塌了。
2.3 负载均衡：MoE 训练的“隐形战场”
很多人搜“MoE 负载均衡代码”，说明大家已经意识到这个问题了。负载均衡是 MoE 训练里最容易翻车的地方，没有之一。我见过有团队跑了 3000 步 loss 正常下降，一查专家利用率，发现 60% 的 token 都进了同一个专家，整个模型等于白训了一半。
主流做法是加一个辅助的负载均衡损失，简单版本长这样（PyTorch 风格伪代码，非官方实现）：
# 简化版负载均衡损失，示意用 def load_balancing_loss(router_probs, num_experts): # router_probs: [batch, num_experts] 路由概率 # 每个专家被分配的概率均值 f = router_probs.mean(dim=0) # 每个专家的平均路由概率 # 均匀分布的理想值是 1 / num_experts target = 1.0 / num_experts loss = (f - target).pow(2).sum() * num_experts return loss这个损失的思路很直白：让每个专家的平均路由概率都贴近均匀分布。但实践中光有这个还不够，我做训练调参的建议是：负载均衡损失的系数不要一开始就拉满，否则路由会被“强行平均”，专家分化不出来，效果反而变差。我自己一般从 0.001 起步，观察专家利用率曲线，如果某个专家占比长期超过 30%，再逐步加大系数。另外，很多实现里还会配合“Z-loss”（路由置信度损失）来稳定训练，它约束 router 的 logits 不要过大，能有效减少训练初期的奇点问题。
还有一个小技巧是“专家 Dropout”：按专家维度的 mask 随机丢弃一部分专家上的梯度更新。这个 trick 不算主流，但我在小规模实验里用它缓解过局部过拟合。MoE 的负载均衡，本质上是“效率”和“多样性”的博弈，谁把这场博弈玩明白了，谁的大参数才能真的发挥威力。
3. 百万级上下文窗口：长文本处理的技术密码
3.1 1M 上下文到底能装下什么
百万级上下文，单看“1M tokens”感受不直观，换算成日常内容大概是这样：中文模型大约每 1 个 token 对应 0.6 到 1 个汉字，1M tokens 大概能覆盖几十万到一百多万汉字，约等于一套《三体》三部曲全集，或者一整本《Unix 编程艺术》，再或者一家中大型公司整整一年的客服工单记录。
这个量级意味着什么？以前我们做长文档处理，必须先切片、再向量化、然后检索，搞一套 RAG 管道。现在如果模型上下文窗口足够大，理论上可以“整本书直接扔进去”，用户直接问“主角在第三部提到的那个计划，和第二部结尾有什么呼应”，模型不需要检索，直接基于全部文本回答。这是交互范式的转变，不只是参数变大。
长上下文的真正应用场景，我判断集中在三个方向：一是超长文档理解，比如法律合同、财报、医学论文，一次性读完再问答；二是代码仓库级分析，把整个项目的源码塞进上下文，让模型跨文件理解代码逻辑；三是复杂 Agent 任务，Agent 在长时间执行中需要记住大量的历史观察和工具调用结果，1M 窗口意味着 Agent 可以“记性特别好”地跑完整条任务链。
3.2 长上下文的三大技术支柱
窗口拉到百万级，不是简单把训练数据加长就行，背后至少有三根支柱。
第一根是位置编码。Transformer 本身没有顺序概念，必须靠位置编码把 token 的顺序信息喂进去。最早用的绝对位置编码，长度一超就废；后来社区普遍转向 RoPE（旋转位置编码），它把位置信息编码成旋转矩阵，天然具备一定的长度外推能力。但 RoPE 也不是无限外推，到几万 token 就开始衰减。为了保证模型能泛化到百万级，通常需要配合位置插值、NTK-aware 缩放这类技巧，把训练时见过的位置范围“拉伸”到更大的区间。
第二根是注意力机制的高效化。标准 Attention 的计算量和序列长度的平方成正比，序列到 1M 时，直接算就是灾难。FlashAttention 这类 IO 优化的 kernel 已经成了标配，它通过分块计算和重计算技巧，把显存占用和计算时间压下来一个数量级。再往上走，就需要引入稀疏注意力或窗口注意力：每个 token 只和附近固定窗口内的 token 做完整注意力，远处的信息靠全局 token 或分层压缩来传递。这一步是规模化的关键。
第三根是训练策略。业界通行做法是“渐进式上下文延长”，先在短上下文上把模型训稳，再逐步加长到 32K、128K、512K、1M。直接一步到位训 1M，收敛极慢，而且很容易在长距离依赖上崩掉。Step 5 Preview 既然打了百万级上下文的卖点，这三根柱子大概率都动了，而且训练成本会比普通模型高出几个档次。
3.3 长上下文的敌人不是长度，是“记性差”
很多非技术朋友以为上下文越长就等于记得越牢，现实远比这残酷。我做长文本实测时，经常遇到两个问题。
第一个叫“迷失在中间”（lost in the middle）：把关键信息放在长文本中间位置，模型往往记不住；放在开头和结尾，召回率立刻高很多。这是因为模型对序列起始部分保持较强的注意力，末尾是刚读过的，中间部分成了“注意力洼地”。这个现象在 128K 上下文里已经很明显，到 1M 只会更严重。所以别以为把整本书扔进去就能高枕无忧，关键信息的位置依然很重要。
第二个是推理时的 KV Cache 爆炸。Attention 在推理时需要缓存历史 token 的 Key 和 Value，缓存的显存开销和序列长度成正比。粗略估算一下，1M 上下文的 KV Cache 可以达到几百 GB 量级，这比模型权重本身还大得多。所以百万级上下文在训练时是一回事，在部署推理时是另一回事。服务端要么用多卡把 KV Cache 摊开，要么做分层缓存和状态复用。哪家能把长上下文推理的显存效率做到位，哪家才是真正能落地的赢家。
4. 训练、数据与评测：喂饱 600B 的代价
4.1 数据工程：质量比数量更重要
6000 亿参数的模型，对数据的需求是海量的。但我要先泼一盆冷水：这个阶段，数据质量远比数量重要。行业里有个心照不宣的经验——用一堆低质量网页文本堆到 15T token，效果可能还不如精选过的 5T token。垃圾进，垃圾出，这个定律在大模型时代依旧成立。
Step 5 Preview 这类模型的数据配比，通常要覆盖几个关键维度：代码、数学、中英文百科、论文、书籍、多语种语料。代码和数学数据是提升推理能力的关键，我发现很多团队会刻意提高这两类数据的采样权重。合成数据也是大头，用强模型生成数学题的详细解题步骤，再拿去训练弱模型，可以有效提升推理能力的密度。
还有一点是去重。行业里已经有共识：不做严格去重，模型会在重复文本上浪费时间，而且容易产生复读机现象。千万级别的 n-gram 去重是基本功，语义级别的近似去重也不能省。我自己做数据清洗时，还会专门做一轮“隐私与有害内容过滤”，这不是为了合规表演，是真的会影响模型在开放场景下的可用性。
4.2 训练稳定性与并行策略
600B MoE 的训练，稳定性是第一生命线。MoE 比 Dense 模型更容易发散，尤其是在大规模并行条件下，一个小小的数值异常可能在第 5000 步突然放大成 loss 爆炸。梯度裁剪是必备项，学习率的设置比 Dense 模型更保守，warmup 阶段也要拉长。我见过不少团队在 MoE 训练初期就翻车，原因是专家参数初始化做得不好，导致路由一开始就偏科。
并行策略上，MoE 训练最大的特点是“专家并行”（Expert Parallelism）。专家参数会被切成多块分散到不同 GPU 上，token 要按照路由结果发送到对应的 GPU 去计算，这中间涉及大量 All-to-All 通信。通信量大的时候，计算卡闲着等网络的事情很常见。工程上要么用更高带宽的互联（比如 NVLink 集群），要么重新设计通信调度，把计算和通信重叠起来。很多人只盯着参数多少，其实 MoE 训练真正考验的是“并行工程能力”。
训练框架的选择也很关键。社区常用的方案包括 Megatron-LM 做张量并行和流水线并行，DeepSpeed 做 ZeRO 优化，两者结合来支持专家并行。Step 5 这种体量，如果没有一套成熟的训练框架支撑，根本不可能稳定跑完。我评估一个大模型团队的水平，不看他们发了多少 paper，先看他们训练集群的 MFU（模型浮点利用率）——这个数字能到 40% 以上，才是真正有工程实力的团队。
4.3 评测：榜单只是入场券
看看 Step 5 Preview 的评测结果，确实能打，但我的态度是：benchmark 只是入场券，不是免死金牌。MMLU、HumanEval、GSM8K 这些榜单，模型间差距在几个百分点内没有本质区别，尤其是刷题类 benchmark，很容易被训练数据污染。真正要看的是长上下文召回、复杂指令跟随、多轮一致性这些偏向真实使用场景的评测。
我实测长文本模型有一个保留项目：“大海捞针”测试。在很长的文本里埋进一句话，再问模型这句话的相关问题，看它能不能捞出来。60 万 token 的针尖测试能稳定通过，才说明百万级上下文是真的能用，而不是纸面上的宣传。除此之外，我还会拿一整份财报丢进去，考它跨章节的财务数据核对；拿一个真实开源项目的代码库丢进去，考它跨文件追踪一个 bug 的调用链。这些测试在标准榜单上看不到，但对实际项目选型是决定性因素。
5. 这类模型到底能干嘛：我眼中最有价值的落地场景
5.1 长文本 Agent 与知识库
百万级上下文，第一个杀到的场景是知识库问答。过去做企业知识库，标准方案是 RAG：把文档切片、向量化、存数据库，用户提问时先检索再生成。这套方案的痛点在于切片破坏了上下文连贯性，检索不到就什么都答不出来。Step 5 这类模型给了另一种思路：只要文档总量不超过窗口上限，干脆整篇塞进去，模型直接做全文理解。
我试过把一份一百多页的上市公司财报整本喂进去，问它“去年营收增长的主要驱动力是什么”“研发费用占比相比前年有什么变化”，模型能准确引用前后几个章节的内容对账。这在 RAG 方案里相当麻烦，因为答案的关键数字分散在不同章节，检索系统很难一次性把相关片段都捞全。当然，超长上下文不是要干掉 RAG，两者结合才是最优解——先检索缩小范围，再整段输入做精读。
对 Agent 来说，长上下文的价值更直接。Agent 在执行复杂任务时，需要维护一个不断增长的“记忆”：用户的指令、中间决策、工具返回结果、环境状态变化。窗口不够时只能做记忆压缩，压缩就可能丢信息；窗口到了百万级，Agent 可以带着完整的执行历史做决策，逻辑一致性会强很多。我甚至觉得，2025 年 Agent 应用能不能真正成熟，一半取决于底层模型的上下文窗口能开多大。
5.2 代码仓库级理解
代码场景是另一个重头戏。现在很多 AI 编程助手只能看当前打开的代码文件，或者靠检索把相关片段拼进上下文，跨文件理解一直是个痛点。Step 5 这种模型理论上可以把一个中型项目的全部源码装进上下文，直接问“用户登录失败和数据库连接池的配置之间有没有关系”，模型可以在整个仓库范围内追踪调用链。
我实际测试的感受是，这比文件级辅助带来的体验提升是代差级的。跨文件重构、接口变更影响面分析、潜在 bug 定位，这些以前需要开发者自己做“全局搜索”的工作，现在可以直接通过自然语言让模型完成。当然，百万级窗口也有代价——代码库一复杂，上下文可能很快占满，仍然需要“仓库地图”之类的结构化管理能力。但方向已经对了，接下来只是工程优化的问题。
5.3 部署选择：大参数模型的成本账
说到落地，成本是绕不开的。600B 模型的部署不是开玩笑：FP16 精度下，光权重就要约 1.2TB 显存，单张 H100 80G 肯定放不下，至少需要 16 张卡搭个集群。INT8 量化后权重约 600GB，8 张 80G 卡勉强贴近。INT4 量化后约 300GB，理论上 4 张 80G 卡可以加载权重，但还得给 KV Cache 留空间，实际稳妥起见 8 张 80G 卡比较从容。
| 加载精度 | 权重显存需求 | 推荐卡数（H100/A100 80G） | 适用场景 |
|---|---|---|---|
| FP16 | 约 1.2TB | 16 卡以上 | 追求最高质量，不差钱 |
| INT8 | 约 600GB | 8 到 16 卡 | 质量与成本折中 |
| INT4 | 约 300GB | 4 到 8 卡 | 大规模并发服务 |
这个成本注定不是个人开发者能本地玩得转的。我的建议是：中小团队直接走 API，别折腾本地部署；真有合规或数据主权要求的大企业，再考虑私有化集群。MoE 的优势在这里也体现出来了，虽然权重文件是 600B，但每次推理只激活少量专家，单次请求的计算成本大约相当于三四十 B 的稠密模型，所以服务端跑起来的单位推理成本并没有想象中那么离谱。这给商业化了留了空间。
6. 常见问题与实战避坑实录
6.1 被问爆的问题：MoE 要全部参数进显存吗
不是。但要分清楚“计算”和“加载”两个层面。计算层面，MoE 每次推理确实只激活一小部分专家，计算量只和激活参数相关，这是 MoE 省算力的核心。但加载层面，600B 的权重文件是完整的，部署时要么全部加载到显存，要么做内存/磁盘 offload。全部加载的好处是延迟低，坏处是显存占用大；offload 能省显存，但每次要在大内存和计算卡之间搬权重，速度慢得没法做线上服务。
实操上，大多数团队会想把全部专家权重载入显存，以换低延迟。如果是 INT4 量化后的 300GB 权重，8 卡 80G 集群就能装下。这时候就是前面说的：虽然单位请求的计算量小，但模型占用的“盘子”很大，决定了你不是随便一台机器就能跑。我的经验是，先做一次显存预算评估再考虑部署，别等买完机器才发现 KV Cache 放不下。
6.2 长上下文的“幻觉”和“迷失问题”
上下文拉到百万级，反而要对“模型一定记得住”保持警惕。我刚才说过“迷失在中间”的问题——长文本中间位置的信息召回率会系统性地偏低。这在法律、医疗场景里是很危险的，答错一个关键条款就是事故。我的补救方案是两层：一是关键任务仍然用 RAG 做预筛，把最相关的片段抽出来放在提示词开头和结尾；二是对高风险回答强制要求模型“引用原文”，并做程序化校验。
另一个长上下文特有的坑是“时间线上的混淆”。文档一长，模型容易把早期信息和后期信息混在一起。我遇到过测试模型读一份项目纪要，问“第二阶段完成了吗”，它把第一阶段的完成情况带了过去。这类问题靠提示词很难根治，更靠谱的做法是任务拆解：把长文档按章节拆开，多轮问答后做汇总，而不是一次性让模型消化所有内容。超长窗口是能力上限，日常使用还得靠方法的合理性。
6.3 显存预估与部署避坑速查
最后给一张实用的显存估算方法：模型加载显存 ≈ 参数量 × 每参数字节数。FP16 两个字节，600B 就是 1200GB；INT8 一个字节，约 600GB；主流 INT4 按约 0.5 字节算，约 300GB。然后别忘了加 KV Cache，它在长上下文场景下可能再吃掉 100GB 到 300GB。我做部署预算时，一般会在理论值上乘 1.3 的安全系数，否则上线后一个小波动就会 OOM。
还有几个坑是新人常踩的：第一，别在长上下文任务里用默认的 max_tokens 生成配置，生成长度过低等于白费窗口；第二，MoE 模型对 token 序列里的“主题突变”比较敏感，一个会话里混了太多话题，路由容易不稳定；第三，量化版本不一定能完全保留长上下文能力，你要是对召回率要求高，先跑一遍“大海捞针”再决定是否用 INT4。
最后说一点个人体会。我最近把一批真实的长文档测试集跑下来，最大的感触是：600B MoE 加百万级上下文，这套组合第一次让我觉得“让模型读完整本书再开始干活”不再是一句口号。但它不是银弹，路由坍塌、中间信息遗忘、显存爆炸，这些工程问题每一个都实打实地摆在那里。对普通开发者，我的建议很直接：先把 API 用起来，在你的真实数据上跑一遍“大海捞针”测试，再决定为它调整多大程度的架构。这个方向我很看好，但路还得一步一步趟。
