3. 推理延迟的度量标准：P50/P99延迟、吞吐量、资源消耗、端到端延迟拆解

在信用评分低延迟推理链路中，度量标准是衡量系统性能与稳定性的核心依据。仅关注单一指标（如平均延迟）往往掩盖长尾请求的恶化，导致生产环境突发超时。本节从四个维度拆解延迟度量体系，并给出端到端延迟的组件级分解方法。

3.1 核心延迟指标：P50、P90、P99

百分位延迟（Percentile Latency）比平均值更能反映真实用户体验。信用评分场景通常要求 P99 延迟 < 100ms，否则可能影响实时审批通过率。

3.2 吞吐量与资源消耗

吞吐量（Throughput）通常以 QPS（Queries Per Second） 或 TPS（Transactions Per Second） 衡量。资源消耗则关注 CPU、内存、GPU（若使用深度学习模型）及网络带宽。

• 吞吐量 vs 延迟的权衡： 当 QPS 超过系统瓶颈时，延迟会急剧上升（拐点效应）。信用评分系统需在压测中找出 安全水位线（通常为最大 QPS 的 70%）。
• 资源消耗关键指标：
  • CPU 利用率（%）：避免持续 > 80%，防止 GC 或调度抖动。
  • 内存占用（GB）：关注堆外内存与模型加载后的常驻内存。
  • GPU 显存（MB）：若使用 Transformer 模型，需监控显存碎片。
  • 网络 I/O（MB/s）：特征向量传输与结果回传的带宽瓶颈。

3.3 端到端延迟拆解

一次信用评分推理请求的完整生命周期可拆解为 5 个阶段。只有逐段测量才能定位瓶颈。

3.4 度量工具与采集策略

生产环境中推荐使用 Prometheus + Grafana 采集百分位延迟，并配合 OpenTelemetry 实现分布式追踪。关键配置如下：

# Prometheus 直方图配置示例（Go 客户端）
histogram := prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "credit_score_inference_latency_seconds",
        Help:    "Inference latency in seconds.",
        Buckets: []float64{0.01, 0.025, 0.05, 0.075, 0.1, 0.2, 0.5},
    },
    []string{"model_version", "stage"},
)
// 记录每个阶段的耗时
histogram.WithLabelValues("v2.3", "feature_engineering").Observe(0.032)
histogram.WithLabelValues("v2.3", "model_inference").Observe(0.048)

3.5 延迟度量标准总结