IntBMoE:将块级条件融入专家组合,实现全参与的混合专家模型
Mixture-of-Experts (MoE) 能扩展容量,但现有设计无法独立设定三个量。对单个 token 而言: - participation(参与度):有多少专家为其输出贡献知识; - execution(执行度):实际参与了计算,即计算成本; - materialization(物化度):需要构建并存储多少专家规模的参数集,即显存成本。 稀疏路由压低了 execution 与 materialization,却牺牲了 participation:每个 token 只有少数专家贡献。稠密输出混合恢复了全参与,但 execution 随专家数量增长。参数合并把 execution 固定为一个专家,但 materialization 随路由决策数量增长。 我们提出 IntBMoE,一种块条件化的 MoE,通过将稠密专家组合与稀疏块执行配对,把上述三个量彻底解耦。其块来自一个小型可学习 codebook,每个条目对应一个块。在每个内部层,一个轻量 hypernetwork 会把该层专家池中的所有专家基合并为一个组合专家。participation 保持全量,因为每个组合专家都动用了整个专家池;execution 维持稀疏,因为路由器只把每个 token 送到少数几个块;materialization 则有界,因为块的数量由 codebook 而非输入决定。Dual-Path Residual Gating (DPRG) 进一步通过乘法门控耦合两条独立组合的路径。 图像分类 实验显示,相较代表性的稀疏与稠密 MoE 基线均有稳定提升;在 语言建模 与 序列推荐 上的额外实验验证了其超越视觉的泛化能力。IntBMoE 已完整部署于 AMap 的生成式推荐系统,在 60ms 延迟预算下服务数亿用户,在线 A/B 测试取得 2.4% 的相对 UVCTR 提升。代码见 https://github.com/AMAP-ML/DreamX-Rec/。
论文精读
TL;DR IntBMoE 用块级条件化解耦 MoE 参与度、执行成本与内存成本,实现全参与、稀疏执行与有限物化,并在 AMap 推荐系统在线 A/B 中提升 2.4% UVCTR。
问题
问题背景
MoE 技术在扩大模型容量方面被广泛采用,当前领域关注如何在保持计算效率的同时,最大化每个 token 的知识参与度。
现有方法局限
- 稀疏路由 保持执行与物化成本低,但每个 token 仅激活少数专家,participation 较低,限制知识融合质量。
- 稠密输出混合 恢复全参与,但 execution 随专家数量线性增长,推理成本不可控。
- 参数合并 执行成本保持单专家水平,但 materialization 随路由决策数增长,因为需要为每个组合单独存储合并参数。
这三类方法均无法同时独立控制 participation、execution、materialization 三个量。
为什么这个问题难/重要
三者解耦在工程上具有直接价值:大模型需要高容量(全参与)、低延迟(稀疏执行)、低内存(有界物化),但现有设计只能实现其中两个。例如在在线服务中,增加专家数量提升容量往往导致延迟或显存爆炸,限制了 MoE 的实际部署规模。IntBMoE 通过 block-conditioned MoE 实现三量解耦,为高容量模型在资源受限环境下的高效推理提供了新路径,对产业界部署大模型具有重要参考意义。
行业类比
类似 在线广告/推荐系统 中,每天处理海量请求,需要模型利用全部用户与商品知识,但每次推理只能执行少量计算分支;IntBMoE 的“全池参与 + 稀疏块执行”恰好匹配此类场景,难怪其已在 AMap 推荐系统中线上部署并取得正向收益。
核心洞察
- IntBMoE 提出块级条件化,将 MoE 的 participation、execution、materialization 三者解耦,实现全参与且计算稀疏的专家组合。现有方法中,sparse routing 牺牲 participation,dense mixing 导致 execution 随专家数增长,parameter merging 使 materialization 随路由决策膨胀,而 IntBMoE 通过 codebook 与 hypernetwork 使三者可独立设定,从设计空间上统一了稀疏与密集 MoE 的优势。
- IntBMoE 的核心机制是用小型可学习 codebook 限定 block 数量,配合 hypernetwork 将每层所有 expert bases 合并为一个 composed expert,实现全池参与但仅稀疏执行少数 block。这解决了 parameter merging 方法中 materialization 随输入或专家组合增长的问题;codebook 大小固定,不依赖输入或专家数,内存开销在部署时高度可控,同时保留 dense 聚合的表达能力,是其在推荐系统等低延迟场景落地的关键。
方法
输入与整体流程
输入 token 序列逐层进入 IntBMoE 层。每个 token 先经过 块级参数合成,再由 token 级路由 选择少量块,最后通过 双路径残差门控 聚合输出。
关键模块
块级参数合成
每个内部层维护一个由多个 expert bases 组成的池。一个轻量 hypernetwork 根据可学习 codebook 中对应 entry 的条件,将所有 expert bases 合并为一个 composed expert。该步骤保证:每个 token 输出的专家知识来自整个池,实现 full participation。token 级块路由
路由器为每个 token 选择少数几个 codebook 块(例如 top-1 或 top-2),仅执行这些块对应的合成专家。这样 execution cost 保持稀疏,与专家总数无关。由于 codebook 大小固定且远小于专家数量,materialization cost 也有界。块条件特征过滤
在合成专家之前,对输入特征进行块相关的线性变换或门控,使不同块关注不同子空间,提升块间差异性。双路径残差门控 (DPRG)
两条路径分别独立合成专家,并通过 乘法门控 耦合:一条路径的激活作为另一条路径的门控信号。该机制增强非线性和条件计算,同时保留残差连接。输出聚合与共享专家
被选块的输出按路由权重加权求和,并与一个所有 token 共享的静态专家相加,稳定训练初期表现。
输出
最终得到每个 token 的隐状态,进入下一层或任务头。
与同类方法差异
相比 sparse MoE 牺牲参与度换稀疏执行、dense mixing 全参与但执行昂贵、parameter merging 执行低但物化随路由增长,IntBMoE 通过 codebook 块级合成与稀疏块执行同时解耦 participation / execution / materialization 三个维度,这是核心差异点。
实验
实验设计
在三个不同领域验证 IntBMoE:图像分类(ImageNet-1K)、语言建模(MiniPile)、序列推荐(IntTravel)。基线覆盖稀疏 MoE、dense output-mixing、parameter-merging 等代表性方案。另在 AMap 生成式推荐系统进行在线 A/B 测试,服务规模达数亿用户。
关键发现
- 图像分类上,IntBMoE 相对稀疏与稠密 MoE 基线取得一致提升;
- 在语言建模与序列推荐任务中泛化有效,验证了跨模态能力;
- 线上 A/B 测试相对 UVCTR 提升 2.4%,推理延迟控制在 60ms 预算内。
与基线对比解读
核心创新在于通过 block-level conditioning 解耦 participation / execution / materialization 三个量:
- 相比稀疏路由,恢复 full participation,提升专家利用率;
- 相比 dense output-mixing,execution 保持 sparse,避免计算量随专家数线性增长;
- 相比 parameter-merging,materialization 由 codebook 固定,不随 routing decision 数量爆炸。
该设计在容量、计算、存储之间取得更灵活的平衡,为大规模 MoE 部署提供了兼顾效果与效率的新路径。
行业影响
落地场景
IntBMoE 适合在线高并发、容量受限的推荐与生成系统。具体包括:
- 电商 / 内容平台推荐:用户行为序列长、候选池大,MoE 容量扩展需求强,但延迟预算通常 <100ms。IntBMoE 用少量 block 路由维持稀疏计算,同时全专家参与提升表达能力。
- 大规模语言模型 / 多模态模型:在移动端或边缘部署大模型时,内存物料化受限,codebook 固定 block 数量可显著降低存储压力。
商业价值
- 降本:execution 稀疏且 materialization 受 codebook 约束,推理 FLOPs 与内存占用低于 dense MoE,单位算力成本下降。
- 增收:论文原报告 2.4% 相对 UVCTR 提升,在成熟推荐系统上直接转化为广告 / 交易收入。
- 体验提升:full participation 带来更细粒度专家组合,推荐多样性、内容相关性可改善。
与现有 stack 接口
- 可作为即插即用 MoE 层替换:保持输入 / 输出张量形状不变,内部实现 block-level synthesis + routing,无需改动模型骨架。
- 推理缓存:codebook 条件与 token 无关,每个 block 的合并专家可预先合成并缓存,进一步降低在线开销。
- 需要额外超参:codebook size、block 数、routing top-k,但可通过蒸馏或网格搜索复用现有 MoE 调参流程。
具体案例
- 出行服务平台推荐系统(如地图导航中的本地服务推荐):服务数亿用户,延迟预算 60ms,IntBMoE 已替代原 MoE,线上 A/B 获得 UVCTR 提升,证明大规模稀疏模型可同时做到低延迟与高容量。
- 电商个性化推荐:将 IntBMoE 应用于排序模型中的用户兴趣塔,用 block 路由代替传统 expert 路由,在相近延迟下提升模型容量与线上指标。
局限
- 论文未在大规模语言模型预训练场景下验证扩展性。虽然 MiniPile 上的语言建模实验展示了可行性,但模型规模与工业级 LLM 相差甚远;当专家数量、层数、隐藏维度大幅增加时,**hypernetwork** 合并所有专家基的通信与计算开销可能成为瓶颈,**codebook** 大小与路由选择的协同调优成本也可能急剧上升,实际部署难度未被充分讨论。
- 方法强依赖预先设定的 **codebook** 大小 `B`,该超参数对性能敏感(论文中有敏感性分析),但在不同任务和数据规模下需要额外搜索,增加了调参负担。此外,**block-level routing** 与 **dense expert composition** 的耦合可能引发优化不稳定,特别是 **DPRG** 双路径残差门控机制引入额外的乘性交互,训练复杂度与收敛稳定性尚未得到充分论证。
- 虽然强调 **full participation**,但所有专家被合并为一个 composed expert,这可能牺牲单个专家的专业化表示能力;与稀疏 MoE 中专家参数独立更新相比,这种合成方式对需要精细专家分工的任务(如细粒度多模态理解)可能不利。实验主要覆盖图像分类、中等规模语言建模和推荐系统,对于生成式 LLM 或其他需要强 token 级动态性的任务,泛化性仍需更多证据支持。