DyntraLB：解码器内部数据并行负载均衡¶

DyntraLB 是一个面向 prefill/decode（P/D）分离部署中数据并行 Decode 节点的负载感知调度器。当请求长度不均衡时，它可以减少负载较轻的 DP rank 等待最繁忙 rank 的时间。

DyntraLB 不会在 DP rank 之间移动请求。相反，每个 DP rank 共享其正在运行和可准入等待请求的快照。规划器根据每个请求的 KV-cache 块数量估算其负载，并告诉每个 rank 应准入、继续运行或暂停哪些本地请求。被 DyntraLB 暂停的请求会保留其已分配的 KV cache，并可以由同一 rank 稍后恢复。

何时使用¶

当以下所有条件都成立时，可以考虑启用 DyntraLB：

• 部署使用 P/D 分离
• Decode 实例在单个节点上使用内部数据并行
• 请求长度偏斜程度足以产生可见的 DP 气泡
• Decode 吞吐量比严格保持本地请求执行顺序更重要

对于大小均匀的工作负载、单个 DP rank 的 Decode 实例或多节点 Decode DP 实例，请保持禁用。

要求¶

DyntraLB 具有以下启动要求：

• 它只能在 P/D 分离的 Decode 节点上启用，且该节点具有 kv_role="kv_consumer"
• data_parallel_size 必须大于 1
• Decode 实例的所有 DP rank 必须位于一个节点上

仅在 Decode 节点上配置 DyntraLB。不要向 Prefill 节点添加带有 enabled=true 的 dyntra_lb_config。

DyntraLB 不能与以下配置组合使用：

• scheduler_config.enable_balance_scheduling
• scheduler_config.profiling_chunk_config.enabled

服务会在启动期间拒绝这些不支持的组合。

配置¶

在 Decode 节点的 --additional-config 中，将 dyntra_lb_config 添加到 scheduler_config 下。

DyntraLB 和重计算调度仍然是相互独立的同级配置。 当 dyntra_lb_config.enabled 和 recompute_scheduler_enable 都为 true 时， Decode 节点会使用组合的 DyntraLB 重计算调度器。

向现有且可工作的单节点 Decode 命令添加以下参数。 此片段默认启用动态模式，推荐用于生产场景：

  --additional-config '{
    "scheduler_config": {
      "dyntra_lb_config": {
        "enabled": true
      }
    }
  }'

保留 Decode 节点现有的 --kv-transfer-config，并验证其将 kv_role 设置为 kv_consumer。

参数¶

long_req_block_threshold 和绝对 bubble_threshold 以 KV-cache 块表示，而不是 token。因此，它们的 token 等价值取决于 配置的块大小。

静态模式和动态模式¶

静态模式¶

静态模式在配置的区间内的每个协调 engine step 上评估 DP 负载：

{
  "scheduler_config": {
    "dyntra_lb_config": {
      "enabled": true,
      "mode": "static"
    }
  }
}

静态模式仅用于排查问题和短验证运行。 它在整个配置区间内保持负载均衡激活，这使得 DyntraLB 行为更容易观察。不要在生产中使用静态模式。 在短诊断运行期间，将 start_step 设置为 0，以便运行实际 触发 DyntraLB。

动态模式¶

动态模式保持非激活状态，直到新添加的请求超过 long_req_block_threshold。然后，它评估负载，直到 dynamic_max_step 个连续活跃步骤过去而没有另一个新添加的 长请求：

{
  "scheduler_config": {
    "dyntra_lb_config": {
      "enabled": true,
      "mode": "dynamic"
    }
  }
}

动态模式推荐用于生产，因为它仅当长请求表明 DP 不均衡可能发生时才激活负载 均衡。start_step 和 end_step 区间在动态模式下仍然适用。

调度工作原理¶

DyntraLB 将每个负载均衡决策跨两个 engine step 流水线化：

1. 当前步骤运行调度和模型执行
2. 所有 DP rank 同步它们的 wave/idle 状态
3. 每个活跃 rank 准备其本地等待请求，这些请求的远程 KV cache 已就绪
4. 各 rank 在 Decode DP 组内 all-gather 正在运行和可准入等待请求的 KV 块数量
5. 规划器生成每个 rank 的计划，该计划可以暂停本地正在运行的请求、 准入选定的本地等待请求，或冻结新准入
6. 下一个 engine step 在正常调度和模型 执行之前应用该计划

新 wave 的第一个 engine step 没有来自先前活跃步骤的计划，因此 遵循正常调度器路径。在动态模式下，在该步骤之后检测到新的 长请求会立即为后续步骤生成计划。start_step 和 end_step 选择可以生成计划的已完成步骤快照；每个生成的计划由下一步消费。

规划器使用请求块数作为轻量级负载估计。该估计旨在减少 DP 气泡；它并非针对所有模型和流量分布的延迟或吞吐量保证。

调优与验证¶

首先使用相同的模型、提示词、采样参数、并发数和 P/D 拓扑进行受控的 A/B 对比。

1. 对于短期故障排查或功能运行，设置 start_step=0、mode="static" 和 enable_diagnostics=true。
2. 确认每个 Decode rank 都进入相同的工作负载收集步骤，并且请求在没有持续 KV 等待状态的情况下完成。
3. 在禁用 DyntraLB 的情况下比较吞吐量和延迟。
4. 关闭诊断以进行性能测量。
5. 切换到 mode="dynamic" 进行工作负载测试。根据观察到的请求块数分布调整 bubble_threshold、long_req_block_threshold 和 dynamic_max_step。

非常小的 bubble_threshold 可能导致请求频繁暂停和准入变化。非常大的值会使 DyntraLB 很少修改正常调度器计划。

诊断¶

仅在验证或故障排查期间设置 enable_diagnostics=true：

{
  "scheduler_config": {
    "dyntra_lb_config": {
      "enabled": true,
      "enable_diagnostics": true
    }
  }
}

Rank 0 会打印 [dyntra_lb] 工作负载快照以及生成的 Out、In 和 Freeze 修改。还会输出调度器摘要和引擎步骤诊断。这些日志可能非常冗长，在 吞吐量基准测试中通常应保持禁用。

限制¶

• 仅支持单节点、内部数据并行的 Decode 实例。
• DyntraLB 不会将请求路由或迁移到另一个 DP rank。
• 规划器根据 KV 缓存块估计工作量，并使用固定的吞吐量启发式方法。特定模型 的成本、投机草稿工作以及算子级差异可能需要针对特定工作负载进行调优。
• 与投机解码或异步调度的组合应使用生产环境中使用的确切模型、vLLM 版本和 vLLM Ascend 版本进行验证。

有关完整的 additional_config 架构，请参阅 附加配置。