分块预填充
chunked prefill 把长输入的 prefill 阶段切成若干块，与 decode 步骤交错执行。这样单个长请求不会独占一步、把其他请求的解码全堵住，尾延迟改善明显；代价是调度更碎，块越小调度开销占比越高。由 enable_chunked_prefill 与 max-num-batched-tokens 等参数控制，各版本默认行为不同。
基本信息
| 解决什么 | 长输入独占导致的尾延迟抬升 |
|---|---|
| 主要参数 | enable_chunked_prefill、max-num-batched-tokens |
| 调小块的收益 | 改善 P99 与请求公平性 |
| 调小块的代价 | 调度开销占比上升 |
| 默认值 | 随版本变化，需查对应文档 |
典型使用场景
- 交互式服务：输入长度参差不齐，要保证短请求不被长请求挡住
- RAG 场景输入普遍很长，需要控制单步工作量
- 混合负载（长摘要与短问答）共用同一实例
- 为 P99 做优化时的首选拨杆之一
- 长文档问答与短对话混跑时，靠它维持请求之间的公平
启用与调块
启用与调块
vllm serve <模型路径> --enable-chunked-prefill --max-num-batched-tokens 8192
# 各版本默认行为不同，以所用版本文档为准
# 压测对照：同一并发下比较 TTFT、P99 与总吞吐相关参数分工
| 参数 | 作用 | 调小的效果 |
|---|---|---|
| enable_chunked_prefill | 开关分块预填充 | 关闭后长请求独占一步 |
| max-num-batched-tokens | 单步处理 token 上限 | P99 改善、调度开销上升 |
| max-num-seqs | 在批序列数上限 | 与分块共同决定并发形态 |
分块大小是延迟与吞吐之间的拨杆：块调小改善尾延迟，但调度开销占比上升，需要按自己的流量结构压测取舍。
参数是否生效要看指标而不是文档：对比开关前后的 TTFT 与 P99，确认改动真的落在服务上，再写进配置基线。
短输入为主的场景收益有限：prefill 本来就占不到多少时间，开启后反而多一层调度开销，先看输入长度分布再决定。
调法上建议按输入长度档位分别验证：短输入档位可能毫无变化，长输入档位才有明显收益，用一个平均值做结论容易误判。