第18章：Scheduler 与连续批处理机制

1. 项目背景

某视频平台的AI字幕生成服务使用vLLM批量处理用户上传视频的语音转文字文本。业务有两个鲜明的特点：第一，短视频（1分钟，约200字文本）和长视频（60分钟，约10000字文本）混合提交；第二，晚间高峰时段（19-23点）QPS是白天的10倍。

技术团队上线后发现一个严重问题：晚上高峰期，短视频的字幕生成被长视频严重拖累——一个60分钟视频的文本处理需要5分钟，在这5分钟内，所有提交到同一批中的短视频请求也被迫等待。用户的15秒短视频等了10分钟才拿到字幕，投诉如潮。

更诡异的是，Grafana显示GPU利用率只有40%，但P99延迟却高达8分钟——GPU明明不忙，为什么请求在等待？

痛点：这是典型的调度公平性问题。vLLM的Scheduler决定了"本轮该跑哪些请求"。在默认参数下，Scheduler倾向于填充尽可能多的工作（最大化吞吐），但这可能导致短请求被长请求"霸凌"——这就是静态Batch和Continuous Batching、Prefill和Decode两阶段调度需要精细设计的根本原因。

本章将深入Scheduler的调度逻辑，理解请求的状态机、KV Cache分配决策、Preemption（抢占）机制，并通过构造混合长短请求的流量实验，直观展示调度参数如何影响TTFT、TPOT和P99。

2. 项目设计

（场景：深夜复盘会。Grafana大屏上并排显示两条曲线——一条是GPU利用率（平缓的40%），一条是P99延迟（陡峭的8分钟尖峰）。）