多租户隔离与权限下推：企业级智能问答系统的安全边界设计
2026/10/10 7:57:21
大模型推理必懂指标全解析：SLO、TBT、MFU、Goodput 到底是什么？
在做大模型推理优化、性能评测或面试时，我们经常会听到这些词：SLO、TBT（TPOT）、MFU、Goodput。很多人把它们和普通的“吞吐量”“延迟”混为一谈，结果优化方向完全跑偏。
这篇博客用通俗语言 + 具体例子，把这些核心概念讲清楚，并补充相关指标，帮你建立完整的推理性能认知体系。
1. SLO（Service Level Objectives）—— 服务等级目标
定义：SLO 是服务提供方对用户承诺的质量目标，通常用延迟、可用性等指标来衡量。
在大模型推理场景中，最常见的两个 SLO 是：
- TTFT ≤ X ms（Time To First Token，首 token 延迟）
- TBT / TPOT ≤ Y ms（后续每个 token 的平均间隔）
举例说明：
假设某聊天机器人承诺：
“95% 的请求，首 token 必须在 500ms 内返回，后续每个 token 间隔不超过 50ms。”
这就是两个具体的 SLO。
如果系统实际测出来 P95 TTFT = 800ms，那即使平均吞吐量再高，也算没有满足 SLO。
为什么重要？
用户真正在意的是“体感速度”，而不是你每秒能处理多少请求。SLO 是连接“技术指标”和“用户体验”的桥梁。
2. TBT / TPOT（Time Between Tokens / Time Per Output Token）
定义：从第二个 token 开始，每生成一个新 token 所花费的平均时间。
- TBT（Time Between Tokens）：token 与 token 之间的时间间隔
- TPOT（Time Per Output Token）：每个输出 token 的平均耗时（本质相同）
举例：
用户输入一段话后，模型开始流式输出：
- 第 1 个 token 在 300ms 后出现（这是 TTFT）
- 之后每隔 40ms 出现一个新 token
那么 TBT / TPOT ≈ 40ms。
注意：
- Prefill 阶段主要影响 TTFT
- Decode 阶段主要影响 TBT
- 很多人只看“每秒生成多少 token”，却忽略了 TBT 是否稳定。TBT 抖动大会让用户感觉“卡顿”。
3. MFU（Model FLOPs Utilization）—— 模型算力利用率
定义：实际使用的浮点运算量 ÷ 硬件理论峰值浮点运算量。
公式简化理解：
MFU=实际有效 FLOPs硬件峰值 FLOPs \text{MFU} = \frac{\text{实际有效 FLOPs}}{\text{硬件峰值 FLOPs}}MFU=硬件峰值FLOPs实际有效FLOPs
举例：
一块 H100 的理论峰值算力约为 1979 TFLOPS（FP16）。
如果模型实际只跑出了 600 TFLOPS 的有效计算，那么：
MFU≈6001979≈30.3% \text{MFU} ≈ \frac{600}{1979} ≈ 30.3\%MFU≈1979600≈30.3%
为什么重要？
- Prefill 阶段是计算密集型，追求高 MFU
- Decode 阶段是访存密集型，MFU 通常很低（很多时候只有 5%~15%）
- 单纯追求高 MFU 而不管延迟，往往会导致 TBT 变差
常见误区：有人看到 Decode 阶段 MFU 只有 10%，就拼命加大 batch size，结果 TBT 从 30ms 飙到 80ms，用户体验直接崩盘。
4. Goodput —— 有效吞吐量（最重要却最容易被忽略）
定义：在满足所有 SLO 约束的前提下，系统单位时间内真正成功处理的请求数（或 token 数）。
对比普通 Throughput：
- Throughput（吞吐量）：不管延迟高低，每秒处理了多少请求
- Goodput（有效吞吐量）：每秒处理了多少符合 SLO的请求
举例对比：
假设系统有两种配置：
| 配置 | 每秒处理请求数 | 满足 SLO 的比例 | Goodput |
|---|---|---|---|
| 配置 A | 100 请求/秒 | 100% | 100 |
| 配置 B | 180 请求/秒 | 50% | 90 |
虽然配置 B 的原始吞吐量更高，但 Goodput 反而更低。用户会觉得系统“有时候很快，有时候很卡”，体验更差。
这就是为什么 DistServe、Mooncake 等系统都把优化目标定为最大化 Goodput，而不是单纯的 Throughput。
5. 相关重要概念补充
| 概念 | 全称 | 简单解释 | 主要影响阶段 |
|---|---|---|---|
| TTFT | Time To First Token | 从发请求到收到第一个 token 的时间 | Prefill |
| TBT / TPOT | Time Between / Per Output Token | 后续每个 token 的平均间隔 | Decode |
| E2E Latency | End-to-End Latency | 整个请求从发到收完的总时间 | 全程 |
| Throughput | 吞吐量 | 单位时间处理的请求数或 token 数 | 全程 |
| Goodput | 有效吞吐量 | 满足 SLO 的吞吐量 | 全程 |
| MFU | Model FLOPs Utilization | 算力实际利用率 | 主要 Prefill |
| MBU | Memory Bandwidth Utilization | 显存带宽利用率 | 主要 Decode |
| Batch Size | 批大小 | 同时处理的请求数量 | 全程 |
| SLO Attainment | SLO 达成率 | 满足 SLO 的请求占比 | 全程 |
6. 一个完整例子串起来理解
场景：在线客服机器人，承诺：
- TTFT ≤ 400ms（P95）
- TBT ≤ 50ms（P95）
现在有两种优化方案：
方案 1：激进加大 batch
- 平均 Throughput = 120 请求/秒
- P95 TTFT = 650ms（超标）
- P95 TBT = 45ms
- 满足 SLO 的比例只有 60%
- Goodput ≈ 72 请求/秒
- MFU 很高（因为 batch 大）
方案 2：PD 分离 + 合理 batch
- 平均 Throughput = 95 请求/秒
- P95 TTFT = 320ms
- P95 TBT = 38ms
- 满足 SLO 的比例 = 98%
- Goodput ≈ 93 请求/秒
- MFU 稍低，但用户体验明显更好
结论：方案 2 的 Goodput 更高，才是真正更好的系统。
7. 总结：这些指标之间的关系
- SLO是目标（用户体验的底线）
- TTFT和TBT是衡量是否满足 SLO 的核心延迟指标
- MFU反映算力有没有被浪费（主要看 Prefill）
- Throughput是“看起来很美”的原始能力
- Goodput才是“真正有用”的最终目标
一句话记住：
好的推理系统，不是跑得最快的，而是在承诺的延迟范围内，能稳定服务最多用户的系统。
理解了这些概念，你在看论文（DistServe、Mooncake、vLLM 等）、做性能优化、写技术方案或面试时，就会站在更高的维度思考问题。
希望这篇博客能帮你把这些“黑话”彻底搞懂！
后记
2026年10月9日于上海，在grok辅助下完成。