🤖 machine learning

Lynx: Enabling Efficient MoE Inference through Dynamic Batch-Aware Expert Selection

Lynx 是一个与负载无关的系统，它通过利用训练诱导的激活偏斜，并采用一种新颖的亲和分桶（AffinityBinning）技术来动态重映射令牌到专家的分配，从而减少被调用的专家数量，在不过度牺牲准确性的前提下将吞吐量提升高达 1.30 倍。

原作者： Vima Gupta, Jae Hyung Ju, Kartik Sinha, Ada Gavrilovska, Anand Padmanabha Iyer

发布于 2026-05-20

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Vima Gupta, Jae Hyung Ju, Kartik Sinha, Ada Gavrilovska, Anand Padmanabha Iyer

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你经营着一家名为“混合专家厨房”（The MoE Kitchen）的超大规模高端餐厅。

在这间厨房里，你并非拥有一位试图烹饪每一道菜品的巨型主厨，而是拥有一支由 64 位专业副厨（即“专家”，Experts）组成的团队。还有一位领班（即“路由器”，Router），他会查看每一道订单（即“词元”，Token），并决定哪 8 位特定的厨师来烹饪这道菜。

这种设置非常精妙，因为它高效：你无需为所有 64 位厨师处理每一道订单而支付费用，只需为所需的 8 位付费。现代人工智能模型（如 Qwen 或 Llama）正是如此运作——它们体量巨大，但在生成每个词时，仅“唤醒”其大脑中的一小部分。

问题：高峰时段的交通拥堵

该论文阐述了一个当餐厅变得繁忙（即“批处理”，Batching）时出现的主要问题。

当你只有一位顾客时，领班会将订单发送给 8 位特定的厨师。这很简单。
但当你有一批 16 位顾客时，领班会查看所有 16 份订单。由于每位顾客都不同，领班最终需要调用“几乎全部 64 位厨师”来处理整个群体。

瓶颈：
厨房的布局是将食材（即厨师们的知识）存储在一个巨大的高速储藏室（即"GPU 显存”）中。为了烹饪，厨师们必须跑去储藏室取他们特定的食材。

问题所在： 当 16 位顾客到达时，储藏室会人满为患。厨师们花在往返取食材上的时间比实际烹饪的时间还要多。厨房变慢了，因为“奔跑”（内存带宽）成为了瓶颈，而非“烹饪”（计算）。
结果： 尽管人工智能本应快速高效，但在同时处理多个请求时，它会因卡在数据获取上而变得极其缓慢。

解决方案：LYNX（智能领班）

作者们创造了一个名为LYNX的新系统。可以将 LYNX 想象为一位超级聪明、动态的管理者，他仅在厨房繁忙时（即“解码”阶段，这好比餐厅一口一口地供餐）介入。

LYNX 不会解雇任何厨师或更改菜单。相反，它使用一种称为亲和分箱（AffinityBinning）的巧妙技巧（一种“按置信度分组”的 fancy 说法）。

以下是 LYNX 逐步工作的过程：

“置信度”检查：
有时，领班 100% 确定厨师 A 是这道菜的最佳人选。其他时候，领班不确定，只是根据“必须选择 8 个不同人”的规则选择了厨师 B。论文发现，这些“不确定”的选择往往是冗余的。
- 类比： 如果你问朋友电影推荐，他们说“我不确定，但也许是《电影 X》或《电影 Y》”，他们其实对两者都没有真正的承诺。如果你再问一次，他们可能还是会选《电影 X》。
“分箱”策略：
LYNX 查看领班的置信度分数，将订单分组到不同的“桶”中。
- 高置信度： “这道订单必须交给厨师 A。”（LYNX 对此保持不变）。
- 低置信度： “这道订单只是有点适合厨师 B。”（LYNX 会说：“实际上，让我们把它交给厨师 A 吧，因为厨师 A 已经在这批订单的其他任务中在厨房忙活了。”）
重新映射：
LYNX 将这些“低置信度”的订单重新定向给那些已经被该批次使用的厨师。
- 神奇之处： 厨房不再需要为 64 位不同的厨师跑去储藏室取食材，而只需为例如 30 位厨师跑去取。
- 结果： 厨师们花在奔跑上的时间更少，花在烹饪上的时间更多。厨房运转得更快了。

