2. 金融推理场景概览
在金融业务中，“推理”并不是一个抽象概念，而是直接嵌入交易、风控、定价与反欺诈等核心链路中的计算行为。与通用AI推理不同，金融推理对延迟、吞吐、稳定性与可解释性有更严苛的约束。理解这些场景的性能需求，是后续做Profiler诊断与基准测试的前提。
一、核心原理：金融推理的四个性能维度
金融推理的性能不能只看“单次推理耗时”。实际生产系统中，需要同时关注以下四个维度：
- 延迟（Latency）：从请求进入到结果返回的时间，通常要求P99而非平均值。量化交易中，延迟每增加1毫秒都可能吃掉策略收益。
- 吞吐（Throughput）：单位时间内可处理的请求数或样本数。风控批处理、反欺诈实时流都依赖高吞吐。
- 确定性（Determinism）：相同输入必须得到相同输出，且延迟抖动可控。实时定价与风控决策不允许随机波动。
- 资源效率（Efficiency）：在给定CPU/GPU/内存预算下，能否稳定支撑业务峰值。金融系统通常不允许无限扩容。
金融推理的“快”不是单一指标，而是延迟、吞吐、确定性与资源效率的联合约束。Profiler诊断时，必须先把业务场景映射到这四个维度，才能判断瓶颈是否真正影响业务。
二、典型场景与性能需求拆解
下面按四类典型场景，分别说明其推理对象、性能瓶颈与关键指标。
| 场景 | 典型推理任务 | 核心性能需求 | 常见瓶颈 |
|---|---|---|---|
| 量化交易 | 信号预测、因子打分、订单执行决策 | 微秒至毫秒级延迟，P99稳定，低抖动 | 特征计算、模型前向、内存拷贝 |
| 风险控制 | 信用评分、额度审批、异常交易识别 | 毫秒至秒级延迟，高吞吐，可解释 | 特征拼接、规则引擎、模型批处理 |
| 实时定价 | 期权定价、衍生品估值、利率曲线拟合 | 毫秒级延迟，数值精度高，确定性 | 数值迭代、浮点运算、缓存命中 |
| 反欺诈 | 图神经网络、序列模型、团伙识别 | 毫秒级响应，高召回，高吞吐 | 图查询、邻居聚合、内存带宽 |
以量化交易为例，一个典型的推理链路包括：行情数据接入 → 特征计算 → 模型推理 → 信号生成 → 订单执行。其中模型推理可能只占20%时间，而特征计算与数据搬运占80%。如果只优化模型，整体延迟改善有限。
# 典型量化推理延迟分解（示例）
行情接入: 0.8 ms
特征计算: 2.4 ms
模型前向: 0.6 ms
信号后处理: 0.3 ms
订单执行: 0.5 ms
------------------------
端到端P99: 4.6 ms
反欺诈场景则不同。它通常面对的是高并发请求，单次推理可能涉及图查询与邻居聚合，延迟要求虽不如量化交易极端，但吞吐量极大。此时Profiler应重点关注内存带宽、图遍历深度与批处理效率。
三、方法流程：从场景到性能基准
要建立有效的金融推理性能基准，建议按以下流程推进：
- 场景建模：明确推理对象、输入输出、调用频率与峰值QPS。
- 指标定义：确定延迟分位数（P50/P95/P99）、吞吐目标、错误率与资源上限。
- 基准构建：构造贴近真实分布的数据集与请求模式，避免只用理想数据。
- Profiler采集：使用CPU/GPU Profiler采集算子耗时、内存占用、线程调度与I/O等待。
- 瓶颈定位：区分计算瓶颈、内存瓶颈、I/O瓶颈与调度瓶颈。
- 优化验证：每次只改一个变量，对比优化前后的P99与吞吐。
基准测试必须使用真实分布的数据。金融数据具有长尾、季节性与突发性，用均匀随机数据测出的性能往往过于乐观。
四、案例与复盘：一个实时定价推理的Profiler诊断
某团队在实时期权定价服务中，发现P99延迟从8ms突增到35ms。初步怀疑是模型变复杂，但Profiler显示模型前向仅增加1ms。进一步采集发现：
- 数值迭代次数因市场波动增大而上升；
- 缓存命中率从92%下降到61%；
- 大量时间消耗在浮点运算与内存分配上。
最终定位为：波动率曲面缓存失效导致重复计算。优化缓存策略后，P99恢复到9ms。这个案例说明，金融推理的性能问题往往不在模型本身，而在数据与缓存链路。
常见误区：只盯着模型推理耗时，忽略特征计算、数据搬运与缓存命中。金融场景中，端到端延迟才是业务指标，单算子优化可能收效甚微。
综合来看，金融推理场景的性能需求可以归纳为：量化交易追求极致低延迟与低抖动；风险控制追求高吞吐与可解释；实时定价追求数值精度与确定性；反欺诈追求高并发与高召回。Profiler诊断时，应先把业务场景映射到这些需求，再选择对应的采集指标与优化路径。