模型性能压测指标
模型服务压测不应该只看“每秒多少请求”。LLM 推理有输入阶段、生成阶段、流式返回、KV Cache 和显存管理等特征，所以需要同时关注延迟、吞吐、token 分布、稳定性和资源利用率。
核心指标
| 指标 | 英文 / 缩写 | 含义 | 主要关注点 |
|---|---|---|---|
| 首 token 延迟 | Time To First Token / TTFT | 从请求发出到收到第一个输出 token 的时间 | 用户开始看到响应要等多久，交互体验最敏感 |
| token 间延迟 | Inter Token Latency / ITL | 流式输出时，相邻输出 token 之间的时间间隔 | 输出是否顺滑，是否有明显卡顿 |
| 完整请求延迟 | End-to-End Latency / E2E Latency | 从请求发出到完整响应结束的总耗时 | 用户完成一次请求的总等待时间 |
| 平均延迟 | Average Latency | 所有请求延迟的平均值 | 快速看整体水平，但容易被分布掩盖 |
| 分位延迟 | p50 / p90 / p95 / p99 Latency | 不同分位上的请求延迟 | 尾延迟和稳定性，p99 往往比平均值更重要 |
| 请求吞吐 | Request Throughput / RPS / QPS | 单位时间内完成的请求数 | 服务能处理多少请求 |
| 输出 token 吞吐 | Output Token Throughput | 单位时间生成的输出 token 数 | decode 阶段生成能力 |
| 总 token 吞吐 | Total Token Throughput | 单位时间处理的输入 + 输出 token 数 | 整体 token 处理能力 |
| 输入长度 | Input Sequence Length / ISL | 每个请求的输入 token 数 | 影响 prefill 成本和 KV Cache 占用 |
| 输出长度 | Output Sequence Length / OSL | 每个请求生成的输出 token 数 | 影响 decode 成本和请求总时长 |
| 并发数 | Concurrency | 同时处理的请求数量 | 服务容量和排队情况 |
| 请求速率 | Request Rate | 单位时间进入系统的请求数 | 模拟线上流量入口，观察是否排队或超时 |
| 成功率 | Success Rate | 成功完成请求占比 | 压测是否有效，服务是否稳定 |
| 错误率 | Error Rate | 失败请求占比 | 超时、限流、服务端异常、OOM 等问题 |
| 超时率 | Timeout Rate | 超时请求占比 | 高负载下是否出现排队或响应过慢 |
| GPU 显存占用 | GPU Memory Usage | 推理服务占用的显存 | 权重、KV Cache、运行时开销是否接近上限 |
| GPU 利用率 | GPU Utilization | GPU 计算资源利用情况 | 判断是否吃满 GPU，或瓶颈是否在 CPU / 网络 / 调度 |
| KV Cache 使用量 | KV Cache Usage | KV Cache 占用或 block 使用情况 | 长上下文、高并发下是否成为瓶颈 |
| 队列等待时间 | Queue Time | 请求进入服务后等待调度的时间 | 高并发下延迟上升是否来自排队 |
怎么看这些指标
| 场景 | 优先关注指标 | 判断方式 |
|---|---|---|
| 聊天机器人 / 助手 | TTFT、ITL、p90 / p99 延迟 | 首 token 要快，流式输出要稳定 |
| 批量生成任务 | Output Token Throughput、E2E Latency、成功率 | 更关注总吞吐和任务完成时间 |
| 长文档总结 | ISL、TTFT、GPU 显存、KV Cache | 长输入会显著增加 prefill 和显存压力 |
| 高并发在线服务 | RPS、p99 延迟、错误率、队列等待时间 | 看是否开始排队、超时或抖动 |
| 模型 / 框架对比 | TTFT、ITL、token throughput、显存占用 | 同一数据集和负载下比较才有意义 |
| 压测容量上限 | Request Rate、错误率、p99 延迟、GPU 利用率 | 找到延迟恶化或错误率上升的临界点 |
指标理解
TTFT
TTFT 主要受 prefill 阶段影响。输入越长、batch 越大、排队越严重，TTFT 往往越高。
对交互式产品来说，TTFT 很关键，因为用户并不一定关心完整回答什么时候结束，但会明显感知“什么时候开始输出”。
ITL
ITL 主要反映 decode 阶段的流式生成速度。
如果 TTFT 很低但 ITL 很高，用户会看到“很快开始输出，但后面一个字一个字蹦得很慢”。如果 ITL 抖动很大，流式输出会显得不稳定。
吞吐
LLM 压测里最好同时看请求吞吐和 token 吞吐：
- 请求吞吐高，不代表 token 吞吐高，因为每个请求的输入/输出长度可能很短。
- token 吞吐高，不代表用户体验好，因为 TTFT 和 p99 延迟可能很差。
所以压测报告里要同时写清楚请求数、输入长度、输出长度和并发条件。
p99 延迟
平均延迟容易掩盖问题。线上服务更应该关注 p90 / p95 / p99。
如果平均延迟看起来正常，但 p99 很高，说明部分用户会遇到明显卡顿，可能来自排队、批处理调度、KV Cache 紧张、显存碎片或后端抖动。
压测记录建议
每次压测至少记录这些信息：
| 类别 | 需要记录 |
|---|---|
| 模型 | 模型名称、参数量、精度、量化方式 |
| 服务 | 推理框架、版本、启动参数、是否 streaming |
| 硬件 | GPU 型号、数量、显存、CPU、内存 |
| 负载 | 并发数、请求速率、总请求数、运行时长 |
| 数据 | 输入长度分布、输出长度分布、数据集来源 |
| 结果 | TTFT、ITL、E2E latency、吞吐、错误率、显存 |
| 备注 | 是否 OOM、是否限流、是否出现明显排队或超时 |
常见误区
- 只看 QPS，不看 token 长度。
- 只看平均延迟，不看 p90 / p99。
- 不区分 prefill 和 decode 阶段。
- 不记录输入长度和输出长度，导致不同压测结果无法比较。
- 用固定并发结果代表线上真实流量，但线上更接近固定请求速率或突发流量。
- 不记录推理框架参数，后续无法复现。