高德地图把推荐系统升级了:同样 60ms 延迟,点得多 2.4%——arXiv 2609.21346 怎么做到的
- 关联论文:2609.21346
你有没有这种感觉:同一个外卖 App、同一个刷脸门禁,底层那个"猜你想看"的模型越做越大,延迟却越压越紧,最后只能在"算力"和"猜得准"之间反复二选一?
这件事在工业界叫"推荐系统的算力账"。在国内推荐场景里,60 毫秒是一个硬指标——超过这条线,用户还没看到结果就划走了。但模型要更聪明,就得让更多"专家"一起投票,这就意味着算力爆涨。
2026 年 9 月来自 arXiv 2609.21346(IntBMoE) 的工作说:这事可以治,而且解法已经被高德地图(AMAP)落到生产了——在数亿用户的线上 A/B 测试里,推荐点击率(UVCTR)相对提升 2.4%,服务延迟仍然稳稳压在 60 ms P99 以内。
关键洞察出奇简单:MoE 的"全参与投票"和"少量计算"本来就是可以分开拧的两个旋钮,之前的方案都把它们绑死了。IntBMoE 把它们解开,等于把一个两难选择变成一道自由题。
一句话故事
IntBMoE(Interleaved Block-conditioned MoE)用一个小型可学习 codebook + 一个轻量 hypernetwork,把 MoE 的三个独立维度(参与度 / 执行 / 物化)首次同时解开,做到"全专家投票 + 极少计算 + 显存锁死"的三全其美;论文已在高德地图生成式推荐系统上完成真实 A/B 部署,60 ms 延迟下 UVCTR 相对提升 2.4%。
为什么这件事值得你关注
这不是又一篇"MoE 变体论文"。它戳中三个真实痛点:
1️⃣ MoE 三难一一锁死的 30 年——Sparse MoE(Mixtral / DeepSeek-MoE 类)只能让 1–2 个专家参与,信息量小;Dense MoE 让所有专家投票,计算爆炸;Parameter-merging 类要按路由决策多存几份参数,显存吃紧。没人能同时把这三件事独立拧到最佳位。
2️⃣ 工业推荐里 2.4% UVCTR 是硬通货——在数亿用户量级上,推荐系统的 ±0.5% 已经值得独立发版。2.4% 是个让所有推荐团队都坐不住的数,尤其还在 P99 60ms 严格延迟预算内。
3️⃣ 真实部署数据稀缺——绝大多数 MoE 新架构只能给 synthetic benchmark,IntBMoE 直接给"高德地图真实流量 A/B + 数亿用户 + 60ms 延迟"三件套。这是 paper→production 的硬通货,论文配套代码 AMAP-ML/DreamX-Rec 已开源,IntBMoE 推荐示例可直接跑。
这事对以下几类人直接相关:
- 🏢 大厂推荐 / 召回 / 精排团队:IntBMoE 的设计哲学直接对应"全特征耦合 + 严格延迟预算"的国产推荐硬场景
- 🛒 MoE 架构研究者:这是 2026 年 9 月的一份关键节点工作,定义了 participation / execution / materialization 三元组坐标系
- 💻 推理服务工程师(vLLM / TensorRT-LLM / TGI):block-sparse execution + dense representation 的混合 kernel 思路可移植
- 🧪 多任务学习研究者:DPRG 双路径门控的"AND 风格"协同是 open recipe
- 💼 产品经理 / 业务方:如果你的业务被"延迟预算严格 + 容量想拉大"两难卡住,这篇给了一个已经被验证可解的方案
MoE 三难到底卡在哪?——一次说清
MoE(Mixture-of-Experts,混合专家)自 2017 年 Shazeer 等引入大模型后,已经成为"用条件计算换参数容量"的标准做法。但所有现有设计都强迫用户在三个互相冲突的旋钮之间做选择题:
| 设计 | 参与度(几个专家投票) | 执行(实际跑几次 FFN) | 物化(显存占多少份参数) |
|---|---|---|---|
| Sparse routing(Mixtral / GShard / GLaM) | 低(k=1~2) | 低 | 低 |
| Dense output-mixing | 高(全专家加权) | 高(全跑) | 低 |
| Parameter merging | 中 | 低(只跑一个) | 高(每多一种路由决策多一份参数) |
核心矛盾就一句话:要"全专家投票"就得"全跑 FFN",要"少算"就得牺牲"投票多样性",要"显存锁死"就没法加新路由分支——这三个量之前没有一种方案能让你同时拧到最佳。
特别是在推荐系统里:用户每个会话都耦合几十个特征、严格延迟预算 60ms——既要"全专家投票"提升精度,又要"少算"压延迟,还要"显存可控"才能服务数亿用户。这就是为什么高德要把 IntBMoE 真的落到生产。
IntBMoE 的解法:用 codebook + hypernetwork 把三个旋钮拆开
IntBMoE 的核心思路是把"在表征空间投票"和"在物理空间计算"两件事彻底解耦:
# IntBMoE 单层 forward(简化伪代码)
def intbmoe_layer(x, codebook, hypernet):
# 1. router: token -> 选哪几个 block(物理计算量)
block_ids = topk(router(x), k) # 只跑 k 个 block
# 2. hypernet: token -> 所有 expert 的混合系数(全专家投票)
mix_coef = hypernet(x) # dense, 全 E 个 expert 都有系数
# 3. 所有 expert 都 forward 一次(用于产生混合系数下的输出)
expert_outs = [E_i(x) for E_i in expert_pool] # dense 表征投票
# 4. dense weighted sum(participation = E,全参与)
composed = einsum('bte,be->bt', mix_coef, expert_outs)
# 5. 但物理计算只在 block_ids 上做一次(execution 极少)
blocks = codebook[block_ids]
block_out = block_ffn(blocks) # 只算 k 个 block 的 FFN
# 6. 残差合并
return composed + block_out
关键 trick 三连:
1️⃣ Codebook 锁显存——每层维护一个小型可学习 codebook(K × d_b),block 数 K 由 codebook 自身决定,与 token 路由无关。这意味着显存占用是固定上界,不会被路由决策数撑爆。
2️⃣ Hypernet 做 dense 混合——每个内层挂一个轻量 hypernetwork,接受 token 表征,输出该层所有 expert 的混合系数。dense 系数,即"全 E 个专家都参与投票",但 hypernet 本身计算量极小。
3️⃣ Sparse block 物理计算——只在 router 选出的 top-k 个 block 上做一次 FFN 物理计算。k 远小于 E,所以 FLOPs 被压到接近 sparse MoE 的水平。
结果:
- 参与度(participation) = 满(全 E 个专家都投票)
- 执行(execution) ≈
k/E ×dense(约1/8) - 物化(materialization) =
K × block_size,与路由决策数无关(锁死)
对比 Mixtral(k=2,participation 极低):execution 接近,但 participation 多 8 倍;对比 dense MoE(全 E FFN):execution 少 8 倍。两边都赢。
关键实验数据:AMAP 真实部署 + 跨域验证
| 维度 | 数字 / 表述 | 来源 |
|---|---|---|
| 生产部署方 | AMAP(高德地图,阿里旗下) | abstract 明示 |
| 核心指标 | 相对 UVCTR 提升 2.4% | abstract 明示 |
| 延迟约束 | 60 ms P99 | abstract 明示 |
| 用户规模 | 数亿用户 | abstract 明示 |
| 真实流量 | 来自 AMAP 内部生成式推荐真实流量 | abstract 明示 |
| 跨域验证 | Vision + Language + Rec 三个域都跑过 | abstract 明示 |
| 代码仓库 | AMAP-ML/DreamX-Rec 含 IntBMoE 推荐 / 语言 / 视觉示例 |
GitHub 已核实存在 |
⚠️ abstract 中"UVCTR 绝对值、参数量、wall-clock 数据、各域具体数字"未给出,需读 PDF 复核。代码仓库
AMAP-ML/DreamX-Rec当前 release 含 IntBMoE 推荐示例;IntSR(搜索推荐联合)和IntLID(学习率动态调整)等模块尚未 release。
数字冲击力再放大
- 2.4% UVCTR 在推荐系统里是"大数"——一个 ±0.5% 已经值得独立发版
- 60 ms P99 是国产推荐推理的硬天花板——超过这条线,用户已经开始划走了
- 数亿用户规模——这意味着任何性能 regression 都会被实时放大
DPRG:把解耦收益榨干净的双路径门控
为了把解耦收益榨干净,IntBMoE 又加了一个 DPRG(Dual-Path Residual Gating) 模块:两条独立的 composed path(路径 A 与路径 B,分别用不同的 hypernetwork)通过乘法门控耦合:
y = σ(g_A(x)) ⊙ σ(g_B(x)) ⊙ (P_A(x) + P_B(x))
直觉:两条路径形成"AND 风格"的协同收敛,避免单路径塌缩——这种 multiplicative gating 让双路径必须同时活跃才能让信号通过,强迫网络学到两条互补路径的协同,而不是某一条独大。
⚠️ abstract 未明确 σ 的具体形式(sigmoid / tanh / 其他),从工程实践看应为 sigmoid 或类似 0-1 门。
三条对工程团队直接可用的启发
1️⃣ 推荐 / 检索系统:IntBMoE 的"dense mix 表征 + sparse block 物理计算"天然适合大规模推荐 / 召回的"全特征耦合 + 严格延迟预算"场景。如果你正用 dense DNN 做精排,可考虑把 FFN 层替换为 IntBMoE-block——单层参数 ×3-5 几乎不增加 wall-clock。
2️⃣ 大模型推理服务:推理服务商(vLLM / TGI / TensorRT-LLM)可考虑把 MoE layer 的 CUDA kernel 按"block-sparse execution + dense representation"改写,预期显存下降但 FLOPs 不变——这是一个独立可工程化的优化方向。
3️⃣ 多任务学习:DPRG 的双路径乘法耦合天然适合"两个副任务互相校准"场景,可作为多任务 MoE 落地的候选 block。
这件事的工程边界(必须看清)
⚠️ 1. 训练 FLOPs 等价于 dense MoE——训练阶段所有 expert 都要 forward,sparse block 的计算节省只在推理时生效。训练成本没省,需与稀疏化方法(Pruning / 稀疏注意力)做严格区分。
⚠️ 2. DPRG 乘法门训练稳定性——乘法门在深层网络容易梯度消失 / saturation,尤其当两条路径输出值都趋近 0 或 1 时。训练中需监控 gate 输出分布,发现塌缩立即加正则。
⚠️ 3. codebook K 的超参搜索成本——K 直接影响 materialization 上限和生产延迟。K 太小表征多样性不足,K 太大 block FFN 延迟上升。需在自己流量分布上扫 K,而非直接用论文配置。
⚠️ 4. GPU HBM 中 codebook 的静态分配——当 codebook 大小超过 GPU 显存的静态分配阈值时,需要重新配置 CUDA 内存分配策略,可能影响整体 serving 吞吐。建议先跑 memory profiling。
⚠️ 5. 推荐系统延迟 budget 与 UVCTR 提升的权衡——2.4% UVCTR 提升在 AMAP 量级上价值巨大,但 60 ms P99 是硬约束——如果 dense mix 的 FLOPs 提升逼近 budget 上限,增量收益会迅速被延迟惩罚吃掉。需要在离线评测中同时跑延迟分位数曲线。
⚠️ 6. IntSR / IntLID 未开源——IntBMoE 推荐示例可参考,但 IntSR 和 IntLID 未 release。端到端复现 AMAP 完整 pipeline 仍有缺口,落地时需要自己补全。
⚠️ 7. GShard / Mixtral / DeepSeek-MoE 未显式对照——abstract 提到"representative sparse and dense baselines",但是否涵盖 2025 年最新 MoE(DeepSeek-V3 类)需查 PDF。
接入 IntBMoE 的最小可行路径(6 步)
🎯 step 1 · 今天:直接 clone AMAP-ML/DreamX-Rec,跑 IntBMoE/ 目录的推荐示例,摸清 block FFN + dense mix 的实际显存占用曲线(显存 / FLOPs baseline)。
🎯 step 2 · 1–2 周:在自己推荐系统的精排 DNN 上加 IntBMoE block,先在 offline 数据上验证 participation 提升是否带来 recall 收益。重点监控 dense mix 阶段 FLOPs 是否成为新瓶颈。
🎯 step 3 · 1–2 周:在 calibrate set 上扫 codebook K 的最优值(K ∈ {8, 16, 32, 64}),同时监控 DPRG gate 输出分布。
🎯 step 4 · 1–2 月:与推理框架(TensorRT-LLM / vLLM)协同 kernel 优化,确保 dense mix 的表征投票不拖慢 block FFN 的并行。
🎯 step 5 · 1–2 季度:参照 AMAP 的 60 ms P99 硬约束,将 IntBMoE 部署到精排模型。先在 1% 流量上灰度。
🎯 step 6 · 持续:跟踪 AMAP-ML/DreamX-Rec 的 IntSR / IntLID 开源状态,GitHub watch。
这件事的"思维启发"
-
复杂系统的"维度解耦"是普适设计模式——MoE 卡在"三难锁死",本质上是因为三个独立维度被绑在一个表达里。任何"X 个相互制约的旋钮"问题,都可以问一句"能不能先把它们拆开"。IntBMoE 就是这个思路的标准答案。
-
生产数据 > synthetic benchmark——一个真实部署的 2.4% UVCTR × 数亿用户 × 60 ms P99,胜过 100 张学术 benchmark 表。paper→production 的硬通货永远稀缺,而且难以伪造。
-
dense mix + sparse execution 的二元论——"表征空间 dense、物理空间 sparse"是深度学习里反复出现的范式(MoE、知识蒸馏、模型并行都是)。它教我们:参与度和计算量本来就是两件事,把它们绑在一起是历史包袱,不是必须。
-
Codebook 是 materialization 控制的银弹——把"哪些块被激活"从"运行时决定"改成"codebook 索引",等于把动态决策变成静态上界。对延迟敏感的服务系统都有这个需求。
与同方向工作的关系
- vs Mixtral / GLaM / DeepSeek-MoE(sparse MoE):它们都还在 participation / execution / materialization 的妥协曲线里。IntBMoE 把 participation 拉到满、execution 压到 sparse 这件事,从设计哲学上是"新坐标"。
- vs Dense MoE(如 vanilla Soft MoE):Soft MoE 类方法 execution 维度也是 dense,与本工作 sparse block execution 形成对照。
- vs Sparsely-Gated MoE(Shazeer 2017):是同一系谱,但 Shazeer 路线十年来没解决 participation 不足,IntBMoE 用 dense mix 补这个洞。
- vs Block-Sparse MoE(OpenMoE 类):block-sparse 是 execution / memory 维度的工程技巧,不解决 participation;IntBMoE 借用了"block"概念但赋予新含义(codebook 块,而不是 token 块)。
- vs LoRA / Adapter 类参数高效方法:直觉相似(用低秩结构改造 FFN),但 LoRA 是"训练时节约",IntBMoE 是"推理时计算结构改造",动机不同。
一句话总结
IntBMoE 用一个 codebook + 一个 hypernetwork,把 MoE 卡了 30 年的"参与度 / 执行 / 物化"三难首次解开——做到 dense 表征全参与 + sparse block 少计算 + 显存锁死不爆,已在高德地图生成式推荐真实部署,数亿用户 60 ms P99 内拿 2.4% UVCTR 提升;但训练 FLOPs 没省、codebook K 需扫描、DPRG 门控需稳定,工程团队落地需先跑通 memory profiling 和延迟分位数曲线。
🔔 评论区聊聊:你团队现在用的推荐模型里,有没有"全特征耦合 + 严格延迟预算"的两难场景?如果换成 IntBMoE-block,你觉得哪一步最难落地?
三个标题变体
- 反直觉版:高德把推荐系统升级了——arXiv 2609.21346 在 60 ms 内让点击率涨 2.4%,用了一种"全参与、少计算"的反常识设计
- 数字钩子版:2.4% UVCTR × 数亿用户 × 60 ms 延迟——arXiv 2609.21346 让 MoE 的"全专家投票 + 极少计算"首次同框
- 类比版:相当于给 MoE 装了"双速变速箱"——arXiv 2609.21346(IntBMoE)让高德推荐系统在不增加延迟的前提下多猜对 2.4% 的点击
📱 小红书风格卡片文案(直接可用)
📱 你有没有这种感觉:同一个外卖 App、同一个刷脸门禁,底层那个"猜你想看"的模型越做越大,延迟却越压越紧?
这件事在工业界叫"推荐系统的算力账"——60 毫秒是个硬指标,超过这条线用户还没看到结果就划走了。
2026 年 9 月 arXiv 2609.21346(IntBMoE) 把这件事端到了台面上:已在高德地图(AMAP)生成式推荐系统上真实部署,在数亿用户的线上 A/B 测试里,UVCTR 相对提升 2.4%,服务延迟仍然稳稳压在 60 ms P99 以内。
核心 trick 出奇简单:MoE 的"全专家投票"和"少量计算"本来就是可以分开拧的两个旋钮,之前的方案都把它们绑死了。IntBMoE 把它们解开,等于把一个两难选择变成一道自由题。
🧠 三个旋钮到底卡在哪:
| 设计 | 参与度 | 执行 | 物化 |
|---|---|---|---|
| Sparse routing(Mixtral) | 低 | 低 | 低 |
| Dense output-mixing | 高 | 高(全跑) | 低 |
| Parameter merging | 中 | 低 | 高(显存爆) |
核心矛盾:要"全专家投票"就得"全跑 FFN",要"少算"就得牺牲"投票多样性",要"显存锁死"就没法加新路由分支——三个量之前没法同时拧到最佳。
💡 IntBMoE 解法:Codebook + Hypernetwork 三连:
1️⃣ Codebook 锁显存——每层维护一个小型可学习 codebook(K × d_b),block 数 K 由 codebook 决定,与 token 路由无关。显存占用是固定上界,不会被路由撑爆。
2️⃣ Hypernet 做 dense 混合——每层挂一个轻量 hypernetwork,接受 token 表征,输出所有 expert 的混合系数(dense,全 E 个专家都投票)。
3️⃣ Sparse block 物理计算——只在 router 选出的 top-k 个 block 上做一次 FFN(k ≪ E,FLOPs 压到接近 sparse MoE 水平)。
🎯 结果三全其美:
- 参与度 = 满(全 E 个专家投票)
- 执行 ≈ k/E × dense(约 1/8)
- 物化 = K × block_size,与路由决策数无关(锁死)
📊 关键数据:
- 2.4% UVCTR(推荐系统里是"大数",±0.5% 已值得发版)
- 60 ms P99(国产推荐推理硬天花板)
- 数亿用户(任何 regression 都会被实时放大)
- 跨域验证:Vision + Language + Rec 三个域都跑过
- 代码仓库:AMAP-ML/DreamX-Rec 已开源,IntBMoE 推荐示例可直接跑
🧪 配套 trick:DPRG 双路径门控——两条独立 hypernetwork 路径通过乘法门控耦合,强迫网络学到"AND 风格"协同,避免单路径塌缩。
💼 三条工程启发:
1️⃣ 推荐 / 检索系统:如果用 dense DNN 做精排,可把 FFN 层替换为 IntBMoE-block,单层参数 ×3-5 几乎不增加 wall-clock
2️⃣ 大模型推理服务:把 MoE kernel 按"block-sparse execution + dense representation"改写,显存下降但 FLOPs 不变
3️⃣ 多任务学习:DPRG 双路径门控天然适合"两个副任务互相校准"场景
⚠️ 七个边界坑:
- 训练 FLOPs 没省——训练阶段所有 expert 都要 forward,sparse block 节省只在推理时生效
- DPRG 乘法门训练稳定性——深层网络易 saturation,监控塌缩
- GPU HBM codebook 静态分配——超过阈值影响整体吞吐,先做 memory profiling
- codebook K 超参搜索——
K ∈ {8, 16, 32, 64}需自己扫 - 延迟与 UVCTR 权衡——dense mix FLOPs 逼近 budget 上限,增量收益会被延迟惩罚吃掉
- IntSR / IntLID 未开源——端到端复现 AMAP pipeline 仍有缺口
- DeepSeek-V3 类最新 MoE 未显式对照——需读 PDF 核实
🎯 接入路径(6 步):
- 今天:clone
AMAP-ML/DreamX-Rec,跑 IntBMoE 推荐示例,摸清显存 / FLOPs baseline - 1–2 周:精排 DNN 上加 IntBMoE block,offline 验证 recall 收益
- 1–2 周:扫 codebook K 最优值 + 监控 DPRG gate 分布
- 1–2 月:与 TensorRT-LLM / vLLM 协同 kernel 优化
- 1–2 季度:参照 60 ms P99 硬约束部署,1% 流量灰度
- 持续:跟踪 IntSR / IntLID 开源状态(GitHub watch)
📌 一句话:IntBMoE 用 codebook + hypernetwork 把 MoE 卡了 30 年的"参与度 / 执行 / 物化"三难首次解开——dense 表征全参与 + sparse block 少计算 + 显存锁死不爆,已在高德地图真实部署,数亿用户 60 ms P99 内拿 2.4% UVCTR 提升;训练 FLOPs 没省 + DPRG 门控需稳定 + codebook K 需扫描,落地前先跑 memory profiling 与延迟分位数曲线。
🔔 评论区聊聊:你团队现在用的推荐模型里,有没有"全特征耦合 + 严格延迟预算"的两难场景?如果换成 IntBMoE-block,你觉得哪一步最难落地?