4. 性能度量体系
在金融推理系统中，平均延迟几乎不具备决策价值。一笔交易撮合请求的P99从80ms恶化到300ms，均值可能只从35ms升到42ms，但业务侧已经出现大量超时拒单。因此，本章建立一套可落地的性能度量体系：用延迟直方图刻画分布，用分位数锁定尾部，用吞吐量、并发度、错误率和资源利用率描述系统状态，最后用端到端追踪把指标串成因果链。
核心原理：为什么必须看分布而非均值
延迟是典型的右偏分布。多数请求很快，少数请求极慢，均值会被大量快请求“稀释”，掩盖尾部风险。金融场景中，P95/P99/P999才是SLA与风控的核心。分位数计算的关键在于：必须基于直方图桶或精确采样，而非仅保留均值。常用两种方式：
- 固定桶直方图：如Prometheus的
le桶，内存小、可聚合，但桶边界外精度有限。 - 指数桶/对数桶：适合跨数量级延迟，如1ms~10s，金融推理常用。
- HDR Histogram：高精度、可合并，适合单机精细分析。
分位数不可直接对多实例的P99求平均，正确做法是合并直方图后重新计算，或使用支持聚合的摘要结构。
方法流程：七类指标的采集与关联
建议按以下顺序建立度量闭环：
- 埋点：在请求入口、模型推理前后、下游调用处打时间戳。
- 直方图：按接口、模型版本、租户维度记录延迟桶。
- 分位数：定时从直方图计算P50/P95/P99/P999。
- 吞吐与并发：QPS、在途请求数、队列深度。
- 错误率：区分超时、限流、模型异常、下游失败。
- 资源利用率：GPU利用率、显存、CPU、网络、批处理大小。
- 端到端追踪：用TraceID串联网关、预处理、推理、后处理。
关键原则：分位数回答“多慢”，吞吐量回答“多少”，并发度回答“堵在哪”，错误率回答“坏没坏”，资源利用率回答“为什么”，追踪回答“哪一段”。六者缺一不可。
案例场景：推理服务P99劣化的定位
某量化推理服务P99从120ms升至450ms，但GPU利用率仅55%。按体系排查：
| 指标 | 观测值 | 判断 |
|---|---|---|
| P50延迟 | 45ms | 正常 |
| P99延迟 | 450ms | 尾部劣化 |
| QPS | 稳定 | 非流量突增 |
| 并发度 | 从20升至80 | 排队加剧 |
| GPU利用率 | 55% | 未饱和，存在等待 |
| 错误率 | 0.3%超时 | 已影响业务 |
进一步用端到端追踪发现：预处理阶段因Python GIL争用耗时从5ms升至90ms，导致请求在推理前排队。GPU并非瓶颈，真正瓶颈在CPU侧预处理。若只看GPU利用率，会误判为“资源充足”。
trace_id=abc123
gateway 2ms
preprocess 90ms <-- 异常
queue_wait 210ms <-- 异常
inference 40ms
postprocess 8ms
total 350ms误区与复盘
误区一：用均值做容量规划。容量必须按P99或P999反推，否则高峰期必然超时。
误区二：跨实例平均分位数。P99不可算术平均，必须合并直方图。
误区三：只看GPU利用率。金融推理链路长，CPU预处理、序列化、网络都可能成为尾部瓶颈。
误区四：错误率与延迟割裂。超时既是错误也是延迟，需统一口径。
复盘结论：建立“直方图—分位数—吞吐/并发—错误—资源—追踪”六层度量，并固定每层的最小可观测字段。只有把P99的劣化定位到具体Span，容量优化才有依据。
把上述六类指标固化到监控看板与告警规则中，并确保每个P99异常都能下钻到具体Span，是金融推理容量优化的起点。