arXiv'26 | DySHARP：MoE 通信里一半流量是重复的，让 NVSwitch 帮你去重

July 22, 2026

2026   ·   MoE   分布式训练   NVLink   论文解读  

arXiv’26 | DySHARP：MoE 通信里一半流量是重复的，让 NVSwitch 帮你去重

原文：Accelerating MoE with Dynamic In-Switch Computing on Multi-GPUs

1. 前言

作为研究 MoE 系统的牛马，expert parallelism（EP）的通信开销是我绕不开的老对手：DeepSeek-V3 这种规模的模型，MoE 层里 Dispatch + Combine 能吃掉 70% 的时间，GEMM 反而只占三成。这篇 HKUST + 上交 + 华为 + 北大的工作提出了一个我之前没认真想过的角度：这些通信流量里有接近一半是重复的，而去重这件事可以让 NVSwitch 交换机来干。

先解释两个概念，后面反复用：

  • Dispatch：token 经过 router 选中 top-k 个 expert，要把这个 token 的激活发到 k 个 expert 所在的 GPU——注意，是同一份数据发给多个目的地
  • Combine：k 个 expert 算完，各自把结果发回 token 的原 GPU 做加权求和——是多份数据回来后被归约成一份

看出问题了吗？Dispatch 时同一个 token 的数据从 GPU 到交换机传了 k 次（内容一模一样）；Combine 时 k 份”注定要被加起来”的结果分别占用 k 次交换机到 GPU 的传输。从交换机的视角看，这些都是冗余：

MoE 的通信冗余与 in-switch computing 机会

理想情况：Dispatch 时 GPU 只发一份给交换机，交换机负责多播；Combine 时交换机先归约再回传一份结果。这就是 in-switch computing。冗余量化一下：

冗余流量占比与消除冗余的理想加速

DeepSeek-V3 在模拟的 GH200 NVL32 32-GPU 系统上，冗余流量占 25-50%，消除后通信理想加速最高接近 2 倍。

2. 核心矛盾：NVLS 只会做”静态”的事

NVIDIA 其实已经有 in-switch computing 了——NVLink SHARP（NVLS），AllReduce 就靠它加速。那直接用不就完了？

不行，而且原因很本质。NVLS 是为静态集合通信设计的：

静态 vs 动态通信模式，NVLS 的适用边界

  • 静态（AllReduce/AllGather）：目标集固定（永远是全体 GPU），地址对称（每个 GPU 上同一个 multimem 地址映射到相同偏移）
  • 动态（Dispatch/Combine）：目标集由 router 逐 token 决定（这个 token 发给 GPU {0,2}，下个发给 {1,3}），地址不对称（每个 GPU 收到的 token 数不同，紧凑排布后同一 token 在不同 GPU 上的偏移完全不同）

硬套 NVLS 的后果是什么？把动态通信重写成静态集合操作（比如把 Dispatch 当 AllGather 发全量），无用流量暴涨 340%，in-switch 省下的还不够填这个坑——论文实验里 NVLS 方案比 DeepEP 还慢一截（0.3-0.6 倍）就是这么来的。

这就是这篇文章要补的功能缺口：让 in-switch computing 学会处理”目标不固定、地址不对称”的动态通信。

3. 方案：两条腿缺一不可

3.1 Dynamic multimem addressing：ISA/架构/运行时三层协同

核心思路：数据包携带一个 multimem 地址 + 一份轻量目标列表，“发给谁”由包自己说，”存在哪”由每个 GPU 本地管。这解开了静态 NVLS 的两个死结（固定目标、对称地址）。

新增两条指令：

  • dymultimem.st：Dispatch 用，交换机按目标列表多播
  • dymultimem.ld_reduce：Combine 用，交换机收齐 k 份后归约，只回传最终结果

三个硬件触点的改动如下：

dynamic multimem 寻址框架的架构设计

对照上图从左到右走一遍：

  1. 源 GPU：SM 里的 LSU 加了一个 MultimemQ。常规指令读了操作数就发射，dymultimem 指令要先按”目标数 + 基地址”从内存取目标列表，凑齐了才把完整请求包发上 NVLink——不能堵住原来的 LSQ，所以单独排队
  2. 交换机：Route 模块按目标列表复制包，每个副本只保留发往该端口的目标（OutPort = Target / 每 GPU expert 数）；Combine 方向 Reduction Logic 给每个请求记目标数，部分响应到一个减一个，清零时把归约结果发回源 GPU
  3. 目的 GPU：Hub 里加了硬件 memory manager，维护一张 AL Table（algebraic index → layout index），把”逻辑上第 i 个 token”翻译成本地紧凑内存里的实际位置，配 AL TLB 加速。Dispatch 时增量分配 layout block，保证碎片化的 token 存成致密张量；Combine 复用同一张映射表反查

这里的关键设计判断是：地址翻译放目的端硬件做，而不是源端软件做。源端软件管理要来回同步元数据（token 到达计数之类），DeepEP 的部分开销正来自于此。

3.2 Token-centric kernel fusion：不对称的流量省不出加速

