vllm模型对比性能有哪些，常见问题和做法（横向对比时真正该量哪几组指标）

准备把 vLLM 上生产时，常卡在同一类问题上：两个方案都号称快，一个吞吐高一个延迟低，到底拿哪个当基准；压测出来的数字比预期差一截，是配置问题还是并发模型没对上。这篇把对比性能要看的指标、测法、读法和排查顺序列成清单，并说明什么场景下这些指标不适用。

准备把 vLLM 上生产时，常卡在同一类问题上：两个方案都号称快，一个吞吐高一个延迟低，到底拿哪个当基准；压测出来的数字比预期差一截，是配置问题还是并发模型没对上。这篇把对比性能要看的指标、测法、读法和排查顺序列成清单，只讲部署工程师真正会用到的那一层。

先说一个前提：不存在一个能概括所有场景的「快」。吞吐高和延迟低经常互相拉扯，同一套配置在短输入和长输入下表现也不一样。所以对比性能的重点不是找最高分，而是固定变量、分层记录，让每次对比只回答一个问题。下文每节都配了可执行动作，判断类内容也写清了什么场景下不适用。

横向对比时真正该量哪几组指标

很多对比失败在只有一句「哪个快」。把指标拆成吞吐、延迟、并发、资源效率四组分别量，才知道换来的是什么。吞吐看单位时间出多少 token，延迟必须拆成首 token 时间和单 token 间隔，两者对用户的感受完全不同。对比时先对齐输入输出长度分布和并发档位，否则两组数字根本没有可比性。

采样参数同样会改变可观测结果：温度、是否流式、是否开缓存都影响数值。对比时不要求两边逻辑一模一样，但至少要确认差异点，并在报告里写出来，不然复测时会被自己误导。模型本身的版本信息不必在这里比，性能只看当前配置下的表现。

怎么把性能测出来：步骤和自建基线

测性能最重要的是先有自己的基线，而不是先看别人的数据。单请求空载基线是后面所有判断的参照：一个请求到底时首 token 多久、单 token 间隔多大、显存占多少。这条线没量出来，后面压测出来的任何数字都说不清是框架慢还是压力上来了。

1. 跑单请求空载基线发一个固定长度的请求，记录首 token 时间、单 token 间隔和显存占用，存成日志作为参照线。
2. 阶梯加压到真实档位按业务实际并发从低到高逐档加，每档记录吞吐、首 token 延迟和 p95 单 token 间隔，观察哪一档开始明显变差。
3. 固定数据集复测用固定长度分布的数据集，改配置时每次只动一个变量，重跑同一套脚本，把日志留档方便前后对照。
4. 单独量链路延迟接入前先用站内测速工具把网络与链路时间量出来，再和框架自身计算时间分开看，避免把链路慢算成推理慢。

数据集的长度分布要接近真实业务，别全用等长短句压。长输入和短输出混在一起，测出来的平均数会掩盖首 token 的真实表现。测完把每档的日志保存下来，下次改配置只跑同一档复测即可，不必每次全量重来。

结果怎么读：哪些提升是真的、哪些是口径差异

拿到两组数字后先问一句：这是取舍还是优化。吞吐翻倍但延迟也翻倍，多半是把批处理开大了，属于用延迟换吞吐，对交互型业务反而不划算。首 token 慢而后续出得快，先从排队和调度找原因，不要一上来就换量化档位，那会同时改变精度与内存行为，让对比变量失控。

• 吞吐涨、延迟也涨：先确认是不是批处理上限调高了，属于取舍不是免费午餐。
• 只慢在首 token：优先查队列与调度，而非直接换模型文件或量化参数。
• 跨显卡、跨量化档位横比：只能当方向参考，不能直接拿来做容量规划。
• 看到官方压力数据：先确认它的输入输出长度与并发口径，再决定能不能映射到自己的业务。

口径差异是另一个常见坑：一个用流式测，一个用非流式测；一个 p99，一个平均值。读结果时先确认单位、统计方式和场景，再去站内相关页面核对当时的数字与统计口径。公开榜单和资料页的数值是特定条件下的产物，你的业务长度分布和并发模型不同时，不适用直接照搬。

实测不达预期的排查顺序

实测不达预期时最容易乱动配置，结果变量越改越多。建议按固定顺序查，每一步只回答一个问题：先看显存是否吃满或触发换出，再看并发是否已经超过实际承载，然后看请求长度分布，最后才考虑换量化档位或调整批处理上限。每次只动一项并复测同一档，才能对上号。

也有不必过度调优的情况：一家 5 人小团队、并发只有个位数时，链路延迟和框架差异往往被淹没，此时把指标记录清楚即可，花大量时间抠批处理参数收益有限。反过来说，面向高并发在线服务、对首 token 敏感的交互场景，这套排查顺序就必须走完，不能跳步。

还有一个容易被忽略的步骤：把结论和时间点绑在一起记。配置、驱动、显存大小变了，之前对的数字就可能不再成立。所以对比报告里写清测试条件和你自己记录的结果，而不是只写一句「比上一版快」，下次回看才知道能不能复用。