08. 吞吐、时延、并发、TTFT、TPS 这些指标应该怎么理解？
整理吞吐、时延、并发、TTFT、TPS 等推理指标的理解方式。
简单回答
吞吐（Throughput）是系统单位时间处理的请求数或生成的 token 数。时延（Latency）是单个请求从提交到完成的总时间。并发（Concurrency）是系统同时处理的请求数。TTFT（Time To First Token）是用户提交请求到收到第一个 token 的时间，反映 Prefill 速度。TPS（Tokens Per Second）是每秒生成的 token 数，可以按单请求算也可以按系统总量算。这些指标之间存在 trade-off——通常提升吞吐要牺牲一些延迟，反之亦然。
详细解释
各指标的精确含义
吞吐量（Throughput） 衡量系统的处理能力。通常有两种口径：请求吞吐量（QPS, Queries Per Second）——每秒完成多少个请求；Token 吞吐量——每秒生成多少个 token（所有请求合计）。Token 吞吐量更能反映 GPU 的利用效率，因为不同请求的输出长度差异很大。
时延（Latency） 衡量用户的等待时间。通常关注几个分位数：P50（中位数）、P90、P99。P50 反映典型体验，P99 反映最差体验。大模型推理的延迟分布通常有很长的尾部（tail latency），P99 可能比 P50 大好几倍。
时延可以进一步分解：TTFT + 生成时间。对于 streaming 输出的场景，用户在 TTFT 之后就开始看到内容了，所以 TTFT 对用户体验的影响最直接。
TTFT（Time To First Token） 主要由 Prefill 阶段决定。Prompt 越长，Prefill 计算量越大，TTFT 越高。在 batch 负载下，排队等待也会增加 TTFT。TTFT 是用户感知最敏感的指标——如果提交请求后等了几秒还没开始看到回复，用户体验就很差。
TPS（Tokens Per Second） 有两个维度。per-request TPS 是单个请求每秒生成多少 token，直接影响用户"看文字出现的速度"。人类阅读速度大约是每秒 3~5 个 token，所以 per-request TPS 只要不低于这个值，用户体验就不会明显卡顿。system TPS 是整个系统每秒生成的 token 总数，衡量系统总处理能力。
并发数（Concurrency） 是系统同时处理的请求数量。并发数受限于显存（主要是 KV Cache 的显存占用）——每个并发请求都需要一份 KV Cache，显存用完了就不能再接新请求。提高并发数的手段包括 KV Cache 量化、PagedAttention 提升显存利用率、更短的上下文长度等。
指标之间的 Trade-off
吞吐量和延迟通常是反向的。增大 batch size 可以提升吞吐量（GPU 利用率更高），但每个请求的延迟会增加（因为每步的计算量变大了）。极端情况下 batch size = 1 延迟最低但吞吐量也最低。
TTFT 和系统吞吐量也有冲突。如果系统满负荷运行，新请求需要排队，TTFT 会增加。要保证低 TTFT，系统需要留有余量（不打满负载），但这意味着吞吐量没有拉满。
实际部署中需要根据业务需求确定优化目标。对话类应用（实时聊天）TTFT 和 per-request TPS 最重要——用户在等，需要快速开始响应。批处理类应用（离线批量生成）吞吐量最重要——用户不在等，要尽量跑满 GPU。API 服务通常需要在吞吐量和 P99 延迟之间找平衡——SLA 要求 P99 延迟不超过某个值，在此约束下最大化吞吐量。
怎么衡量和测试
用 benchmark 工具（如 vLLM 自带的 benchmarking 工具、genai-perf、LLMPerf）做负载测试。逐步增大并发数，观察吞吐量和各分位延迟的变化曲线——通常吞吐量先线性增长然后趋于平稳，延迟先平稳然后急剧上升。"拐点"就是系统的最大健康负载。
测试时要注意用真实或接近真实的 Prompt 长度分布和输出长度分布。如果用固定长度的合成 Prompt 测试，结果可能和真实场景差异很大。
面试时可以这样答
这些指标各自衡量不同维度。吞吐量衡量系统处理能力，通常用每秒生成的 token 总数。时延衡量单个请求的等待时间，要看分位数特别是 P99。TTFT 是用户提交到看到第一个 token 的时间，主要由 Prefill 和排队决定，是用户体验最敏感的指标。TPS 是每秒 token 数，分单请求和系统两个维度。并发数受显存约束。
关键要理解它们之间的 trade-off。增大 batch 能提升吞吐但增加延迟。要保证低 TTFT 就不能把负载打满。实际部署要根据业务需求确定优先级——对话应用优先 TTFT 和 per-request TPS，批处理优先吞吐量，API 服务在 P99 延迟约束下最大化吞吐。
测试时要用接近真实的输入输出长度分布，别用固定长度的合成数据测——结果会有很大偏差。
常见追问
- P99 延迟很高通常是什么原因导致的？
- 你在实际项目中是怎么做性能测试的？
- 怎么在吞吐量和 TTFT 之间找平衡点？