📚 课程目录第2章 Serving性能指标体系

2、Serving性能指标体系：QPS、TP50/TP95/TP99延迟、吞吐量、资源利用率

信用评分模型的线上Serving性能不能仅靠单一指标衡量。一个完整的指标体系需要覆盖流量承载能力、响应速度分布、系统处理总量以及资源消耗效率四个维度。本章定义核心指标的计算方式、业务含义及观测标准。

2.1 核心指标定义与对比

指标	英文全称	单位	核心关注点
QPS	Queries Per Second	次/秒	系统每秒能处理的请求数量，反映并发处理能力
TP50	50th Percentile Latency	毫秒 (ms)	半数请求的延迟低于此值，代表“典型体验”
TP95	95th Percentile Latency	毫秒 (ms)	95%请求的延迟低于此值，代表“大多数用户感受”
TP99	99th Percentile Latency	毫秒 (ms)	99%请求的延迟低于此值，代表“长尾延迟”
吞吐量	Throughput	请求/分钟或 MB/s	单位时间内成功处理的请求总量或数据量
资源利用率	Resource Utilization	百分比 (%)	CPU、内存、GPU、网络带宽的使用比例

  关键认知：QPS 与延迟是“跷跷板”关系。当 QPS 逼近系统瓶颈时，TP95/TP99 会率先急剧恶化，而 TP50 可能变化不大。因此，TP99 是比平均延迟更敏感的过载预警指标。

2.2 延迟百分位（TP50 / TP95 / TP99）详解

百分位延迟比平均值更能反映真实用户体验。平均值容易被极端值拉偏，而百分位能清晰展示延迟分布。

TP50（中位数延迟）：衡量系统在正常负载下的“基准速度”。如果 TP50 超过 100ms，用户会感到轻微卡顿。
TP95：衡量系统在一般压力下的表现。通常作为 SLA（服务等级协议）的达标线。
TP99：衡量系统的尾部延迟。TP99 过高意味着存在少量“慢请求”，可能由 GC（垃圾回收）、资源争抢或网络抖动引起。

实践建议：在信用评分场景中，建议将 TP99 延迟控制在 500ms 以内。如果 TP99 超过 1s，应优先排查模型推理耗时或特征数据库查询瓶颈。

2.3 指标关系与瓶颈定位流程

下图展示了从“用户请求”到“资源消耗”的完整链路，以及各指标在链路中的观测位置。

2.4 吞吐量与资源利用率的联动分析

吞吐量（Throughput）与 QPS 的区别在于：QPS 是瞬时速率，吞吐量是累计总量。例如“单台机器每分钟处理 6000 次评分请求”即为吞吐量。

资源利用率是判断系统是否“健康”的关键。当资源利用率超过 70% 时，延迟通常会开始非线性增长。

避坑指南：不要只看 CPU 利用率。在 GPU 推理场景中，GPU 显存带宽利用率往往先于 CPU 达到瓶颈。同时，内存利用率过高会导致频繁 GC，直接推高 TP99。

2.5 指标体系速查表

场景	首要关注指标	次要关注指标	典型阈值
日常平稳运行	TP50	CPU 利用率	TP50 < 50ms
大促/高峰流量	QPS + TP99	GPU 利用率	TP99 < 500ms
容量规划	吞吐量	内存利用率	资源利用率 < 60%
异常排查	TP99 + 错误率	网络 IO	TP99 突增 > 2x 基线

2.6 指标采集与计算示例

以下是一个简单的 Prometheus 指标采集与 TP99 计算伪代码示例：

# 定义 Histogram 指标（单位：毫秒）
model_score_duration_seconds_bucket{le="10"}  1200
model_score_duration_seconds_bucket{le="50"}  4500
model_score_duration_seconds_bucket{le="100"} 6200
model_score_duration_seconds_bucket{le="500"} 7900
model_score_duration_seconds_bucket{le="+Inf"} 8000

# TP99 计算逻辑（PromQL 近似）
histogram_quantile(0.99,
  sum(rate(model_score_duration_seconds_bucket[5m])) by (le)
)
# 结果：约 420ms，表示 99% 的请求在 420ms 内完成

  总结：建立 Serving 性能指标体系的核心是“分层观测”——用 QPS 看流量，用 TP50/TP95/TP99 看质量，用吞吐量看产能，用资源利用率看成本。四者缺一不可。