经过第 10 章的微调与对齐，模型在评测基准（Benchmark）上的得分可能很漂亮；但把它部署到生产环境后，用户实际感受到的却是“卡不卡”“等多久”“能同时服务多少人”。如果说训练阶段的评测目标是“对不对”，那么推理阶段的评测目标就是“快不快、省不省、稳不稳”。本节聚焦三个最硬的工程指标——吞吐量、延迟与显存占用，帮助你建立可复现、可落地的推理性能评估方法。
一、吞吐量（Throughput）：系统不是一个人用的
吞吐量定义为单位时间内模型服务处理并输出的 Token 数量，常用单位为 tokens/s。但在实际汇报这个数字时，你必须分清三种口径，否则对比就没有意义：
| 口径 | 含义 | 适用场景 |
|------|------|----------|
| 总吞吐（System Throughput） | 服务实例每秒输出的总 Token 数，除以总耗时 | 评估机柜/集群产能，核算成本 |
| 单用户吞吐（Per-Request） | 单个请求每秒收到多少 Token | 评估用户阅读体验是否流畅 |
| 并发吞吐 | 在固定并发数（如 10/50/100 用户）下的总吞吐 | 评估服务扩容拐点 |
关键细分：Prefill vs Decode
现代自回归模型的推理包含两个阶段：
- Prefill（首 Token 计算）：把用户输入的整段 Prompt 一次性过模型，计算并缓存 KV Cache。这个阶段是计算密集型，决定了 TTFT（见下文）。
- Decode（逐 Token 生成）：自回归地一个 Token 一个 Token 往外蹦。这个阶段是显存带宽密集型，决定了后续生成速度。
很多框架会把 Prefill 和 Decode 混在一起报一个“平均吞吐”，这在工程调优时毫无参考价值。规范的做法是分别测量：如果你的应用是长文档摘要（长输入、短输出），Prefill 效率是瓶颈；如果是聊天机器人（短输入、长输出），Decode 效率才是生命线。
二、延迟（Latency）：用户耐心是有限的
延迟衡量的是“从发出请求到拿到结果”的时间成本，需要拆解为三个子指标：
1. Time To First Token（TTFT）
从请求发起到第一个输出 Token 返回的时间。对应用户视角就是：我按下回车，多久能看到“对方正在输入……”。
- 主要瓶颈：Prefill 阶段的矩阵计算量，与输入长度成正比。输入 1K Token 和 32K Token 的 TTFT 可能相差一个数量级。
- 体验阈值：在线对话场景，TTFT 超过 500ms 就会有明显顿挫感；超过 2s，用户开始怀疑网络问题。
2. Time Between Tokens（TBT）/ Inter-Token Latency（ITL）
相邻两个输出 Token 之间的时间间隔。对应用户视角：字是不是连续、流畅地蹦出来。
- 体验阈值：人类阅读舒适区约为 50–100 ms/Token（即 10–20 tokens/s）。如果 ITL 超过 200ms，用户会明显感觉到“一顿一顿”。
- 技术瓶颈：Decode 阶段每步只生成一个 Token，且需要加载全部模型权重和 KV Cache，因此显存带宽（HBM 带宽）往往比算力（FLOPS）更先成为瓶颈。
3. 端到端延迟（E2E Latency）
E2E Latency ≈ TTFT + (输出 Token 数 × ITL)在评估报表生成、代码补全等任务时，看这个总值才有意义。
生产铁律：看 P99，别看平均值。 平均延迟很容易被低并发下的快速请求拉低。生产环境必须统计 P95、P99 长尾延迟，因为它直接决定你的告警线和 SLA。
三、显存占用（Memory Footprint）：看得见的天花板
推理时的显存占用不是“模型文件有多大”，而是服务运行时的峰值显存。它通常由四部分构成：
- 模型权重（Model Weights）
- 以 FP16/BF16 为例，每 1B 参数约占用 2 GB；INT8 量化约 1 GB；INT4 约 0.5 GB。
- 这是静态的、可预期的部分。
- KV Cache（键值缓存）
- 这是长文本推理的显存杀手。每生成一个新 Token，模型都需要把当前层的 Key 和 Value 张量缓存下来，供下一步复用。
- 粗略估算（以 Llama 2 7B 为例，batch_size=1）：
- 层数 32 × 隐藏维度 4096 × 头数相关项 × 序列长度 × 精度字节数 × 2（K+V）
- 当序列长度从 1K 拉到 32K，KV Cache 显存占用线性膨胀，很容易超过权重本身。
- 第 22 章将介绍的 PagedAttention、KV Cache 量化、滑动窗口注意力，本质上都是在压缩这部分开销。
- 激活值（Activations）
- 与 Batch Size 正相关。连续批处理（Continuous Batching）虽然提升吞吐，但也会拉高峰值激活显存。
- 框架开销（Overhead）
- CUDA Context、cuBLAS 工作区、Allocator 缓存池、PyTorch 显存预留等，通常再吃掉 2–4 GB。
显存评测实操：
不要只看 nvidia-smi 的瞬时读数，要在压测峰值时抓取 torch.cuda.max_memory_allocated() 或服务进程的显存峰值。同时记录 Batch Size 从 1 增加到 OOM（显存溢出） 的临界曲线，这就是你的服务容量上限。
四、评测方法与工具：怎么测才靠谱
手工发几条请求看响应速度是不够的。规范的推理评测需要模拟真实并发负载。
推荐工具链：
| 工具 | 特点 | 适用场景 |
|------|------|----------|
| vLLM benchmark_serving | 社区最常用，支持固定/随机输入输出长度，直接输出 TTFT、TPOT、Throughput | 通用 LLM 服务压测 |
| TensorRT-LLM Benchmarks | NVIDIA 官方脚本，针对 TensorRT-LLM 后端深度优化 | 追求极致 GPU 利用率 |
| llmperf（Anyscale） | 标准化、跨后端对比，支持 TGI、vLLM、Triton 等 | 不同框架横向对比 |
| TGI benchmark | HuggingFace 生态，适合测试文本生成推理容器 | HF 模型快速验证 |
标准评测配置建议：
- 负载分布：不要只测单点。至少覆盖三类场景：
- 短输入/短输出（聊天）；
- 短输入/长输出（创意写作）；
- 长输入/短输出（文档摘要）。
- 并发梯度：1, 4, 16, 64, 128 并发逐步加压，观察吞吐何时饱和、延迟何时陡增。
- 长度控制：固定输入/输出长度测极限性能；随机长度（按泊松分布）测真实波动。
- 温度设置：评测性能时建议
temperature=0或极小值，避免采样随机性导致结果波动。
五、吞吐、延迟、显存的“不可能三角”
在生产环境中，这三个指标相互制约，你需要根据业务场景做显式取舍：
- 低延迟优先（实时交互）：如聊天机器人、代码 Copilot。使用小 Batch Size + 流式返回（SSE），牺牲总吞吐，保证 TTFT < 300ms、ITL < 50ms。
- 高吞吐优先（离线批处理）：如报表生成、数据标注。使用 Continuous Batching + 大 Batch Size，允许单用户 ITL 增加到 200ms，换取系统总吞吐最大化。
- 低显存优先（端侧/低成本）：如消费级显卡部署。必须上 INT4/AWQ 量化 + 小上下文窗口，甚至牺牲部分精度，确保不 OOM。
工程中的典型陷阱：
- 陷阱 1：汇报总吞吐时隐瞒了并发数。单用户 20 tokens/s 和 100 并发下系统总吞吐 2000 tokens/s 是两个完全不同的概念。
- 陷阱 2：用短文本评测结果推广到长文本。KV Cache 随序列长度线性增长，长文本下显存和延迟可能断崖式恶化。
- 陷阱 3：忽略 Prefill 延迟。在 RAG 场景中，用户塞进来一篇 10K 字的文档，TTFT 可能长达 10 秒以上，体验极差。
六、小结与延伸
吞吐量、延迟、显存占用是推理落地的“铁三角”。评测时务必做到：口径清晰、并发真实、长短文本兼顾、看长尾分布而非平均值。
这些指标同时也是第 22 章（推理优化技术）和第 23 章（推理框架选型）的优化靶点：
- 量化技术（INT8/INT4/AWQ）压缩权重和 KV Cache，直接降低显存并提升有效吞吐；
- PagedAttention（vLLM）减少 KV Cache 显存碎片，支持更大 Batch Size；
- Continuous Batching 在同一条请求流水线里动态组批，在不牺牲 ITL 太多前提下提升总吞吐。
在 11.5 节中，我们将进一步讨论幻觉与鲁棒性的专项评测方法——这是另一类“测不准会出大事”的评估维度。