执行摘要

• 一句话：默认启用 FlashInfer all-reduce 并跳过批不变模式
• 推荐动作：值得精读，重点关注默认开启带来的性能变化以及批不变模式的兼容性处理。建议运行更多平台和形状的测试以验证鲁棒性。

功能与动机

FlashInfer all-reduce 是已有的高性能后端，但默认关闭。将其默认启用可让更多用户自动受益于其性能优势。批不变模式要求固定的归约顺序，而 FlashInfer 不保证，因此需在该模式下禁用。

实现拆解

1. 在 vllm/envs.py 中将 VLLM_ALLREDUCE_USE_FLASHINFER 的默认值从 False 改为 True，使该选项默认开启。
2. 在 vllm/distributed/device_communicators/cuda_communicator.py 中，选择 FlashInfer all-reduce 时增加条件 not envs.VLLM_BATCH_INVARIANT，在批不变模式下自动禁用。
3. 未新增测试文件，但现有测试（如 test_envs.py 和 test_comm_ops.py）可验证行为和回归。

关键文件：

• vllm/envs.py（模块 环境配置；类别 source；类型 configuration；符号 VLLM_ALLREDUCE_USE_FLASHINFER）: 将 FlashInfer all-reduce 默认值从关闭改为开启，是本次变更的核心。
• vllm/distributed/device_communicators/cuda_communicator.py（模块 通信器；类别 source；类型 core-logic；符号 CudaCommunicator.init）: 增加批不变模式下的禁用逻辑，确保确定性。

关键符号：CudaCommunicator.init

评论区精华

审查中，mosafariuk 指出 FlashInfer 的 mnnvl all-reduce 在 H100 上不具备运行间确定性，即使没有融合也如此，可能影响批不变模式的正确性。作者 WoosukKwon 采纳建议，在批不变模式下禁用 FlashInfer all-reduce。

• FlashInfer all-reduce 的确定性问题 (correctness): 作者在批不变模式下禁用 FlashInfer all-reduce 以规避。

风险与影响

• 风险：风险在于 FlashInfer all-reduce 的确定性不足，可能影响依赖固定输出顺序的批不变模式；已在配置中规避。默认开启可能暴露现有平台或形状限制，但原有防护条件仍在，不支持的调用会回退到普通 all-reduce。
• 影响：影响所有使用 CUDA 且启用张量并行的用户，默认获得 FlashInfer 性能提升；批不变用户自动禁用该功能以保证确定性。对系统无破坏性，可通过环境变量关闭。
• 风险标记：默认启用新后端, 潜在确定性风险

关联脉络

• PR #51292 [Bugfix] batch-invariant fused all-reduce behavior: 讨论中提及，涉及批不变 all-reduce 行为，本 PR 的禁用逻辑与其相关。
• PR #50505 redesign of batch-invariant custom all-reduce: 包含相同的通信器排除逻辑，本 PR 只取其守护条件。