深度学习项目发展到一定阶段后，往往会面临同一个困境：硬盘里躺着几十个模型文件，文件名从model_final.pt、model_final_v2.pt一路写到model_final_真的最终版.pt，谁也说不清哪个模型对应哪组超参数，实验结果无法复现，线上服务用的到底是哪个版本更是一笔糊涂账。MLflow正是为了解决这类问题而生的开源框架，它把机器学习生命周期拆解为实验跟踪（Tracking）、项目打包（Projects）、模型管理（Models）和模型注册（Model Registry）四大模块。本文聚焦其中最实用的两环：如何借助MLflow管理神经网络训练产生的多版本模型，以及如何把指定版本的模型部署成RESTful API服务。
一、环境搭建与核心概念速览
MLflow的安装非常轻量，通过pip即可完成。建议同时安装mlflow-sklearn之外的深度学习相关依赖，本文示例使用PyTorch。安装完成后，在任意目录执行mlflow ui命令，即可在本地5000端口启动一个可视化界面，所有实验记录都会呈现在浏览器中。
pip install mlflow torch torchvision fastapi mlflow ui --host 0.0.0.0 --port 5000
在动手写代码之前，需要理解三个核心概念。Experiment（实验）是记录的顶层容器，例如一个图像分类项目可以是一个Experiment；Run（运行）对应一次具体的训练过程，每次训练自动生成唯一的run_id；Model Registry（模型注册中心）则是模型的版本仓库，每个注册的模型（Registered Model）可以拥有多个版本（Version），并带有Staging、Production、Archived等阶段标签。这三层结构组合起来，正好对应了从实验到上线的完整链路。
值得强调的是，MLflow的后端存储是可插拔的。默认情况下元数据存在本地./mlruns目录，生产环境建议改用MySQL或PostgreSQL存储元数据，模型文件本身则放到对象存储或共享文件系统上，这样多人协作和多机部署才有可靠的基础。
二、在神经网络训练中集成MLflow跟踪
集成方式非常直接：在训练脚本的开始处启动一个run，在训练过程中把学习率、batch size、epoch数等超参数记录下来，每个epoch结束后记录loss和准确率等指标，训练结束后把模型保存进当前run。MLflow支持自动日志功能mlflow.pytorch.autolog()，它会自动捕获模型结构、参数和训练指标，但手动记录能提供更精细的控制，下面是一个典型的手动记录示例。
import mlflow
import torch
import torch.nn as nn
# 设置实验名称，不存在会自动创建
mlflow.set_experiment("cifar10-classification")
with mlflow.start_run() as run:
# 记录超参数
mlflow.log_params({
"lr": 0.001,
"batch_size": 64,
"epochs": 20,
"model": "resnet18"
})
model = build_model() # 自定义的模型构建函数
for epoch in range(20):
train_loss, acc = train_one_epoch(model, epoch)
# 每轮记录指标，可在UI中绘制曲线
mlflow.log_metric("train_loss", train_loss, step=epoch)
mlflow.log_metric("train_acc", acc, step=epoch)
# 保存模型到当前run，mlflow会记录模型格式和依赖
mlflow.pytorch.log_model(model, artifact_path="model")
print("run_id:", run.info.run_id)这段代码执行后，打开MLflow UI就能看到每次训练的完整记录：参数、指标曲线、模型文件、运行时间、代码版本一目了然。对比不同学习率或网络结构的效果时，不再需要翻阅零散的日志文件，直接在界面中按指标排序即可筛选出最优的那次运行。这种可追溯性带来的价值远超想象，当线上模型出现问题时，你能立刻定位到它当时的训练环境和完整参数。
需要注意指标记录中的step参数，它决定了曲线图的横轴。如果不传step，多次记录同名指标会被视为多次实验而非时间序列，曲线会变成散点，这是新手最常踩的坑之一。
三、模型注册与版本管理实战
训练出好模型后，下一步是把它注册到Model Registry。注册后的模型拥有独立的名字和递增的版本号，每次注册一个新模型文件，版本号自动加一，历史版本全部保留。可以用代码注册，也可以在UI界面中操作。
result = mlflow.register_model(
# run路径指向刚才保存的模型
model_uri=f"runs:/{run_id}/model",
name="cifar10-resnet"
)
print("注册的模型版本:", result.version)
# 将版本1切换到生产阶段
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
name="cifar10-resnet",
version=1,
stage="Production"
)阶段（Stage）机制是版本管理的关键设计。Staging表示测试阶段，团队内部验证通过后切换到Production供线上服务加载，旧的线上模型则移入Archived归档。线上服务始终加载Production阶段的最新版本，这意味着模型更新时只需切换阶段标签，服务端无需修改任何代码，配合简单的重启逻辑即可实现热更新式的模型迭代。
回滚同样简单：假设版本3上线后指标下降，只需把版本2重新切回Production，服务重启后自动加载旧版本。整个过程在UI中留有完整的审计记录，谁在什么时间做了什么变更都可查证，这在合规要求较高的金融和医疗场景中尤其重要。
四、将模型发布为RESTful API服务
模型管理的终点是服务化。MLflow内置了mlflow models serve命令，可以把注册的模型直接启动为REST服务，默认使用环境分数组格式接收输入。对于深度学习模型，推荐使用pyfunc风格部署，它提供了统一的调用接口。
mlflow models serve \ --model-uri models:/cifar10-resnet/Production \ --port 8000 \ --host 0.0.0.0
服务启动后即可用HTTP请求推理。输入数据需要包装成JSON格式的dataframe_split或张量结构，下面用Python模拟一次调用。
import requests
import json
payload = {
"inputs": [[0.1, 0.2, 0.3, 0.4]] # 简化的特征向量
}
resp = requests.post(
"http://127.0.0.1:8000/invocations",
data=json.dumps(payload),
headers={"Content-Type": "application/json"}
)
print(resp.json())其中models:/cifar10-resnet/Production这种URI写法表示加载该模型处于Production阶段的最新版本，也可以直接写models:/cifar10-resnet/2指定具体版本。内置服务适合快速验证，但生产环境往往需要更多控制，此时可以只用MLflow做模型加载，用Fastapi或gRPC自建服务框架，再配合Docker容器化和Nginx负载均衡，构建出高可用的推理服务集群。
五、总结
MLflow把模型从训练到上线之间的混乱环节梳理成了清晰的流水线：Tracking记录每次实验的完整上下文，Registry以版本号和阶段标签管理模型资产，内置的serve命令则打通了部署的最后一公里。对于小团队而言，这套方案几乎零成本就能建立起规范化的模型管理流程；对于大型团队，MLflow的元数据库和对象存储都可以水平扩展，还能与Kubernetes、CI/CD流水线无缝衔接。建议从当前项目的一个训练脚本开始接入，先体验参数与指标的自动归档，再逐步引入模型注册和服务化，最终形成一套可追溯、可回滚、可持续迭代的模型工程体系。