2. Model Serving 核心概念：模型推理、在线预测、批处理与流处理、Serving 延迟与吞吐量指标
在实时交易风控场景中，Model Serving 是连接训练好的风控模型与线上交易请求的关键桥梁。理解其核心概念，是设计高可用、低延迟风控系统的前提。本章将围绕模型推理、在线预测、批处理与流处理、以及延迟与吞吐量指标展开，帮助您建立 Serving 层的知识框架。
2.1 模型推理与在线预测
模型推理（Model Inference）是指将输入数据（如交易特征）传递给已训练好的模型，通过前向计算得到输出结果（如风险评分）的过程。在实时交易风控中，推理通常以在线预测（Online Prediction）的形式呈现，即每次请求独立触发一次推理，并立即返回结果。
关键区别： 模型推理是计算行为，在线预测是服务形态。在线预测要求推理在毫秒级完成，且服务必须保持高可用。
在线预测的典型流程如下：
- 请求到达：交易系统发起 HTTP/gRPC 请求，携带交易特征（如金额、设备指纹、地理位置）。
- 特征预处理：Serving 层对原始特征进行标准化、缺失值填充、类别编码等操作。
- 模型推理：将预处理后的特征向量输入模型，执行前向计算。
- 后处理与返回：将模型输出（如概率值）转换为风控决策（通过/拒绝/人工审核），并返回给调用方。
实践建议： 在线预测的模型应尽量轻量化（如使用 ONNX 或 TensorRT 优化），避免在请求路径中引入复杂的特征工程逻辑，以降低延迟。
2.2 批处理与流处理
除了在线预测，Model Serving 还支持批处理（Batch Processing）和流处理（Stream Processing）两种模式，它们在实时交易风控中各有适用场景。
| 特性 | 在线预测（实时） | 批处理 | 流处理 |
|---|---|---|---|
| 触发方式 | 单次请求触发 | 定时或数据量阈值触发 | 持续数据流触发 |
| 延迟要求 | 毫秒级（< 100ms） | 分钟级到小时级 | 秒级到分钟级 |
| 典型场景 | 支付授权、登录验证 | 离线批量评分、模型回测 | 实时规则引擎、窗口聚合风控 |
| 资源消耗 | 高并发、低吞吐 | 高吞吐、资源可规划 | 中等吞吐、状态管理复杂 |
| 常用框架 | Triton Inference Server, TorchServe | Spark MLlib, Batch 推理脚本 | Flink, Kafka Streams, Spark Streaming |
避坑提示： 不要将批处理逻辑直接嵌入在线预测服务。批处理任务应独立部署，避免因批量计算阻塞实时请求。
在实时交易风控中，流处理常用于构建滑动窗口特征（如过去 5 分钟交易次数）或实时规则引擎。模型推理可以作为流处理中的一个算子，对每条消息进行评分，实现近实时的风控决策。
2.3 Serving 延迟与吞吐量指标
衡量 Model Serving 性能的核心指标是延迟（Latency）和吞吐量（Throughput）。在交易风控中，这两个指标直接影响用户体验和系统稳定性。
2.3.1 延迟指标
- P50 / P99 延迟：P50 代表中位数延迟，反映典型请求的响应速度；P99 代表 99% 请求的延迟上限，是衡量系统尾部延迟的关键指标。风控场景通常要求 P99 延迟 < 200ms。
- 平均延迟：所有请求延迟的算术平均值，容易受极端值影响，通常与 P50 配合使用。
- 延迟分布：通过直方图或热力图观察延迟的集中趋势和异常峰值，用于定位性能瓶颈。
2.3.2 吞吐量指标
- QPS（Queries Per Second）：每秒处理的请求数，是衡量服务并发能力的基本单位。
- RPS（Requests Per Second）：与 QPS 类似，但在某些上下文中强调请求而非查询。
- 吞吐量上限：在保证延迟 SLO（Service Level Objective）的前提下，系统能承受的最大 QPS。
核心关系： 延迟与吞吐量通常呈负相关。当 QPS 接近系统上限时，延迟会急剧上升（即“拐点”）。设计 Serving 系统时，需要在延迟 SLO 和吞吐量需求之间找到平衡点。
下图展示了在线预测服务的典型延迟-吞吐量关系曲线：
2.4 核心概念关系总结
下表梳理了 Model Serving 核心概念在实时交易风控中的定位与关系：
| 概念 | 定义 | 风控场景示例 | 关键指标 |
|---|---|---|---|
| 模型推理 | 模型前向计算过程 | 输入交易特征，输出风险概率 | 推理时间、模型大小 |
| 在线预测 | 单次请求触发的实时推理服务 | 支付授权时实时评分 | P99 延迟、QPS |
| 批处理 | 批量数据集中推理 | 每日离线批量评分、模型回测 | 吞吐量、完成时间 |
| 流处理 | 持续数据流中的推理 | 实时窗口特征计算 + 模型评分 | 处理延迟、状态大小 |
| 延迟 | 请求从发出到收到响应的耗时 | P99 < 200ms 是风控硬性要求 | P50, P99, 平均延迟 |
| 吞吐量 | 单位时间处理的请求数 | 峰值 10 万 QPS 需提前压测 | QPS, RPS, 吞吐量上限 |
工程落地要点： 在搭建 Serving 系统前，先明确业务对延迟和吞吐量的 SLO。例如：“P99 延迟 < 150ms，峰值 QPS 5 万”。然后根据 SLO 选择推理框架、硬件配置和部署架构。
下图展示了 Model Serving 在实时交易风控中的整体架构与核心概念关系：
总结： 实时交易风控的 Model Serving 设计，本质是在延迟、吞吐量、资源成本之间做权衡。理解模型推理、在线预测、批处理与流处理的差异，并掌握延迟与吞吐量指标的测量与优化方法，是构建高可用风控系统的第一步。