vLLM 和 SGLang 的调度器区别是什么

为什么值得回答

“都支持 continuous batching / prefix caching”只是功能邻接，不能推出相同的延迟、吞吐或公平性。真正影响结果的是调度单位、容量模型、preemption、prefill/decode 混合和 prefix 命中后的执行路径。这个问题直接约束 Inference Engine Selection，但答案会随版本变化，不能写成无日期的永久排名。

当前理解

两者都需要在有限计算与 KV Cache 下选择每轮执行的 token；Continuous Batching 是共同上层机制，PagedAttention 或对应 KV 管理是下层约束。尚未验证的是：面对同一突发流量、长短请求混合和重复前缀时，各自如何在 TTFT、TPOT、throughput 与公平性之间取舍。

比较框架

  • 调度单位与抢占策略
  • Prefill / Decode 混合策略
  • KV Cache 分配与复用
  • Prefix caching
  • 多租户、公平性与优先级
  • 在相同硬件、模型和流量下的延迟与吞吐

最小验证实验

  1. 固定同一模型、权重精度、单机硬件、最大上下文和采样参数。
  2. 回放四类轨迹：短入长出、长入短出、突发混合、重复前缀。
  3. 分别改变并发与 KV 压力，记录 queue time、TTFT/TPOT P50/P95/P99、吞吐、显存和抢占/重算。
  4. 保存引擎版本、完整配置和原始请求轨迹；默认配置与调优配置分开报告。
  5. 解释差异来自调度策略、KV 管理、kernel 还是配置，而不是只给赢家。

结论边界

在实验完成前，只能确认比较维度，不能声称某个 scheduler 普遍更优。即使某版本在一个轨迹胜出，也只能作为该硬件、模型和请求分布下的实现证据。

结果应该怎样解释

如果某引擎在重复前缀轨迹上 TTFT 明显更低，先确认 prefix hit token 数和命中请求是否真的走到同一副本；否则可能只是路由或 prompt 长度差异。若总吞吐更高但短请求 P99 更差，重点看长 prefill 的 token budget、decode 优先级和抢占，而不是简单宣布“batch 更好”。若两者 GPU 利用率相近但 TPOT 不同，要继续看 KV 读带宽、attention backend、实际 batch shape 和 stream/synchronization。

可以把实验结果写成下面这种因果记录：

1
2
3
4
5
观察：SGLang 在共享前缀场景 TTFT -30%
证据：prefix hit token、prefill kernel 时间、queue time
替代解释：请求路由/模板不同、cache warmup 不同
边界：只适用于该版本、模型、硬件和前缀重复率
下一步：跨副本、冷/热 cache、不同输出长度复测

调度器比较还要包含取消、超时和 KV 快满时的行为：一个实现如果能及时释放取消请求的 block，长尾流量下可能比静态吞吐更重要；如果发生抢占后需要重算，吞吐改善可能是以额外 prefill 为代价。记录这些状态，才是在比较调度器而不是比较 demo 参数。