阿里巴巴与北京大学联手，让AI大模型"按需用电"：BEAM技术如何让语言模型跑得更快、耗得更少

这项由阿里巴巴淘宝天猫集团与北京大学深圳研究生院联合完成的研究，以预印本形式发布于2026年5月，论文编号为arXiv:2605.14438，题为"BEAM: Binary Expert Activation Masking for Dynamic Routing in MoE"。感兴趣的读者可以通过该编号在arXiv平台查阅完整原文。

一、先从一个费电的比喻说起

假设你家有一栋大房子，里面住着一百位各有专长的工匠——有木工、瓦工、水电工、厨师……每当有客人来访，你需要完成某项接待任务，比如做一顿家常饭。按照现有规矩，你必须同时叫醒其中固定的八位工匠，不管这顿饭是否真的需要水电工来帮忙。结果当然是：大量工匠白白被叫起来站在厨房里发呆，既浪费了他们的精力，也让厨房变得拥挤不堪，做饭速度反而下降了。

这个比喻，其实正是当下大型语言模型（AI对话系统）面临的真实困境，只不过"工匠"换成了"专家模块"，"做饭"换成了"处理每一个词"。

现代AI大模型，尤其是那些被称为"专家混合模型"（Mixture-of-Experts，简称MoE）的系统，其内部构造正是这样一批分工明确的"工匠团队"。每次模型处理一个词（在AI术语里叫"token"），它的路由机制会从几十甚至上百位工匠中，固定挑选出K位（比如8位）来协同工作。这个K是事先写死的，不管这个词是复杂的专业术语，还是简简单单的"的"字，都一视同仁地叫醒同样数量的工匠。

这种"一刀切"的做法，在算力上造成了大量浪费。阿里巴巴与北京大学的研究团队敏锐地抓住了这个痛点，提出了一套名为BEAM（二进制专家激活掩码）的新方案，让模型学会根据每个词的实际难度，动态决定到底需要叫醒几位工匠。

二、现有的"省电"方案为何都不够好

在BEAM出现之前，已经有不少研究者试图解决这个浪费问题，但每种方案都有各自的软肋。

第一类方案是修改"路由打分"——也就是改变评判工匠是否需要出场的标准。比如有研究提出，当模型对"谁最重要"这件事不太确定的时候，就少叫几个工匠；反之则多叫几个。然而这类方法有个根本缺陷：它从来不敢真正叫停那些得分排名靠前的工匠，因为默认排名靠前的工匠就一定有用，即便他对当前这个词毫无贡献。这就好比你永远不会拒绝"最有名"的工匠出场，哪怕今天的任务根本不需要他。

第二类方案是引入"零计算占位工匠"——模型可以把工作分配给一位什么都不做、但占据一个名额的虚假工匠，从而变相减少真正开工的人数。AdaMoE就是这个思路的代表：它在原有工匠团队里额外塞进若干个"摆烂工匠"，让模型在不需要太多帮手时，自然而然地把名额分给他们。问题是，这种方式是被动的，你无法精准控制到底省下了多少算力，调参也相当麻烦，像是在黑盒子里摸鱼。

第三类方案是静态裁员——事先分析哪些工匠功能高度重叠，直接把他们合并或开除，然后永久减少工匠数量。这个方法的缺点同样致命：一旦裁定，就是一刀切的永久减员，面对不同的词、不同的任务，灵活性完全丧失。遇到真正复杂的内容时，人手不够的问题就会暴露得淋漓尽致。

这三类方案有一个共同的深层问题：它们都把"决定叫哪些工匠"和"决定叫多少工匠"这两件事搅和在一起处理，导致彼此之间产生矛盾，训练时一件事的优化往往会干扰另一件事的效果。

三、BEAM的核心思路：给每位工匠贴一张"今日需要"的标签

BEAM的解决思路，可以用一个更精确的比喻来理解：它并不是减少候选工匠的范围，而是在原有候选名单之上，再增加一个"今日是否真正需要"的二值判断——每位工匠的答案只有"是"或"否"两种，没有中间状态。

具体来说，BEAM在原有的主路由器旁边，并行增加了一个轻量级的"掩码路由器"（Mask Router）。这个掩码路由器的参数矩阵非常小，只有输入维度乘以专家数量那么大，几乎不增加模型的整体体积。

