3. Model Serving 基础概念
在金融图谱系统中，模型训练与模型推理（Serving）承担着截然不同的角色。训练阶段关注如何从历史数据中学习规律，而推理阶段则关注如何将训练好的模型快速、稳定地应用于实时或批量金融决策。理解两者的本质差异，是设计高可用 Serving 系统的前提。
3.1 模型推理与训练的区别
训练（Training）是一个计算密集型、时间跨度较长的离线过程，通常使用 GPU 集群或分布式框架（如 PyTorch DDP、TensorFlow PS）迭代更新模型参数。推理（Inference）则是在模型参数固定后，将输入数据前向传播一次得到预测结果，对延迟和资源效率要求极高。
| 对比维度 | 模型训练 | 模型推理 |
|---|---|---|
| 目标 | 最小化损失函数，更新参数 | 快速、稳定地输出预测值 |
| 计算模式 | 前向 + 反向传播，多轮迭代 | 仅前向传播，单次或批量 |
| 硬件偏好 | GPU 大显存、高算力 | CPU/GPU/TPU 均可，侧重低延迟 |
| 数据规模 | TB 级历史数据集 | 单条或小批量实时请求 |
| 延迟要求 | 小时/天级别 | 毫秒/秒级别 |
| 部署形态 | 离线作业、分布式集群 | 在线服务、边缘节点、API 网关 |
| 金融场景示例 | 基于历史交易数据训练反欺诈模型 | 实时判断当前交易是否为欺诈 |
关键认知：训练追求“收敛精度”，推理追求“响应速度”。在金融图谱中，一个模型可能每周训练一次，但每秒需要服务数千次推理请求。训练与推理的架构分离是 MLOps 最佳实践。
3.2 Serving 系统的核心指标
衡量一个 Model Serving 系统是否合格，主要看三个黄金指标：延迟、吞吐量和可用性。在金融场景中，这三个指标直接关系到交易成功率、风控时效和合规要求。
- 延迟（Latency）：从客户端发起请求到收到完整响应所经过的时间。通常关注 P50、P99 和 P999 分位延迟。例如，实时风控场景要求 P99 延迟 < 50ms。
- 吞吐量（Throughput）：单位时间内系统能处理的推理请求数量，常用 QPS（Queries Per Second）或 TPS（Transactions Per Second）表示。高吞吐意味着系统能承载更大的业务流量。
- 可用性（Availability）：系统正常服务时间占总时间的百分比。金融级要求通常为 99.99%（四个九）以上，对应全年停机时间不超过 52.56 分钟。
| 指标 | 定义 | 金融典型要求 | 常见优化手段 |
|---|---|---|---|
| 延迟 | 请求-响应往返时间 | P99 < 100ms（实时风控） | 模型量化、算子融合、GPU 推理优化 |
| 吞吐量 | 每秒处理请求数 | 单节点 > 1000 QPS | 请求批处理、异步推理、负载均衡 |
| 可用性 | 服务正常运行时间占比 | 99.99%+ | 多副本部署、熔断降级、健康检查 |
金融图谱提示：三个指标之间存在 trade-off。例如，增大批处理大小可以提升吞吐量，但会显著增加单个请求的延迟。设计 Serving 系统时，需要根据业务优先级（如实时交易 vs 批量征信查询）来平衡指标。
3.3 同步与异步推理模式
根据业务场景对实时性的要求，Model Serving 系统通常支持两种推理模式：同步推理和异步推理。在金融图谱中，两种模式各有适用场景，有时甚至需要混合使用。
3.3.1 同步推理模式
同步推理是最常见的模式。客户端发送请求后，Serving 系统立即执行模型前向计算，并将结果直接返回给客户端。整个过程是阻塞的，客户端必须等待响应才能继续后续操作。
- 适用场景：实时风控、在线授信、交易欺诈检测等对延迟极度敏感的金融业务。
- 优点：实现简单，结果实时返回，适合交互式应用。
- 缺点：当请求量突增时，容易导致服务端线程/进程阻塞，引发雪崩效应。
- 典型实现：RESTful API（如 FastAPI、Flask）、gRPC 一元调用。
3.3.2 异步推理模式
异步推理模式下，客户端提交请求后立即获得一个任务 ID（或回调凭证），无需等待模型计算完成。Serving 系统将请求放入消息队列或任务队列中，由后台 Worker 异步处理，处理完成后通过回调、轮询或事件通知将结果传递给客户端。
- 适用场景：批量征信查询、大规模资产定价、非实时风控报告生成。
- 优点：削峰填谷，系统吞吐量高；客户端不阻塞，资源利用率更均衡。
- 缺点：实现复杂度高，需要额外的消息中间件和结果存储；端到端延迟增加。
- 典型实现：Kafka + Celery + Redis 结果后端、gRPC 异步流式调用。
| 对比维度 | 同步推理 | 异步推理 |
|---|---|---|
| 响应方式 | 直接返回结果 | 返回任务 ID，后续获取结果 |
| 客户端阻塞 | 是 | 否 |
| 延迟特征 | 低延迟（毫秒级） | 较高延迟（秒级甚至分钟级） |
| 吞吐量上限 | 受限于连接数和线程池 | 高，可水平扩展 Worker |
| 金融典型场景 | 实时交易反欺诈 | 批量客户信用评分 |
| 中间件依赖 | 无 | 消息队列（Kafka/RabbitMQ） |
金融图谱避坑指南：不要将异步推理用于实时交易场景。如果风控系统采用异步模式处理支付请求，用户可能在结果返回前就已经完成支付，导致欺诈损失。同步与异步的选择必须严格匹配业务 SLA。
3.4 小结
本章从三个层面建立了 Model Serving 的基础认知：
- 训练 vs 推理：明确两者在目标、计算模式、硬件需求和延迟要求上的本质差异。
- 核心指标：延迟、吞吐量、可用性是衡量 Serving 系统质量的黄金三角，金融场景对三者均有严苛要求。
- 同步与异步：同步模式适合实时交互，异步模式适合批量处理，架构设计需根据业务场景灵活选择。