执行摘要

• 一句话：提前发布 DP 请求计数减少负载不均衡
• 推荐动作：值得精读的低成本高收益优化。展示了如何通过调整发布时机来显著改善分布式负载均衡，是系统调优的范例。建议团队在后续 DP 相关 PR 中参考此模式。

功能与动机

当多个数据并行（DP）引擎共享一个负载均衡器时，_maybe_publish_request_counts() 仅在 GPU 步骤后调用，导致新到达的请求（ADDs）需要等待几乎整个步骤（150-300 ms）才能被 LB 感知。加上协调器约 100 ms 的广播间隔，LB 持续将新请求发送给已积压工作的引擎，造成严重不均衡（如 DP=8 中单引擎收到 160-170 个请求，而理想应是 128）。

实现拆解

在 vllm/v1/engine/core.py 的 run_busy_loop 方法中，于 _process_input_queue() 之后、_process_engine_step() 之前添加一行调用 self._maybe_publish_request_counts()，使新入队的请求计数立即发布给协调器。原有的后置调用（第 1832 行）保留作为性能优化：当计数未变化时，该方法通过 last_counts 检查快速返回，几乎零开销。

关键文件：

• vllm/v1/engine/core.py（模块 引擎核心；类别 source；类型 core-logic；符号 run_busy_loop, _maybe_publish_request_counts）: 核心引擎循环，添加了提前发布请求计数的调用，是整个优化的唯一变更点。

关键符号：run_busy_loop, _maybe_publish_request_counts

评论区精华

Review 中仅有 reviewer njhill 提出一条注释修改建议：将冗长的注释精简为“Publish request counts before and after GPU step to ensure freshness.”，作者接受并合并。整体审核通过，未引发技术争议。

• 代码注释精简 (style): 注释被精简为 'Publish request counts before and after GPU step to ensure freshness.'

风险与影响

• 风险：风险极低：变更仅增加一行函数调用，且在无负载变化时该调用为快速返回（counts != self.last_counts 判断），对性能影响可忽略。未引入新的依赖或修改现有逻辑。但该优化依赖于 _maybe_publish_request_counts 本身的去重机制，若未来修改该方法可能导致预期失效，建议在单元测试中覆盖此场景。
• 影响：直接影响 vLLM v1 的 DP 负载均衡准确性，显著减少端到端推理时长和引擎间请求分布不均。对非 DP 场景无影响，因 publish_dp_lb_stats 标志默认关闭。变更仅涉及引擎核心循环，不涉及 API 或用户侧接口。
• 风险标记：暂无

关联脉络

• PR #39568 Replace shared-memory routed experts with ModelRunnerOutput transfer and HTTP support: 同为 v1 引擎核心循环中的性能优化重构，涉及调度和输出路径。
• PR #42434 Revert "[Core] Replace routing replay with device cache and async D2H pipeline" (#39917): 回退 MoE 路由捕获机制，影响引擎循环中的调度与输出逻辑。