当模型处理一个词时，整个流程分四步走。首先，原有的主路由器照常运作，从所有工匠中按得分高低选出前K位候选人，并计算出每位候选工匠应该获得多少"权重"（可以理解为这位工匠在此次任务中应该贡献多少力气）。这一步完全不变，保证了模型原有的专家选择逻辑不受干扰。

第二步，掩码路由器拿到同样的词信息，独立计算出每位工匠的一个"必要性得分"，数值被压缩在0到1之间（通过一个叫Sigmoid的数学函数实现，可以理解为把任意数值映射成百分比）。这个得分反映的是掩码路由器对"这位工匠今天到底有没有必要出场"的判断。

第三步是二值化判断：以0.5为分界线，得分达到或超过0.5的工匠获得"是"的标签（对应数值1），得分低于0.5的工匠获得"否"的标签（对应数值0）。整个判断过程干净利落，没有任何模糊地带。

第四步是最终整合：把主路由器给出的权重，与掩码路由器给出的二值标签逐一相乘。被标记为"否"的工匠，权重直接变为零，意味着他们不会参与这个词的计算。最终模型的输出，是所有"是"标签工匠的计算结果加权求和。

这个设计的精妙之处在于它的解耦性。主路由器只管"谁最合适"，负责平衡各专家的工作量；掩码路由器只管"到底需要几个"，负责消除冗余计算。两者各司其职，互不干扰，从根本上避免了此前方法中"一个路由器要同时处理太多目标"的矛盾。

另外值得一提的是：由于二值标签可以直接告诉硬件"这个工匠今天不用计算了"，CUDA内核（GPU上的并行计算程序）可以非常高效地跳过这些工匠的全部运算。这种硬件友好性，是BEAM能够在实际部署中真正提速的物质基础。

四、训练时如何教会模型"学会偷懒"

有一个问题需要解释清楚：二值判断（只有0或1，没有0.3或0.7）在数学上是不可导的——意思是，训练神经网络时依赖的"梯度"（可以理解为"往哪个方向调整参数能让结果变好"的指引）无法穿过这个硬性分界线传递下去。这就好比你想知道把灯光调暗一点点是否会影响拍照效果，但灯的开关只有开和关两档，你没法做"调暗一点点"的实验。

研究团队采用了一个在深度学习领域已有成熟先例的技巧，叫做"直通估计器"（Straight-Through Estimator，STE）。它的做法相当直接：在前向传播时（也就是计算预测结果时），老老实实用那个硬性的0/1判断；但在反向传播时（也就是调整参数时），假装那个硬性分界线根本不存在，把梯度直接"穿透"过去，传给掩码路由器。这样，掩码路由器虽然输出的是0/1，却依然能接收到"你判断对了/判断错了"的信号，从而在训练中不断改进自己的判断能力。

为了让模型真正学会"能少叫工匠就少叫"，而不是每次都懒得思考直接标记所有人为"是"，训练过程中还加入了一个专门鼓励稀疏的惩罚项。这个惩罚项的计算方式很直白：把当前被选中的K位候选工匠的"必要性得分"加总，得分越高、被标记为"是"的工匠越多，惩罚就越重。用一个超参数β来控制这个惩罚的力度——β越大，模型就越倾向于少叫工匠；β越小，模型就越倾向于保留更多工匠参与计算。

最终的训练目标是三项损失的加权求和：预测下一个词的准确性（语言建模损失）、确保工匠们的工作量分配均匀（负载均衡损失）、以及尽可能减少参与计算的工匠数量（稀疏正则化损失）。三项目标在同一个训练过程中同时优化，通过调节各自的权重系数来取得平衡。

研究团队还特别处理了训练启动的问题：掩码路由器的参数初始化为全零，这意味着在训练刚开始时，所有工匠的"必要性得分"恰好是0.5，全部被标记为"是"，模型行为与原始Top-K路由完全一致。随着训练推进，稀疏惩罚的压力逐渐推动掩码路由器学会区分哪些工匠真正必要，稀疏性自然地从训练中"涌现"出来，而不是一开始就强制施加，避免了训练初期的不稳定。

