4. 模型 Serving 基础：模型部署方式、版本管理与推理模式

在风险定价流式决策系统中，模型 Serving 是连接离线训练与在线决策的核心桥梁。本章聚焦于模型部署的两种主流通信协议（REST 与 gRPC）、模型版本管理策略以及在线推理与批处理的适用场景，帮助你在生产环境中构建稳定、高效的模型服务层。

4.1 模型部署方式：REST vs gRPC

模型 Serving 的通信协议直接影响推理延迟、吞吐量和系统复杂度。REST（Representational State Transfer）和 gRPC（gRPC Remote Procedure Call）是当前最主流的两种选择，它们在数据格式、传输效率和生态支持上存在显著差异。

4.2 模型版本管理

模型版本管理是 Serving 层的核心治理能力，直接影响线上决策的稳定性和回滚效率。一个成熟的版本管理方案需要覆盖版本注册、灰度切换、回滚与监控四个环节。

4.2.1 版本管理核心要素

• 版本号规范：采用语义化版本（SemVer），例如 v2.1.0，其中主版本号表示不兼容的模型架构变更，次版本号表示新增特征或策略调整，补丁号表示 bug 修复或参数微调。
• 模型注册中心：使用 MLflow Model Registry、Seldon Core 或自建元数据表，记录每个版本的模型路径、输入/输出 Schema、训练时间、评估指标（AUC、KS、PSI）和上线状态。
• 灰度发布策略：支持按流量比例（如 10% → 50% → 100%）或按用户维度（如白名单、地域）逐步切换版本，配合实时监控自动回滚。
• 回滚机制：保留至少最近 3 个稳定版本，当新版本触发告警（如拒绝率飙升、PSI 超过阈值）时，自动或手动切回上一版本。

4.2.2 版本管理流程示例

# 模型注册与版本切换伪代码（Python + MLflow）
import mlflow

# 注册新模型版本
mlflow.register_model(
    model_uri="runs:/<run_id>/model",
    name="credit_risk_model"
)

# 将版本 v2.1.0 设置为 Staging（预发）
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="credit_risk_model",
    version=2,
    stage="Staging"
)

# 灰度切换：将 20% 流量指向 v2.1.0
# 实际生产可通过配置中心（如 Apollo、Nacos）动态调整路由权重
routing_config = {
    "v2.0.0": 0.8,
    "v2.1.0": 0.2
}

4.3 在线推理与批处理

风险定价决策系统需要同时支持两种推理模式：在线推理处理实时请求（如用户点击申请按钮时的额度计算），批处理用于离线或近线场景（如每日批量额度重算、策略回测）。

4.3.1 在线推理

• 请求模式：单条或少量请求（通常 < 100 条/次），要求毫秒级响应。
• 部署架构：模型服务通常以无状态容器部署在 Kubernetes 上，通过 Service Mesh（如 Istio）做流量管理和灰度路由。
• 优化手段：特征预计算、模型量化（INT8/FP16）、GPU 推理加速、请求级缓存（相同特征组合直接返回缓存结果）。
• 典型框架：Triton Inference Server、TorchServe、BentoML、Seldon Core。

4.3.2 批处理推理

• 请求模式：大规模数据集（百万至亿级），分钟到小时级完成。
• 部署架构：通常由 Spark/Flink 作业或 Airflow DAG 触发，从 Hive/ClickHouse 读取特征，调用模型服务批量推理。
• 优化手段：批量请求合并（将多条请求打包为一次 gRPC 调用）、动态批处理（Dynamic Batching）、模型并行分片。
• 典型框架：Spark MLlib、Ray Serve、Triton 的 Dynamic Batcher。

4.4 模型 Serving 架构总览

下图展示了风险定价场景下模型 Serving 的完整架构，涵盖 REST/gRPC 双协议接入、版本管理、在线与批处理两条推理链路。

4.5 在线推理与批处理对比总结