你手上有个要上线的模型服务，同事说 vLLM 快，另一个说换成别家框架差不多，但谁也拿不出同口径的数字。问题通常不在框架，而在比的不是同一个东西：输入长度不同、并发不同、量化不同、输出长度设定不同，比出来的数没有意义。这篇把 vLLM 性能对比该量什么、按什么顺序量、哪些情况下结论不成立讲清楚，照着走一遍就能拿到自己环境下的基线。
你手上有个模型服务要上线，同事说 vLLM 快，另一个说换别的框架差不多，但谁也拿不出同口径的数字。问题往往不在框架本身，而在比的不是同一个东西：输入长度不同、并发不同、量化档位不同、输出长度设定不同，比出来的数就没有可比性。这篇文章讲清楚 vLLM 性能对比该量什么、按什么顺序量、哪些情况下结论不成立，照着走一遍，就能拿到自己环境下的基线。
先说清定位：这篇是给部署工程师看的操作思路，不给你现成的排名数字。各家公开的性能数字都绑定了特定卡型、特定数据集和特定参数，只能当方向参考。你自己那台机器上的真实表现，必须自己压出来；具体卡型对应的参考数据，到 站内速度测试工具页（/tools/speed-test） 核对当时的数字。
先定指标：vLLM 对比性能到底比哪几项
对比性能最忌讳只报一个数。至少要同时记四类指标：吞吐（每秒总 token 数）看的是单位成本，单请求输出速度、首 token 延迟、并发上限看的是用户体验。只报吞吐，服务可能一上并发就卡死；只报延迟，成本可能翻倍。四类一起记，结论才立得住。
| 指标 | 衡量什么 | 必须一起记录的口径 |
|---|---|---|
| 吞吐（总 token/秒） | 相同成本下的服务容量 | 输入长度、输出长度、并发数、卡数 |
| 单请求输出速度 | 单个用户感知的生成快慢 | 量化精度、是否开前缀缓存 |
| 首 token 延迟 | 用户点击到看到第一个字的等待 | 输入长度、批大小 |
| 并发上限与显存峰值 | 一张卡能撑多少路请求 | 最大序列长度、KV 缓存配置 |
口径比指标本身更重要。同一组指标，换了输入长度、并发数、量化档位、张量并行卡数或者前缀缓存开关，就是另一个数，不能放在一起比。显存峰值要单独记，它决定同一张卡能塞多少并发，也决定压测会不会中途 OOM。业务侧的间接指标，比如超时率、排队等待、单请求成本，放在压测之后单独补测，别混进框架对比里，否则分不清是框架的问题还是业务配置的问题。
压测怎么做才可比：固定变量与取样方法
- 固定基础变量把模型、权重版本、量化档位、卡型、驱动和推理参数固定下来，只留一个要对比的变量，一次只动一处。动了两处，结果就说不清是谁造成的。
- 按真实分布取输入长度翻业务日志，取输入长度的真实分布，至少各跑一档短输入和一档长输入。只测单一长度，线上长尾一上来表现就会不一样。
- 阶梯加压找拐点并发从 1 开始逐级往上加，记录吞吐曲线和延迟曲线，找出吞吐不再涨、延迟开始明显抬升的那个点。别只报一个最大并发数，那个数通常已经不可用了。
- 预热后多轮取样每档先跑若干请求预热，再开始计数，至少跑多轮取稳定值。单轮数字波动很大，不要拿它下结论。
和谁比、比哪些维度：框架之间的对比维度清单
- 同卡同模型比框架：vLLM 和其他推理框架在同一机型、同一权重上的差异才有参考价值，换卡换模型之后的数只代表那一组配置
- 比特性支持而不只比速度：多卡并行、前缀缓存、连续批处理、多模态输入、结构化输出，你业务要用的特性不支持，速度再高也得换方案
- 比运维成本：启动耗时、显存碎片、崩溃恢复、参数项多少，这些不进吞吐数字里，但天天影响值班的人
- 比扩展性：从单卡到多卡、单机到多机，性能是不是随资源近似放大，只看单机数看不出上限
还要提醒一句：这几项里，很多结论只在特定场景下成立。比如你的请求都是短问答，那长文档下的吞吐对比就跟你没关系；你的业务并发一直很低，那高并发拐点就只是参考。先想清楚自己的流量形态，再决定哪几项值得花时间测。
结论什么时候不成立：四类常见误读
| 常见做法 | 为什么结论不成立 | 正确做法 |
|---|---|---|
| 直接引用公开性能数字 | 卡型、数据集、驱动版本都和你不同 | 只当方向参考，自己复测基线 |
| 压测客户端和服务同机 | 客户端抢资源，量到的是客户端上限 | 客户端独立部署，先做客户端压测 |
| 用短输入高并发的数推广到全场景 | 长输入场景下表现完全不同 | 按任务形态分开测，分别记录 |
| 升级前后混用旧数据 | 版本变化会造成明显落差 | 升级或换卡后重新测基线 |
还有一种情况容易被忽略：多卡场景里，只调小并行度或者只加卡数，都可能让数字变差或者不变。这时候别急着认定框架不行，先确认模型切分方式和通信开销是否匹配你的硬件拓扑。具体到某张卡、某个模型版本的参考表现，到 站内模型资料页（/models） 对照当时的记录。
落地排查顺序：从上不了线到调得动
- 先跑通单请求确认首 token 延迟和输出速度在可接受区间。这一步不过，就别急着压并发，否则只会把配置问题放大。
- 按业务峰值并发压测先找吞吐拐点，再确认延迟是否还在你承诺的范围内。两者都满足，才能算这一档达标。
- 显存吃紧就逐项回调回头看量化档位、最大序列长度、并发缓存配置，一次放开一项，验证到哪个配置开始 OOM 或者延迟失控。
- 多卡补测扩展性测线性度和通信开销，必要时对比不同的并行切分方式，确认加卡是不是真的加性能。
- 存一张基线表把上面所有指标、口径和配置记录下来存档，升级框架或换卡后照着同一张表复测。没有基线，下次对比又得从头吵。
性能数字本身没有意义，有意义的是同一口径、同一硬件、同一流量形态下，你自己跑出来的那组对照。下一步想先看看自己这张卡上跑出来的基础速度，再去对比框架差异，可以到站内速度测试工具直接跑一轮，把结果存下来当基线。→
常见问题
vLLM 对比性能主要看吞吐还是延迟？
看你的业务形态。批量离线任务看每秒总 token，因为它直接决定单位成本；在线对话看首 token 延迟和单请求输出速度，用户感知的是这两项。两个都要测，只报一个数容易误导自己。
同一个模型，vLLM 和别人测出来的数字差很多，正常吗？
正常，先核对口径：输入输出长度、并发数、量化档位、卡型、张量并行数是否一致。如果这些都对齐还差很多，再看驱动、CUDA 版本、是否开了前缀缓存。对齐口径前不要下谁更快的结论。
只跑一次压测就下结论可以吗？
不建议。推理服务受显存分配、缓存预热、机器负载影响，单轮波动可能很大。至少预热后跑多轮取稳定区间，并记录下当时的配置，否则过几天复现不出来，也没法判断是版本变了还是环境变了。
