模型版本管理：从 DVC 到 Model Registry 的完整指南

💡 本文你将学到：

• 模型版本管理的完整体系——为什么 Git 不够用，需要 DVC + MLflow 的组合方案
• **模型注册表（Model Registry）**的核心概念和四个生命周期阶段
• 数据与模型的联合版本控制——如何通过 DVC 实现模型-数据-代码的三位一体追溯
• 模型版本管理在企业中的落地方案——从个人项目到企业级平台
• 实际代码示例——DVC 追踪、MLflow 注册、Hugging Face Hub 发布

⚠️ 本文是 AI 工程化 系列文章的第 4 篇，建议先阅读 aieng-003（实验管理与追踪），了解实验记录的基础知识。

在 AI 工程中，模型版本管理是最容易被低估、但一旦出问题就最致命的环节。

很多团队在初期用 Git 管理代码，这很自然——Git 就是为代码设计的。但当模型文件出现时，问题就来了：一个微调后的 BERT 模型可能有 400MB-2GB，一个图像分割模型可能达到 5GB。Git 对大文件的处理效率极低，仓库体积迅速膨胀。

但这只是表面问题。更深层的挑战在于模型的「多维性」——一个模型不仅仅是一个文件，它是多个维度的产物：

训练代码版本：训练脚本的哪个 commit 生成了这个模型？超参数是什么？

训练数据版本：用哪个版本的数据集训练的？数据预处理流程是什么？

依赖环境版本：PyTorch 1.13 还是 2.0？CUDA 11.8 还是 12.0？

评估指标版本：这个模型在测试集上的准确率、F1 分数、推理延迟是多少？

部署状态版本：这个模型当前在哪个环境运行？开发？测试？生产？

如果缺少模型版本管理，会出现以下灾难场景：

场景一：生产事故无法回滚。线上模型突然出现性能下降，但你不知道当前运行的是哪个版本、用什么数据训练的、和哪个旧版本有差异。没有版本记录，回滚就变成盲人摸象。

场景二：模型效果无法复现。三个月前的模型效果很好，但现在无法复现——因为数据已经更新了、代码已经改了、环境已经升了。没有版本追溯，好的模型就变成了一次性的。

场景三：团队协作混乱。数据科学家 A 训练了模型 v3，部署了模型 v5，数据科学家 B 基于 v4 继续微调。如果没有统一的版本注册表，没有人能说出「当前最好的模型是哪个」。

模型版本管理的核心目标：让每一个产出模型都可追溯、可复现、可比较、可回滚。这四个「可」是评估任何模型版本管理方案是否合格的铁律。

模型注册表（Model Registry）是模型版本管理的核心组件。它是一个集中的、有状态的模型仓库，记录了每个模型的所有版本、元数据、生命周期状态和性能指标。

模型注册表的四个生命周期阶段：

None（未分类）：模型刚训练完成，还未被评审和分类。通常由训练脚本自动注册到这个阶段。

Staging（测试环境）：模型通过了基本的指标验证，被部署到测试环境中进行进一步验证。从 None 到 Staging 通常需要人工审批或自动化规则（如准确率高于阈值）。

Production（生产环境）：模型通过了所有验证，正在生产环境中服务真实用户。这是最有价值的状态——它意味着这个模型是当前线上服务使用的版本。

Archived（已归档）：模型已被新版本替代，不再活跃使用。归档不是删除——保留归档记录对于审计、回滚和知识积累至关重要。

模型注册表的核心功能：

版本编号：每个模型有独立的版本号序列（v1, v2, v3...），不同模型的版本号互不干扰。

元数据追踪：每个版本记录训练参数、数据集版本、依赖环境、评估指标等完整信息。

状态转换：支持在状态之间转换（Staging → Production），每次转换都有审计日志。

比较能力：可以在注册表中直接对比不同版本的指标，回答「v3 比 v2 好在哪里」这个问题。

