vLLM 批调度评估：吞吐提升不等于每个请求都更快
vLLM 通过 PagedAttention 和连续批处理提高大模型推理吞吐，是当前常见部署选择。但评估 vLLM 时，不能只看 tokens/s。批调度会改变请求排队、首 token 延迟和长短请求之间的资源竞争。吞吐提升，可能伴随部分请求延迟变差。
生产推理评估要同时看吞吐、TTFT、TPOT、显存和不同长度请求的公平性。
一、先拆开延迟指标
flowchart TD A[Request Arrives] --> B[Queue Wait] B --> C[Prefill] C --> D[First Token] D --> E[Decode Tokens] E --> F[Finish]端到端延迟可以拆成排队时间、prefill 时间、首 token 延迟和后续 token 生成时间。不同优化影响的阶段不同。
二、构造混合负载
只用固定长度 prompt 压测意义有限。真实业务里有短问答、长文档总结、多轮对话，输入输出长度差异很大。
workload: short_qa: prompt_tokens: 128 output_tokens: 128 ratio: 0.5 long_summary: prompt_tokens: 4096 output_tokens: 512 ratio: 0.3 coding: prompt_tokens: 2048 output_tokens: 1024 ratio: 0.2混合负载能暴露长请求是否挤压短请求。只看平均延迟，会掩盖尾部问题。
请求到达模式也要设定清楚。固定并发压测和泊松到达压测得到的结论不同。前者适合观察系统饱和点，后者更接近真实线上流量。评测报告应写明到达率、并发上限和超时阈值。
三、指标要按请求类型分组
metrics: throughput_tokens_per_second ttft_p50_p95_p99 tpot_p50_p95 e2e_latency_p95_by_workload gpu_memory_peak request_timeout_rate如果整体 tokens/s 提升 30%，但短问答 TTFT p95 从 500ms 变成 3s，某些产品场景可能无法接受。
四、调参要记录版本和上下文
vLLM 的 batch size、max model len、GPU 类型、并发、量化方式都会影响结果。
{ "engine": "vllm", "version": "0.x", "gpu": "A100-80G", "max_num_seqs": 128, "max_model_len": 8192, "dtype": "float16" }没有这些上下文，压测结果很难复现。推理性能报告必须像实验记录，而不是一句“速度提升明显”。
五、总结
vLLM 批调度评估不能只看吞吐。要拆分排队、prefill、首 token、decode 阶段，使用混合负载，并按请求类型统计 TTFT、TPOT、尾延迟和超时率。
吞吐提升是好事，但生产系统还要关心每类用户请求是否变快。公平、稳定、可复现的压测，才有决策价值。
如果某个调度参数提高了总吞吐，却让短请求长时间排队，它不一定适合交互式产品。推理服务的优化目标必须和业务体验一致。
因此压测报告应同时给出总体指标和分组指标，避免平均值掩盖尾部用户体验。