从训练曲线来看，这个设计的效果相当理想。在三个被测试的模型上，BEAM的语言建模损失最终都收敛到了与普通微调相近的水平，说明稀疏化没有损害模型的语言理解和生成能力。更有规律性的是，专家激活率（也就是平均有多少工匠被标记为"是"）在训练开始后约半个epoch内就急剧下降到一个稳定水平，随后便保持稳定，整个训练过程十分平稳。

五、从理论到实践：BEAM在GPU上的具体落地

理论上能省掉一批工匠的计算，不等于实际运行时真的变快了。这取决于能否让GPU也"知道"哪些工匠不用算。

研究团队把BEAM集成到了vLLM（目前业界广泛使用的大模型推理框架）中，通过修改两个底层CUDA内核实现了无缝加速。第一个改动是在"掩码路由内核"中，把掩码路由器对某位工匠的判断结果为负（即得分≤0，对应sigmoid之前的原始值）时，该工匠的索引直接被写成-1，代表"本轮跳过"。第二个改动是在GPU进行工匠-token批处理分组时，凡是索引为-1的工匠，直接从计数统计中排除，整个计算序列中这位工匠的运算就彻底不会被调度执行。

这两处改动加起来不超过几十行代码，对vLLM的其他优化机制（如算子融合、显存合并等）完全没有影响，也不需要对模型结构做任何修改。从用户的角度来看，只需要加载经过BEAM微调后的模型权重，推理框架的其余部分完全不用动，真正做到了"即插即用"。

还有一个值得单独解释的边界情况：如果某个词的所有候选工匠都被标记为"否"，会发生什么？对于带有"共享专家"的模型（如阿里巴巴的Qwen1.5-MoE和DeepSeek），那些永远在线的共享工匠依然会处理这个词，只是所有"可选工匠"都被跳过了。对于没有共享专家的模型（如Qwen3），这个词会完全绕过整个专家层，仅通过残差连接传递——效果上类似于动态地跳过了整层网络的计算。这种"全跳过"行为在深度学习界也有专门的研究先例，被称为动态层跳跃。

六、实验数据：省了多少、损失多少

研究团队在三个有代表性的MoE模型上进行了测试：规模相对较小的Qwen1.5-MoE-A2.7B（每层从60个工匠中选4个）、中等规模的DeepSeekV2-Lite（每层从64个工匠中选6个，另有2个共享工匠）、以及规模较大的Qwen3-30B-A3B（每层从128个工匠中选8个，无共享工匠）。

所有模型都在同一个训练数据集（Tulu 3 SFT Mixture Dataset，涵盖推理、编程、通用知识等多类任务）上进行微调，然后在八个标准测试基准上评估性能，覆盖数学推理（MATH、GSM8K）、代码能力（HumanEval）、知识广度（MMLU、CEVAL、CMMLU）和常识理解（BoolQ、CommonsenseQA）等维度。

在中等稀疏度的设置下（β=0.01），BEAM在Qwen3-30B-A3B上将平均激活工匠数从8个降低到4.23个，而综合性能从81.41分仅下降到79.99分，保留了98.3%的原始能力。相比之下，直接把固定Top-K从8降到4的基线方法只能达到78.90分，而更激进的"训练用8个、推理时强行砍到4个"的方案更是直接跌到了69.60分，说明BEAM的智能化选择确实比粗暴削减有效得多。

在高稀疏度设置下（β=0.1），BEAM在Qwen3上将平均激活工匠数压到了1.23个（原来的15%），综合性能维持在77.14分，仍然超过了把固定K值减为2的基准方法（72.18分）。在极端稀疏设置下（β=1.0），Qwen3模型平均只激活0.56个工匠——意味着大多数词根本不需要任何工匠出场——综合性能仍有71.91分，而固定K=1的基准方法只能达到53.95分，差距高达33个百分点。

在Qwen1.5-MoE上，极端稀疏设置（β=1.0）甚至能把平均激活工匠数压到0.11个，绝大多数词完全绕过了所有可选工匠，性能依然保留了85%。这个结果从某种意义上证明了一个令人惊讶的事实：大语言模型中相当大比例的专家计算是冗余的，完全可以在不影响输出质量的前提下省略。

