模型序列化与版本管理：Pickle/Joblib/ONNX的使用、模型版本控制策略、模型注册中心概念
模型训练好了，只是万里长征走了一半。另一半，是怎么把它从你的 Jupyter Notebook 里「请」出来，放到生产环境里去干活。我见过不少团队，模型在本地跑得飞起，一上线就崩，原因往往出在序列化和版本管理上。说白了，就是模型「搬家」的时候，东西没打包好，或者搬过去之后不知道哪个版本在跑。
今天我们就聊聊这个环节。我会结合自己踩过的坑，把 Pickle、Joblib、ONNX 这几个工具讲透，再聊聊版本控制和注册中心那点事。
1. 序列化三剑客：Pickle、Joblib、ONNX
序列化，就是把内存里的模型对象，变成可以存到磁盘或网络传输的字节流。反序列化就是逆过程。听起来简单，但选错工具，后面全是泪。
1.1 Pickle：Python 原生的「万能钥匙」
Pickle 是 Python 自带的序列化模块。用法极其简单：
import pickle
# 保存模型
with open('model.pkl', 'wb') as f:
pickle.dump(model, f)
# 加载模型
with open('model.pkl', 'rb') as f:
model = pickle.load(f)
嗯，就这么几行。但我要提醒你，Pickle 有安全问题。我曾经在项目里接过一个外部团队交付的 .pkl 文件，反序列化时直接执行了恶意代码——因为 Pickle 允许在反序列化时执行任意 Python 对象。所以，永远不要加载不可信来源的 Pickle 文件。
另外，Pickle 对大型 NumPy 数组的序列化效率不高。如果你的模型里有很多树模型或深度学习权重，文件会很大，加载也慢。
1.2 Joblib：专为大数据而生
Joblib 是 Scikit-learn 官方推荐的序列化工具。它对 NumPy 数组做了优化，处理大模型时比 Pickle 快得多，文件也更小。
import joblib
# 保存模型
joblib.dump(model, 'model.joblib')
# 加载模型
model = joblib.load('model.joblib')
用法和 Pickle 几乎一样，但底层实现不同。Joblib 会把大的 NumPy 数组单独存成 .npy 文件，然后打包。所以你会看到保存后生成一个文件夹，而不是单个文件。
我个人习惯，只要是 Scikit-learn、XGBoost、LightGBM 这类基于 NumPy 的模型，一律用 Joblib。Pickle 只用在一些简单的、非数值型的对象上。
compress=3 参数，文件能缩小 3-5 倍，加载速度几乎不变。
1.3 ONNX：跨语言、跨平台的「通用语言」
Pickle 和 Joblib 都只能用于 Python 环境。但现实是，你的模型可能要在 Java、C++、Go 甚至移动端上跑。这时候，ONNX（Open Neural Network Exchange）就派上用场了。
ONNX 是一种开放的模型表示格式。你可以把训练好的模型（PyTorch、TensorFlow、Scikit-learn 等）导出为 ONNX 格式，然后在任何支持 ONNX Runtime 的环境中运行。
import onnx
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
# 假设你有一个训练好的 RandomForest 模型
initial_type = [('float_input', FloatTensorType([None, 4]))]
onnx_model = convert_sklearn(model, initial_types=initial_type)
# 保存 ONNX 模型
with open('model.onnx', 'wb') as f:
f.write(onnx_model.SerializeToString())
加载和推理也很简单：
import onnxruntime as ort
sess = ort.InferenceSession('model.onnx')
input_name = sess.get_inputs()[0].name
output = sess.run(None, {input_name: input_data})
我为什么推荐 ONNX？因为它解耦了训练和推理环境。你可以在 Python 里训练，在 Java 服务里推理，互不干扰。而且 ONNX Runtime 做了大量优化，推理速度往往比原框架还快。
2. 模型版本控制策略
模型不是一次性的。你会不断迭代、调参、换特征。如果没有版本控制，你根本不知道线上跑的是哪个版本，出了问题也回滚不了。
我见过最惨的一次：某团队把新模型直接覆盖了旧模型文件，结果新模型有 bug，线上坏了一整天，却找不到旧模型在哪。嗯，从那以后，我再也不敢不做版本控制了。
2.1 语义化版本号
参考软件工程的语义化版本（SemVer），我建议模型版本也采用 MAJOR.MINOR.PATCH 格式：
- MAJOR：重大架构变更，比如从 LR 换成 DNN，或者特征体系重构。
- MINOR：新增特征、调参、换算法（但架构不变）。
- PATCH：bug 修复、数据修正、小优化。
举个例子：v2.3.1 表示第 2 个大版本的第 3 次小迭代，修复了一个 bug。
2.2 存储策略
我习惯用文件系统或对象存储来管理模型文件，目录结构如下：
models/
├── credit_score/
│ ├── v1.0.0/
│ │ ├── model.joblib
│ │ ├── config.yaml
│ │ └── metrics.json
│ ├── v1.1.0/
│ │ ├── model.joblib
│ │ └── ...
│ └── v2.0.0/
│ └── ...
└── fraud_detection/
└── ...
每个版本目录里，除了模型文件，还要保存配置（特征列表、超参数）和评估指标。这样你随时可以回溯：哪个版本在什么数据上表现如何。
2.3 回滚策略
线上模型出问题时，回滚是第一要务。我建议：
- 保留最近 3-5 个版本的模型文件，不要删除。
- 回滚时，先切回旧版本，再排查问题。不要边排查边修，那样线上损失会持续扩大。
- 回滚后，要验证旧版本在当前数据上是否仍然有效。有时候数据分布变了，旧版本可能也不灵了。
3. 模型注册中心概念
当团队规模变大、模型数量变多，文件系统就不够用了。你需要一个模型注册中心——说白了，就是一个集中管理模型元数据、版本、状态、部署信息的系统。
3.1 注册中心的核心功能
| 功能 | 说明 |
|---|---|
| 模型存储 | 统一存放模型文件，支持版本管理 |
| 元数据管理 | 记录模型名称、版本、作者、训练时间、评估指标等 |
| 状态管理 | 标记模型为「开发中」「已上线」「已下线」「已回滚」等 |
| 部署集成 | 与 CI/CD 管道联动，自动部署指定版本 |
| 权限控制 | 谁可以发布新版本？谁可以上线？谁可以回滚？ |
3.2 常见工具
- MLflow Model Registry：开源，与 MLflow 深度集成，支持 REST API，适合中小团队。
- Kubeflow：基于 Kubernetes，适合大规模、多租户场景。
- DVC + 对象存储：轻量级方案，用 Git 管理版本，用 S3 存模型文件。
我个人比较喜欢 MLflow。它简单、直观，而且和 Python 生态无缝衔接。你只需要几行代码就能把模型注册进去：
import mlflow
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("credit_score_model")
with mlflow.start_run():
mlflow.sklearn.log_model(model, "model")
mlflow.log_param("n_estimators", 100)
mlflow.log_metric("auc", 0.85)
mlflow.register_model("runs:/<run_id>/model", "CreditScoreModel")
注册后，你可以在 MLflow UI 里看到所有版本，并一键部署到指定环境。
4. 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以看到，从训练到部署，序列化、版本控制、注册中心三者缺一不可。
你看，训练好的模型，先序列化成文件，再打上版本号，最后注册到中心。部署时，直接从注册中心拉取指定版本，干净利落。
好了，模型序列化和版本管理这块，核心就是这些。工具选对、版本管好、注册中心用起来，你的模型部署之路会顺畅很多。下一节我们聊聊模型监控，那又是另一片天地了。
公众号:蓝海资料掘金营，微信deep3321