vllm模型对比性能有哪些，先量对这四组指标再谈谁快

两台机器跑同一个模型，A 说自己快，B 说自己省，吵半天发现量的是两件事。做 vLLM 对比最容易犯的错不是测不准，是压根没对齐口径。这篇把指标怎么分组、每个指标在什么场景下才有意义、遇到「压测结果和线上体验对不上」先查哪几项讲清楚，数字一律去站内对应页面拉当期的。

两台机器跑同一个模型，A 说自己快，B 说自己省，吵半天发现量的是两件事。做 vLLM 对比最容易犯的错不是测不准，是压根没对齐口径——一个在测离线批处理的总吞吐，一个在聊在线对话的首字等待。这两种「快」根本不是一码事。

所以别急着上压测脚本。先把「快」拆成能分别测的几组指标，说清楚每组在什么场景下才有意义，再谈谁赢。数字本身会漂，模型、量化档、上下文长度、卡型任一变了就不在同一张桌子上比。真要拿当期数值，去站内资料库按相同条件拉，别拿一篇旧文章里的结论套今天的部署。

别把所有数字揉成一个「快」字

我先给个分法：吞吐、延迟、显存占用、长时间稳定性。四组指标经常互相打架——你把批处理开大，吞吐上去，首 token 延迟跟着变差；你把并发压满，显存水位逼近上限，跑一会儿就开始抖。所以对比时不能只报一个数，得四组一起看，否则很容易把一个维度的胜利说成全面胜利。

同一组里还得再分总量和单请求。单请求快不代表并发起来也快，反过来也一样：一个配置在单条请求上首 token 很漂亮，并发一压反而排队排到天边。反过来某些批处理调优的配置，离线吞吐很猛，但单请求延迟惨不忍睹。对比表里这两列最好分开记，不然读表的人会误会。

吞吐和延迟，你要的到底是哪个

这问题听着简单，实际沟通里翻车最多。批处理、离线生成、语料清洗这类任务，看的是每秒总 token 数，单个请求排队久一点无所谓，反正没人盯着屏幕等。在线对话、代码补全就不一样，用户对第一句话的等待最敏感，首 token 延迟一上去，体感立刻变差，哪怕后端总吞吐再高也救不回来。

• 离线批量任务：吞吐优先，延迟只要不触发上游超时就行
• 实时对话：首 token 延迟优先，吞吐够用即可
• 代码补全这类边打字边出结果的：单 token 间隔比首 token 还关键
• 混合业务：按流量占比给两组指标各设一条及格线，别只优化一头
• 对外报数时写清楚测的是哪一组，避免对方默认成自己关心的那个

拿吞吐数字去说服一个做实时聊天的团队，是特别常见的沟通翻车点。对方要的是「敲下去多久出第一个字」，你给的是「一小时能吐多少 token」，两边都觉得自己有理，其实在说不同的事。对比前先问一句「你们线上最在意哪段等待」，比多跑十轮压测都管用。

我建议的实测顺序

顺序错了，后面全是白测。先把变量钉死，再一步步加负载，每步都留记录。我的习惯是先固定模型与量化档，把 max_model_len 和显存占用比例显式写进启动参数，抄在测试记录里，别让默认值替你决定对比条件——默认值一改，两轮测试就不在一个口径上了。

1. 单条请求跑基线空载发一条请求，记录首 token 延迟和单 token 间隔，作为后面所有对比的参照点。
2. 按并发梯度加压从低并发往上加，每档跑够时长，同时记吞吐、P99 延迟和显存水位，别只看均值。
3. 跑长稳观察漂移持续跑一段时间，看吞吐有没有往下掉、显存有没有缓慢爬升，这两条是生产环境最容易暴露的问题。
4. 回填记录表把每档的模型、量化档、上下文长度、卡型、并发数一起记下，缺一项这组数据以后就没法复用。

这里有个我踩过的坑：第一次做对比时只记了吞吐和平均延迟，忘了记上下文长度，结果两轮测试一个用短 prompt 一个用长输入，数字差了一截，排查半天才发现是参数没对齐，不是框架的问题。从那以后启动参数一律抄进记录表，省了很多扯皮。

压测好看、线上却慢，按这个顺序排查

这种对不上的情况太常见了，先别怀疑框架。第一步看请求长度分布：压测里用的短 prompt 和真实业务的长输入完全不是一回事，上下文一长，KV 缓存吃显存，延迟和吞吐都会变脸。先拿线上真实请求的长度分布重跑一轮，很多「线上慢」在这一步就有答案了。

第二步查并发是不是被上游限流挡住。你测出来的可能是网关的上限，不是框架的上限，这种事在多层代理的部署里特别容易发生。第三步看批处理参数和实际并发匹不匹配，开太大反而拖慢小请求，得按真实并发量回调。最后才轮到驱动、CUDA 版本和卡间通信，跨卡部署时这一步最容易漏，也最费时间。

排查顺序别乱跳。先数据口径，再链路瓶颈，再参数匹配，最后才动底层环境。跳着查很容易改了一圈配置，回头发现是压测脚本的 prompt 写短了。