4. 模型部署与版本管理：序列化、仓库与回滚
在生产环境中，模型从训练到上线需要经历序列化、存储、版本追踪与回滚等多个环节。任何一个环节的失误都可能导致服务中断或推理结果错误。本章围绕模型序列化格式、模型仓库选型以及版本回滚策略展开，帮助你在风险决策链路中建立可靠的模型交付基线。
4.1 模型序列化格式对比
模型序列化是将训练好的模型参数、计算图及预处理逻辑打包为可存储、可加载的二进制或文本格式。不同格式在跨平台兼容性、推理性能、元数据保留能力上差异显著。
| 格式 | 跨平台/语言 | 推理优化 | 元数据支持 | 典型场景 |
|---|---|---|---|---|
| ONNX | 高（PyTorch/TF/ONNX Runtime） | 支持算子融合、量化 | 输入输出类型、形状 | 跨框架部署、边缘端推理 |
| PMML | 中（Java/Python/R） | 有限（依赖引擎） | 特征工程、模型参数 | 传统机器学习、合规审计 |
| Pickle | 低（仅Python） | 无 | 无（需额外封装） | 快速原型、内部实验 |
风险提示： Pickle 在加载时会执行任意 Python 代码，存在严重的安全风险。在生产环境中，应优先使用 ONNX 或 PMML 等标准化格式，避免直接使用 Pickle 进行跨服务传输。
4.2 模型序列化格式选择流程
下图展示了从训练完成到选择序列化格式的决策路径，帮助你在不同业务约束下做出合理选择。
4.3 模型仓库选型
模型仓库负责存储序列化后的模型文件、版本元数据、训练参数及评估指标。在风险决策链路中，模型仓库需要支持快速回滚、权限隔离和审计追踪。
4.3.1 MLflow Model Registry
- 阶段管理： 支持 None → Staging → Production → Archived 四个阶段，每个阶段可绑定审批流程。
- 版本标注： 每个模型版本可关联 run_id、实验名称、标签（如“风控模型v3.2”）。
- 部署集成： 通过 REST API 或 Python SDK 直接拉取指定阶段的模型。
4.3.2 自建 Model Registry
- 存储后端： 对象存储（S3/MinIO）+ 元数据库（PostgreSQL/MySQL）。
- 版本策略： 语义化版本号（major.minor.patch），每次部署记录模型哈希、部署时间、部署人。
- 权限控制： 按团队/项目隔离，生产环境模型仅允许 CI/CD 管道写入。
| 特性 | MLflow Model Registry | 自建 Model Registry |
|---|---|---|
| 部署复杂度 | 低（开箱即用） | 高（需自行开发） |
| 审计追踪 | 内置阶段变更日志 | 需自行实现 |
| 自定义元数据 | 支持标签与描述 | 完全灵活 |
| 与 CI/CD 集成 | REST API 友好 | 取决于实现 |
4.4 版本回滚策略
模型上线后，若出现推理质量下降、数据漂移或服务异常，需要快速回滚到上一个稳定版本。回滚策略需要兼顾速度、一致性和可追溯性。
4.4.1 回滚触发条件
- 监控指标告警： 如 AUC 下降超过 2%、推理延迟超过 P99 阈值、错误率上升。
- 人工判定： 业务方反馈异常，经风险委员会确认后触发回滚。
- 自动回滚： 灰度发布期间，若新版本在 10 分钟内错误率 > 5%，自动切回旧版本。
4.4.2 回滚操作流程
4.4.3 回滚策略对比
| 策略 | 切换速度 | 一致性保证 | 适用场景 |
|---|---|---|---|
| 蓝绿部署 | 秒级（负载均衡切换） | 全量切换，无中间状态 | 关键风控模型，需瞬时回滚 |
| 金丝雀发布 | 分钟级（逐步切流） | 部分流量验证，降低风险 | 新模型灰度验证，逐步放量 |
| 版本快照 | 依赖存储拉取速度 | 需确保快照与当前环境兼容 | 模型文件较大，需保留多个历史版本 |
常见陷阱： 回滚时若模型依赖的特征工程逻辑或预处理代码已变更，直接切换模型文件可能导致特征对齐错误。建议在模型仓库中同时保存模型版本对应的预处理管道版本号，回滚时一并切换。
4.5 实战建议
- 序列化格式： 新项目默认使用 ONNX，传统风控场景保留 PMML 用于合规审计，Pickle 仅限本地调试。
- 模型仓库： 团队规模较小时优先使用 MLflow Model Registry；大规模生产环境建议自建仓库，实现更细粒度的权限与审计。
- 回滚演练： 每月至少执行一次回滚演练，确保回滚脚本、模型文件、依赖环境均处于可用状态。