在批序列数上限
max-num-seqs 限制同一时刻处于批处理中的序列数。调大能抬高吞吐上限，但排队与尾延迟可能跟着变差；调小能降低峰值压力、改善尾延迟，代价是吞吐下降。它与 KV 池容量和窗口长度联动，是并发策略里最主要的一个拨杆。
基本信息
| 参数 | --max-num-seqs |
|---|---|
| 作用 | 限制同时处理的序列数 |
| 联动对象 | KV 池容量与最大窗口长度 |
| 调大后果 | 吞吐上限上升、尾延迟可能变差 |
| 调小后果 | 尾延迟改善、吞吐下降 |
典型使用场景
- 交互服务的并发保护，避免被打满后整体劣化
- 为 P99 做优化时最主要的可调档位
- KV 池不够时先降这个值，避免触发抢占重算
- 按业务分池时给交互池与离线池设不同档位
- 同一模型部署多个实例时，按各实例的规格分别设定档位
设置与压测联动
设置与压测联动
vllm serve <模型路径> --max-num-seqs 256 --gpu-memory-utilization 0.90 --max-num-batched-tokens 8192
# 压测关注：吞吐(tokens/s)、TTFT、排队时长与抢占次数
# 出现大量抢占重算时：先降 max-num-seqs 或扩容 KV 池现象与处理
| 现象 | 指向 | 处理 |
|---|---|---|
| 抢占重算频繁 | KV 池不够用 | 降 max-num-seqs 或扩池 |
| 尾延迟偏高 | 在批序列数太多 | 降并发或分池 |
| 吞吐上不去 | 在批数偏低 | 结合 KV 账适度上调 |
能不能真的容纳这么多序列，取决于窗口长度与 KV 池大小：先算 KV 账再定值，只改参数不看显存水位容易来回折腾。
启动日志通常会给出 KV 缓存可容纳的 token 数与并发估计：照日志校准比按经验值填参数快，也更容易复现。
调这个值要连带看 gpu-memory-utilization：预分配比例一变，KV 池大小跟着变，两件事最好一次只动一个。
多数引擎不支持运行期修改这个值：调整要走滚动重启，按实例逐个进行，避免一次性全部重启把容量打到谷底。