权限控制：谁可以将模型从 Staging 提升到 Production？谁可以删除版本？这些都需要明确的权限规则。

**DVC（Data Version Control）**是专门为机器学设计的版本控制工具。它的核心理念很简单：用 Git 管理元数据和流程，用 DVC 管理大文件（数据和模型）。

DVC 的工作原理：当你对一个大文件（如模型权重文件 .pt）执行 dvc add 时，DVC 不会把文件本身存入 Git 仓库。相反，它做两件事：将文件内容哈希后存储在远端（S3、GCS、SSH 等），在本地生成一个 .dvc 元数据文件（只有几百字节），这个 .dvc 文件记录了文件的哈希值和远端地址。

这个设计非常巧妙：Git 只追踪轻量级的 .dvc 元数据文件，仓库体积保持在合理范围；实际的模型文件存储在远端，通过哈希值确保内容不可篡改——如果文件内容变了，哈希值就变了，DVC 就能检测到。

DVC 的核心能力：

数据与模型版本追踪：每一次 dvc add 都是一次版本快照。你可以随时 checkout 到历史版本。

数据管道（Pipeline）：DVC 可以定义从原始数据 → 预处理 → 训练 → 评估的完整流水线。每个步骤的输入输出都被版本化。

实验管理：DVC 支持在同一个数据集上运行多次实验（不同超参数），自动记录每次实验的结果。

远端存储：支持 S3、GCS、Azure Blob、SSH、本地网络存储等多种远端。团队共享模型文件时，每个人都从远端拉取。

DVC 与 Git 的协同工作流：

git add 代码文件（.py、.yaml），dvc add 数据/模型文件（.csv、.pt），然后 git commit 包含两者。这样，每个 Git commit 不仅记录了代码状态，还通过 .dvc 文件记录了对应的数据和模型版本。一个 commit 就是一个完整的、可复现的实验快照。

# ML 模型版本管理实战：使用 DVC + Git 管理模型和数据
import dvc
from pathlib import Path

# 初始化 DVC 项目
dvc_project = dvc.Repo()

# 追踪模型文件
model_path = Path("models/bert-finetuned-v3.pt")
dvc_project.add(str(model_path))

# 追踪训练数据集
data_path = Path("data/training-dataset-v2.csv")
dvc_project.add(str(data_path))

# 查看版本历史
history = dvc_project.history.show(str(model_path))
for version in history:
    print(f"版本: {version.revision}, 大小: {version.size}, 时间: {version.timestamp}")

# 切换到特定版本
dvc_project.checkout(str(model_path), rev="v2.1")

MLflow 是目前最流行的开源 ML 生命周期管理平台，其 Model Registry 组件提供了企业级的模型版本管理能力。

MLflow 的设计哲学是实验与注册分离：MLflow Tracking 负责记录实验（每次训练运行的参数、指标、输出文件），MLflow Model Registry 负责管理模型的版本和生命周期。

MLflow 注册表的工作流程：

第一步：训练并记录实验。使用 MLflow Tracking API 记录训练过程中的所有信息——超参数、数据集路径、模型架构、评估指标。训练完成后，模型自动保存为 MLflow Model 格式（包含模型权重、依赖定义、推理代码）。

第二步：注册模型。将训练好的模型注册到 Model Registry，获得第一个版本号（v1）。注册时可以添加描述性标签（如模型类型、业务用途）。

第三步：版本评审。团队成员在 MLflow UI 中查看 v1 的指标、对比历史版本、评估是否达到生产标准。如果达标，将状态从 None 提升为 Staging。

第四步：部署与提升。Staging 环境验证通过后，提升为 Production。MLflow 支持自动提升规则——例如「准确率高于 90% 且推理延迟低于 50ms 的模型自动提升为 Production」。

MLflow 的高级功能：

模型别名（Aliases）：除了版本号，可以给模型起别名（如 "best-model"、"canary"），方便在代码中引用而不必硬编码版本号。

