4. 模型Serving架构总览：在线推理与离线推理的区别、Serving系统的核心组件
在信用额度定价的流式决策链路中，模型Serving（模型服务）是连接训练环境与生产环境的桥梁。本章从架构视角出发，首先厘清在线推理与离线推理的本质差异，再深入剖析Serving系统的三大核心组件：模型仓库、推理引擎与特征存储。
4.1 在线推理 vs 离线推理：场景决定架构
信用额度定价场景同时存在两种推理模式：在线推理用于实时授信、提额等交互式决策，要求毫秒级响应；离线推理用于批量额度重估、风险回溯、模型验证等非实时任务，侧重吞吐量与成本。两者在延迟、数据源、部署方式上存在显著差异。
| 对比维度 | 在线推理（实时） | 离线推理（批量） |
|---|---|---|
| 响应延迟 | P99 < 100ms（含网络与特征计算） | 分钟级～小时级 |
| 数据来源 | 实时特征流（Kafka / 缓存）+ 请求参数 | 离线数仓（Hive / HDFS / 对象存储） |
| 计算模式 | 单条请求，串行或小批量 | 大规模并行，分片处理 |
| 模型更新 | 热加载 / 蓝绿部署，无感切换 | 定时调度，允许短暂停服 |
| 资源规格 | CPU 密集型，低内存，高 QPS | CPU/GPU 混合，大内存，高吞吐 |
| 典型框架 | Triton Inference Server, TorchServe, BentoML | Spark MLlib, Flink ML, 自研批推理引擎 |
| 信用额度场景 | 实时额度审批、提额申请、交易拦截 | 月度额度重估、策略回测、模型监控 |
架构决策要点： 在线推理与离线推理不应共用同一套Serving基础设施。在线推理优先保证延迟与可用性，离线推理优先保证吞吐与成本。两者在特征存储、模型版本管理、日志采集层面可共享元数据，但计算资源必须物理隔离。
4.2 Serving系统核心组件总览
一个生产级的模型Serving系统由三个核心组件构成：模型仓库（Model Registry）、推理引擎（Inference Engine）、特征存储（Feature Store）。三者协同工作，形成从模型发布到在线/离线推理的完整链路。
4.3 模型仓库：版本管理与发布中心
模型仓库是Serving系统的“配置中心”，负责存储模型文件、版本元数据、部署标签与审批记录。在信用额度场景中，模型迭代频繁（每周甚至每天），模型仓库必须支持：
- 版本化存储： 每个模型按语义版本号（如 v1.2.3）归档，保留完整历史。
- 元数据管理： 记录模型类型（XGBoost / DNN / 线性模型）、特征依赖、训练数据时间窗口、性能指标（AUC / KS / PSI）。
- 部署标签： 标记模型所处的环境（dev / staging / prod），支持灰度发布与回滚。
- 存储后端： 通常基于对象存储（S3 / MinIO / HDFS）或分布式文件系统。
生产实践： 模型仓库应提供 模型签名（Model Signature） 校验机制，确保推理引擎拉取的模型文件未被篡改或损坏。推荐使用 MLflow Model Registry 或自研元数据数据库 + 对象存储的组合方案。
4.4 推理引擎：模型加载与计算核心
推理引擎是Serving系统的“执行单元”，负责加载模型、接收请求、执行前向计算并返回结果。在信用额度定价中，推理引擎需要处理以下关键任务：
| 功能模块 | 说明 | 信用额度场景要求 |
|---|---|---|
| 模型加载 | 从模型仓库拉取模型文件，加载到内存/显存 | 支持热加载，不中断在线服务 |
| 请求路由 | 根据请求参数（用户ID、产品类型）路由到对应模型版本 | 支持按策略分流（A/B测试、灰度） |
| 批处理 | 将多条请求合并为batch，提升GPU/CPU利用率 | 动态批处理，延迟与吞吐平衡 |
| 特征拼接 | 将请求参数与特征存储中的实时特征合并为模型输入 | 特征对齐与缺失值处理 |
| 结果后处理 | 将模型输出（如违约概率）转换为额度定价决策 | 阈值判断、额度映射、拒绝原因码 |
避坑提示： 推理引擎的 特征拼接 环节是线上故障的高发区。模型训练时的特征工程逻辑（如分箱、归一化、缺失值填充）必须在推理引擎中完全复现，否则会导致训练-推理偏差（Training-Serving Skew）。建议将特征变换逻辑封装为独立的 特征变换算子，与模型文件一同发布。
4.5 特征存储：实时与离线的统一视图
特征存储是Serving系统的“数据底座”，为在线推理提供低延迟的实时特征，为离线推理提供批量特征。在信用额度定价中，特征存储需要解决以下核心问题：
- 实时特征计算： 基于用户实时行为（如当前查询、交易流水）计算特征，延迟需控制在10ms以内。
- 离线特征回溯： 支持按时间窗口回溯历史特征，用于模型训练与回测。
- 特征一致性： 在线与离线使用同一套特征定义与计算逻辑，避免特征漂移。
- 缓存与预计算： 对高频访问的静态特征（如用户画像）进行缓存，减少重复计算。
4.6 组件协同：一次完整的在线推理流程
以信用额度实时审批为例，三个核心组件的协同流程如下：
- 请求到达： 用户提交额度申请，API网关将请求转发至推理引擎。
- 特征获取： 推理引擎向特征存储请求该用户的实时特征（如近30天交易频次、当前负债率）。
- 模型加载： 推理引擎从模型仓库拉取当前生效的额度定价模型（如 v2.1.0）。
- 特征拼接与推理： 引擎将请求参数与实时特征拼接为模型输入，执行前向计算，输出违约概率与建议额度。
- 结果返回： 引擎将结果（额度、利率、拒绝原因）返回给业务系统，同时将推理日志写入特征存储用于后续监控。
架构总结： 模型仓库、推理引擎、特征存储三者构成Serving系统的“铁三角”。模型仓库保证模型版本的可追溯与可回滚；推理引擎保证计算的高效与稳定；特征存储保证特征的实时性与一致性。在信用额度定价场景中，任何一环的故障都可能导致额度误判或服务不可用，因此三者的高可用与监控体系必须同步建设。