LLM 推理 Benchmark 完全指南：评价指标、主流基准与评测方法论

请求生命周期：TTFT、ITL/TPOT 与端到端延迟#

一个流式请求从发出到结束，在时间轴上天然分成两段：prefill（预填充）阶段，模型读完整个输入 prompt、算出第一个输出 token；之后是 decode（解码/生成）阶段，逐 token 产出直到遇到结束符。三大延迟指标就是在这条时间轴上切出来的。下图是 NVIDIA NIM 文档里标准的端到端时间轴示意：

TTFT（Time To First Token）：从请求提交到收到第一个输出 token 的时间。注意它包含的不只是 prefill 计算：请求在队列里等待的时间、调度器分配 KV 显存的时间、网络与 tokenize 的耗时都算在内。因此 TTFT 是「系统在负载下的体验指标」，同一个引擎空载和满载时的 TTFT 可以差一个数量级；而论文里常说的「prefill 延迟」是只算 prefill 阶段的纯计算指标，两者不可混用。

ITL 与 TPOT：ITL（Inter-Token Latency，token 间延迟）和 TPOT（Time Per Output Token）在多数语境下是同义词，都指 decode 阶段相邻两个输出 token 的时间间隔——它是用户感受到的「出字速度」的直接来源，也是单请求速率的核心参数。个别工具对两者的口径有细微差别（有的把 TPOT 定义为排除首 token 后的平均单 token 时间，有的把 ITL 定义为流式响应中相邻两个 chunk 之间的间隔再除以 chunk 内 token 数），阅读报告时先确认口径。

E2E（端到端）延迟：从提交到收到完整响应的总时间。它是前两者的线性组合：

其中 $N_{\mathrm{out}}$ 是输出 token 总数，$\Delta_i$ 是第 $i$ 个间隔的长度；用平均间隔近似时就是第二个等号。反过来，由总耗时反推 TPOT 时要把首 token 对应的 prefill 段排除掉，否则 prefill 越长、输出越短，误差越大：

分子上减去的 $T_{\mathrm{first}}$（首 token 到达时刻）正是为了剥离 prefill；分母用 $N_{\mathrm{out}}-1$ 而不是 $N_{\mathrm{out}}$，是因为第一个输出 token 的等待已经被 TTFT 完整计入，decode 阶段实际只有 $N_{\mathrm{out}}-1$ 个「间隔」。这是个非常容易踩的口径坑：同一组测量数据，用 $N_{\mathrm{out}}$ 做分母会把 TPOT 系统性报低约 $1/N_{\mathrm{out}}$，短输出时偏差很大。

一个具体的数字例子可以帮助建立量级感（示意数据，不代表任何特定引擎）：某请求提交于 $t=0$，首 token 于 200 ms 到达（TTFT = 200 ms），共生成 256 个 token，最后一个 token 于 $t=1.2$ s 到达。则 E2E = 1200 ms，TPOT = (1200 − 200) / 255 ≈ 3.92 ms，对应单请求平均出字速度 ≈ 255 个 token / 1.0 s ≈ 255 token/s。如果同样测到「首 token 1 s、总共 1200 ms」，那 256 个 token 几乎瞬间就吐完了，说明模型要么没在生成、要么输出了空响应——这类异常也是评测脚本要显式剔除的（NVIDIA 的指标文档专门提醒：首响应不含 token 时 TTFT 无意义）。

吞吐类指标：总产出与请求速率#

延迟指标回答「单个请求多快」，吞吐指标回答「整机塞满后单位时间产出多少」。输出 token 吞吐的定义是：

测量窗口的取法直接影响结果。业界引擎自带的基准（如 vLLM benchmark_serving）通常把所有请求都发完、等最后一个请求完全结束才停止计时——这保证了分母覆盖「从第一个请求发出到最后一个请求结束」的完整区间，但也意味着最后一个慢请求会拖长窗口、摊薄平均值，这正是高负载下 P99 拖尾直接压低平均吞吐的原因。下图展示了这种并发交错的时间线：

围绕吞吐有四个口径问题，几乎每个都出过乌龙：

