💬 NLP

GEM: GPU-Variability-Aware Expert to GPU Mapping for MoE Systems

GEM 是一个框架，它通过将专家根据硬件差异和令牌负载模式映射到 GPU，从而优化混合专家（MoE）模型的推理延迟，以此缓解拖尾效应并将端到端性能提升高达 16.5%。

原作者： Sourish Wawdhane, Avinash Kumar, Poulami Das

发布于 2026-05-20

📖 1 分钟阅读☕ 轻松阅读

原作者： Sourish Wawdhane, Avinash Kumar, Poulami Das

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

想象你正在经营一家高端餐厅的厨房（即GPU 集群），你有一支由专业厨师（即专家）组成的团队，同时为众多顾客准备大量的菜肴。

在现代“混合专家”（MoE）AI 模型中，厨房并非由一位全能的大厨包揽所有工作，而是拥有许多更小型的、专业化的厨师。对于 AI 生成的每一个词（即一个“token”），一位经理（即路由器）会决定哪两位厨师负责烹饪该特定词汇。

问题：“最慢厨师”规则

在这个厨房里，有一条严格的规定：整个团队必须等待最慢的人完成任务后，才能进入下一步。

如果你有 8 位厨师，其中 7 位在 10 秒内完成了任务，但有一位厨师因为速度较慢或工作量过大而花费了 12 秒，那么整个厨房都会被迫多等待这额外的 2 秒。在 AI 领域，这种等待时间被称为"拖后腿者"（straggler），它会扼杀整个系统的速度。

该论文指出，导致厨师成为“拖后腿者”的主要原因有两个：

分配不当：经理不小心将最繁忙、最受欢迎的食谱全部分配给了某一位厨师，而其他厨师则处于闲置状态。
硬件差异：即使工作被完美分配，由于特定硬件（如较旧的烤箱或疲惫的手臂）的原因，某些厨师天生就比其他厨师慢。论文发现，在一组外观相同的 GPU 中，最快的那台比最慢的那台快了近28%。

旧方法：“工作量相等，时间相等”

之前的解决方案试图通过给每位厨师完全相同数量的菜肴来解决这个问题。他们的想法是：“如果每个人的工作量相同，大家就会同时完成。”

但这行不通，因为：

速度差异：一位快速厨师在相同时间内能比慢速厨师多烹饪 14% 的菜肴。如果你给他们完全相同的工作堆，快速厨师会提前完成并等待，而慢速厨师仍在挣扎。
隐藏模式：有些厨师几乎一直很忙（一致性专家），而另一些厨师则只在短暂而强烈的爆发期一起忙碌（时间性专家）。旧方法忽略了这些“突发性”模式。如果两位总是在完全相同时间变得忙碌的厨师被分配到同一台慢速机器上，整个厨房就会陷入停滞。

新方案：GEM（感知 GPU 差异的专家映射）

作者提出了GEM，这是一个智能系统，就像一位天才厨房经理，确切知道每位厨师的速度以及订单是如何到来的。

GEM 运用了两个巧妙的策略：

1. “比例负载”策略
GEM 不是给每个人相同数量的菜肴，而是给快速厨师更多菜肴，给慢速厨师更少菜肴。

类比：想象一场比赛。如果一名跑步者比另一名快 14%，你不会给他们相同的距离。你会给快者更长的赛道，这样他们就能在同一时刻冲过终点线。
GEM 精确计算快速 GPU 能额外处理多少工作量，以确保所有人同时完成该层计算。

2. “模式侦探”策略
GEM 会观察厨房一小段时间（仅 16 个步骤），以了解两件事：

谁一直很忙？（一致性专家）。
谁会同时变得忙碌？（时间性专家）。
类比：如果厨师 A 和厨师 B 总是在同一时间迎来巨大的订单高峰，GEM 会确保他们不被分配到同一台慢速烤箱上。它会将他们分散到不同的工作站，以免彼此形成瓶颈。

GEM 的工作原理（四步流程）

观察与学习：GEM 会观察 AI 极短的一瞬间，看看哪些专家被使用以及何时被使用。
测试硬件：它运行快速测试，以确切了解每台特定 GPU 在不同负载下的速度。它通过仅在特定的“里程碑”处进行测试（例如每 32 英里检查一次车速，而不是每英里都检查）来智能地节省时间。
搜索：它运行模拟，以寻找厨师与烤箱的完美排列。它会尝试交换厨师的位置，直到找到一种设置，使得“最慢”的厨师尽可能快地完成。
部署：它锁定这种新排列。AI 开始运行，由于工作是根据机器的实际速度进行平衡的，整个系统运行得更加顺畅。

结果

当作者在五个不同的高性能 AI 模型上测试此方法时：

速度提升：AI 完成任务的平均速度提高了7.9%。
最佳情况：在某些情况下，速度提高了16.5%。
更流畅的体验：“尾部延迟”（即导致用户感觉 AI 卡顿的最坏情况延迟）改善得更为显著，最高达16.9%。

简而言之，GEM 通过给快速部分分配更多工作、给慢速部分分配更少工作，并确保没有两个“忙碌”的专家被卡在同一个慢速机器上，从而阻止 AI 等待系统中最慢的部分。它将硬件差异从弱点转化为提升性能的工具。

技术摘要：GEM——面向混合专家模型的 GPU 感知专家到 GPU 映射

1. 问题陈述

混合专家（MoE）模型通过在每个 token 上仅激活部分“专家”子网络来提高推理效率。然而，在真实世界的服务环境中，其性能受到**慢速 GPU（straggler GPUs）**的严重瓶颈制约。在锁步执行模式下，一个批次必须等待最慢的 GPU 完成某层的处理后才能继续。

该论文指出，现有解决方案未能同时解决导致慢速 GPU 的两个主要原因：

