MoE(混合专家)架构这两年撑起了几乎所有大模型的容量扩张,但有一个结构性矛盾长期被绕过去:对单个 token 而言,"多少专家参与贡献"、"实际计算多少次专家前向"、"要在显存里存多少套专家参数",这三个量在现有设计里是绑死的。高德团队 9 月发布的 IntBMoE 论文(arXiv:2609.21346)给出一组解耦方案,论文自述已部署在高德的生成式推荐系统里服务数亿用户。
三个量为什么一直绑着
论文给三个量下了明确定义:participation(参与度)指一个 token 的输出由多少专家贡献知识;execution(计算量)指实际发生多少次专家计算;materialization(实例化)指需要构建并存储多少套专家级参数。现有三条路线各卡一头:稀疏路由把计算量和实例化压得很低,但每个 token 只有少数专家参与;稠密输出混合恢复了全员参与,计算量却随专家数增长;参数合并把计算压到一个专家,实例化又随路由决策数膨胀。换句话说,过去你最多同时优化两个量,第三个必然恶化。
IntBMoE:先组合,再稀疏执行
IntBMoE 的核心是"块级条件化":从一个小的可学习码本取出块配置,每层由轻量超网络把该层专家池中的全部专家基座合并成组合专家。这样参与度天然拉满——每个组合专家都动用整个池子;执行仍然稀疏——路由器只把 token 送到少数几个块;实例化有上界——块数量由码本决定,与输入无关。作者还设计了双路径残差门控(DPRG),将两条独立组合的路径通过乘法门控耦合,配合特征过滤和一个常驻共享专家完成整体变换。
一个实用细节值得划重点:块可以预先组合并缓存,块配置固定时推理计算量与专家数量无关。这是它区别于稠密混合方案的关键——容量扩张不再直接换算成推理账单。
生产成绩单:官方口径
按论文自述,IntBMoE 已完整部署于高德的生成式推荐系统,在 60ms 延迟预算内服务数亿用户,在线 A/B 测试拿到 UVCTR 相对提升 2.4%。实验侧,图像分类任务上稳定超过代表性的稀疏与稠密 MoE 基线,语言建模与序列推荐验证了跨域泛化。需要说明:在线数字全部来自官方 A/B 自报,暂无独立复现,阅读时建议带上这层滤镜。
开源仓库给了什么,没给什么
代码落在 GitHub 的 DreamX-Rec 仓库(Apache 2.0,当前 121 stars)。该仓库承载高德六篇生成式推荐工作,IntBMoE 是其中负责容量扩展的模块,配套推荐、自然语言(MiniPile)、视觉(ImageNet-1K)三个域的示例。两点冷静面:其一,开源实现里 BlockMoE 的前向每次调用都重新组合参数,论文研究的 serving 缓存并未包含在公开代码里;其二,推荐示例训练的是单任务 POI 预测,而非完整的多任务目标。在线收益是高德内部系统的结果,公开代码与复现它之间还有明确距离——README 自己也写明了这条边界。
对推理架构方向的人,这篇论文的真正增量不是那 2.4%,而是把 MoE 的成本模型从"专家数单一旋钮"细化成三个可独立调节的量。当社区一边苦恼专家并行的通信开销、一边苦恼显存装不下全量专家时,"先组合、后执行"提供了第三条路径。下一个值得盯的节点,是社区能否把 serving 缓存补出来——那才是这套设计能否走出高德、进入通用 LLM 栈的胜负手。
参考:论文 arxiv.org/abs/2609.21346;代码 github.com/AMAP-ML/DreamX-Rec