1. 课程导入与性能度量
在 GPU 推理与批处理服务中，几乎所有优化决策最终都会落到两个数字上：吞吐量和延迟。它们不是两个独立的指标，而是一对相互拉扯的约束。理解这对约束的定义、度量方式与取舍关系，是后续所有调优工作的起点。
1.1 吞吐量与延迟的定义
吞吐量（Throughput）指单位时间内系统成功完成的请求数量，常用单位是 requests/s 或 tokens/s。它衡量的是"产能"：在稳定负载下，GPU 每秒能处理多少条推理请求、生成多少个 token。
延迟（Latency）指单个请求从进入系统到返回结果所经历的时间，单位通常是毫秒（ms）。它衡量的是"响应速度"：用户发出请求后要等多久才能拿到答案。
在批处理场景中，延迟需要进一步细分。以一次 LLM 推理为例，端到端延迟可拆为：
- 排队延迟：请求在调度队列中等待被组批的时间；
- 预填充延迟（Prefill）：处理输入 prompt、计算 KV Cache 的时间；
- 解码延迟（Decode）：逐 token 生成输出的时间，通常用 TPOT（Time Per Output Token）或 ITL（Inter-Token Latency）衡量；
- 首 token 延迟（TTFT）：从请求到达到生成第一个 token 的时间，是交互式应用最敏感的指标。
因此，讨论"延迟"时必须明确是 TTFT、TPOT 还是端到端 P50/P99，否则优化目标会失焦。
1.2 为什么需要 P99 而不只是平均值
平均值会掩盖长尾。假设 100 个请求中 95 个耗时 40 ms、5 个耗时 800 ms，平均延迟约 78 ms，看起来尚可；但 P99 延迟接近 800 ms，意味着每 100 个用户就有 1 个经历近 1 秒的等待。在线服务通常以 P99 或 P95 作为 SLA 约束，因为用户体验由最慢的那部分请求决定。
与之配套的还有 QPS（Queries Per Second），它是吞吐量在请求维度上的表达。当系统同时报告 QPS 和 P99 时，才能判断"高吞吐是否以牺牲尾部延迟为代价"。
1.3 吞吐与延迟的平衡关系
GPU 的核心优势是并行。增大批大小（batch size）能让更多请求共享同一次权重读取和矩阵计算，从而提升吞吐；但批越大，单个请求等待组批的时间越长，且共享计算资源被摊薄，延迟随之上升。这就是经典的吞吐—延迟权衡曲线：
- 小批量：延迟低、吞吐低，GPU 利用率不足；
- 大批量：吞吐高、延迟高，可能突破 P99 约束；
- 平衡点：在满足延迟 SLA 的前提下，把吞吐推到最高。
平衡优化的目标可以形式化为：在 P99 延迟 ≤ 目标值（如 500 ms）的约束下，最大化 QPS。这是一个带约束的优化问题，而不是单纯追求某一项指标。
1.4 度量指标速查
| 指标 | 含义 | 典型关注场景 |
|---|---|---|
| QPS | 每秒完成请求数 | 容量规划、吞吐目标 |
| TTFT | 首 token 延迟 | 交互式对话、流式输出 |
| TPOT / ITL | 每 token 生成时间 | 长文本生成流畅度 |
| P50 / P95 / P99 | 延迟分位数 | SLA 约束、长尾分析 |
| GPU 利用率 | SM / 显存带宽占用 | 判断是否受算力或带宽限制 |
1.5 平衡优化的整体学习路径
本课程后续将围绕"如何找到并守住平衡点"展开，路径大致分为四层：
- 度量层：建立可信的压测与监控，明确 QPS、TTFT、TPOT、P99 的采集口径；
- 机制层：理解批处理、连续批处理（continuous batching）、KV Cache、显存带宽与算力瓶颈的相互作用；
- 调优层：通过批大小、并发上限、调度策略、量化与并行方式调整吞吐—延迟曲线；
- 验证层：在 SLA 约束下回归测试，确认优化没有把长尾延迟推高。
在进入具体调优之前，先建立一套可复现的度量方法：固定请求分布、固定输入输出长度、固定测量窗口，分别记录不同批大小下的 QPS 与 P99。只有数据口径一致，后续的每一次参数调整才有可比性，平衡点也才能被稳定地找到并守住。