3. 模型部署流程：模型导出、版本管理与加载策略
模型部署是将训练完成的模型投入生产服务的关键环节。本章围绕三个核心步骤展开：模型导出（将训练框架格式转换为标准中间表示）、模型版本管理（确保可追溯与灰度回滚）、模型加载策略（平衡资源与响应延迟）。以下逐一深入。
3.1 模型导出：SavedModel / ONNX / TorchScript
模型导出是将训练框架（TensorFlow、PyTorch 等）的运行时图与权重序列化为标准格式，使 Serving 引擎能够脱离训练环境独立加载。三种主流格式对比如下：
| 格式 | 来源框架 | 核心特点 | 适用场景 |
|---|---|---|---|
| SavedModel | TensorFlow | 包含图定义、权重、签名函数；支持 TF Serving 原生热加载 | TF 生态、TFX 流水线、大规模分布式 Serving |
| ONNX | 跨框架 | 开放神经网络交换格式；支持算子融合与量化优化 | 跨框架迁移、边缘设备推理、ONNX Runtime |
| TorchScript | PyTorch | 通过 tracing 或 scripting 生成静态图；支持 JIT 优化 | PyTorch 生产部署、LibTorch C++ 推理 |
导出避坑提示： 导出前务必固定算子版本（如 ONNX opset 版本），避免因算子不兼容导致 Serving 端加载失败。建议在 CI 中加入导出后加载验证步骤。
3.2 模型版本管理
生产环境中模型迭代频繁，版本管理是灰度发布与快速回滚的基础。推荐采用语义化版本号 + 存储目录结构的方式：
- 主版本号：架构变更或训练数据源切换时递增，如 v2 → v3。
- 次版本号：新增特征或超参数调优时递增，如 v2.1 → v2.2。
- 补丁版本号：修复数据泄漏或算子 bug 时递增，如 v2.1.1 → v2.1.2。
典型存储结构示例：
models/
├── recommendation/
│ ├── v1.0.0/
│ │ ├── saved_model.pb
│ │ └── variables/
│ ├── v1.1.0/
│ │ ├── saved_model.pb
│ │ └── variables/
│ └── v2.0.0/
│ ├── saved_model.pb
│ └── variables/
└── model_manifest.yaml # 记录版本元信息：上线时间、AUC、回滚标记
最佳实践： 在模型仓库（如 MLflow、DVC）中同时存储模型文件与评估指标，便于自动选择最优版本进行灰度推送。
3.3 模型加载策略
模型加载策略直接影响 Serving 的启动速度、内存占用与请求延迟。常见策略包括：
| 策略 | 加载时机 | 内存开销 | 首次请求延迟 | 适用场景 |
|---|---|---|---|---|
| 预加载 | 服务启动时 | 高（常驻内存） | 低（无冷启动） | 延迟敏感、流量稳定的核心模型 |
| 按需加载 | 首次请求到达时 | 低（按需分配） | 高（冷启动延迟） | 低频调用、多模型共享资源 |
| 预热加载 | 服务启动后、流量接入前 | 中（预热后常驻） | 中（预热阶段阻塞） | 灰度发布、版本切换 |
| 分片加载 | 按模型分片逐步加载 | 可控（分片粒度） | 分片内低延迟 | 超大模型（如推荐模型 > 10GB） |
注意： 按需加载策略下，若模型文件较大（如 > 500MB），首次请求可能超时。建议结合预热加载，在服务注册到服务发现前完成模型加载。
3.4 模型导出→版本管理→加载策略 整体流程
下图展示了从训练完成到生产加载的完整链路：
3.5 灰度发布中的加载策略选择
在灰度发布场景下，推荐采用预热加载 + 版本目录切换的组合策略：
- 导出新模型：使用 SavedModel 或 ONNX 格式，写入
models/v2.0.0/目录。 - 预热加载：Serving 实例在启动后、注册到服务发现前，加载新版本模型并执行 10~100 次推理预热，确保 JIT 编译完成。
- 版本目录切换：通过符号链接或配置中心将
current指向新版本目录，实现秒级切换。 - 灰度流量接入：逐步将 1% → 5% → 20% → 100% 流量导向新版本，监控延迟与错误率。
- 回滚：将
current指回旧版本目录，无需重新加载。
工程经验： 模型加载失败时，Serving 应保持旧版本继续服务，避免因新版本加载异常导致全量宕机。建议在加载流程中加入健康检查探针（Readiness Probe）。