先定方向再调参
延迟与吞吐此消彼长：批越大吞吐越高、单请求延迟越差。所以调参之前先定服务定位——交互产品守 P95/P99 延迟，离线任务压单 token 成本。方向没定就调参，通常两边都不达标，还很难判断哪个参数的调整起了作用。
基本信息
| 交互型目标 | 守 P95/P99 延迟 |
|---|---|
| 离线型目标 | 压单 token 成本 |
| 小批策略 | 延迟好、吞吐低 |
| 大批策略 | 吞吐高、尾延迟差 |
| 常见解法 | 按目标分池部署 |
典型使用场景
- 给新服务定基线参数前先明确目标
- 排查「加了并发但用户说变慢」
- 给容量规划确定验收指标
- 向业务解释为什么不能同时优化两者
- 给交互池与离线池分别写验收口径并纳入发布检查
方向对照
| 目标 | 主要手段 | 代价 |
|---|---|---|
| 低延迟 | 小批、限制并发、优先调度 | 吞吐下降 |
| 高吞吐 | 大批、拉高并发 | 尾延迟上升 |
两种池的起步参数
两种池的起步参数
# 交互池：限制并发与批次，验收看 P95/P99
vllm serve <模型路径> --max-num-seqs 32 --max-num-batched-tokens 2048
# 离线池：拉高并发与批次，验收看单 token 成本
vllm serve <模型路径> --max-num-seqs 256 --max-num-batched-tokens 8192常见解法是分池：交互池守延迟，离线池吃吞吐，互不干扰，比在一个实例上做折中更有效。
验收口径分开写：交互池写 P95/P99 与并发档位，离线池写单 token 成本与日吞吐量，两边分开立项才不会互相打架。
同一份压测数据可以算出两种口径的结论：先把指标定义与采样点固定下来，再去比较不同配置，否则对比没有意义。
拆池之后要给两条链路各自的告警阈值与容量基线：沿用同一套阈值，等于把两个相反的目标又混在一起。
两类池的容量与告警要分开配置：共用一套阈值，等于把方向相反的目标重新绑回一起。