外观
基准数据与工具档案
推理加速的所有结论，最终都要被一组数字验证："换 FP8 提速多少"、"H200 比 H100 decode 快多少倍"、"vLLM 与 TensorRT-LLM 谁更强"。本页整理截至 2026-08 公开可见的基准榜单与代表性实测数据，配套主流 benchmark 工具。它是硬件基础速查的"实测对照"、延迟、吞吐与并发与推理基准测试实践的"数据底座"，与引擎对比互为印证。
时效声明
本页所有数据截止 2026-08，引用自 MLPerf 官方结果、各引擎 README/blog、厂商白皮书与公开论文。基准数据强依赖具体配置（batch、序列长度、量化、KV cache 上限、引擎版本、硬件 BIOS），不同来源数字不可直接比较；引用时务必连同配置一起读。新版本发布后请以官方最新结果为准，本页仅作"量级与相对关系"的参考。
使用建议
本页分四块：榜单看"SOTA 在哪"、实测数据表看"具体卡上具体模型多快"、引擎对比看"该选谁"、工具速查看"自己怎么测"。先看榜单建立全局观，再按你的目标模型/硬件查实测数据，最后挑工具自己复现一跑。
一、主流基准榜单
1.1 MLPerf Inference
MLPerf Inference 是 MLCommons 维护、业界最权威的推理基准，覆盖数据中心（Datacenter）与边缘（Edge）两套。LLM 部分从 Inference 4.0（2024）起成为正式 benchmark。
| 版本 | 发布时间 | LLM 测试模型 | 关键场景 |
|---|---|---|---|
| Inference 4.0 | 2024-04 | GPT-J 6B、Llama-2-70B | 单流与多流延迟、Offline 吞吐 |
| Inference 4.1 | 2024-09 | GPT-J 6B、Llama-2-70B | 加 Server 场景（多流稳定 QPS） |
| Inference 5.0 | 2025-07 | Llama-2-70B、Llama-3.1-405B（FP8） | 405B 首次进榜，FP8 大规模亮相 |
三种场景：
- SingleStream：单请求 TTFT/TPOT，延迟视角；
- MultiStream：少量并发多流，延迟 + 轻度吞吐；
- Server：在固定 SLA（如 P99 TTFT < 2s）下的最大稳定 QPS，最贴近线上服务；
- Offline：批量模式下的纯吞吐 tokens/s。
怎么读 MLPerf 结果
只比同版本、同场景、同模型——跨版本因为基准规则调整不可直接比较。NVIDIA 通常在 H100/H200/B200 上提交全场最优（FP8 + TensorRT-LLM），是各硬件性能上限的"金标尺"。开源引擎（vLLM/SGLang）结果多来自社区提交，量级上接近但不一定最优。详见推理基准测试实践。
1.2 Hugging Face Open LLM Leaderboard
Hugging Face Open LLM Leaderboard v2 是模型质量（不是推理速度）的主榜单，覆盖推理、代码、数学、工具使用等多任务。它是选模型的第一参考——"这个模型能力够不够"由它定，"跑得多快"由本页其他表定。详见推理基准测试实践。
不要把质量榜与性能榜混
Open LLM Leaderboard 测模型质量（准确率、pass@k）；MLPerf 测推理性能（延迟、吞吐）。一个模型可以质量高但推理慢（405B FP16）、也可以推理快但质量低（1B INT4）。两者必须同时看。
1.3 各引擎官方 benchmark
| 引擎 | 官方 benchmark 入口 | 测什么 |
|---|---|---|
| vLLM | benchmark suite | online serving throughput、offline inference、KV cache util、prefix caching |
| TensorRT-LLM | Benchmark repo | microbenchmark、end-to-end latency、throughput |
| SGLang | sglang bench | structured generation、prefix cache hit、multi-round |
| TGI | benchmark script | latency、throughput、memory |
各引擎 README 通常带一个"在某卡上某模型 tokens/s"的数字，是同类配置最快复现入口。但配置差异巨大，别拿 vLLM blog 的数字与 TensorRT-LLM blog 的数字直接比——batch、序列长度、量化精度、引擎版本都不同。详见引擎对比与推理基准测试实践。
二、各 GPU 上代表性 LLM 推理数据
下表汇总公开 benchmark 的代表性数据，所有数字以单卡 SXM 版为准，配置尽量对齐（batch、序列长度相同）。不同来源差异在 10–30% 量级属正常，只看量级与相对关系，不当作精确值。
2.1 Llama-3-8B 推理吞吐（tokens/s，单卡）
| GPU | 精度 | decode 吞吐（batch=1） | 多流吞吐（batch=32） | 数据来源 |
|---|---|---|---|---|
| A100 80GB | FP16 | ~50 tok/s | ~1800 tok/s | vLLM blog |
| A100 80GB | INT8（W8A8） | ~70 tok/s | ~2600 tok/s | TensorRT-LLM benchmark |
| H100 SXM 80GB | FP16 | ~110 tok/s | ~3800 tok/s | vLLM blog |
| H100 SXM 80GB | FP8 | ~160 tok/s | ~5500 tok/s | NVIDIA LLM benchmark |
| H200 141GB | FP8 | ~220 tok/s | ~7800 tok/s | NVIDIA MLPerf 5.0 |
| B200 | FP4 | ~400 tok/s | ~14000 tok/s | NVIDIA Blackwell LLM paper |
| RTX 4090 | INT4（AWQ） | ~80 tok/s | ~1200 tok/s | llama.cpp 社区 |
| MI300X | FP8 | ~180 tok/s | ~6200 tok/s | AMD MI300X benchmark |
为什么 B200 数据这么高
B200 的 FP4 Tensor Core 算力是 H100 FP8 的 ~9 倍（稀疏），HBM3e 带宽 8 TB/s 是 H100 的 2.4 倍——而 Llama-3-8B 在 B200 上完全带宽受限（decode 是 memory-bound），所以吞吐提升 ≈ 带宽比 × 精度压缩比。FP4 把权重体积压一半，单 token 访存量减半，又翻倍。详见硬件基础速查与Roofline 模型。
2.2 Llama-3-70B 推理吞吐（tokens/s，单卡）
70B 模型 FP16 需 ~140 GB，单卡 80 GB 放不下，必须量化或 TP。下表是单卡 + INT4 量化或 TP=2 的数据。
| GPU | 精度 | 部署方式 | decode 吞吐（batch=1） | 多流吞吐（batch=32） |
|---|---|---|---|---|
| A100 80GB | INT4（AWQ） | 单卡 | ~18 tok/s | ~700 tok/s |
| H100 SXM 80GB | INT4（AWQ） | 单卡 | ~40 tok/s | ~1500 tok/s |
| H100 SXM 80GB ×2 | FP8 | TP=2 | ~75 tok/s | ~2800 tok/s |
| H200 141GB | INT4 | 单卡 | ~55 tok/s | ~2100 tok/s |
| H200 141GB | FP8 | 单卡 | ~35 tok/s | ~1500 tok/s |
| B200 | FP4 | 单卡 | ~120 tok/s | ~4500 tok/s |
| MI300X | FP8 | 单卡 | ~50 tok/s | ~2000 tok/s |
70B 单卡 vs 双卡的关键差异
70B FP16（140 GB）单卡 80 GB 装不下，必须 INT4 量化（~35 GB）或 TP=2（每卡 70 GB）。单卡 INT4 吞吐高但精度损失大；双卡 FP8 精度高但需要 NVLink。这是 70B 部署的核心权衡，详见权重量化与混合精度与分布式推理。
2.3 Qwen2.5-72B 在各 GPU 上的延迟（TTFT / TPOT）
输入 1024 token prompt、输出 128 token，单请求。
| GPU | 精度 | TTFT (ms) | TPOT (ms) | E2E (s) |
|---|---|---|---|---|
| H100 SXM 80GB | FP8（单卡，INT4 权重） | 280 | 28 | 3.86 |
| H100 SXM 80GB ×2 | FP8（TP=2） | 180 | 18 | 2.48 |
| H200 141GB | FP8（单卡） | 220 | 22 | 3.04 |
| B200 | FP4（单卡） | 120 | 12 | 1.66 |
| RTX 4090 | INT4（AWQ） | 480 | 48 | 6.62 |
2.4 INT8 vs INT4 vs FP8 对比（Llama-3-70B，H100 SXM）
| 精度 | 权重体积 | 单卡显存（含 KV cache） | decode 吞吐（batch=1） | 质量损失 |
|---|---|---|---|---|
| FP16（baseline） | 140 GB | 不装 | — | 0 |
| FP8（W8A8） | 70 GB | ~80 GB（刚好） | ~30 tok/s | <1% |
| INT8（W8A8 SmoothQuant） | 70 GB | ~80 GB | ~32 tok/s | 1–2% |
| INT4（AWQ，weight-only） | 35 GB | ~45 GB | ~40 tok/s | 2–4% |
| INT4（GPTQ） | 35 GB | ~45 GB | ~38 tok/s | 2–4% |
怎么选精度
H100/H200 优先 FP8——硬件原生、精度损失最小；A100/RTX 4090 选 INT4（AWQ/GPTQ）——只能 weight-only、但显存与吞吐优势最大；精度敏感场景用 FP8 或保留关键层 FP16（混合精度）。详见模型量化基础与权重量化与混合精度。
三、各引擎对比基准
同一硬件、同一模型、不同引擎的横向对比最能说明"该选谁"。下表汇总社区在 H100 SXM 80GB 上对 Llama-3-70B INT4 量化的代表性结果。
| 引擎 | 版本 | 精度 | 多流吞吐（batch=32） | TTFT (ms) | 备注 |
|---|---|---|---|---|---|
| vLLM | 0.6.x | INT4（AWQ） | ~1450 tok/s | 240 | PagedAttention + continuous batching |
| TensorRT-LLM | 0.13+ | INT4 | ~1800 tok/s | 200 | in-flight batching + Planner |
| SGLang | 0.3.x | INT4（AWQ） | ~1500 tok/s | 230 | RadixAttention 前缀缓存强 |
| TGI | 2.x | INT4（AWQ） | ~1300 tok/s | 260 | 与 vLLM 量级相近 |
引擎对比的常见陷阱
3.1 不同模型规模下的引擎选择
| 模型规模 | 单卡可装 | 推荐引擎 | 关键优化 |
|---|---|---|---|
| 7B–8B FP16 | 16 GB，单卡足 | vLLM | continuous batching + PagedAttention |
| 13B–14B INT4 | ~8 GB，单卡 | vLLM / llama.cpp | 端侧 INT4 |
| 30B–34B INT4 | ~18 GB，单卡 | vLLM / SGLang | prefix caching |
| 70B INT4 | ~40 GB，单卡 | vLLM / TensorRT-LLM | FP8 优先（Hopper） |
| 70B FP8 | ~70 GB，单卡 H200 | TensorRT-LLM | in-flight batching |
| 70B FP16 / 405B INT4 | 多卡 TP | TensorRT-LLM / vLLM | NVLink + TP=2/4/8 |
| 405B FP8 | 8×H200 NVL / GB200 | TensorRT-LLM | NVLink Switch 全互联 |
四、benchmark 工具速查
4.1 引擎自带 benchmark
| 工具 | 引擎 | 测什么 | 入口 |
|---|---|---|---|
benchmark_throughput.py | vLLM | offline 吞吐 | vllm/benchmarks/ |
benchmark_serving.py | vLLM | online serving 延迟与吞吐 | vllm/benchmarks/ |
benchmark_latency.py | vLLM | 单流延迟 | vllm/benchmarks/ |
cpp/test/perf | TensorRT-LLM | microbenchmark | TensorRT-LLM/benchmarks/ |
sglang.bench | SGLang | 一键多场景压测 | sglang/benchmark/ |
text-generation-benchmark | TGI | TGI 服务端压测 | text-generation-inference/benchmark/ |
4.2 通用 benchmark 工具
| 工具 | 用途 | 入口 |
|---|---|---|
| MLPerf Inference | 业界标准基准 | mlcommons.org |
| lm-evaluation-harness | 模型质量评测（Open LLM Leaderboard 用） | EleutherAI |
| vLLM benchmark suite | LLM 服务压测 | vllm-project |
| SGLang bench | 结构化生成压测 | sglang-project |
| promptbench | 多模型多任务统一评测 | Microsoft |
| opencompass | 上海 AI Lab 综合评测框架 | open-compass |
4.3 性能剖析工具
| 工具 | 测什么 | 用法 |
|---|---|---|
| Nsight Systems | GPU 时间线、kernel 占比、CPU-GPU 异步 | nsys profile python script.py |
| Nsight Compute | 单 kernel 算力/带宽/占用率剖析 | ncu --set full python script.py |
| PyTorch Profiler | PyTorch 算子级耗时与显存 | torch.profiler.profile |
| Triton tutorial | 自定义 kernel 性能调优 | OpenAI Triton |
Nsight Systems 是排查推理瓶颈的第一工具
80% 的推理性能问题能被 nsys profile 一次性看出："CPU 在等 GPU"、"kernel launch 间隙太大"、"某算子占 60% 时间"——全在时间线上一目了然。详见GPU 体系结构与优化与调参与性能调优。
4.4 自己测基准的最小配置
跑一个可比较的 LLM 推理 benchmark，至少要固定以下变量（详见推理基准测试实践）：
| 变量 | 示例值 | 为什么重要 |
|---|---|---|
| 硬件 | H100 SXM 80GB | 算力与带宽的硬上限 |
| 模型 | Llama-3-70B | 参数量决定访存量 |
| 精度 | INT4 AWQ | 显存与算力同时影响 |
| batch size | 1 / 32 | 单流延迟 vs 多流吞吐 |
| 输入长度 | 1024 token | prefill 计算量 |
| 输出长度 | 128 token | decode 重复次数 |
| 引擎版本 | vLLM 0.6.3 | 同引擎跨版本差 20% |
| KV cache 上限 | 90% 显存 | 影响 batch 上限 |
| prefix caching | 关 | 否则相同 prompt 会命中缓存 |
五、基准数据的常见误读
数字背后的五个陷阱
- 峰值 ≠ 实测：FP8 1979 TFLOPS 是稀疏峰值，LLM decode 实际跑到 30–50% 已是优等生；
- 单卡 ≠ 多卡线性：TP=2 不会让吞吐翻倍，AllReduce 开销与负载均衡会让加速比停在 1.6–1.8×；
- batch=1 与 batch=32 不是一回事：前者 memory-bound、后者 compute-bound，结论可能相反；
- prompt 分布影响巨大：相同长度但不同 token 分布的 prompt，prefill 时间差可达 2×（长重复 token 命中缓存）；
- 冷启动 ≠ 稳态：引擎预热后吞吐通常升 10–20%，benchmark 必须先跑 warmup。