vLLM 突发流量调优：3600 次请求的排队与延迟对照
我固定同一段突发到达流量，只调整 vLLM 的活动序列上限，按 64 → 128 → 128 → 64 启动四轮独立服务。3600 次请求全部完成，通过流式输出与 token 数校验；两轮候选配置的排队延迟都低于两轮基线。
参数与资源
| 项目 | 本次配置或实测用量 |
|---|---|
| 模型与精度 | Qwen2.5-1.5B-Instruct，BF16；vLLM 0.8.5 |
| GPU 数量与运行方式 | 1 张 GPU，四轮串行，每轮重新启动服务 |
| 活动序列上限 | max-num-seqs=64 / 128；实际活动序列采样峰值最高 128 |
| 上下文与批 token | max-model-len=1024，max-num-batched-tokens=4096 |
| 其他参数 | gpu-memory-utilization=0.75；关闭前缀缓存；seed=20260923 |
| 单轮请求 | 900 个；128 / 512 token 输入各 450 个；每请求输出 64 token |
| 到达流量 | 20 秒到达窗口；突发段 90 req/s，其余 30 req/s；实际一秒峰值 110 个请求 |
| 本组已测最高完成吞吐 | 43.98 req/s；最高已测活动序列上限为 128，并非硬件极限 |
| 测量窗口用量 | 四轮含排空时间合计 81.88 秒；按 1 张 GPU 折算 0.02274 GPU·时 |
| 设备显存采样峰值 | 基线 35643–35775 MiB；候选 41123–41207 MiB |
GPU·时由卡数乘正式测量墙钟折算，排除了启动、加载和暖机，表示本表测量窗口占用，并非 GPU 内核忙时或整个项目累计消耗。客户端并发上限为 2048，用于避免客户端限流，不能等同于服务端实际并发。
四轮对照结果
合格请求要求同时满足 TTFT≤500 ms、请求内平均 TPOT≤35 ms；goodput 包含请求排空时间。
| 活动序列上限 / 轮次 | TTFT p95 / p99 ms | 合格 / 900 | Goodput req/s | 平均 TPOT 的 p95 ms | 显存峰值 MiB |
|---|---|---|---|---|---|
| 64 / 第一次 | 1221 / 1385 | 601 | 29.36 | 13.79 | 35775 |
| 128 / 第一次 | 368 / 481 | 896 | 43.76 | 23.53 | 41207 |
| 128 / 第二次 | 365 / 479 | 895 | 43.72 | 23.58 | 41123 |
| 64 / 第二次 | 1246 / 1409 | 594 | 29.02 | 13.81 | 35643 |
按两次独立运行汇总，TTFT p95 约 1234→366 ms，合格吞吐约 29.2→43.7 req/s。代价是平均 TPOT 的 p95 约增长 71%，显存峰值增加约 5.4–5.6 GiB。全部请求完成吞吐仍约为 43.96–43.98 req/s，改善的是联合延迟条件下的服务合格率。
每种配置只有两段短时固定负载；这些数据不构成长期 SLA，也没有寻找全局最大并发或最高速度。完整实现、逐请求记录及后续计划保留在对应私有全文中。
完整实验记录保存在 pegasas-notes-v2 私有仓库，仅向已获仓库访问权限的账号开放。