3. 金融推理负载特征
在金融推理系统中，延迟与容量优化之所以困难，根本原因在于负载本身不是单一形态。同一个推理平台，白天要支撑在线实时推理，夜间要跑批量评分，交易时段还要处理流式决策与高频请求，遇到行情波动或营销活动又会出现突发流量。更复杂的是，模型并非只有一个：反欺诈、信用评分、额度定价、营销响应、合规审查往往使用不同结构、不同参数量、不同硬件依赖的模型。理解这些负载特征，是后续做P95/P99延迟治理和容量规划的前提。
核心原理：七类负载特征如何共同决定资源画像
金融推理负载可以拆解为七个相互交织的维度，它们分别从时间、并发、数据形态、模型形态和合规约束五个方向施加压力。
- 在线实时推理：请求-响应模式，用户或上游系统同步等待结果，通常要求端到端延迟在几十到几百毫秒。P99延迟直接决定用户体验和交易成功率。
- 批量评分：离线或准离线任务，单次提交数十万到数亿条记录，追求吞吐和成本，对单条延迟不敏感，但会与在线流量争抢GPU/CPU资源。
- 流式决策：事件驱动，输入是持续到达的事件流（如交易流水、点击行为），需要窗口聚合、状态维护和低延迟输出，对内存和背压处理要求高。
- 高频请求：单位时间内请求密度大，QPS高但单请求计算量可能很小，瓶颈常在调度、序列化和网络而非模型本身。
- 突发流量：流量在秒级到分钟级出现数倍甚至数十倍尖峰，如开盘、放款日、促销活动，考验弹性伸缩和排队策略。
- 模型多样性：不同模型对显存、算力、精度、批处理能力要求不同，混部时容易互相干扰。
- 合规低延迟要求：部分场景（如支付反欺诈、实时风控）受监管约束，必须在一定时限内完成决策并留痕，延迟超标不仅是性能问题，更是合规问题。
这七类特征并非孤立存在，而是叠加在同一套基础设施上。例如，夜间批量评分占用大量GPU，若未做资源隔离，次日早高峰的在线实时推理P99就会恶化；流式决策的状态存储若与在线推理共享内存，突发流量下可能触发OOM。因此，负载特征分析的目标不是罗列现象，而是建立“业务形态→请求模式→资源消耗→延迟分布”的映射关系。
方法流程：把负载特征转化为可量化的容量模型
识别特征之后，需要一套可落地的方法，把定性描述转化为可计算的容量与延迟指标。建议按以下流程推进。
- 业务分层：按SLA把请求分为实时关键、准实时、离线三类，分别定义P95/P99目标。例如实时风控P99≤80ms，批量评分无单条延迟要求但需在窗口内完成。
- 流量建模：采集历史QPS曲线，识别基线、周期峰值和突发峰值。突发流量要单独建模，不能只用平均值做容量规划。
- 资源画像：对每个模型测量单次推理的GPU耗时、显存占用、CPU预处理耗时、网络往返。模型多样性意味着要按模型分别建画像。
- 混部隔离：为在线、流式、批量分配独立资源池或设置优先级与配额，避免批量任务拖垮在线P99。
- 压测验证：用真实流量比例做混合压测，观察P95/P99随并发变化的拐点，确定安全水位。
- 弹性与降级：设定扩容触发阈值和降级策略，如突发时关闭非关键模型或降低批大小。
关键参数示例：某实时反欺诈模型在A100上单次推理GPU耗时12ms，预处理3ms，网络2ms，理论P50约17ms。当并发从50升到200时，由于批处理排队，P99从35ms升至180ms。这说明容量规划不能只看平均耗时，必须看尾延迟拐点。
案例/场景：一次开盘突发流量导致的P99恶化复盘
某券商智能投顾平台在开盘后3分钟内请求量从200 QPS突增至1500 QPS。监控显示P99从60ms升至900ms，部分请求超时。排查发现三个叠加因素：一是批量评分任务未与在线推理隔离，占用了40% GPU；二是流式决策的状态存储与在线推理共享Redis实例，突发写入导致读延迟上升；三是模型多样性导致路由层在高峰时频繁切换模型版本，增加了调度开销。
优化措施包括：将批量评分迁移到独立GPU池并限制其最大占用；为流式状态使用独立Redis集群；路由层缓存模型元数据，减少高峰切换；设置基于QPS和P99的自动扩容策略。调整后，同样突发流量下P99稳定在120ms以内。
# 容量水位检查示例（伪代码）
online_pool:
gpu: A100 x 8
max_batch: 32
target_p99_ms: 80
current_qps: 1500
safe_qps: 1200 # 压测拐点
action: scale_out + degrade_non_critical
batch_pool:
gpu: A100 x 4
max_concurrency: 2
window: "02:00-05:00"
isolation: true
误区/复盘：常见认知偏差与纠正
| 常见误区 | 问题本质 | 纠正做法 |
|---|---|---|
| 用平均延迟做容量规划 | 平均值掩盖尾延迟，突发下P99先恶化 | 以P95/P99为目标，结合压测拐点定容量 |
| 所有模型共用一个资源池 | 模型多样性导致互相干扰，大模型挤占小模型 | 按模型画像分池或设置优先级与配额 |
| 批量任务随时可跑 | 批量与在线争抢资源，拖垮实时P99 | 错峰执行，或使用独立资源并限制占用 |
| 突发流量只靠扩容解决 | 扩容有冷启动延迟，来不及应对秒级尖峰 | 预留缓冲容量+降级+排队策略组合 |
| 忽视合规时限 | 延迟超标导致决策未在监管时限内完成 | 将合规时限纳入SLA，设置超时告警与留痕 |
实践建议：为每类负载建立独立的延迟看板，至少包含P50、P95、P99、超时率和排队深度。每周复盘一次尾延迟拐点变化，因为业务量增长和模型迭代都会让拐点前移。
注意：合规低延迟要求不是单纯的性能指标，而是业务约束。在容量规划时，必须把监管时限作为硬性上限，任何降级策略都不能突破该时限，否则可能引发合规风险。
综上，金融推理负载的七类特征决定了系统必须在延迟、吞吐、成本和合规之间做精细平衡。只有先把负载特征量化成资源画像和延迟模型，后续的P95/P99优化与容量弹性才有可靠依据。