vllm github benchmarks

你大概遇到过这种情况：想给项目定一个推理框架，搜到 vLLM 的官方基准图表，延迟和吞吐看起来都很漂亮，但抄到自己机器上完全不是那个数。问题不在 vLLM，在于你没搞清那张图是在什么卡、什么模型、什么并发和什么量化档位下跑出来的。这篇不吹也不黑，只讲一件事：官方基准怎么看、怎么复现、怎么和你自己的场景对齐。

你大概遇到过这种情况：想给项目定一个推理框架，搜到 vLLM 的官方基准图表，延迟和吞吐看起来都很漂亮，但抄到自己机器上完全不是那个数。问题不在 vLLM，在于你没搞清那张图是在什么卡、什么模型、什么并发和什么量化档位下跑出来的。

这篇不吹也不黑，只讲一件事：官方基准怎么看、怎么复现、怎么和你自己的场景对齐。核心结论先给你——官方数字只用来排序和排除，绝不用来承诺容量。

先接受一件事：官方基准不是你的基准

官方基准的定位是横向比较框架本身的实现效率，它必须固定一大堆前提：特定型号的卡、固定的模型与精度、固定的批处理策略、固定的请求长度分布。任何一项变了，数字都会漂。所以看到和自己实测差一截，先别怀疑框架，先怀疑前提对不上。

• 卡型与显存带宽不同，同样的模型换个档位的卡，吞吐可能差出一大截
• 量化档位不同，权重占的显存和算力开销完全不是一回事
• 并发与请求长度分布不同，长输入偏预填充、长输出偏解码，瓶颈位置都不一样
• 是否开前缀缓存、是否开投机解码，这两个开关对短前缀重复率高的场景影响极大
• 客户端与网络这一层有没有算进去，压测脚本位置不同结论就不同

判断标准很简单：只看官方数值的绝对值没有意义，看同一组参数下不同配置之间的相对差距才有意义。什么时候不适用？如果你打算用托管 API 或别人的推理平台，官方基准基本只能当参考，真正的数要按平台自己的口径测。

去哪找这些数据，找的时候看哪几个字段

官方仓库里通常有专门的基准目录和性能说明文档，读的时候先找三样东西：测试脚本本身、依赖版本清单、硬件描述。脚本决定它到底压了什么请求形状，依赖版本决定调度和算子实现，硬件描述决定这组数字能外推到什么范围。三样缺一样，这张图就只能看趋势。

看图表必须连同图注一起读。图注里一般会写明卡型、精度、模型规模、并行方式和上下文长度，这五项就是这张图的「身份证」。你引用这个数字的时候，这五项得能一起说出来，否则就是断章取义。

基准脚本

决定请求长度分布和并发梯度，读不懂脚本就看不懂图

依赖版本

调度、算子、注意力实现都可能影响结果，版本不同结论会变

硬件描述

卡型、卡数、互连方式，决定这个数字能不能外推到你的机器

图注前提

精度、模型规模、并行方式、上下文长度，缺一项都不能直接引用

想省去翻文档的功夫，可以到站内的 /benchmarks 和 /benchmarks/registry 看整理过的测评榜单，先建立「同一口径才可比」的习惯；再拿自己的模型、卡型和量化档位到 /models/deploy 的部署测算页填一遍，得到一个属于你场景的估算区间，用来和官方数字做对照。

三类图分别想告诉你什么

官方基准图看起来很多，其实主要就三类，各自回答一个不同的问题。搞清楚图在答什么问题，比记住曲线长什么样重要得多。

• 吞吐-并发曲线：回答框架在大批量下还能不能扛住，重点看拐点在哪，而不是峰值多高
• 延迟分位图：首 token 延迟和单 token 延迟要分开看，均值没有参考价值，必须盯尾部
• 显存占用与批大小关系：决定你能开多大并发，也决定高峰期会不会被打爆

读法的顺序是反过来的：先确定你能接受的尾部延迟上限，再看在这个上限之内吞吐能到多少，由此反推你能开多大并发。很多人是从峰值吞吐出发倒推，结果线上延迟一塌糊涂，这是最常见的读图错误。