与竞争方案的对比同样清晰。AdaMoE（空工匠方案）在各个稀疏度设置下性能都偏低，原因在于它新增的"摆烂工匠"会干扰正常工匠的训练过程。MoE-Dynamic（累积概率阈值方案）在调参上需要针对每个模型单独摸索，且无法有效跳过高权重但冗余的工匠。DynMoE（Sigmoid路由方案）在测试中表现最差，因为它完全替换了原有路由架构，在微调场景下极度不稳定，在DeepSeekV2-Lite上综合性能从55.15分崩溃至3.59分。相比之下，BEAM在所有设置和所有模型上都保持了最优的稀疏性-精度权衡曲线。

在推理速度方面，测试结果同样令人关注。在在线服务场景（模拟真实用户请求），DeepSeekV2-Lite在每秒24个请求的压力下，BEAM将每个输出词的生成时间从76.2毫秒压缩到30.8毫秒，实现了2.5倍加速。Qwen3-30B-A3B在高负载下实现了约1.9倍的解码加速，吞吐量提升1.4倍。Qwen1.5-MoE由于有4个固定共享工匠，可削减的MoE层计算量上限只有50%，加速比相对有限，但在高负载下也能实现1.7倍的解码加速。对比之下，MoE-Dynamic和AdaMoE不仅稀疏度有限，还引入了额外计算开销，在多数测试设置下几乎没有带来可见的提速效果。

七、模型到底学会了什么：工匠的工作规律

除了性能数字，研究团队还对BEAM学到的稀疏模式做了深入分析，揭示了一些有趣的规律。

在词级别上，BEAM清晰地体现出"按词的信息量分配工匠"的特点。在Qwen3-30B-A3B上，"hiking"（徒步）、"skipping"（跳绳）、"boarding"（寄宿）等具有实质语义内容的词汇平均激活工匠数超过4.5个；而"while"（当……时）、"from"（从）、"by"（被）等功能词的激活数降至0.6-1.0个；聊天模板中的固定语句"You are a helpful assistant"（你是一个有帮助的助手）几乎不激活任何工匠，但并不影响模型的正常输出。这说明BEAM成功地把计算资源集中在了真正"有话可说"的词上。

在层级别上，不同模型呈现出不同的模式。DeepSeekV2-Lite在预填充（处理输入）和解码（生成输出）两个阶段的激活模式几乎相同，说明该模型的专家分工在两个阶段高度一致。Qwen1.5-MoE和Qwen3则表现出明显的差异：在预填充阶段，浅层激活更多，深层激活较少；在解码阶段，深层反而激活更多。这种模式与编码器-解码器架构有几分相似：浅层负责"理解和存储知识"，深层负责"推理和生成"。

在专家排名的维度上，BEAM的一个核心优势得到了量化验证。研究人员比较了BEAM、MoE-Dynamic和AdaMoE在"倾向于保留哪些排名的工匠"这件事上的行为差异。MoE-Dynamic表现出极强的排名偏见：排名第一的工匠从不被跳过（掩码概率为0.00），而排名第六以后的工匠几乎总是被跳过（掩码概率高达0.79到0.94）。这意味着它其实只是在做"把低权重工匠踢掉"的事，与直接降低K值并无本质区别。AdaMoE的排名偏见虽然稍弱，但仍然单调递增，从排名第一的0.06到排名第八的0.66。而BEAM的掩码概率在不同排名之间几乎持平，从排名第一的0.43到排名第八的0.53，变化幅度极小。这说明BEAM真正地在根据"这位工匠对当前这个词有多大用"来判断，而不是简单地依赖排名高低。进一步的逐层分析也证实，即便是排名第一或第二的工匠，在某些层的某些词上，也会被BEAM的掩码路由器判定为"今天不需要出场"。

在专家负载均衡方面，BEAM在降低整体激活量的同时，并没有让少数工匠变成"全职打工人"而让其他工匠彻底闲置。负载分布可视化显示，BEAM微调后各工匠的使用频率依然相对均匀，即便对于拥有128位工匠的Qwen3也是如此，这说明BEAM的稀疏化是"普遍性地减少工作量"，而非"选择性地养活几位明星工匠"。

八、几个关键设计选择的背后考量

研究团队通过消融实验（逐一去掉某个设计要素、观察结果变化的分析方法）验证了BEAM若干关键设计选择的合理性。

