[Paper] 解决 LLM 服务中的数据并行负载均衡瓶颈:大规模实用在线路由
发布: (2026年5月7日 GMT+8 20:25)
8 分钟阅读
原文: arXiv
Source: arXiv - 2605.06113v1
概览
在大规模部署大型语言模型(LLM)时,数据并行(DP)负载不均衡日益成为限制因素。当模型通过张量并行或专家并行在 GPU/NPUs 上拆分后,再在众多 DP 工作节点上复制时,每一次解码步骤都必须等待最慢的工作节点,从而浪费宝贵的计算周期。论文提出了 BalanceRoute,这是一系列在线路由算法,能够动态地将进入的请求分配给 DP 工作节点,显著降低此瓶颈,同时满足实时生成的亚 100 ms 延迟预算。
关键贡献
- BalanceRoute‑0 (BR‑0) – 一种零预测路由方案,使用分段线性“F‑score”来判断接受请求是否会使工作者保持在安全负载范围内,或将其推入过载区间。
- BalanceRoute‑H (BR‑H) – 在 BR‑0 基础上加入短且固定的前瞻视野 (H) 和轻量级终止分类器,使得在无需庞大预测基础设施的情况下做出更为明智的决策。
- 两阶段分解 – 将路由问题拆分为快速的逐步过滤器和更细粒度的分配步骤,将每步开销保持在低毫秒级范围。
- 真实场景部署 – 已在 144‑NPU 集群上实现,并在专有生产追踪和公开的 Azure‑2024 追踪上进行评估,展示了相较于最先进 vLLM 基线的一致吞吐提升。
- 开源友好设计 – 这些算法仅依赖易获取的运行时指标(例如当前 KV‑cache 大小、每个工作者的 token 数),便于集成到现有服务堆栈中。
方法论
- 问题框定 – 作者将 DP 负载均衡建模为在线分配问题,其中每个进入的请求都有一个 粘性 分配(移动其 KV 缓存成本高),并且负载会随着解码进行而增长。
- F‑score 公式 – 对于每个工作节点,算法计算一个 F‑score,对会超过“安全边际”(延迟仍在解码预算内的负载水平)的分配进行强惩罚。该分数是分段线性的,便于快速评估。
- 两阶段路由
- 阶段 1:轻量过滤器剔除会立即超出安全边际的工作节点。
- 阶段 2:在剩余候选中,算法选择 F‑score 最高的工作节点(或对 BR‑H,选择折扣后视野最高的分数)。
- 视野扩展 (BR‑H) – 通过向前查看固定数量的未来解码步骤 ((H)),路由器可以预判负载增长,避免在几步后出现问题的分配。一个小型分类器预测请求是否会在视野内完成,并将其结果用于折扣分数。
- 实现细节 – 路由逻辑运行在服务系统的请求调度器内部,在每生成一个 token 后更新每个工作节点的负载计数。所有计算均基于整数,并能在子 100 ms 的解码窗口内完成,即使处理数百个待处理请求。
结果与发现
| Metric | vLLM baseline | BalanceRoute‑0 | BalanceRoute‑H |
|---|---|---|---|
| Average DP imbalance (std. dev. of per‑worker token count) | 1.84 × baseline | 0.71 × | 0.58 × |
| Throughput (tokens / s) | 1.00 × baseline | 1.27 × | 1.35 × |
| 99‑th‑percentile latency | 115 ms | 98 ms | 94 ms |
| Scheduler overhead (per step) | 1.9 ms | 0.9 ms | 1.1 ms |
- 在 专有生产追踪 中,BalanceRoute 将平均 DP 负载方差降低了 70 %,整体吞吐量提升了 27 %。
- 在 Azure‑2024 公共追踪 中,改进幅度更大(方差降低 58 %,吞吐量提升 35 %),验证了在不同请求模式下的鲁棒性。
- 路由开销在每轮调度中保持在 1 ms 以下,确保了解码预算的紧凑性。
实际影响
- 更高的昂贵硬件利用率 – 通过让所有 DP 工作器保持相似的负载水平,云服务提供商和企业可以从相同的 NPU/GPU 阵列中挤出更多的推理吞吐量,从而降低每个生成 token 的成本。
- 降低尾部延迟 – 终端用户会感受到更平滑的响应时间,尤其在突发流量下,因为系统不再因单个过载工作器而卡顿。
- 即插即用的集成 – 由于 BalanceRoute 只需要运行时负载计数器和一个小型分类器,它可以直接加入现有的服务框架(例如 vLLM、TensorRT‑LLM、DeepSpeed‑Inference),无需重新设计模型并行层。
- 可扩展到更大集群 – 该算法每一步的复杂度随工作器数量呈线性增长,适用于拥有数百台设备的集群,这在 LLM API 场景中很常见。
- 自适应 QoS 的基础 – 可以将 F‑score 扩展为包含优先级或 SLA 权重,从而实现差异化服务等级(例如,付费用户被路由到负载更低的工作器)。
限制与未来工作
- Sticky KV‑cache 假设 – 该方法假设移动 KV 缓存成本极高;未来的硬件或软件创新(例如快速缓存迁移)可能会改变这一权衡。
- 固定视野 (H) – BR‑H 使用固定的前瞻长度;基于请求长度或系统负载的自适应视野可能进一步提升决策。
- 仅限解码工作负载 – 本文聚焦于逐标记生成;将路由逻辑扩展到混合编码‑解码或批量推理仍是未解之题。
- 仅在单一硬件系列上评估 – 实验在 144‑NPU 集群上进行;在以 GPU 为主的集群或异构平台上验证这些算法将提升其通用性。
总体而言,BalanceRoute 提供了一种务实、低开销的方案,以应对 LLM 服务中最紧迫的可扩展性挑战,其理念也非常适合在下一代推理平台上进一步探索。
作者
- Tianci Bu
- Yuan Lyu
- Zixi Chen
- Chendong Song
- Hong Liang
- Tsepten Gurung
- Yuwei Fan
- Yinyu Ye
- Zijie Zhou
论文信息
- arXiv ID: 2605.06113v1
- 分类: cs.DC
- 出版时间: 2026年5月7日
- PDF: 下载 PDF