vLLM 开 chunked prefill 后首字延迟反而变长

vLLM 0.6.3 开 enable-chunked-prefill 处理 32k 长文，TTFT 从 2.1 秒涨到 3.8 秒，吞吐是提高了一点，但首字明显变慢。

一开始怀疑是「短请求被排在长请求后面」，查了一圈，方向不对。

排查方向其实有限，先把可能性排一排。长 prompt 被拆成多个批次处理。还有一种是与 max_num_batched_tokens 的默认值冲突。

另外，调度策略偏向吞吐而不是延迟。

先对比开关前后的 TTFT 指标

curl -s http://localhost:8000/metrics | grep -E 'ttft|time_to_first'

调大 max_num_batched_tokens 减少切块次数

python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-14B-Instruct --enable-chunked-prefill --max-num-batched-tokens 8192

然后用固定长 prompt 压测 50 次取 P95

python bench_ttft.py --url http://localhost:8000 --prompt long.txt --n 50

末了按业务优先级关掉分块 prefill

python -c "print('--enable-chunked-prefill off when latency first')"

排查用的命令都是临时敲的，没有写成脚本，事后才整理。

手上没有现成的复现脚本，就照着线上请求手工拼了一个。

报错是间歇性的，我蹲守了半小时才抓到一次完整现场。

改完先别撤，确认这几项。首字延迟回到 2.2 秒附近，吞吐下降在可接受范围内，长文请求都能正常完成。

这里还有个坑。分块 prefill 是吞吐优化，延迟敏感的场景要单独评估，别看到参数能开就默认打开。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。