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、尾延迟和超时率。吞吐提升是好事但生产系统还要关心每类用户请求是否变快。公平、稳定、可复现的压测才有决策价值。如果某个调度参数提高了总吞吐却让短请求长时间排队它不一定适合交互式产品。推理服务的优化目标必须和业务体验一致。因此压测报告应同时给出总体指标和分组指标避免平均值掩盖尾部用户体验。