1. 只算输出还是输出+输入。LLM 服务的 prefill 与 decode 计算量不是一个量级，把输入 token 计入吞吐会显著抬高数字。GenAI-Perf 等工具只统计输出 token（称为 Output Token Throughput），而部分厂商宣传材料喜欢报 Total Token Throughput。两者不可直接比较。
2. 单用户速率还是系统吞吐。单用户速率 = 输出长度 / E2E，随输出变长渐近收敛到 $1/\mathrm{TPOT}$；系统吞吐是所有并发请求的合计产出。一个常见宣传话术是拿「系统输出吞吐」除以「用户数」冒充单用户体验——当并发足够大时，单用户速率会远低于这个均值。
3. 请求吞吐与 token 吞吐的关系。RPS = 完成请求数 / 窗口时长，它强烈依赖平均输出长度：同样的算力，输出 128 token 的负载能支撑的 RPS 远高于输出 4096 token 的负载。因此报 RPS 必须同时报平均输入输出长度，否则毫无可比性。
4. 负载形态：是「固定并发压满」还是「按到达率打流」。前者测的是系统容量上限，后者测的是在指定流量下的稳态表现，两者对应 MLPerf 的 offline 与 server 场景（见后文），数字含义完全不同。

分位数与 goodput：高负载下的「稳」#

推理服务是交互系统，均值和 P99 之间隔着整个「排队」现象。一个引擎的 TTFT 均值可能是 50 ms，但负载上来后 P99 可能到 800 ms——前者决定宣传数字，后者决定用户体验与 SLA 违约。分位数的定义无需赘述（P99 即按升序排列后 99% 样本都不超过的值），关键在于评测必须同时报告负载水平与分位数，二者才共同构成有效信息：空载 TTFT P99 = 45 ms 只能证明引擎本身快，无法证明它能扛住流量。

「达标率（goodput）」概念把分位数和业务目标结合：给定一组 SLO 阈值（如 TTFT ≤ 某值且 TPOT ≤ 某值），统计达标请求的占比：

其中 $\mathbb{1}[\cdot]$ 是指示函数，条件同时满足才记 1；$a$、$b$ 是业务方给出的 SLO。vLLM 的 benchmark_serving 与 NVIDIA GenAI-Perf 都支持这类约束：GenAI-Perf 通过 --goodput time_to_first_token:<ms> inter_token_latency:<ms> 传入阈值，报告中给出满足约束的请求吞吐；vLLM 则在 --goodput ttft:<ms> tpot:<ms> e2el:<ms> 下统计 request goodput。用 goodput 而不是裸吞吐做优化目标，能直接过滤掉「靠把所有人拖慢来抬高平均产出」的伪优化。

用数字看问题会更直观。NVIDIA 官方博客给出的 GenAI-Perf 单 GPU vLLM 示例中：并发 1 时 TTFT P50/P99 为 45/89 ms、ITL P50/P99 为 12/21 ms；并发提高到 32 后，输出吞吐上涨而 TTFT P99 涨到 800 ms 量级——吞吐上去了，但任何交互型 SLO 都被击穿。这就是为什么 2024 年之后的推理服务论文与厂商提交几乎都改成同时报告「吞吐 vs P99 延迟」曲线，而不是单点数字。

顺带一提，尾延迟的分布形状还能当诊断工具用（社区常见经验）：TTFT 的 P99 高而 TPOT 正常，问题多半出在 prefill 与调度环节（排队、长 prompt prefill 占住算力、前缀缓存未命中）；TTFT 与 TPOT 同时恶化，通常是整机算力或带宽饱和；TPOT 正常但逐 token 间隔忽大忽小，则往往是有大 prefill 或抢占事件周期性插入 decode 流。

微观指标：内核占用、算力利用率与「带宽墙」#

上面所有指标都是黑盒视角（从外部观测服务），而内核开发与硬件评估需要白盒指标。最常用的是占峰值比例：kernel 实测 FLOPs 除以硬件标称峰值。FlashAttention 系列论文是这一惯例的标杆——FlashAttention-2 报告在 A100 上达到 73% 的峰值利用率，FlashAttention-3 在 H100 上逼近 FP8 峰值；它让「注意力比 GEMM 慢多少」有了可比较的答案。访存型 kernel 则看有效带宽（GB/s）或与 HBM 理论带宽的比例。