为何这很特别

论文强调了 LYNX 之所以重要的三个关键原因：

它是“工作负载无关”的： LYNX 不需要针对特定类型的顾客或菜单进行训练。它每次都能即时找出模式。这就像一位管理者能瞬间学会人群的习惯，而无需查阅手册。
它不会破坏任何东西： LYNX 不解雇厨师，也不改变食谱。它只是重新安排在特定时刻谁做什么。论文表明，食物（即人工智能的回答）味道一样好，有时甚至更好，因为它不再强迫厨师去烹饪他们不确定的菜品。
它能与他人良好协作： LYNX 可以叠加在其他加速技巧之上（例如缩小厨师的围裙或将他们送往不同的建筑），使它们变得更快。

结果

当作者在真实世界的人工智能模型（如 Qwen、Mixtral 和 Llama）上测试该方法，涵盖编码、数学和推理等任务时：

速度： 在最坏的情况下，系统速度提升了1.3 倍（即 30% 的加速）。
准确性： 答案的准确性保持不变，甚至略有提升。在最坏的情况下，准确率下降不到 1%，几乎难以察觉。
效率： 它允许系统在不减速的情况下同时处理更多顾客。

总结

LYNX 就像繁忙人工智能厨房的交通警察。它注意到，当一批订单涌入时，厨房因要为太多不同的厨师跑去储藏室而浪费时间。因此，它巧妙地将那些“也许”的订单重新定向给已经在工作的厨师，从而减少交通拥堵，让食物更快端出，同时不改变菜单也不解雇任何人。

技术摘要：LYNX – 通过动态批感知专家选择实现高效 MoE 推理

1. 问题陈述

现代基础模型越来越多地采用混合专家（Mixture-of-Experts, MoE）架构，以将参数量与计算成本解耦。尽管 MoE 每个 token 仅激活一小部分参数（例如 Qwen2-57B 中 570 亿参数里仅激活 14 个），但由于延迟与吞吐量之间的张力，这一效率承诺在生产服务中无法实现。

为了实现高吞吐量，推理系统会对请求进行批处理。然而，由于批处理中的每个 token 独立选择其 top- $k$ 个专家，必须从高带宽内存（HBM）加载的专家集合会随着批大小和组成的变化而增长。在满足延迟服务等级目标（SLO）所需的中等批大小下，这种动态的、数据依赖的内存访问模式使得 MoE 解码受限于内存带宽。因此，延迟会随着整个批处理中激活的不同专家总数而增加，往往导致整个专家池被饱和（例如，仅 8 个多样化请求组成的批处理即可激活 Qwen2-57B 中的所有 64 个专家）。这抵消了 MoE 的稀疏性优势，使其性能与同等容量的稠密模型相似，却增加了动态专家移动的额外开销。

现有解决方案，如静态剪枝、量化或聚类，依赖于离线校准并永久改变模型，使其难以适应工作负载的变化。动态的 per-token 方法未能解决瓶颈，因为它们没有减少批处理层面获取的专家总数。

2. 方法论：LYNX

LYNX 是一个与工作负载无关的系统，旨在无需修改模型架构或进行离线校准的情况下，缓解 MoE 推理中的内存带宽瓶颈。它利用了一个源自 MoE 训练动态的关键洞察：负载均衡损失迫使路由器将 token 广泛地分配给各个专家，即使对次要选择的置信度较低。这造成了批级别冗余，即路由器选择专家是出于训练约束，而非真正的 token-专家亲和力。

LYNX 通过一种新颖的**AffinityBinning（亲和力分箱）**技术和完全在运行时运行的三组件管道来利用这种冗余：

2.1 核心原则

该设计基于三个经验观察：

阶段敏感性：MoE 在*预填充（prefill）阶段受计算限制，而在解码（decode）*阶段受内存带宽限制。专家重映射仅在解码阶段有益。此外，预填充阶段对专家保真度高度敏感，而解码阶段对重新分配具有鲁棒性。
Token 置信度：路由器置信度分数（源自排名最高专家 logits 之间的差距）可可靠地识别哪些 token 到专家的映射是关键的。低置信度 token 可以被重新映射，且对精度的影响极小。
专家等级层次：排名最高的专家（rank-0）主导输出质量。top- $k$ 中排名较低的专家表现出高度冗余。对重新分配的敏感度也随层而变化。

