vllm github performance

很多人看到 vLLM 仓库里那张延迟吞吐表，就默认自己换上同样的卡也能跑出那个数，结果一上线差出好几倍。问题通常不在 vLLM 本身，而在基准的测试口径和你的输入输出长度、并发、量化格式根本不是一回事。这篇给一套读表和自测的流程，让你把官方数据翻译成自己机器上的预期区间。

很多人翻 vLLM 的 GitHub 仓库，看到那张延迟和吞吐的对照表，第一反应是「我换上同样的卡也能跑出这个数」。上线之后发现差出好几倍，于是开始怀疑框架有问题。其实问题多半不在 vLLM，而在于那张表的测试口径——输入多长、输出多长、并发多少、用什么精度、几张卡跑——和你实际的线上流量根本不是一回事。

这篇不解释 vLLM 的原理，只讲怎么把那堆基准数字翻译成你自己机器上的预期区间。读完你应该能做到三件事：看懂官方表里每列在测什么；知道自己的实测为什么对不上；按固定变量的方式自测一遍，拿到能用来做容量估算的拐点。

官方那张表到底在测什么

先把指标分成三类，混着看一定会误判。第一类是单请求延迟，通常拆成首 token 时间（TTFT）和后续每个 token 的间隔，前者看你排队和预填充快不快，后者看解码稳不稳。第二类是整体吞吐，也就是每秒能吐多少 token，这个数在并发上来之后才有意义。第三类是并发下的排队表现，请求一多，延迟怎么涨、吞吐什么时候封顶。

光看指标还不够，必须连着测试条件一起读。同一张表里，输入长度、输出长度、并发数、量化精度、张量并行的卡数、采样参数，缺任何一项，结论都没法横向比。官方数字大多建立在固定长度的合成数据上，和你业务里那种忽长忽短的 prompt 分布差距很大。想知道当前各家卡的规格口径怎么对齐，到 /compute/gpus 对一遍。

为什么你跑出来对不上

第一步不是怀疑硬件，而是先把口径对齐。把并发、输入输出长度、采样参数调成和基准一致，再跑一遍，如果还是差很多，才轮到排查性能本身。跳过这一步，后面所有比较都是白费。

• 显存不够，触发了换页或分批，吞吐直接掉档，先看显存占用和是否有大量换出
• 并发设得太小，压不满算力，吞吐自然上不去，这是自测最常见的低分原因
• 输出被超长 prompt 拖着走，预填充占了大头，看起来像解码慢
• 量化格式没走对算子路径，用了不匹配的档位，速度和白测的不一样

同一张卡在不同量化档位下的吞吐差别可以很大，选档位不能只看参数量。档位和显存、延迟之间的取舍，到 /models/deploy 看当时的测算口径，再结合自己的业务长度定。

自己跑一遍延迟基线：按这个顺序做

1. 固定变量一张卡、一种量化、一组你业务里真实的输入输出长度，测试过程中别改配置，改了就不是同一组对比。
2. 从低并发往上压用框架自带的基准脚本或自己写压测，从单并发开始逐步加，每个并发档都记录 TTFT、每 token 间隔和总吞吐。
3. 找拐点吞吐不再明显上涨、延迟开始陡增的那个并发值，就是线上该设的上限参考，超过它只会多排队。
4. 存档重跑把结果存下来，换卡、换量化、升级版本后，用同一组参数重跑，才有可比性。接口侧想先要个参照数，用 /tools/speed-test 量一下。

从基准数字推到上线配置

测出来的单卡安全并发，乘卡数之前要先打折。真实业务里有长尾请求、有重试、有突发的尖峰，这些都会吃掉余量。把安全并发直接乘卡数当容量，通常上线没几天就被打脸。

估算卡数时别忘了把上下文长度算进去。长上下文吃的是显存和带宽，不是只看参数规模就够了。具体的容量测算口径对照 /compute/sizing，别自己拍脑袋乘个系数。

这些情况下基准数据不用看

• 业务请求形态极端时，比如超长输入、超长输出或突发尖峰，固定长度的合成基准参考价值很低，只能自己压
• 多机多卡、异构卡混跑、非主流加速卡上的表现，官方单机数据基本不适用，要看对应适配分支自己的说明
• 只做离线批处理、对延迟完全不敏感的任务，延迟指标可以直接忽略，只比总吞吐和单位成本
• 框架版本差异大时，老基准和新实现的算子优化对不上，别拿旧表推新版本

判断要不要信一份基准，最简单的办法是问一句：我的请求分布和这份测试的条件差多远。差得越远，越只能靠自己压测，官方数字顶多当个量级参照。

基准测的是它的条件，不是你的业务；能平移的只有方法，不是数字。