关于二值化阈值的选取，研究团队测试了从0.1到0.9的五个不同阈值，发现0.5在综合性能上最优。一个合理的解释是：0.5恰好是Sigmoid函数梯度最大的点，意味着在这个位置附近，参数的微小变化能够最有效地改变掩码的判断结果，学习效率最高。同时，全零初始化使得训练开始时所有得分恰好为0.5（sigmoid(0)=0.5），恰好位于判断边界，确保了训练初期的平稳过渡。

关于稀疏惩罚项的形式，研究团队对比了L1范数（取绝对值求和）和L2范数（取平方求和）两种方式。L1明显优于L2，这与深度学习中L1正则化更容易诱导稀疏性的理论预期一致。完全去掉稀疏惩罚项后，模型虽然在推理性能上略有提升，但激活工匠数量急剧回升到6.31个（从1.23个），完全失去了提速效果，证明稀疏惩罚项是BEAM方案中不可或缺的组成部分。

关于是否使用二值化（硬决策）还是软化的连续权重（软决策），测试结果非常清晰。直接使用Sigmoid的连续输出作为权重（不做0/1二值化）的方案，综合性能灾难性地下降了69.5%，核心原因正是训练与推理之间的不匹配：训练时使用连续值，推理时却需要给出确定性的"跳过"或"执行"决策，两者之间存在根本性的鸿沟。即便加入了"温度退火"技巧（训练时从软决策逐渐过渡到硬决策），也只是把性能损失从69.5%降到了5.0%，仍然明显逊于直接使用二值化的方案。这一对比鲜明地说明了为什么BEAM从一开始就坚持使用硬性的二值判断，而不是走"软化"的折中路线。

说到底，BEAM解决的是一个看似简单、实则深刻的工程问题：大模型在处理不同难度的词时，它的计算量应该有所不同。这个道理谁都明白，但要在实际系统中平稳实现，需要解决梯度传播、训练稳定性、硬件适配等一系列技术挑战。BEAM的方案并不激进——它没有改变模型架构，没有修改主路由器，没有引入复杂的强化学习过程——只是用一个极其轻量的掩码路由器，加上一个简洁的训练目标，把"动态决定用几个工匠"这件事从无到有地学了出来。

对普通用户而言，BEAM意味着同样的AI助手可以在更便宜的硬件上运行得更快，或者在同样的硬件上同时服务更多人。对于需要大批量运行AI模型的企业而言，推理成本的降低是实实在在的经济收益。这项研究提示我们去思考一个更宏观的问题：现有的大模型中，还有多大比例的计算是真正被需要的？如果大多数词其实只需要少量专家就能处理，那么未来的模型设计是否应该从一开始就把"按需分配计算"作为核心设计原则，而不是事后的补丁？

有兴趣深入了解技术细节的读者，可以通过arXiv编号2605.14438查阅完整论文，代码实现也已在GitHub公开发布（仓库地址：Time-Rune/BEAM）。

Q&A

Q1：BEAM方法需要从零开始训练大模型吗？

A：不需要从零开始。BEAM是一种后训练微调方案，只需要在已有预训练模型的基础上，用有监督微调（SFT）的方式训练若干epoch即可。训练过程中只新增了一个轻量的掩码路由器模块，原有模型的所有参数都保持可训练状态。训练成本与模型规模成正比，但远低于从头预训练一个新模型。

Q2：BEAM把激活工匠数压得极低时，模型的输出会不会变得语无伦次？

A：研究结果显示，即便在极端稀疏设置下（平均每个词只用0.56个工匠），Qwen3-30B-A3B的综合性能依然维持在71.91分，远高于同等稀疏度下固定Top-K方案的53.95分。这说明BEAM的智能化选择能够在极低的计算量下保留大部分语言理解能力，但极端稀疏设置下确实存在一定性能损失，需要根据实际部署需求在β参数上做权衡。

Q3：BEAM加速效果在不同模型上差异为什么这么大？

A：主要原因是模型架构中"共享专家"的比例不同。Qwen1.5-MoE有4个固定激活的共享专家和4个可选专家，即便把可选专家全部跳过，共享专家的计算量仍然占据了一半，因此MoE层FLOPs最多只能降低50%。而Qwen3-30B-A3B完全没有共享专家，8个工匠全部可以被BEAM的掩码机制管控，理论上可以将MoE层FLOPs降低85%，因此加速效果更为显著，实测吞吐量提升达1.4倍。