2.2 系统组件

LYNX 通过一个阶段感知优化器和三个轻量级 CUDA 内核组件与服务引擎（如 vLLM）集成：

阶段感知优化器：判断当前迭代是受内存限制（解码）还是受计算限制（预填充）。它在预填充或分块预填充阶段绕过 LYNX 逻辑，以避免不必要的开销。
置信度分析器：拦截每一层的路由器 logits。它使用AffinityBinning将每个 token 的路由器置信度离散化为多个箱。箱宽和数量完全由模型的稀疏率（ $k/N$ ）决定，使系统具备自校准能力且独立于工作负载。它识别出与其分配专家亲和力较低的 token。
自适应专家评分器：为每个专家计算批级别分数。它使用基于置信度分析器分配的箱值的指数加权方案。这确保了高置信度 token 偏好的专家获得不成比例更高的分数。它确定了该批处理所需的“关键”专家的最小集合。
专家重映射器：将低亲和力的 token 到专家分配重定向到幸存的关键专家集合。关键在于，LYNX 保留了top- $k$ 激活语义；每个 token 仍然激活恰好 $k$ 个专家，但整个批处理共同激活的独立专家集合更小、更集中。

2.3 实现

LYNX 作为 vLLM 之上的即插即用模块实现。其核心逻辑使用四个融合的 Triton/CUDA 内核来实现，这些内核拦截路由器输出。该设计消除了中间张量数据的移动，并减少了内核启动开销，确保系统在关键路径上运行时仅增加可忽略的延迟（<4% 开销）。

3. 主要贡献

首个工作负载无关系统：LYNX 是首个无需校准数据或永久模型更改即可缓解 MoE 推理中内存带宽瓶颈的系统。
AffinityBinning 技术：一种基于架构稀疏率离散化路由器置信度的新颖方法，使系统能够自动适应任何 MoE 架构。
批级别优化：与以往 per-token 动态方法不同，LYNX 在批级别运行，以减少从 HBM 获取的独立专家总数，直接解决内存带宽瓶颈。
互补性：LYNX 设计为与现有优化（包括卸载和量化）协同工作。

4. 实验结果

LYNX 在来自四个家族（Qwen、DeepSeek、Mixtral、Llama）的最先进模型上进行了评估，涵盖了八个基准测试（代码生成、数学、推理和视觉）。

延迟降低：与基线相比，LYNX 实现了高达1.30 倍的延迟降低（每个输出 token 的时间）。在解耦服务场景（预填充和解码分离）中，降低幅度可达 1.35 倍。
精度影响：在最坏情况下，系统造成的精度损失小于 1%。值得注意的是，LYNX 经常提高平均精度（例如，DeepSeek-Coder-V2 在 HumanEval 上提升了 +1.9%），这表明训练时的负载均衡迫使选择了次优专家，而 LYNX 对此进行了修正。
吞吐量：在固定 SLO 预算下（例如 25ms 或 50ms），LYNX 将系统吞吐量提高了高达2.1 倍。
兼容性：
- 卸载：当与卸载技术（如 Fiddler）结合使用时，LYNX 将性能提升了31%。
- 量化：在 INT4 量化之上应用时，LYNX 提供了额外的**10%**加速。
- 并行化：LYNX 在专家并行（EP）和张量并行（TP）之上提供了额外的吞吐量增益。
鲁棒性：性能提升在不同批大小（在中等大小处饱和）和具有突发到达率的真实世界轨迹中保持一致。

5. 意义

该论文指出，随着 GPU 计算能力继续超越内存带宽的增长，MoE 解码的算术强度差距将扩大，使得内存受限的瓶颈变得日益关键。LYNX 通过从根本上改变批级别专家选择的方式来解决这一问题。通过利用训练时负载均衡引入的冗余，LYNX 使 MoE 架构能够在未来硬件上实现其效率承诺，而无需模型重新训练或离线分析。该系统证明，动态的、运行时感知的专家管理可以显著地将吞吐量与当前 MoE 服务范式固有的内存带宽限制解耦。