模型描述和注释：每个版本可以添加文本描述和注释，记录为什么发布这个版本、做了哪些改动、已知问题等。这是知识传递的重要渠道。

Webhook 集成：当模型状态变化时触发 Webhook，自动通知 CI/CD 系统重新部署、或通知 Slack 频道告知团队。

模型签名（Model Signature）：定义模型的输入输出 schema，在部署时自动验证输入数据的格式是否正确。

# MLflow 模型注册表配置示例
name: text-classification-model
description: "基于 BERT 的文本分类模型，用于客户反馈自动分类"
tags:
  framework: pytorch
  model_type: bert-base-chinese
  business_domain: customer_service

versions:
  - version: 1
    status: archived
    metrics:
      accuracy: 0.87
      f1_score: 0.85
      inference_latency_ms: 45
    source_run: "experiments/run-20260315"
    
  - version: 2
    status: staging
    metrics:
      accuracy: 0.91
      f1_score: 0.89
      inference_latency_ms: 38
    source_run: "experiments/run-20260410"
    
  - version: 3
    status: production
    metrics:
      accuracy: 0.93
      f1_score: 0.92
      inference_latency_ms: 32
    source_run: "experiments/run-20260515"

promotion_rules:
  - from: staging
    to: production
    requires:
      - accuracy >= 0.90
      - f1_score >= 0.88
      - approval: "ml_team_lead"

Hugging Face Hub 是当前全球最大的 AI 模型共享平台，截至 2026 年已有超过 200 万个模型。它提供了一种不同于企业内部注册表的模型版本管理方式——基于 Git 的、社区驱动的、公开透明的版本管理。

Hugging Face Hub 的核心设计：每个模型仓库就是一个 Git 仓库。模型文件、训练代码、配置文件、README 文档都在同一个仓库中。这意味着你可以用标准的 Git 操作来管理模型版本——commit、branch、tag 都可以用。

Hugging Face Hub 的独特能力：

Git LFS 支持：大模型文件通过 Git LFS（Large File Storage）管理，结合了 Git 的版本控制能力和对大文件的友好处理。

模型卡片（Model Card）：每个模型都有标准化的文档页面，描述模型的用途、训练方法、限制、偏见、许可证等。这是 AI 模型透明度的行业标准。

社区协作：任何人都可以对模型仓库提交 Pull Request，提出改进建议、修复 Bug、添加新版本的模型。这种开放协作模式是 Hugging Face Hub 快速增长的核心动力。

Spaces 和 Demos：模型可以直接在 Hub 上部署交互式演示（Gradio、Streamlit），让其他人无需下载就能体验模型效果。

版本标签（Tags）：通过 Git tag 标记重要版本（如 v1.0、v2.0-optimized），方便快速定位特定版本。

适用场景对比：Hugging Face Hub 适合开源项目、社区协作、模型分享场景；MLflow 适合企业内部、封闭团队、生产部署场景。两者不是替代关系，而是互补——很多企业用 MLflow 管理内部模型生命周期，在模型稳定后发布到 Hugging Face Hub 供社区使用。

模型版本管理的最高境界是三位一体的追溯能力——给定任何一个线上运行的模型，都能精确追溯到：

它是什么代码训练出来的（Git commit hash）

它用了哪个版本的数据（DVC commit hash）

它在什么环境中运行的（Docker image tag 或 Conda environment lock）

这种追溯能力为什么重要？

合规审计：在金融、医疗等受监管行业，你必须能证明线上模型的来源和训练过程。监管机构会问：「这个模型的训练数据是否包含个人隐私？训练代码是否经过了安全审查？」三位一体追溯让这些问题都有据可查。

问题排查：线上模型突然出现偏差（Bias），你需要快速定位原因：是数据漂移？代码 Bug？还是环境变更？有了完整的追溯链，你可以在几分钟内定位到具体的 commit 和数据版本，而不是花几天时间逐个排查。

