[Paper] FUSCO：通过变换-通信融合实现高性能分布式数据洗牌

发布: 2天前 (2025年12月26日 GMT+8 22:16)

6 min read

原文: arXiv

Source: arXiv - 2512.22036v1

概述

本文介绍了 FUSCO，一种新型通信库，旨在加速在大规模 Mixture‑of‑Experts（MoE）模型的训练和推理中占主导地位的数据洗牌步骤。通过将数据布局转换与实际网络传输融合，FUSCO 能够削减通信开销，而该开销在现有系统中可能占总运行时间的一半以上。

Transformation‑Communication Fusion: 检测 MoE 的 expert‑major 布局与 GPU 通信原语所需的 device‑major 布局之间的不匹配，并将布局转换与发送/接收操作合并。
Pipelined Communication Engine: 在多跳路径上执行融合后的操作，使网络和计算流水线保持忙碌，避免空闲时间。
Lightweight Planning & Load Balancing: 生成紧凑的通信计划，去除冗余传输，并在设备之间均匀分配流量，防止瓶颈。
Performance Gains: 在合成基准测试中实现相较于 NCCL 提升 3.84×、相较于 DeepEP 提升 2.01×，在真实 MoE 工作负载中实现端到端训练延迟降低 1.10–1.39×。
Open‑Source Prototype: 提供可直接替换现有 MoE 框架的原型，仅需极少的代码修改。

布局分析： FUSCO 首先检查 MoE gating 网络生成的 token‑to‑expert 路由映射图。该映射图揭示了细粒度的 “expert‑major” 排序（所有属于 expert E₁ 的 token，然后是 E₂，…）。
融合规划： 与先将张量重新排列为 “device‑major” 顺序（如 NCCL 所做）再发送不同，FUSCO 构建一个 融合计划，告诉每块 GPU 如何切分本地缓冲区、在飞行中转换切片，并直接推送到目标设备。
流水线引擎： 该计划由轻量级运行时执行，重叠三个阶段：(a) 本地数据提取，(b) 转换（例如转置/reshape），以及 (c) 网络发送/接收。由于这些阶段是流式的，GPU 可以在前一个切片传输期间继续处理下一个切片。
负载均衡： 引擎监控每个设备的流量，并动态将小的 “spill‑over” 块重新分配到利用率较低的链路，确保没有单个 NIC 成为热点。
集成： FUSCO 暴露与 NCCL/DeepEP 相同的 API 接口，因此现有的 MoE 代码库（如 DeepSpeed、Megatron‑LM）可以在不重写路由逻辑的情况下切换后端。

Benchmark	Baseline (NCCL)	DeepEP	FUSCO	Speedup vs. NCCL	Speedup vs. DeepEP
Synthetic expert‑shuffle (64 GPUs)	1.24 s	0.62 s	0.32 s	3.84×	2.01×
GPT‑3‑style MoE training (128 GPUs)	1.87 s/step	1.71 s/step	1.48 s/step	1.26×	1.16×
Inference first‑token latency (32 GPUs)	12.4 ms	11.6 ms	10.8 ms	1.15×	1.07×

通信占主导地位： 通过分析发现，在使用 NCCL 时，shuffle 过程占总步耗的 ≈55 %，而使用 FUSCO 后降至 ≈30 %。
可扩展性： 随着专家数量和 GPU 数量的增加，收益会提升，因为融合消除了原本会呈 O(N²) 爆炸式增长的数据重排成本。
最小开销： 即使在最大规模的运行中，规划阶段也仅增加 < 0.5 ms，验证了 “轻量级” 的说法。

更快的 MoE 训练周期： 团队可以在更大的专家数量或更深的模型上进行迭代，而不会受到通信瓶颈的限制，从而缩短研究周期。
降低云成本： 缩短每步运行时间直接转化为更少的 GPU 小时，这对按需付费的云服务商尤为重要。
提升推理延迟： 实时服务（例如大规模语言模型 API）受益于降低的首 token 延迟，使基于 MoE 的模型在对延迟敏感的应用中变得可行。
即插即用的采用： 由于 FUSCO 模仿 NCCL API，现有流水线（DeepSpeed、FairScale、Megatron‑LM）只需更换一个库即可集成，降低了生产部署的门槛。
硬件无关的收益： 该方法适用于任何支持标准 RDMA/NCCL 的 GPU，可在本地集群和主要云平台上使用。

假设每步静态路由： FUSCO 的规划依赖于在整个训练步骤期间固定的 token‑to‑expert 映射。高度动态的 gating（例如在步内对每个 token 进行更改）将需要重新规划，导致额外开销。
关注 GPU‑to‑GPU 链路： 当前原型未涉及异构环境（例如 CPU‑offload 或 TPU 集群），这些环境可能需要不同的转换 kernel。
内存开销： 融合引擎为即时转置保留临时缓冲区；在内存受限的 GPU 上，这可能限制最大批量大小。
未来方向： 将融合概念扩展到 MoE 流水线中的其他集合操作（all‑reduce、broadcast），探索能够响应运行时流量模式的自适应规划，并与新兴互连（如 NVLink‑C2C、InfiniBand HDR）集成，以实现更高吞吐量。