理解白盒指标的关键背景是 decode 阶段的带宽墙：生成阶段每个 token 都要把全部权重（以及当前 KV 缓存）从 HBM 读一遍，计算量相对小，因此单请求的生成速度上限基本由显存带宽决定：

其中 $B_{\mathrm{HBM}}$ 是显存带宽，$S_{\mathrm{weights}}$ 是权重字节数（例如 70B 模型 FP16 约 140 GB），$S_{\mathrm{kv,per\_token}}$ 是每个 token 需要新增读取的 KV 字节数（与层数、KV head 数、维度、精度成正比）。代入 H200（带宽约 4.8 TB/s）跑 FP16 的 Llama-2-70B：$r_{\max} \approx 4.8 \times 10^{12} / 1.4 \times 10^{11} \approx 34$ token/s——这就是为什么 70B 模型单用户 30–40 token/s 是「正常」，而 8B 模型能到 100+ token/s（权重小了近一个数量级）。这个粗算上界解释了评测中很多「为什么快不起来」的问题，也说明报告 tokens/s 时若不说明模型规模与精度，数字几乎无意义；反过来，量化把权重字节数砍到 1/4，带宽墙上限几乎线性上移，这正是量化论文里「实测提速接近 2–3 倍」的底层原因。

质量保持指标：优化之后「还是不是原来的模型」#

速度数字单独存在没有意义——任何推理优化都必须先证明没有把模型换成别的模型。质量评测按粒度分三档：

第一档：困惑度（perplexity，PPL）。对一段文本，模型的条件对数似然越低越好：

其中 $t_1, \dots, t_N$ 是评测文本的 token 序列，$p_\theta(t_i \mid t_{<i})$ 是模型在给定前文条件下对第 $i$ 个 token 的预测概率。PPL 是最便宜的「无损性探针」：权重量化、KV 量化论文（如 GPTQ、KIVI、KVQuant 等）几乎都以 WikiText-2 等语料上的 PPL 变化为主要质量指标——前提是用同一 tokenizer、同一评测集、同一长度截断方式。PPL 的问题是它对长上下文中的事实性错误不敏感，因此只配当第一道门槛。

第二档：任务准确率。用真实任务验证推理行为没有系统性退化：MMLU/MMLU-Pro（知识推理）、GSM8K（数学）、代码生成、摘要等。开源工具 lm-evaluation-harness（EleutherAI）把这些评测统一成「加载模型 + 跑 task」的接口，几百个 task 开箱即用，是量化与加速研究的事实标准。为控制成本，评测中常用子集：InferenceBench 的质量门就是固定 500 题的 MMLU-Pro 子集，要求优化后的服务在贪心解码下的准确率不低于 PyTorch 基线模型的 0.95 倍。

第三档：长上下文与检索能力。凡是改动注意力机制、压缩/驱逐 KV 缓存、缩短上下文的优化，都必须过这一档——因为 PPL 与短任务对「模型有没有真的读进上下文」不敏感。常用基准：

• LongBench（THUDM，2023）覆盖单文档/多文档问答、摘要、代码等 6 类长文本任务，是 KV 压缩与稀疏注意力论文的标配；
• LongBench v2（2024 年底推出）把难度提到「需要跨长文推理」：503 道多选、上下文 8k 到 200 万词，人类专家限时作答只有 53.7% 准确率——设计目标就是让只靠检索表层信息的模型现形；
• RULER（NVIDIA，arXiv 2024）是合成基准，可控地生成 NIAH 检索（单针/多针/多跳）、变量追踪（VT）、词频聚合（CWE/FWE）与带干扰的 QA 四族共 13 个任务，在 4K–128K+ 各长度上测。RULER 的核心发现是：几乎没有任何模型能在标称上下文长度内保持质量不跌——「支持 128K」与「128K 下还能用」是两回事；
• Needle in a Haystack（NIAH）是单点检索测试，作为最低门槛仍被广泛使用（很多 KV 驱逐论文用它做 sanity check），但它只能证明「模型记得上下文里有这根针」，证明不了深层理解。