知识传承：团队成员离开后，新成员接手模型项目。如果有完整的版本追溯记录，新成员可以理解「为什么选择这个模型版本」「训练数据有什么特点」「遇到过什么问题」，而不需要从零开始摸索。

实现三位一体追溯的技术方案：

方案一：DVC Pipeline + Git 整合。在 DVC pipeline（dvc.yaml）中定义从数据到模型的完整流程，每个步骤关联一个 Git commit。每次 pipeline 执行后，DVC 自动记录代码版本、数据版本和模型版本之间的关系。

方案二：MLflow + Git 整合。MLflow 在记录实验时自动捕获当前 Git commit hash。在 MLflow UI 中，每次实验都显示对应的代码版本。

方案三：定制化元数据服务。在大型团队中，可以搭建一个元数据服务（Metadata Service），统一管理模型、数据、代码之间的关联关系。每次模型发布时，服务自动记录完整的追溯链。

在企业环境中落地模型版本管理，需要考虑的不仅仅是技术选型，还有组织架构、流程规范、和合规要求。

企业模型版本管理的三个层级：

团队级（Team Level）：小型数据科学团队（3-10 人）可以使用 DVC + Git + MLflow 的开源组合。DVC 管理数据和模型文件，Git 管理代码和配置，MLflow 记录实验和管理注册表。这种方案成本低、灵活性高，适合敏捷团队。

部门级（Department Level）：当多个团队共享模型时，需要集中的模型注册表平台。可以在 MLflow Tracking Server 的基础上，搭建共享的 Model Registry，配合权限管理（谁可以注册模型、谁可以提升为 Production）。同时引入模型审批流程——生产模型必须经过至少两人的评审。

企业级（Enterprise Level）：大型企业需要端到端的 MLOps 平台，整合模型版本管理、数据治理、CI/CD、监控告警、合规审计。常见方案包括：Databricks Unity Catalog、AWS SageMaker Model Registry、Azure ML Model Registry 等云平台方案，或基于 MLflow + Kubeflow + DVC 的自建方案。

企业模型版本管理的关键实践：

命名规范：制定统一的模型命名规则（如 「业务域-模型类型-版本号」），避免不同团队使用冲突的名称。

保留策略：不是所有版本都需要永久保留。制定保留策略：Production 版本永久保留，Staging 版本保留 90 天，None 版本保留 30 天。合理的保留策略可以控制存储成本。

自动化测试：每次模型注册或状态提升时，自动运行测试套件（性能测试、偏差检测、鲁棒性测试）。只有通过测试的模型才能进入下一阶段。

变更管理：生产模型的替换（v2 → v3）必须经过变更管理流程——包括影响评估、灰度发布、回滚计划。这和传统软件的发布流程本质上是一样的。

审计日志：所有模型版本操作（注册、提升、删除、回滚）都必须有审计日志，记录操作人、时间、原因。这是合规审计的基础要求。

在模型版本管理的实践中，有一些反复出现的反模式——看似合理但实际有害的做法。识别这些反模式，可以避免走弯路。

反模式一：只管理模型文件，不管数据和代码。这是最常见的错误。团队花精力把模型文件存入注册表，但不知道这个模型是用什么数据和代码训练的。结果：模型可存储但不可复现。正确做法：模型、数据、代码必须三位一体。

反模式二：版本号用日期而不是递增序列。用 20260521 作为版本号看起来直观，但一天可能训练多个模型，日期无法区分。正确做法：使用递增版本号（v1、v2、v3），日期作为元数据记录。

反模式三：删除「不好」的模型版本。团队认为 v2 效果不好，直接删除。但如果 v2 中使用了某个后来发现有效的技巧呢？ 正确做法：标记为 Archived 而不是删除。存储成本远低于知识丢失的成本。

反模式四：没有定义模型的「成功标准」。团队成员各自判断模型是否可以上线，标准不统一。正确做法：在模型注册前就定义明确的指标阈值（准确率、延迟、偏差等），用数据而不是感觉来决定模型是否可以上线。

