📈 LLM 推理服务核心指标体系
1. 指标体系总览
LLM 推理服务与传统 API 的最大差异：响应是流式生成的，"响应时间"要拆成两段看——等待首个 token 的时间（Prefill 阶段）和逐 token 吐字的时间（Decode 阶段）。用单一"接口耗时"描述 LLM 服务会丢失一半信息。
| 指标 | 含义 | 敏感阶段 | 典型劣化原因 |
|---|---|---|---|
| TTFT（Time To First Token） | 请求发出 → 收到首个 token 的耗时 | Prefill（计算密集） | 上下文过长、并发排队、显存换页 |
| TPOT（Time Per Output Token） | 相邻两个输出 token 的间隔 | Decode（访存密集） | batch 过大、显存带宽打满、量化精度损失 |
| E2E 端到端 | TTFT + (输出token数-1) × TPOT | 全程 | 上述叠加 + 输出长度分布变化 |
| 吞吐量 | tokens/s（服务级）或 req/s | 全程 | 调度不连续、抢占重算 |
| Goodput | SLO 约束下（如 TTFT P95<2s）的最大吞吐 | 全程 | 压测只跑"能跑多少"，没跑"达标能跑多少" |
| KV Cache 命中率 | Prefix Caching 命中比例 | Prefill | system prompt 不一致、cache 被逐出 |
| 显存 / GPU 利用率 | 权重+KV Cache+激活占用；SM 活跃度 | 全程 | 容量规划不足 → OOM 或频繁抢占 |
📌 报告口径：延迟指标必须报 P50 / P95 / P99 三个分位（均值会被长尾掩盖），并附输出 token 数的均值/分布——不同模型的"输出长度"不可比，脱离长度谈 TPOT 无意义。
2. 参考目标（按硬件与场景）
| 场景 | TTFT P95 | TPOT | 说明 |
|---|---|---|---|
| 对话/问答（7B-27B，单卡或双卡） | < 1s（上下文 < 8K） | 30-80ms/token | 用户体感：首字 1 秒内、吐字接近人眼阅读速度 |
| 长文档生成（>2K token 输出） | < 3s | 50-100ms/token | 重点看 E2E 与中途卡顿（token 间隔抖动） |
| 长上下文理解（>100K 输入） | 秒级~数十秒 | — | Prefill 主导，TTFT 与上下文近似线性，需单独定 SLO |
| 批量离线推理 | 不敏感 | — | 只看总吞吐（tokens/s）与成本 |
注：以上为 2026 年主流开源模型（Qwen/Llama 系 7B-32B）在消费级~数据中心卡上的工程经验值，具体基线以本服务实测为准——参考值用于定 SLO 的起点，不用于跨硬件比较。
3. 测量方法
- 黑盒客户端埋点（推荐，最贴近用户）：记录 t0 发请求、t1 收到首个非空 delta、逐 delta 记时，E2E 在 [DONE] 收尾。SSE 解析开销（通常 <1ms/事件）可忽略但要固定实现。
- 引擎侧日志：vLLM 的 request-level 指标（queuing/prefill/decode 分段耗时）用于归因，不用作对外口径。
- 外部 APM：Grafana + Prometheus（vLLM 内置 /metrics）看 GPU 利用率、KV 占用、队列长度，与压测曲线对齐。
4. 常见测量陷阱
⚠️ 五个坑：① 未预热就测（首批请求含 JIT/显存分配，TTFT 虚高 3-10 倍）——至少 10 次请求或 60s 预热；② 单请求测试冒充并发测试（batch=1 与 batch=16 的 TPOT 完全不同）；③ 输出长度不齐就比总耗时（A 生成 200 token、B 生成 2000 token，E2E 差 10 倍不代表性能差）；④ 把 HTTP 连接建立算进 TTFT（用 keep-alive 连接池）；⑤ 只测"能跑多少并发"，不测"SLO 下能跑多少"（Goodput 才是容量结论）。