RuntimeError: […/gloo/transport/tcp/pair.cc:553] Connection closed by peer [::1]:46193. …

问题场景

用户在多卡环境下用 vLLM 启动张量并行服务，默认使用 FlashInfer 后端的 MoE 算子。当某次启动发现已有 FlashInfer autotune 缓存（autotune_configs.json）时，rank 0 打印缓存命中并直接往下走到同步屏障，其他 rank 却继续执行 autotune，最终引擎启动死锁并报 gloo 连接错误。复现方给出的现象是：缓存目录已存在时 9/9 次挂起，冷缓存（目录为空）时 3/3 次正常启动。

报错原文

RuntimeError: [.../gloo/transport/tcp/pair.cc:553] Connection closed by peer [::1]:46193. ...

伴随日志（节选）：

(Worker_TP1) [Autotuner]: Loaded 44 configs from .../flashinfer_autotune_cache/0.6.18.post1/120f/.../autotune_configs.json
(Worker_TP0) [Autotuner]: Loaded 44 configs from .../flashinfer_autotune_cache/0.6.18.post1/120f/.../autotune_configs.json
(Worker_TP0) [Autotuner]: Config cache hit for trtllm::fused_moe::gemm1 (runner=MoERunner, source=config file)
(Worker_TP1) [AutoTuner]: Tuning trtllm::fused_moe::gemm1:   0%|          | 0/22 [00:00<?, ?profile/s]
(Worker_TP0) ERROR 09-24 21:18:45 [multiproc_executor.py:1053]   File ".../vllm/model_executor/warmup/kernel_warmup.py", line 480, in flashinfer_autotune
(Worker_TP0) ERROR 09-24 21:18:45 [multiproc_executor.py:1053]     world.barrier()
(Worker_TP0) ERROR 09-24 21:18:45 [multiproc_executor.py:1053] RuntimeError: [.../gloo/transport/tcp/pair.cc:553] Connection closed by peer [::1]:46193. ...
(Worker_TP1) [AutoTuner]: Tuning trtllm::fused_moe::gemm1:   0%|          | 0/22 [30:01<?, ?profile/s]

另一组复现中，rank 1 侧表现为：

No available shared memory broadcast block found in 60 seconds

原因分析

根据 Issue 讨论，最可能的原因是各 rank 的 autotune 缓存键不一致：两个 rank 都能加载配置文件的日志说明文件本身是存在的，但只有 TP0 判定“cache hit”，其他 rank 判定未命中并进入调优。rank 0 因命中缓存提前到达 flashinfer_autotune 里的 world.barrier()，其他 rank 还停在调优阶段，同步屏障两端永远等不齐，最终广播/连接超时，表现为 gloo 的 Connection closed by peer 和 No available shared memory broadcast block。

讨论中还确认了以下上下文：该问题并非只出现在 EP、FP8 或 SM90 场景，在普通 bf16 MoE、SM120 默认 FlashInfer CUTLASS 路径下同样可复现。当前 v1 自动调优逻辑是“leader 主导持久化/加载”，与 FlashInfer ≥0.7 / autotune_v2 相关的 #55671 目前仍是草稿且被阻塞，对 0.6.18 没有实际修复作用。因此现阶段需要修正加载路径，让所有 rank 在集合调优前拿到一致的缓存命中结果（由 #57635 处理）。

环境排查

• 确认是否为多 rank 启动（TP>1），并检查每个 Worker 的启动日志；单卡通常不会触发此类同步死锁。
• 确认 vLLM 版本与 FlashInfer 版本是否匹配 Issue 中的组合（复现环境包括 vLLM 多卡 TP、flashinfer-python==0.6.18 / 0.6.18.post1，以及 vLLM v0.30.0）。
• 检查 …/vllm/flashinfer_autotune_cache/<flashinfer版本>/…/autotune_configs.json 在所有 rank 上是否都存在；复现方提到第一组挂起时两个 rank 的文件 SHA-256 相同，第二组是各 rank 复用了自己上一次冷启动写出的缓存。
• 确认日志中是否只有 Worker_TP0 出现 Config cache hit for trtllm::fused_moe::gemm1，而其他 rank 仍在输出 Tuning trtllm::fused_moe::gemm1 进度条。
• 确认模型是否为 MoE，且是否走 FlashInfer MoE / CUTLASS 后端；Issue 中涉及 bf16 MoE、NVFP4 MoE，以及 --moe-backend flashinfer_cutlass、--load-format dummy 等启动参数。
• 关注 PyTorch/CUDA/驱动版本（复现环境为 torch 2.13.0+cu130、CUDA 13.0、H100 驱动 580.173.02；另有 Blackwell SM 12.0 / SM121 环境），但版本本身不是本 Issue 的直接根因。

解决步骤

1. 先确认当前症状符合“部分 rank 缓存命中、部分 rank 仍在调优”的模式：对比各 rank 日志中是否只有 TP0 出现 cache hit，并查看 rank 0 堆栈是否停在 kernel_warmup.py 的 world.barrier()。
2. （可优先尝试，Issue 中复现方已验证）在每次启动 vLLM 前，登录所有参与节点/所有 rank，删除各自的 …/vllm/flashinfer_autotune_cache 目录，使所有 rank 冷启动、全部缓存未命中，从而一起进入 autotune 并一起完成同步。
3. 删除后启动服务，确认所有 rank 都输出 Loaded ... configs from ... 并共同进入调优流程；首次启动的调优耗时约 30–50 秒（Issue 观测值），之后服务应正常启动。
4. （修复方向，未合并前不要当作稳定方案）关注并验证 PR #57635：该 PR 修改加载路径，让各 rank 在 autotune 同步前获得一致的 fallback 行为；也关注 #55671 的进展，但其依赖 FlashInfer ≥0.7 / autotune_v2，对当前 0.6.18 不生效。
5. 如果你维护本地补丁，Issue 中有用户表示需要自行维护到 nightly 发布，可参考 #57635 的改动；在上游正式发布前，不建议仅依赖补丁而忽略缓存一致性检查。

验证方法

用复现日志判断：所有 Worker 的 autotune 缓存命中情况应一致，不应出现只有一个 rank 打印 Config cache hit、其他 rank 仍在 Tuning ... 的交叉局面；引擎启动后不再出现 world.barrier() 等待超时，也不再报 RuntimeError: [.../gloo/transport/tcp/pair.cc:553] Connection closed by peer 或 No available shared memory broadcast block found in 60 seconds。若采用“启动前删除缓存”的绕行方法，建议连续多次启停验证（Issue 中冷缓存启动验证为 3/3、4/4 正常），并记录每次启动的调优耗时。

参考来源

vllm-project/vllm #57423（含评论中引用的 #55671、#57579、#57635 讨论）

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。