2. 模型Serving基础：定义、推理模式与性能要求
模型Serving（模型服务化）是将训练完成的机器学习模型部署到生产环境，对外提供稳定、低延迟、高吞吐推理接口的过程。在风控场景中，模型Serving直接决定了欺诈检测、信用评分等决策的实时性与准确性。本章从定义出发，厘清在线推理与批量推理的核心差异，并给出Serving系统的延迟与吞吐量量化要求。
2.1 模型Serving的定义
模型Serving是MLOps生命周期中“部署与运维”阶段的核心环节，其本质是将模型封装为可调用的服务端点，接收输入特征并返回预测结果。一个完整的Serving系统通常包含以下组件：
- 模型加载与版本管理：支持多版本模型的热加载、回滚与A/B测试。
- 特征预处理：对原始请求数据进行标准化、缺失值填充、特征工程等操作。
- 推理引擎：执行模型前向计算，支持TensorFlow/PyTorch/ONNX等框架。
- 结果后处理：将模型原始输出（如概率值）转换为业务可用的分数、标签或决策。
- 监控与告警：采集推理延迟、吞吐量、模型漂移等指标。
关键认知： 模型Serving ≠ 模型训练。训练关注准确率与召回率，Serving关注延迟、吞吐量与稳定性。一个在训练集上AUC=0.99的模型，若Serving延迟超过500ms，在实时风控场景中几乎不可用。
2.2 在线推理与批量推理的区别
根据业务对实时性的要求，模型推理分为两种模式：在线推理（Online Inference） 和 批量推理（Batch Inference）。下表从多个维度对比两者的差异：
| 对比维度 | 在线推理 | 批量推理 |
|---|---|---|
| 触发方式 | 单条请求触发（如用户点击、交易提交） | 定时任务或数据累积触发（如每日T+1报表） |
| 延迟要求 | 毫秒级（通常 < 200ms） | 分钟级或小时级 |
| 吞吐量 | QPS（每秒查询数）波动大，需应对突发流量 | 数据量可预估，吞吐量相对稳定 |
| 资源消耗 | 需预留峰值资源，GPU利用率可能较低 | 可充分利用批处理加速，资源利用率高 |
| 典型场景 | 实时支付风控、登录反欺诈、信贷审批 | 离线信用评分、批量用户分层、历史数据回溯 |
| 部署架构 | RESTful API / gRPC + 负载均衡 | Spark / Flink 批处理作业或离线模型服务 |
工程建议： 在风控系统中，同一模型可能同时服务于在线与批量两种场景。建议将模型导出为统一格式（如ONNX或TorchScript），分别部署为在线Serving和离线批处理两个独立服务，避免资源争抢。
2.3 Serving系统的延迟与吞吐量要求
延迟（Latency）和吞吐量（Throughput）是衡量Serving系统性能的两个核心指标，且通常相互制约。在风控场景中，这两个指标直接关联到用户体验与业务损失。
2.3.1 延迟（Latency）
延迟指从客户端发送请求到收到完整响应所经过的时间，通常以P50（中位数）、P99（99分位） 和 P999（99.9分位） 来衡量。风控场景的典型延迟要求如下：
- 实时支付风控：P99 < 100ms，P999 < 300ms。超过此阈值可能导致用户支付超时或订单流失。
- 信贷审批：P99 < 500ms。用户等待授信结果时，过长的延迟会显著降低转化率。
- 异步反欺诈：P99 < 2s。适用于非实时拦截场景，如事后风险分析。
2.3.2 吞吐量（Throughput）
吞吐量指系统在单位时间内能处理的请求数量，常用QPS（Queries Per Second） 或 RPS（Requests Per Second） 表示。吞吐量要求取决于业务峰值流量：
- 大型电商平台：大促期间支付风控QPS可达数万甚至数十万。
- 中型金融科技公司：日常QPS在数千级别，峰值约为日常的3~5倍。
- 小型业务：QPS通常在数百以内，但对延迟的敏感度同样很高。
常见误区： 不要只关注平均延迟。在风控场景中，P99延迟才是关键——如果P99延迟从100ms飙升到500ms，意味着每100个请求中就有1个请求的响应时间超过500ms，这对用户体验和业务转化是灾难性的。
2.4 在线推理与批量推理的架构对比
下图从架构层面直观展示在线推理与批量推理的差异：
2.5 延迟与吞吐量的权衡策略
在实际工程中，延迟和吞吐量往往是一对矛盾体。以下表格总结了常见的优化策略及其对两者的影响：
| 优化策略 | 对延迟的影响 | 对吞吐量的影响 | 适用场景 |
|---|---|---|---|
| 模型量化（INT8） | 降低（推理加速） | 提升（单卡处理更多请求） | 在线推理，对精度损失不敏感的场景 |
| 批处理（Dynamic Batching） | 可能增加（等待批处理填充） | 显著提升 | 在线推理中延迟容忍度较高的请求 |
| 模型蒸馏 | 降低（小模型更快） | 提升 | 在线推理，需保持较高精度 |
| GPU多流并行 | 基本不变 | 提升（充分利用GPU资源） | 在线推理与批量推理均可 |
| 缓存（Cache） | 显著降低（命中时） | 提升（减少重复计算） | 在线推理，特征或结果可复用的场景 |
实战要点： 在风控Serving系统中，建议先以P99延迟为硬约束，再最大化吞吐量。例如：设定P99 < 100ms，然后通过压力测试找到在该延迟约束下的最大QPS。这个QPS值就是系统的“安全吞吐量”，日常流量应控制在此值的70%以下，以应对突发峰值。