ShortRequestFirst 预填充调度¶

ShortRequestFirst 通过让短提示词先于长提示词运行，减少预填充期间的队头阻塞。它面向混合提示词长度流量设计，在这种流量中，少量长请求可能会延迟许多短请求。

何时使用¶

在以下情况下启用 ShortRequestFirst：

• 请求长度高度偏斜
• 短请求 TTFT 比严格 FCFS 顺序更重要
• 服务使用 FCFS 调度器，并采用同步或异步调度

如果工作负载大体均匀，或者 FCFS 顺序比短请求延迟更重要，请保持禁用。

配置¶

在 scheduler_config 中添加 short_request_first_config。它在普通部署的 FCFS 同步和异步调度中受支持，在 PD 分离式预填充（P）节点上受支持，并在 PD 混合部署中受支持。它不需要 recompute_scheduler_enable：

{
  "scheduler_config": {
    "short_request_first_config": {
      "enabled": true,
      "threshold": 256,
      "long_max_wait_ms": 2000
    }
  }
}

字段¶

• enabled (bool, 默认 false) 打开或关闭 ShortRequestFirst。
• threshold (int, 默认 256) num_prompt_tokens <= threshold 的请求被视为短请求。
• long_max_wait_ms (float, 默认 0) 长请求在短请求之后等待的最长时间，超过该时间后它可以被提升到短请求之前。 0 禁用长请求提升，并保持严格的短请求优先级。

阈值调优¶

如果 threshold 太低，大多数请求会落入 long 车道，拆分基本不再有帮助。如果太高，大多数请求会落入 short 车道，拆分也不再有帮助。

在实践中，threshold 应位于短请求主簇和长请求尾部之间的边界附近。目标不是选择所有请求长度的固定中点，也不是将阈值移动到接近最长请求的位置。

如果你还没有精细的流量模型，可以先以提示词长度的 P70-P85 作为工程基线，然后使用真实请求长度直方图进行细化。对于清晰的双峰工作负载，阈值通常应位于短请求簇的上边缘附近，而不是接近最长提示词。

简而言之：合适的阈值通常是短请求群体和长请求群体之间的谷底。当无法进行详细分布建模时，P70-P85 是一个实用的起始范围。

long_max_wait_ms 调优¶

long_max_wait_ms 是一个公平性门控，而不是吞吐量优化旋钮。它控制长请求在正常的短请求优先行为下何时停止等待，并有资格获得防饥饿提升。

先调优 threshold。如果降级警告频繁出现，首先怀疑 threshold 对于当前流量组合太小，然后再考虑增大 long_max_wait_ms。

一个实用的调优流程是：

• 从 long_max_wait_ms = 0 开始，建立严格的短请求优先基线
• 在该基线下测量长请求的等待时间分布
• 将 W_normal 定义为长请求等待时间的正常上尾，通常为 P90 或 P95
• 将 W_slo 定义为你的服务对长请求可容忍的最大额外排队延迟
• 将 long_max_wait_ms 设置在 [W_normal, W_slo] 内的某个位置

在该区间内，如果短请求 TTFT 更重要，将值偏向 W_slo；如果长请求公平性更重要，将值偏向 W_normal。如果 W_normal 已经接近 W_slo，主要问题更可能是阈值选择或整体系统容量，而不是等待参数本身。

不要根据平均短请求 TTFT 来确定 long_max_wait_ms。它通常更适合锚定在严格短请求优先行为下长请求等待的尾部。

简而言之：long_max_wait_ms 应基于严格短请求调度下长请求等待尾部推导，并以你的服务可接受的长请求排队延迟为上限。如果 aged-long 提升反复发生，先增大 threshold，然后再增大 long_max_wait_ms。

调度行为¶

等待队列被拆分为三个车道：

• immediate 恢复式请求，例如被抢占的请求或已经计算了 token 的请求。
• short 提示词长度小于或等于 threshold 的请求。
• long 提示词长度大于 threshold 的请求。

调度优先级为：

immediate > aged-long > short > long

这意味着：

• immediate 请求总是胜出
• 短请求在普通长请求之前运行
• 如果最老的长请求等待超过 long_max_wait_ms，它可以跳到等待中的短请求之前

降级警告¶

如果长请求连续三次调度被提升到等待中的短请求之前，vLLM Ascend 会发出警告。这表明该功能正在偏向长请求优先级，通常是因为阈值对于当前流量组合太小。

当出现此警告时：

• 增大 short_request_first_config.threshold
• 或禁用 short_request_first_config.enabled

ShortRequestFirst 还会每 5 秒输出一次聚合统计日志，以便在不添加额外配置的情况下观察队列行为。

调度器兼容性¶

ShortRequestFirst 只更改等待队列策略。它要求 FCFS 调度，并支持同步和异步调度。它不支持批处理作业感知调度、profiling-chunk 调度，或 PD 分离式 D 节点（kv_role='kv_consumer'）。

additional_config.scheduler_config.enable_balance_scheduling 设置保持其现有行为：它控制平衡调度的跨 DP 准入逻辑。ShortRequestFirst 独立于是否启用平衡调度而安装，因此禁用平衡调度的路径会继续将调度委托给 vLLM，同时使用 ShortRequestFirst 等待队列。

最小示例¶

显式禁用它：

vllm serve <model> \
  --additional-config '{"scheduler_config": {"short_request_first_config": {"enabled": false}}}'