★ FEATURED ARTICLE 1. 从 5010 亿到 230 亿Beam 到底在玩什么把戏第一次看到 Reflection AI 放出 Beam 的参数表时我盯着那两个数字看了很久——总参数 5010 亿单次推理激活 230 亿。这个比例大概是 21.8:1也就是说模型里超过 95% 的参数在任意一次前向计算里都是睡着的。这不是什么新鲜概念MoE混合专家架构从 2017 年那篇 Outrageously Large Neural Networks 开始就在讲这个故事但真正把总参数量推到 5000 亿这个量级、同时把激活量压到 200 亿出头、还愿意把权重开放出来的团队屈指可数。Beam 这个命名本身就挺有意思。梁Beam在结构工程里是承受横向载荷的核心构件讲究的是用最少的材料撑起最大的跨度。放到模型架构上这个隐喻几乎是把 MoE 的设计哲学直接写在了脸上你不需要让所有参数都参与每一次计算你只需要在正确的时刻唤醒正确的那一小撮专家。我先把结论摆在前面方便你判断这篇内容值不值得往下读。Beam 解决的核心问题是推理成本与模型容量之间的解耦。传统稠密模型里你想让模型更聪明就得加参数加了参数推理就变慢变贵这是一条死绑定的曲线。MoE 把这条曲线掰开了容量可以堆到 5010 亿但每次推理只走 230 亿的路径显存占用和计算量按激活量算而不是按总量算。适合谁来参考三类人——一是手里有推理集群、想评估部署成本的工程同学二是研究 MoE 路由策略和负载均衡的算法同学三是想搞清楚开放权重这条路线现在走到哪一步的观察者。提示本文涉及的所有参数比例、架构推断均基于公开技术资料与同类 MoE 系统的常见实践进行合理演绎具体实现细节以官方发布为准。我会在每一处推断的地方明确标注避免你把我的推测当成官方事实。2. MoE 架构的核心逻辑为什么专家要分而治之2.1 稠密模型的成本墙到底卡在哪要理解 Beam 为什么这么设计得先搞清楚稠密模型的天花板在哪。假设你有一个 5000 亿参数的稠密 Transformer用 FP16 存储光权重就要占 1TB 显存。推理的时候每一个 token 都要过一遍全部 5000 亿参数矩阵乘法的 FLOPs 跟参数量成正比。这意味着什么意味着你的吞吐量被死死摁在硬件算力上想提升只能加卡加卡就是加钱而且是线性加钱。更难受的是稠密模型的能力提升并不是线性的。你把参数从 1000 亿加到 5000 亿loss 可能只降了一点点但推理成本翻了五倍。这就是所谓的边际收益递减。业内有个粗略的经验在固定数据量下模型参数量翻倍效果提升大概对应到 loss 下降 0.05 到 0.1 这个量级越往后越平。你花五倍的钱买 5% 的提升这笔账怎么算都不划算。MoE 的思路是既然不是每个 token 都需要动用全部知识那为什么不把参数切成很多块每个 token 只挑几块来用这就像一家综合医院你去看个感冒不需要把心外科、骨科、神经科的专家全叫来会诊分诊台把你导到内科就行了。医院的总编制可以很大总参数但单个病人占用的医生时间很少激活参数。2.2 稀疏激活的数学直觉MoE 层通常替换掉 Transformer 里的 FFN前馈网络层。一个标准 FFN 是Linear(d_model, 4*d_model) - Activation - Linear(4*d_model, d_model)。MoE 把它改成 N 个并行的 FFN每个叫一个专家外加一个路由器Router/Gate。路由器的活儿是给定一个 token 的隐状态x算出一个 N 维的分数向量然后取 top-k 个专家只让这 k 个专家参与计算最后按路由权重加权求和。公式大概长这样scores softmax(x W_gate) # W_gate: [d_model, N] topk_vals, topk_idx topk(scores, k) output sum over i in topk_idx: topk_vals[i] * Expert_i(x)Beam 的 5010 亿总参数、230 亿激活如果按常见的 top-2 路由来反推单个专家的参数量大概在 115 亿左右230 除以 2专家总数大约 43 到 44 个5010 除以 115。当然这只是量级估算实际专家数可能是 64 或 128单个专家更小路由 k 值也可能不是 2。但核心比例关系是成立的激活参数 ≈ k × 单专家参数量总参数 ≈ N × 单专家参数量。这里有个容易被忽略的点路由器和 embedding 层通常不算在专家参数里它们是稠密的、每次都要走的。所以 230 亿激活里有一部分是共享的稠密参数真正分给专家的可能只有 180 到 200 亿。这个细节在做显存预算的时候很关键后面讲部署的时候我会展开。2.3 负载均衡MoE 最容易被忽视的暗礁MoE 听起来很美但它有个天然的毛病路由塌缩。训练初期如果某几个专家碰巧表现好一点路由器就会倾向于把更多 token 送给它们这几个专家被训练得更充分表现更好于是吸引更多 token……正反馈循环下来大部分专家饿死少数专家累死。结果就是你名义上有 5010 亿参数实际有效的可能只有几百亿稀疏性变成了摆设。解决这个问题的主流手段是加负载均衡损失auxiliary load balancing loss。常见做法是统计每个专家在一个 batch 里收到的 token 比例和理想均匀分布算一个 KL 或者方差惩罚加进总 loss 里。还有一个工程手段叫容量因子capacity factor给每个专家设一个 token 上限超了就丢弃或者走残差。DeepSeek 系列在这方面做了不少公开的技术分享Beam 作为后来者大概率也借鉴了类似的思路。注意负载均衡损失是个双刃剑。系数调太大模型会为了平均分配牺牲路由的准确性专家变得同质化系数调太小又压不住塌缩。这个超参的调优经验往往比架构本身更能决定 MoE 的成败。3. Beam 的架构推断与关键参数拆解3.1 参数配置的几种可能组合我把 Beam 的参数拆成几种可能的配置做成表格方便你对照。需要强调的是以下组合是基于公开量级和 MoE 常见实践的推断不是官方规格。配置项可能性 A可能性 B可能性 C专家总数 N6412844路由 top-k222单专家参数量约 78 亿约 39 亿约 115 亿共享稠密参数约 30-50 亿约 30-50 亿约 30-50 亿激活参数合计约 200 亿约 130 亿约 280 亿从 230 亿激活这个数字倒推可能性 A 和 C 更接近。如果共享参数按 40 亿算专家激活部分就是 190 亿top-2 的话单专家 95 亿N 约 52 个。这个数字不整所以实际很可能是 64 专家、单专家 80 亿左右、top-2 激活 160 亿专家参数加 70 亿共享参数。当然也可能用了 top-1 路由配更大的专家或者 top-4 配更小的专家。关键不是猜中具体数字而是理解这个比例背后的工程取舍。3.2 为什么是 230 亿这个激活量230 亿这个激活量选得很有讲究。从部署角度看230 亿参数的模型FP16 权重约 46GBINT8 量化后约 23GBINT4 约 12GB。这意味着什么意味着一张 80GB 的卡比如 A100/H100 级别可以比较从容地放下 FP16 的激活权重甚至留出 KV Cache 的空间。如果激活量再往上走到 400 亿、500 亿单卡就放不下了必须做张量并行部署复杂度陡增。从能力角度看230 亿激活的模型能力大致对标一个 200 亿到 300 亿的稠密模型。这个量级在当前的开放权重阵营里属于能打的区间——比 70 亿强不少又不像 700 亿那样对硬件要求苛刻。Reflection AI 选这个点明显是冲着可部署性去的而不是单纯刷榜。这里有个反直觉的地方MoE 的显存占用并不等于激活参数量。因为虽然每次只激活 230 亿但所有 5010 亿专家权重都得加载到显存里路由器才知道该往哪送。所以真实显存需求是全部专家权重 激活部分的中间激活值 KV Cache。5010 亿 FP16 就是 1TB 显存这是硬门槛。除非用专家卸载expert offloading把不常用的专家放到 CPU 内存甚至 SSD 上按需换入。这个技术路线在 DeepSeek 的公开分享里出现过Beam 如果想降低部署门槛大概率也会支持类似的卸载策略。3.3 路由器的设计细节路由器虽然参数量小就是一个d_model × N的矩阵但它决定了整个模型的性格。几个值得关注的设计点第一路由是在 token 级别还是序列级别。token 级路由更细粒度但路由抖动大序列级路由更稳定但灵活性差。主流做法是 token 级。第二是否用 noisy top-k gating。在训练时给路由分数加噪声增加探索性防止过早塌缩。Shazeer 那篇原始论文就用了这个技巧。第三专家是共享还是分组。有些实现会把专家分成若干组组内共享一部分参数减少总参数量。Beam 的 5010 亿如果是纯独立专家那规模确实惊人。第四路由权重的归一化方式。top-k 选出来的权重是重新 softmax 还是直接用原始分数会影响输出的尺度稳定性。这些细节官方未必全部公开但你在复现或者评估的时候必须把这些变量考虑进去否则很容易得出MoE 不过如此的错误结论。4. 开放权重这条路Beam 接的是什么招4.1 开放权重阵营的现状开放权重这个词这两年越来越热但它和开源是两回事。开源通常意味着代码、训练脚本、数据配方都公开开放权重往往只放出模型权重文件训练细节、数据来源、完整代码未必给。Beam 走的是开放权重路线这对整个生态的意义在于它给了研究者和工程团队一个可以本地部署、可以微调、可以深度分析的大规模 MoE 样本。在此之前5000 亿级别的 MoE 开放权重几乎是空白。大家能拿到的要么是几百亿的稠密模型要么是规模更小的 MoE。Beam 把量级拉上来等于把大规模稀疏模型到底能不能打这个问题摆到了台面上让更多人能亲手验证。4.2 对推理基础设施的冲击大规模 MoE 对推理框架提出了新要求。传统的推理引擎比如早期的 TensorRT、ONNX Runtime对 MoE 的支持并不好因为专家路由是动态的每个 token 走的路径不一样很难做静态图优化。现在主流的方案是 vLLM、SGLang、TensorRT-LLM 这些支持动态路由的引擎。部署 Beam 这类模型你会遇到几个特有的问题专家并行Expert Parallelism把不同专家放到不同卡上token 通过 all-to-all 通信送到对应专家。通信开销是瓶颈尤其是跨节点的时候。动态 batch不同 token 激活的专家不同导致每张卡的负载不均需要动态调度。KV Cache 管理MoE 的 KV Cache 和稠密模型一样但显存被专家权重占了大头留给 KV Cache 的空间更紧张。我实测过类似规模的 MoE 部署最深的体会是通信比计算更值得优化。all-to-all 的延迟如果压不下去再快的算力也白搭。4.3 微调与二次开发的可行性开放权重最大的价值之一是微调。但 5010 亿的 MoE 微调门槛不低。全量微调需要的数据并行加专家并行配置普通团队玩不起。更现实的是 LoRA 或者 QLoRA只训练低秩适配器冻结专家权重。这里有个 MoE 特有的坑LoRA 加在哪些层上。如果只加在注意力层专家部分不动那微调的效果可能有限如果加到专家 FFN 上又面临路由不稳定的问题——你微调了专家 A但推理时 token 可能被路由到专家 B。所以 MoE 的微调策略往往需要配合路由的冻结或者约束。5. 实操如何评估和部署一个 Beam 级别的 MoE5.1 硬件预算怎么算假设你要部署 Beam先算三笔账。第一笔权重显存。5010 亿参数FP16 是 1002GBINT8 是 501GBINT4 是 250GB。这是必须常驻的除非用卸载。按 8 卡 H100 80GB 算总共 640GBFP16 放不下INT8 勉强INT4 比较从容。第二笔激活显存。230 亿激活FP16 中间激活值大概几个 GB 到十几 GB取决于 batch size 和序列长度。第三笔KV Cache。这个跟激活参数量无关跟层数、头数、序列长度、batch 有关。假设 80 层、GQA 8 组、序列 8K、batch 32KV Cache 可能要到几十 GB。三笔账加起来INT4 权重 250GB 激活 15GB KV Cache 40GB ≈ 305GB8 卡 H100 的 640GB 能放下还有余量。如果是 FP161002GB 就超了得上 16 卡或者用卸载。提示实际部署时专家权重的分布很关键。如果专家并行做得好每张卡只放一部分专家单卡显存压力会小很多但通信开销上去了。这是个典型的空间换时间。5.2 推理引擎选型对比引擎MoE 支持专家并行易用性适合场景vLLM较好支持高快速验证、中小规模SGLang好支持中高吞吐服务TensorRT-LLM好支持低极致性能、生产环境原生 PyTorch一般需自己写高研究、调试我的建议是先用 vLLM 跑通验证权重加载和基本推理没问题要上生产再考虑 SGLang 或 TensorRT-LLM。原生 PyTorch 适合你想深入看路由行为的时候用但性能别指望。5.3 加载与推理的最小示例下面是一段伪代码展示 MoE 推理的核心逻辑帮你理解每一步在干什么。注意这是教学用的简化版不是 Beam 的实际实现。import torch import torch.nn as nn class MoELayer(nn.Module): def __init__(self, d_model, n_experts, top_k, expert_hidden): super().__init__() self.n_experts n_experts self.top_k top_k # 路由器把隐状态映射到专家分数 self.gate nn.Linear(d_model, n_experts, biasFalse) # 专家每个是一个独立的 FFN self.experts nn.ModuleList([ nn.Sequential( nn.Linear(d_model, expert_hidden), nn.SiLU(), nn.Linear(expert_hidden, d_model) ) for _ in range(n_experts) ]) def forward(self, x): # x: [batch, seq, d_model] scores self.gate(x) # [batch, seq, n_experts] topk_vals, topk_idx scores.topk(self.top_k, dim-1) topk_vals torch.softmax(topk_vals, dim-1) # 归一化路由权重 output torch.zeros_like(x) for k in range(self.top_k): idx topk_idx[..., k] # 每个 token 选的第 k 个专家 weight topk_vals[..., k].unsqueeze(-1) for e in range(self.n_experts): mask (idx e) if mask.any(): expert_out self.experts[e](x[mask]) output[mask] weight[mask] * expert_out return output这段代码里for e in range(n_experts)那个循环就是性能杀手。真实实现会用 grouped GEMM 或者 scatter-gather 把不同专家的计算批处理起来避免 Python 层的循环。这也是为什么 MoE 推理对 kernel 实现要求高——路由的动态性让静态优化很难做。5.4 路由行为的观测方法部署之后我强烈建议你加一段路由统计的日志。具体做法是在 MoE 层里记录每个专家收到的 token 数跑一批真实数据看分布是否均匀。# 在 MoE 层里加统计 expert_counts torch.zeros(n_experts) # 每次 forward 后累加 for e in range(n_experts): expert_counts[e] (idx e).sum().item() # 打印分布 print(expert_counts / expert_counts.sum())如果发现某些专家占比超过 30%说明负载不均可能是训练时的均衡损失没调好或者你的输入数据分布太偏。这个观测对判断模型是否名不副实特别有用——名义 5010 亿如果实际只有 10 个专家在干活那有效容量可能就几百亿。6. 常见问题与排查实录6.1 加载权重就 OOM 怎么办这是最常见的问题。5010 亿参数你按 FP16 加载1TB 显存瞬间爆掉。排查顺序第一确认你的加载精度。用torch_dtypetorch.float16还是torch.bfloat16还是量化版本。如果官方提供了 INT8/INT4 权重优先用。第二检查是否支持分片加载。大模型权重通常切成多个 shard用device_mapauto让 accelerate 自动分配。但 MoE 的专家分片比较特殊要确认分片是按专家切的还是按层切的。第三考虑专家卸载。把不活跃的专家放到 CPU 内存用offload_folder指定路径。代价是首次访问慢但能大幅降低显存。第四如果以上都不行减少并发。batch size 降到 1序列长度降到 512先跑通再说。6.2 推理速度远低于预期MoE 的推理速度理论上应该接近同等激活量的稠密模型但实际往往更慢。原因通常是通信瓶颈专家并行下all-to-all 通信占了大量时间。用nsys或者torch.profiler看通信占比如果超过 30%说明并行策略有问题。路由开销top-k 选择和 scatter-gather 的 kernel 效率低。检查是否用了融合 kernel。负载不均某些专家过载其他空闲导致整体被最慢的专家拖累。看路由统计。KV Cache 碎片MoE 显存紧张KV Cache 分配不连续影响访存效率。6.3 微调后效果反而变差MoE 微调有个反直觉的现象微调后在某些任务上变好在另一些任务上变差。原因往往是路由漂移——微调改变了专家的权重导致原本的路由决策不再最优但路由器没跟着更新。解决办法有两个一是微调时同时更新路由器但学习率要小二是用路由约束损失让微调后的路由分布尽量接近微调前。我试过第二种效果比较稳但需要额外实现。6.4 常见问题速查表问题现象可能原因排查手段解决方向加载 OOM精度过高/无分片看显存峰值量化/分片/卸载推理慢通信瓶颈profiler 看通信占比优化并行策略输出质量差路由塌缩看专家分布检查均衡损失微调退化路由漂移对比微调前后路由加路由约束显存碎片KV Cache 管理看显存分配预分配/分页7. 我对这类大规模 MoE 的几点实操体会踩过几次坑之后我越来越觉得 MoE 的评估不能只看参数表。5010 亿总参、230 亿激活这两个数字本身不说明任何问题真正决定体验的是路由质量、负载均衡、通信效率这些看不见的东西。一个路由塌缩的 5000 亿 MoE实际能力可能还不如一个训练充分的 300 亿稠密模型。另外开放权重不等于开箱即用。Beam 这类模型的部署门槛比 70 亿的稠密模型高一个数量级。如果你只是想试试效果用官方提供的 API 或者量化版本先跑通如果你要自己部署先把显存预算和通信拓扑算清楚别上来就拉满配置。最后分享一个小技巧评估 MoE 的时候除了看常规 benchmark一定要测长尾输入的稳定性。MoE 在分布内的数据上表现通常很好但遇到训练时少见的输入模式路由可能做出奇怪的选择导致输出质量骤降。我一般会构造一批边缘案例比如超长序列、罕见领域术语、混合语言专门看模型在这些输入上的路由分布和输出一致性。这个测试往往能暴露出参数表上看不到的问题。
阅读完成 · 觉得有帮助？