专家负载不均衡：某些专家的使用频率远高于其他专家。如果这些“高频使用”的专家被共置于同一块 GPU 上，该 GPU 就会成为瓶颈。
硬件性能差异：由于工艺偏差、环境因素和电源管理，现代 GPU 表现出固有的性能差异。即使 token 负载完全均衡，物理上较慢的 GPU 仍会成为慢速节点。

prior 工作试图通过引入专家利用率的伪均匀性（损害模型精度）或动态重分布专家（产生内存开销）来解决此问题。关键在于，这些方法对硬件性能差异一无所知，往往将高频使用的专家放置在最慢的可用 GPU 上，从而 perpetuating 慢速节点问题。

2. 方法论：GEM 框架

作者提出了GEM（GPU 感知专家映射），这是一个通过显式考虑任务特定的 token 负载和硬件性能特征，将专家映射到 GPU 的框架。GEM 通过四步流程运行：

步骤 1：专家利用率追踪

GEM 在在线推理期间捕获特定任务的 token 路由模式。它统计路由到每个专家的 token 数量，以构建利用率追踪。

洞察：论文区分了一致性专家（在大多数时间步频繁使用）和时序专家（使用频率低，但在特定的相关突发中大量使用）。
优化：实验表明，16 个时间步的追踪长度足以捕捉一致性和时序模式，而不会延迟部署。

步骤 2：性能差异分析

GEM 将 MoE 层的延迟作为 token 负载的函数，在不同 GPU 上进行性能分析。

挑战：细粒度分析（每个 token 计数）太慢（需数小时），而粗粒度采样会错过 MoE 延迟的“阶梯”特性（即延迟在特定批次大小处发生跳跃）。
解决方案：GEM 仅在tile 边界（32 或 64 个 token 的倍数，即延迟发生跳跃处）采样 token 计数。这将分析时间从数小时缩短至数分钟（例如，Llama-4-Scout 仅需 3 分钟），同时保持准确性。

步骤 3：感知差异的专家映射

GEM 使用迭代启发式搜索来寻找最优的专家到 GPU 映射。

评分函数：GEM 不是平衡 token 数量，而是最小化所有时间步的慢速节点延迟总和。分数 $S(M)$ 计算如下：
$S(M) = \sum_{t \in T} \max_{g} (C_g(n_g(M, t)))$
其中 $C_g$ 是根据差异分析得出的 GPU $g$ 在 token 计数 $n_g$ 下的延迟成本。
应用的关键洞察：
1. 非均匀负载平衡：较快的 GPU 被分配比例上更多的 token，而较慢的 GPU 分配较少，从而使所有 GPU 几乎在同一时间完成某层的处理。
2. 相关性处理：GEM 检测相关的时序专家（在突发中同时使用的专家），并确保将它们放置在不同的 GPU上。此外，它避免将这些高负载专家放置在最慢的 GPU 上。
搜索算法：系统从多个初始映射开始（通过向利用率指标添加噪声以确保多样性），并迭代交换专家对以降低总慢速节点延迟分数，直到收敛。

步骤 4：部署

一旦确定最优映射，GEM 在模型加载时将专家权重加载到其分配的 GPU 上。MoE 路由器继续按常规分发 token，但专家的物理位置现在已针对特定硬件集群进行了优化。

3. 主要贡献

双重瓶颈的识别：论文强调，慢速节点源于非均匀专家利用率与固有 GPU 硬件差异的结合，这是 prior 静态或动态平衡方法所忽视的问题。
GEM 框架：首个针对 MoE 模型执行硬件差异感知专家映射的框架。
新颖的映射策略：
- 基于延迟的平衡：从平等的 token 分布转向基于 GPU 速度的比例 token 分布。
- 时序专家检测：识别并分离相关的时序专家，以防止单个 GPU 上出现同时的负载峰值。
高效分析：一种 tile 边界采样策略，可在数分钟而非数小时内捕获硬件差异分析。

4. 实验结果

作者在五个最先进的 MoE 模型（Mixtral-8x7B、Mixtral-8x22B、Llama-4-Scout、Hunyuan-A13B、Qwen3-30B-A3B）上，使用 ShareGPT 和 CodeContests 数据集评估了 GEM。他们在 4-GPU 节点上模拟了三种级别的 GPU 差异（低、中、高）。

端到端延迟：与基线（vLLM 的默认线性映射）相比，GEM 将延迟平均提高了7.9%，最高达16.5%。
- 高差异设置下的收益最为显著（高达 16.5%）。
- 即使在低差异设置下，GEM 通过优化相关时序专家也提供了改进（高达 4.5%）。
尾部延迟（p90 TPOT）：GEM 将第 90 百分位的每输出 token 时间平均降低了9.1%（最高达 16.9%），显著改善了感知响应速度。
分析开销：差异分析和映射过程总耗时不到 4 分钟，与生产环境中数小时或数天的推理服务时间相比微不足道。

5. 意义与主张

论文声称 GEM 是首个面向 MoE 推理的硬件差异感知专家映射框架。其意义在于将硬件差异从一种负担转化为一种可被利用的映射约束，从而提升性能。

作者强调：

简单地平衡 token 数量是不够的，因为它忽略了硬件异构性。
忽视时序专家（通常具有相关性）会导致即使平均负载平衡，映射结果仍次优。
随着系统规模扩大（例如从 4 个 GPU 增加到 64 个 GPU），最快与最慢 GPU 之间的差距单调扩大，使得差异感知映射对于大规模部署变得日益关键。

该工作证明，通过将专家放置与 token 路由的统计特性以及 GPU 性能的物理现实相一致，可以在不重新训练模型或产生重大内存开销的情况下实现显著的延迟降低。