大模型推理引擎vLLM(36)：消除vLLM025中gloo:all_reduce导致的DeepEP低延迟30ms大空泡

目录1 介绍2 空泡现象和原因分析2.1 空泡表现2.2 空泡可能原因12.3 空泡根本原因2.3.1 这个gloo:allreduce的由来为什么存在2.3.2 修改方法2.4 Gloo2.4.1 什么是Gloo2.4.2 vLLM 为什么用它3 修改后验证4 总结1 介绍测试某个模型性能时候发现低延迟有个大空泡记录下解决过程。2 空泡现象和原因分析2.1 空泡表现首先搭建环境复现空泡问题复现后现象如下2.2 空泡可能原因1按照以往的经验我以为这次可能是因为这有个H2D的memcpy, 然后算子下发晚了所以导致了空泡我还分析了下_get_num_sampled_and_rejected_kernel → _post_update_kernel → Memcpy DtoD → 【空泡】 → Memcpy HtoD很长 → … 同时另一条 stream 上还有 Memcpy DtoH然后这里就是把304 305行那里直接改掉因为这里都是pinned memoryGPU是可以直接访问的不需要拷贝改成self.temperature temperature self.seeds seeds然后我就想去测试下但是我花时间又看了下这个prof文件有了意外发现2.3 空泡根本原因我发现最根源的原因应该这个glooWorker 热路径线程卡在 CPU 侧 gloo allreduce 上等其它 DP这段时间走不下去后续 CUDA kernel 迟迟 enqueue不上GPU 就空等表现为空泡。空泡长短主要来自 各 rank 到达时间差straggler不是 gloo 传那几个 int 有多慢。2.3.1 这个gloo:allreduce的由来为什么存在这个gloo:allreduce就来自这个地方vllm的每个dp用这个通信干两件事DP1 时上游担心各 rank 本步不一致例如Rank真实 tokens本地倾向DP013pad→16FULL CGDP116正好 16FULL CGDP2少量/空更小 bucket 或 NONE后面还有 EP/DeepEP 等跨 rank 行为时CG mode 不同、有效 batch 规模不同存在对不齐甚至死等的风险。于是 vLLM 在sync_cudagraph_and_dp_paddingvllm/v1/worker/gpu/dp_utils.py里做协商每个 rank 往 CPU 小张量写入num_tokens、cg_mode、uniform_token_count在 DP 的cpu_group上all_reduce约定token 取全局 max再统一dispatchcg_mode 取 min有人 eager → 全员 eageruniform 不一致则清空。2.3.2 修改方法修改方法就是把这个同步删掉现在 各 DP 不再看别人只对本机真实num_tokens做本地dispatch。这里需要展开说明一下「本地选 bucket」的含义。所谓 bucket是指 vLLM 在 CUDAGraph 模式下预先捕捉好的若干固定 batch 尺寸档位例如 4、8、16 等。每个档位对应一组已经编译好的 CUDA Graph运行时只能从这些档位里选一个来执行不能随意使用任意 batch 大小。在原来的全局同步逻辑下每个 DP rank 都要先通过 gloo allreduce 拿到全局最大的 num_tokens上游希望各 DP 的 CG mode 和本步有效 batch 规模一致避免后续跨 rank 路径含 EP 相关逻辑因步调不一致出问题。但代价是每个 rank 都要等最慢的那个到达空泡就这样被放大了。删掉同步之后每个 DP 只根据本机真实的 num_tokens 就近选一个 bucket。比如本机真实 tokens 是 3就选 4 这个档位真实 tokens 是 13就选 16 这个档位。这样每个 rank 的 batch 规模可能不一样DeepEP-LL 路径不依赖这层跨 DP 的 CG padding 协商因此可以安全跳过普通 DP / 其它 all2all 后端则不宜贸然删除。空泡也就随之消失。需要特别注意的是这个改动只适用于 DeepEP-LL 场景。如果是在普通 DP 场景下贸然删掉同步各 rank 的 CG mode 和 batch 规模不一致很可能导致跨 rank 通信对不齐甚至死等反而引入更严重的问题。2.4 Gloo2.4.1 什么是Gloo集合通信库allreduce / broadcast / barrier 等不是和 TCP 同级的“网络协议名”主要服务CPU / 主机侧小消息传输常见走主机网卡以太网 TCP 等部分环境也可走 IB与NCCL/RCCL在 PyTorch 里是平级 backendGPU 大 tensor → NCCL/RCCLCPU 元数据 / 控制面 → Gloo。2.4.2 vLLM 为什么用它并行组通常拆两套device_groupGPU 数据面cpu_groupCPU 控制面backend 为 gloo。sync_cudagraph_and_dp_padding里group get_dp_group().cpu_group tensor torch.zeros(3, dp_size, dtypetorch.int32, devicecpu) dist.all_reduce(tensor, groupgroup)所以 Profiler 里事件名是gloo:all_reduce。重要纠正空泡的根因不是“Gloo 传得慢”就几十字节。 根因是每步强制全 DP 同步把各 rank 到达时间的抖动放大成全体 GPU idle。3 修改后验证4 总结现象DPEP decode 出现 GPU 空泡与gloo:all_reduce对齐多 rank 右边界齐 → straggler 等待。CUDAGraph固定 shape本地要把 batch pad 到已捕捉 size我们最大捕捉 16。上游 sync担心各 DP 的 CG mode / pad 规模不一致每步用 DPcpu_groupglooallreduce 几个 int统一成 global max tokens min mode。空泡成因同步点数据量极小但每步 barrier 把到达抖动放大成全员 GPU idle。GlooCPU 侧集合通信库管控制面NCCL/RCCL/DeepEP 管数据面。修复DeepEP-LL 下跳过 CG padding 的跨 DP sync只保留本地 dispatch用 HCU 插件 monkey-patch不改基线。验证gloo 热事件消失、轨变密精度用 standard MTP 回归。