第一条腿做完，发现一个反直觉的事：流量砍半了，速度没快多少。为什么？

Dispatch 的冗余在 GPU→switch 方向被消除，Combine 的冗余在 switch→GPU 方向被消除。但传统调度里 Dispatch、GEMM、Combine 是串行的三个阶段——Dispatch 阶段只用上行带宽（下行闲着），Combine 阶段只用下行带宽（上行闲着）。流量减少是方向不对称的，串行执行时每个阶段的瓶颈方向并没有变短多少。

解法：把整条 Dispatch → GEMM-1 → GEMM-2 → Combine 链按 token 粒度流水线化，让 Dispatch 和 Combine 同时在跑，上下行带宽互补着用：

token 级数据依赖链与 SM 分组

实现要点：

  • SM 分组：SM 划成四组分别跑 Dispatch / GEMM-1 / GEMM-2 / Combine 的 persistent thread block（megakernel 绕过硬件 TB 调度器），两个 GEMM 组可以互借空闲 SM
  • readiness 门控：token tracker 硬件表跟踪每个 token 的就绪状态；GEMM 的某行 tile 只有等它依赖的 token 全部到齐才发射，Combine 只有等某 token 的 top-k 个 expert 输出全就绪才发 ld_reduce
  • 同步 tile 尺寸取 128，正好对齐 GEMM tile——再细会拖累 GEMM 效率，再粗会损失 overlap

4. 效果

模拟平台是 GH200 NVL32（32 GPU，9 台 NVSwitch，cycle-accurate：BookSim2 + 魔改 Accel-Sim，H200 规格）。Baseline 阵容很全：DeepEP、NVLS、FasterMoE、Tutel、CCFuser、COMET、DualPipe。

训练端到端：

端到端训练加速

对 DeepEP 几何平均 1.93 倍（最大 2.3 倍左右，Large-32 配置），对 COMET 也有 1.63 倍；MoE 层单独看，对 DeepEP 几何平均 2.26 倍。NVLS 那根矮柱（几何平均反而只有 DeepEP 的三成）就是”静态方案硬扛动态通信”的代价，非常有画面感。

消融实验值得细看，它验证了”两条腿缺一不可”：

时间分解与消融：两个技术单独都不够

  • DySHARP-Basic（只有动态寻址，无 overlap）：流量砍了，但 Dispatch+Combine 时间只从 0.494 降到 0.462——不对称问题活生生摆在这
  • Fusion Only（只有 kernel fusion，无 in-switch）：0.512，比 COMET 还略差，fusion 自己不产生流量减少
  • 完整 DySHARP：通信时间压到 0.061（ideal）/ 完全被计算掩盖（eval 里 exposed communication 几乎为零），MoE 层最高 2.8 倍于 DeepEP

推理端到端也测了（Large-32 配置约 1.9 倍 vs DeepEP）：

推理端到端加速

硬件开销方面，交换机和 GPU 的增量逻辑都很轻（AL Table 放 DRAM，TLB 和 buffer 是小 SRAM），论文还讨论了经由 IB Quantum Switch 的多节点扩展，思路是把整个集群抽象成共享内存，NVSwitch 管节点内、IB Switch 管节点间的多播/归约。

5. 一点个人 take

  1. “冗余在交换机视角下才可见”是个很好的抽象升维。GPU 侧的通信优化（DeepEP 的分层通信、COMET 的重叠）做得再好，也只是把冗余流量传得更高效，没有消除冗余本身。换到交换机视角，Dispatch 是多播、Combine 是归约，两者都是网络设备的经典能力——MoE 的 all-to-all 从来就不是真正的 all-to-all，是被迫用 all-to-all 表达的 multicast + reduce。这个 framing 我很喜欢。
  2. 消融里”流量减半但不加速”的教训值得所有做通信优化的人记住：带宽是有方向的，节省也是有方向的。不对称的节省要靠调度上的重叠来”兑现”，否则就是纸面收益。这和我们做 offloading 时”PCIe 上下行错峰”是同一个道理。
  3. 冷静的部分：这是需要改 NVSwitch 和 GPU 硬件的方案，模拟器数字再漂亮，落地取决于 NVIDIA 愿不愿意把 NVLS 做成动态的。不过考虑到 MoE 已经是主流架构、且论文展示的改动相对克制（复用 NVLS 的骨架做动态扩展），我觉得这个方向进厂商 roadmap 的概率不低。倒是软件侧可以先抄作业：token-centric 的 readiness 门控流水线不依赖新硬件，DeepEP 们完全可以借鉴。

欢迎评论区交流，尤其是搞 EP 通信的朋友。

顺带一提，MoE 系统优化是我自己的主研究方向之一（ExpertFlow 就是做稀疏 MoE 推理的）。我们也把 LLM 效率优化这条线的方法论整理进了《动手学 AutoML：从 NAS 到大语言模型优化实战》——书里第 8 章讲 LLM 压缩与模型融合，和通信优化角度不同，但目标一致：让大模型跑得起、跑得快。对 MoE 感兴趣的读者可以两条线对照着看。

动手学AutoML书籍封面

Flag Counter