3. 性能基准基础
在金融推理系统中，性能基准不是一组孤立的数字，而是一套彼此约束、相互换算的指标体系。延迟回答“单笔请求多久返回”，吞吐量回答“单位时间能处理多少笔”，并发度回答“系统同时承载多少请求”，资源利用率回答“这些能力消耗了多少硬件成本”。四者共同构成性能画像，任何只盯一个指标的做法都会导致误判。
一、核心指标的定义与内在关系
延迟（Latency）指从请求发出到收到完整响应所经历的时间，通常以毫秒或秒计。金融场景中必须区分端到端延迟、服务端处理延迟、首字节延迟（TTFB）与尾延迟（P95/P99）。均值延迟会掩盖长尾问题，而风控、行情、交易类业务恰恰对尾延迟最敏感。
吞吐量（Throughput）指单位时间内成功完成的请求数，常用 QPS、TPS 或 samples/s 表示。吞吐量必须在给定延迟约束下才有意义，脱离 SLO 的峰值吞吐是无效指标。
并发度（Concurrency）指系统在某一时刻同时处于处理中的请求数量。它与吞吐量、延迟满足利特尔法则：并发度 ≈ 吞吐量 × 平均延迟。这条公式是容量估算与压测设计的基石。
资源利用率（Utilization）指 CPU、GPU、显存、内存、网络、磁盘等资源被占用的比例。利用率过低意味着成本浪费，过高则意味着排队风险，通常 GPU 利用率在 70%～85% 区间较为健康。
二、度量方法与工具链
度量延迟必须使用高精度时钟并区分阶段。推荐在服务端埋点记录入队、预处理、模型推理、后处理、返回五个时间戳，从而定位瓶颈阶段。压测工具方面，wrk、Locust、JMeter 适合 HTTP 层，vLLM benchmark、Triton perf_analyzer 适合推理服务层。
# 使用 wrk 测量延迟分布（P50/P90/P99）
wrk -t8 -c64 -d60s --latency http://localhost:8000/v1/infer
# 输出示例
Latency Distribution
50% 42.31ms
90% 88.75ms
99% 210.44ms
Requests/sec: 1523.67
Transfer/sec: 12.45MB
吞吐量度量需固定并发与输入长度，否则不同批次不可比。资源利用率可通过 nvidia-smi、dcgm-exporter、Prometheus + Grafana 采集，重点关注 GPU 利用率、显存占用、SM 活跃度与显存带宽。
# 采集 GPU 利用率与显存
nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total \
--format=csv -l 1
三、典型场景：风控实时推理基准
某风控模型要求 P99 延迟低于 150ms、吞吐量不低于 800 QPS。压测发现 P99 达 320ms，但 GPU 利用率仅 45%。分析后确认瓶颈在预处理阶段的特征拼接，而非模型推理。将特征拼接改为异步流水线后，P99 降至 118ms，吞吐量提升至 1050 QPS，GPU 利用率升至 72%。这说明资源利用率偏低往往指向非 GPU 瓶颈。
| 指标 | 定义 | 度量工具 | 金融场景目标 |
|---|---|---|---|
| 延迟 P50 | 中位响应时间 | wrk / 埋点 | < 50ms |
| 延迟 P99 | 尾部响应时间 | wrk --latency | < 150ms |
| 吞吐量 | 单位时间完成请求数 | Locust / perf_analyzer | > 800 QPS |
| 并发度 | 在途请求数 | 服务端计数器 | 按利特尔法则推算 |
| GPU 利用率 | GPU 计算占用比例 | nvidia-smi / DCGM | 70%～85% |
| 显存占用 | 已用显存 / 总显存 | nvidia-smi | < 90% |
四、常见误区与复盘
- 只看均值延迟：均值 40ms 可能掩盖 P99 的 500ms，金融业务必须看分位数。
- 脱离延迟谈吞吐：无限提高并发虽能推高 QPS，但延迟会急剧恶化，需在 SLO 约束下取最优点。
- 忽略并发度换算：用 64 并发压出 1500 QPS，不代表 128 并发能到 3000 QPS，系统存在饱和点。
- 资源利用率越高越好：GPU 利用率长期 95% 以上意味着排队严重，尾延迟不可控。
- 压测环境与生产不一致：输入长度、batch 策略、特征维度不同会导致基准失效。
掌握四维指标的定义、换算与度量方法，是后续使用 Profiler 定位瓶颈、优化推理性能的前提。只有建立可复现、可对比的基准，性能优化才有可靠的判断依据。