大模型推理延迟和吞吐对比，测试条件不同结论就不同
大模型推理速度对比，先要统一测试条件，否则不同来源的跑分没有可比性。
实际影响体验的指标主要有两个：首 token 延迟（用户发出请求到看到第一个字的时间）和输出吞吐（每秒能生成多少 token，或同时服务多少请求）。
本文按同一套条件讲清楚怎么测、怎么看结果，以及常见误判。
速度对比前先固定这五个条件
对比推理速度时，至少要让以下条件保持一致，否则数字只能当参考：
- 硬件：GPU 型号、显存容量、是否多卡并行
- 模型：参数量、量化方式（FP16、INT8、INT4 等）、上下文长度上限
- 输入长度：prompt 的 token 数，长 prompt 会明显拉高首 token 延迟
- 输出长度：生成 token 数，决定吞吐统计是否公平
- 并发数：单请求测的是延迟，多请求测的是吞吐，两者不能混着比
如果只看到“某模型每秒 200 token”这类结论，却没有说明输入输出长度和并发，它只能说明那个特定场景，不能直接套到你的业务上。
用 vLLM 做一次可复现的测速
下面以 vLLM 自带的 benchmark 脚本为例，演示如何在同一台机器上对比两个模型。
前提是已经装好 vLLM 并能正常加载模型，显存足够容纳目标模型。
启动服务时固定关键参数：
python -m vllm.entrypoints.openai.api_server \
--model /path/to/model-a \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--port 8000另开终端，用 benchmark 客户端压测。
输入长度和输出长度要写死，方便两个模型用同一组参数对比：
python benchmarks/benchmark_serving.py \
--backend openai-chat \
--base-url http://127.0.0.1:8000 \
--model /path/to/model-a \
--dataset-name random \
--random-input-len 512 \
--random-output-len 256 \
--num-prompts 100 \
--request-rate 10脚本会输出请求延迟、首 token 延迟和吞吐等统计。
换模型时保持 --random-input-len、--random-output-len、--num-prompts、--request-rate 完全一致，只改模型路径，得到的数字才有对比意义。
如果不想用脚本，也可以用 curl 手动发一条请求，看总耗时，但这种方式只适合粗略感受，不适合做正式对比。
延迟和吞吐分别对应什么场景
同一组测速结果里，两个指标回答的是不同问题：
- 首 token 延迟低：适合聊天、客服等交互场景，用户等的是第一个字出现的时间
- 输出吞吐高：适合批量摘要、文档处理等后台任务，关心单位时间能处理多少内容
- 并发下的延迟：并发升高后首 token 延迟通常会变大，要看你业务峰值时还能不能接受
一个模型单请求很快，不代表高并发下也快；
反过来，吞吐高也可能单条请求延迟偏大。
对比时先明确业务更在意哪一个，再去看对应指标。
容易踩的三个坑
用不同量化版本直接比。 FP16 和 INT4 的显存占用、计算量都不同，速度差异里混入了量化因素。
要对比模型本身，先固定量化方式。
忽略 warmup。 第一次请求包含模型加载和显存分配，耗时会明显偏高。
正式测速前先发几条预热请求，再开始统计。
只看平均值不看长尾。 平均延迟好看，但部分请求可能慢很多。
如果业务对超时敏感，要关注 P95、P99 这类分位值，而不是只看均值。
结果怎么验证是否可信
拿到一组对比数据后，做三个检查：同一组参数是否只改了一个变量；
预热是否完成；
重复跑两到三次结果是否接近。
如果两次结果波动很大，先排查机器上是否有其他进程占用 GPU，再考虑模型差异。
推理速度对比的结论一定带条件。
对大多数团队来说，先在自己的硬件上用固定输入输出长度测一轮首 token 延迟和吞吐，比收集网上的跑分更有参考价值。