反模式五：模型版本管理和 CI/CD 脱节。模型版本由数据科学家手动管理，部署由运维团队通过另一套流程执行。两者之间没有自动化连接。结果：注册表中的 Production 版本和实际线上运行的版本不一致。正确做法：将模型版本管理与 CI/CD 流水线整合，模型状态变化自动触发部署。

反模式六：忽视模型的文件格式演进。同一个模型，v1 用 PyTorch 格式，v2 用 ONNX 格式，v3 用 TensorRT 格式。如果注册表不记录格式信息，部署时可能选错格式导致推理失败。正确做法：在模型元数据中记录格式、框架版本、和兼容性信息。

截至 2026 年，模型版本管理领域出现了几个值得关注的新趋势。

大模型版本管理的特殊性：随着模型规模从几十 GB 增长到数百 GB（甚至 TB 级别），传统的模型版本管理方式面临挑战。LoRA 和 Adapter 的流行改变了游戏规则——你不再需要为每次微调保存完整的模型权重，只需要保存轻量级的 LoRA 权重（几 MB 到几百 MB）。这意味着模型版本管理的粒度变得更细——基础模型（Base Model）+ LoRA 适配器（Adapter）的组合可以产生指数级的模型变体。

模型版本的「组合式管理」：2026 年的最佳实践是将模型分解为可组合的组件——基础模型、LoRA 适配器、Prompt 模板、推理配置，各自独立版本化。这样可以灵活组合不同的组件，而不必为每种组合创建完整的模型副本。

自动化模型治理：随着 AI 监管法规的完善（如欧盟 AI Act），模型版本管理正在与合规审计自动化整合。模型注册表现在需要记录偏见检测结果、公平性指标、数据使用许可等信息，以满足监管要求。

模型版本的「供应链安全」：类似于软件供应链安全（SBOM），AI 领域也在推进模型物料清单（Model BOM）——记录模型的完整供应链：基础模型来源、训练数据来源、依赖库版本、安全扫描结果等。Hugging Face 的 Open Model Card 标准和 NIST 的 AI RMF 框架正在推动这一趋势。

边缘模型的版本管理：随着 AI 向边缘设备扩展（手机、IoT、汽车），模型版本管理需要考虑离线环境下的版本同步。边缘设备可能断网运行数周，如何在网络恢复后安全地同步最新版本，是一个新的挑战。

模型版本管理是 AI 工程化的基石。没有可靠的版本管理，AI 系统的可复现性、可追溯性、和可治理性都无从谈起。

本文的核心要点回顾：

模型不是单一文件，而是代码、数据、环境的多维产物。管理模型版本必须同时管理这三个维度。

模型注册表是版本管理的核心组件，提供版本编号、状态流转、指标比较、权限控制等能力。

DVC + MLflow + Hugging Face Hub 是目前最主流的三套方案，分别适用于端到端追溯、企业级管理、和社区协作场景。

三位一体追溯（代码-数据-环境）是模型版本管理的最高目标，在合规审计、问题排查、知识传承中都有不可替代的价值。

反模式识别比工具选择更重要。理解了常见反模式，可以避免在工具选型和流程设计上走弯路。

扩展阅读建议：

aieng-003（实验管理与追踪）：了解如何记录和管理 ML 实验。

mlops-002（模型版本管理与实验追踪）：本文的姐妹篇，侧重 MLOps 视角。

aieng-007（模型监控与告警）：模型上线后如何监控性能变化和数据漂移。

ethics-003（隐私保护 ML）：模型版本管理中的隐私和数据安全考虑。

外部资源：

DVC 官方文档：dvc.org/doc

MLflow 官方文档：mlflow.org/docs

Hugging Face Model Hub：huggingface.co/models

NIST AI Risk Management Framework：nist.gov/ai-risk-management-framework