还要注意拐点的含义。曲线在某个并发之后开始变平，说明再往上加并发只会堆延迟、换不来吞吐，那个位置就是你这套配置的实际容量天花板。真正上生产，得在这个拐点下面留安全余量，而不是贴着拐点跑。

在自己机器上做一次最小复现

复现不需要做到和官方一模一样，只要保证「同一组固定条件」下你得到一组稳定数，能和官方曲线做趋势对照就够了。下面是四步，按顺序做，别跳步。

1. 锁定变量选定一个模型和一个量化档位，全程不再更换；把上下文长度和批处理上限也固定下来，验证方式是前后两次压测的配置能完全对上。
2. 造请求用接近你线上分布的请求长度去压，不要全用同一长度的假数据；验证方式是统计这轮压测的输入输出长度分布，和你的流量画像比一下。
3. 爬并发梯度从小到大拉几档并发，每档记录吞吐、首 token 延迟、单 token 延迟的尾部值；验证方式是曲线是否出现明显拐点，没有拐点说明档位还不够。
4. 对齐官方把结果和同硬件档位的官方曲线放一起比趋势，差距超过预期就按排查顺序查：显存是否吃紧、是否走了 CPU 卸载、预处理是否成瓶颈、网络或客户端是否拖后腿。

在正式压之前，先到 /tools/speed-test 量一遍你自己的接口延迟基线，把客户端和网络这一层的干扰排除掉，再谈框架性能。否则你测出来的延迟里混着网络抖动，根本分不清是谁的问题。

什么情况下不用复现？只是做选型初筛、而且候选框架之间的差距一眼就能看出来时，复现成本高于收益，直接按公开数据排序排除即可。但一旦进入容量规划，复现就是必须的。

把官方数据映射到你的业务形状

官方基准给的是通用形状，你的业务是具体形状。对齐之前，先把自己的流量画像写清楚，四项就够：平均输入长度、平均输出长度、并发峰值、能忍受的尾部延迟上限。这四项比任何基准数字都重要。

想算卡数，可以到 /compute/sizing 按模型规模跑一遍，再和 /inference 里开源模型的性能口径对齐，两头对得上再下结论。只想比价格和托管方案，去 /price-watch 看当时的数字，但记住性能口径和价格口径是两码事，别混着比。

判断标准：如果官方基准里，你这个业务形状对应的那一档本来就不好看，换框架大概率也救不回来，该换的是硬件档位或量化策略，而不是再试第四个框架。

什么情况下可以信官方基准

信不信官方数字，不取决于它多好看，取决于你的条件和它差多远。下面按可信度分三档说清楚。

• 可以信：硬件型号与官方测试一致、模型与量化档位一致、请求长度分布接近、并发区间落在你实际会用的范围内
• 要打折：跨卡型外推、跨量化档位外推、把实验室批处理数字直接当作线上容量
• 不能用：拿它做容量承诺，拿它写进采购合同里的性能条款
• 稳妥做法：官方数字只用来排序和排除，最终容量按自己压测结果再留安全余量

特别提醒一句跨卡型外推。显存带宽和互连方式一变，同样的模型跑的瓶颈位置就可能从算力转到带宽，这时候官方那条曲线连趋势都未必能参考，必须自己在目标卡型上实测一遍才能用。

几个最常见的误读

最后列几个高频误读，都是在引用官方基准时最容易踩的坑。对着检查一遍，比再读一遍文档有用。

• 把峰值吞吐当日常吞吐，实际线上很少能长时间跑在峰值批大小上
• 忽略缓存带来的差异，开了前缀缓存的场景和冷启动场景完全是两回事
• 拿不同精度、不同并行配置的数字直接比大小
• 只顾吞吐不看尾部延迟，结果用户体验被少数慢请求拖垮
• 只看一张图就下结论，没有把延迟和吞吐放在同一个配置下一起看

引用任何一个性能数字之前，先能完整说出它的卡型、精度、模型规模和并发区间，说不出来就先别用。

养成一个固定动作：每次要引用官方基准，先把上面那四个前提抄在便签上，对不上就不要引。时间长了你会发现，真正能直接用的官方数字其实不多，但它们足够帮你排除掉大部分错误选项。