还有一个容易被误分类的指标：投机解码的接受率。接受率（草稿 token 被验证通过的比例）描述的是草稿模型与目标模型的分布契合度，它是效率指标的中间量而非质量指标——真正证明「投机解码无损」的是输出分布与目标模型自回归一致（理论上拒绝重采样保证一致，实验上用 PPL/任务分不退化佐证）。评测投机解码系统时，接受率、每步期望 token 数 $\mathbb{E}[\#\text{tokens/step}] = 1 + \sum_{k=1}^{\gamma}\Pr(K \ge k)$（$K$ 为单次验证接受个数，$\gamma$ 为草稿长度）与端到端 wall-clock 提速要分开报：接受率再高，若草稿模型计算开销大、验证步无法并行，端到端也可能不赚。

MLPerf Inference：行业「考卷」与场景化目标#

MLPerf Inference（MLCommons 旗下）是数据中心推理的事实标准，它的核心方法论（2019 年的论文里定下）到今天仍在使用：LoadGen（负载生成器）按给定场景向被测系统打流，被测系统在固定模型、固定数据集（QSL）与固定精度下跑分。LLM 时代它把基准文本模型从 GPT-J 一路升级到 Llama 2 70B、Llama 3.1 405B；2025 年的 v5.0 引入 Llama 3.1 405B 的 server/offline 场景，v5.1 为 405B 新增 interactive 场景——其 SLO 是硬指标：P99 TTFT ≤ 4.5 秒、每用户吞吐 ≥ 12.5 token/s。2026 年 4 月公布的 v6.0 把阵容扩成 11 个数据中心测试：新增 GPT-OSS-120B（开源 MoE 推理模型）、DeepSeek-R1（其 interactive 场景把最低生成速率要求提到以往文本模型的 5 倍，并明确允许投机解码）、Qwen3-VL 多模态、Wan 2.2 文生视频、DLRMv3 推荐模型等，并推出允许跑服务式软件栈的 LoadGen++ 框架；该轮共 23–24 家机构提交 451 项结果。

MLPerf 的三个经典场景与指标的关系值得单独讲清：

v6.0 的公开结果给出了很好的解读样本（均出自厂商提交说明与报道）：NVIDIA 用 288 张 Blackwell Ultra（GB300 NVL72 集群）把 DeepSeek-R1 跑到约 249 万 token/s（offline）、155 万 token/s（server）；并且强调纯软件收益——同一 GB300 NVL72 硬件上，相比半年前的提交，DeepSeek-R1 server 吞吐提升最高 2.7 倍（软件栈包括 TensorRT-LLM 更新、PD 分离框架 Dynamo、MoE 的 Wide Expert Parallel、多 token 预测与 KV-aware 路由），生成成本降了 60% 以上。AMD 用 MI355X 提交了首个多节点结果：11 节点 87 卡跑 Llama 2 70B 超过 100 万 token/s（offline），扩展效率 97–98%；单节点 8 卡 server 场景约 10 万 token/s，达到同配置 B300 的 93%，interactive 场景则达到 104%；其 405B interactive（FP4）结果约 793 token/s，代价是结构化裁剪了约 1/5 的层，同时报告 ROUGE-L 99.30% 的生成质量保持。

从这批数字能提炼出读 MLPerf 报告的三条经验：其一，吞吐数字必须连同「多少张卡、什么互联、什么精度」一起看，288 卡的 249 万 token/s 与 8 卡的 10 万 token/s 不构成竞争关系；其二，量化与裁剪是允许的参赛手段，同场景下 FP4+裁剪 vs FP16 的数字差异不全是引擎功劳，要看质量报告；其三，server/interactive 场景的成绩同时是「调度与批处理能力」的成绩——同样的硬件，排队策略决定你能否在 SLO 内吃下更多流量。

引擎自带基准：合成负载 + 可控到达过程#

vLLM 的 benchmark_serving.py 是目前被引用最多的在线服务评测脚本，SGLang、TensorRT-LLM 等生态里都能看到它的同源变体。它的设计值得仔细看，因为它定义了开源社区评测的事实约定：

• 请求数据集可选三类：ShareGPT 真实对话（对提示做截断或拼接）、随机合成（--random-input-len/--random-output-len 指定平均输入输出长度，长度可在一定范围内均匀抖动，避免所有请求一模一样）、自定义 JSONL 回放；
• 到达过程由 --request-rate（每秒请求数）控制，默认按 Poisson 过程随机到达——即相邻请求的间隔服从参数为 $\lambda$（请求速率）的指数分布，模拟真实用户「随机且独立」地发起请求；--request-rate inf 表示瞬间把全部请求砸进去（最坏情况排队测试）；--burstiness 参数可以把到达过程在「均匀」与「突发」之间调节；
• 报告指标：请求吞吐（req/s）、输出 token 吞吐、TTFT/TPOT/ITL/E2E 的均值、中位数与 P99，以及可选 SLO 约束下的 goodput；
• 结果里 TTFT/TPOT 的分位数与负载一一对应，方便画「延迟-吞吐」曲线。

这套约定也有已知缺陷，最典型的是负载发生器自身成为瓶颈：vLLM 社区 2025 年的 RFC（issue #30383）指出，单进程 asyncio 写法的客户端在 --request-rate inf 或高并发下会先于服务器耗尽 CPU，测出来的 TTFT/TPOT 曲线严重失真（作者用固定 100 ms TTFT 的假服务验证：rate=100 时结果准确，rate=200 与 inf 时显著偏高），RFC 提议多进程架构解耦「按速率发送」与「维护并发」。这个案例本身是评测方法论的好教材：任何基准的结果都隐含「客户端能力 ≥ 被测服务能力」的前提，压测前要先确认客户端没先被打爆。

API 供应商对比：LLMPerf 与 GenAI-Perf/AIPerf#

LLMPerf（Anyscale，2023 年底开源）定位是「给不同推理供应商/引擎做可复现对比」。它只保留两个核心指标——输出 token 吞吐（面向批量场景）与 TTFT 分位分布（面向流式场景），并给出固定测试形态（如 150 个请求、5 并发、平均 550 输入 / 150 输出 token），附带的 leaderboard 曾横向测过 Llama-2-70B 在多家供应商上的表现，中位输出吞吐从 21 到 185 token/s 不等——同一个模型，供应商之间可以差近一个数量级。LLMPerf 的方法论贡献是明确了「供应商对比」必须锁死请求形态与统计口径，否则比的是负载不是服务。

GenAI-Perf / AIPerf（NVIDIA）脱胎于 Triton Inference Server 的 Perf Analyzer，是面向服务部署的负载测试工具。它的标准用法是并发扫描：从并发 1 扫到数百，每个并发档位下跑一轮，报告该档的 TTFT/ITL/请求时延（avg/min/max/P50/P75/P90/P99）与输出吞吐、请求吞吐，从而画出一条完整的「吞吐-尾延迟」权衡曲线；它同样支持 SLO 约束的 goodput 模式。NVIDIA 从 2025 年起在官方文档中把指标定义与收集统一收口到新一代工具 AIPerf（GenAI-Perf 的继任者），两者指标定义一致。对自建服务团队，这类工具的核心价值在于把「并发-时延-吞吐」三者的关系量化出来，找到吞吐饱和点与 SLO 击穿点的位置。

四个服务层工具对比如下：

模型级与内核级快速评测#

在做技术选型或本地对比（尤其是量化与 GGUF 精度对比）时，轻量基准更常用：llama.cpp 自带 llama-bench，可测量 prompt 处理与 token 生成两个阶段的速率并报告内存占用，适合 CPU/小 GPU 场景的横向对比；vLLM 仓库里也有单请求延迟脚本（benchmark_latency）用于快速看模型前向延迟。内核层面，NVIDIA Nsight Compute 的 Speed-of-Light / roofline 视图把 kernel 实测性能拆成「算力利用率、带宽利用率、占用率」三块，是判断 kernel 到底差在哪里的标准工具；学术内核论文则习惯直接报「占峰值 FLOPs 百分比」（见 FlashAttention 系列的 73% 先例）与实测带宽。

质量评测工具链：把「无损」变成可执行检查#

质量侧的基准生态相对稳定：lm-evaluation-harness（EleutherAI）是通用任务执行器，负责 MMLU-Pro、GSM8K 等几百个任务的统一加载与打分；长上下文专项由 LongBench（v1/v2） 与 RULER 覆盖（前文已述）；NIAH 类单点检索以 gkamradt 的 LLMTest_NeedleInAHaystack 等实现流传最广。推理优化研究的标准证据链由此固定下来：速度改进（吞吐/延迟曲线）+ 质量保持（PPL 与任务分 + 长程检索分）双报告，缺一不可。