模型版本管理基础设施：大规模管理机器学习工件

更新于 2025 年 12 月 11 日

2025 年 12 月更新： MLflow 3.0 将注册表扩展至生成式 AI 和 AI 智能体——将模型与代码版本、提示词配置、评估运行和部署元数据关联起来。模型版本管理现在不仅追踪权重，还追踪微调适配器、提示词模板和检索配置。动辄数百 GB 的大语言模型权重需要超越 Git 的专用基础设施。

MLflow 3.0 扩展了其模型注册表以处理生成式 AI 应用和 AI 智能体，将模型与精确的代码版本、提示词配置、评估运行和部署元数据关联起来。¹ 这一演进反映了"模型版本管理"含义的根本转变——从追踪简单的 pickle 文件，到管理包含多个微调适配器、提示词模板和检索配置的复杂系统。运行生产环境 AI 的组织需要的基础设施不仅要对权重进行版本控制，还要管理可靠复现和部署模型所需的完整上下文。

与传统软件版本控制不同，机器学习模型版本管理涉及追踪大型二进制文件、复杂的训练配置、数据集版本和评估指标——同时还要满足可复现性和合规性要求。² 对于大语言模型而言，挑战更加复杂：微调模型快速增殖，而提示词工程又增加了另一层需要版本控制的工件。

为什么模型版本管理至关重要

生产环境的机器学习系统会悄无声息地失效。模型性能随时间衰退，微调版本表现出乎意料地不佳，而没有适当的版本控制，团队无法识别发生了什么变化，也无法回滚到已知良好的状态。

版本管理的挑战

二进制工件： 模型权重从经典机器学习的几兆字节到大语言模型的数百吉字节不等。Git 无法高效处理这些文件；专用基础设施变得必不可少。

配置爆炸： 单个模型涉及训练代码、超参数、数据预处理、特征工程和部署配置。任何变更都可能影响模型行为。

数据集依赖： 模型质量取决于训练数据。没有数据集版本控制，即使代码完全相同也无法复现模型。

评估耦合： 在特定测试集上的性能指标决定部署决策。这些指标必须与模型版本永久关联。

业务需求

可复现性： 金融和医疗行业的监管要求必须能够重建任意时间点部署的精确模型版本。³

可审计性： 合规要求将已部署模型追溯到训练数据、代码以及批准部署的决策者。

回滚能力： 生产事故需要在几分钟内（而非几小时）恢复到之前的模型版本。

协作： 多名数据科学家同时处理同一模型时，需要明确的所有权和模型工件冲突解决机制。

模型注册表架构

模型注册表作为中央仓库，管理机器学习模型从开发到生产的整个生命周期：⁴

核心组件

版本控制： 每个模型版本获得唯一标识符，通常结合模型名称与语义版本（v1.2.3）或基于哈希的标识符。

元数据存储： 训练参数、评估指标、数据血缘和部署历史与模型工件一起持久化存储。

工件存储： 模型权重、配置文件和关联资产存储在可扩展的对象存储中（S3、GCS、Azure Blob）。

生命周期管理： 模型在各阶段之间转换——开发、预发布、生产、归档——每次转换都有治理控制。

注册表工作流

训练任务 → 注册模型 → 预发布审核 → 生产部署
     ↓              ↓               ↓                    ↓
  记录指标      生成版本 ID      记录审批            监控流量路由

注册： 训练流水线自动注册成功的模型及关联元数据： - 训练运行 ID 和实验上下文 - 超参数和配置 - 留出数据上的评估指标 - 数据版本引用 - 代码提交哈希

预发布： 候选模型在投入生产前进行验证： - 针对基准的自动化测试 - 敏感应用的人工审核 - 与当前生产模型的 A/B 测试 - 推理延迟的性能分析

晋升： 经批准的模型部署到生产环境： - 流量逐步切换到新版本 - 监控检测性能下降 - 指标下降时触发回滚

平台对比

MLflow

MLflow 提供最全面的开源模型注册表：⁵

模型注册表功能： - 支持版本控制和别名的集中式模型存储 - 血缘追踪（实验 → 运行 → 模型） - 阶段转换（Staging、Production、Archived） - 注释和元数据标签 - 用于编程访问的 REST API

MLflow 3.0 增强功能： - LoggedModel 实体将模型与代码、提示词和评估关联 - 增强的生成式 AI 应用追踪 - 复杂 AI 系统的智能体支持 - Databricks 提供托管企业版

示例工作流：

import mlflow

# 训练期间记录模型
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# 注册到模型注册表
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# 晋升到生产环境
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

最适合： 希望获得全面 MLOps 能力且保持开源灵活性的组织。

Weights & Biases

W&B 强调实验追踪与强大的工件版本控制：⁶

核心能力： - 具有丰富可视化的实验追踪 - 带血缘图的工件版本控制 - 支持别名的模型注册表（@champion、@production） - 团队工作流的协作功能 - 与主流机器学习框架的集成

工件版本控制：

import wandb

run = wandb.init(project="nlp-models")

# 将模型记录为工件
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# 使用别名链接到注册表
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

注意事项： 云优先架构需要将数据发送到外部服务器，这可能与严格的数据隐私要求相冲突。

最适合： 优先考虑实验追踪和协作且希望最小化设置开销的团队。

DVC（数据版本控制）

DVC 将 Git 扩展到大文件和数据集：⁷

架构： - 类 Git 命令（dvc add、dvc push、dvc pull） - 元数据文件在 Git 中追踪，大文件存储在远程存储 - 可复现实验的流水线定义 - 多种存储后端（S3、GCS、Azure、SSH）

最新进展： DVC 加入了 lakeFS 家族，lakeFS 作为 PB 级数据版本控制的企业标准。

示例工作流：

# 将大型模型文件添加到 DVC
dvc add models/bert-finetuned.pt

# 将元数据提交到 Git
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# 推送到远程存储
dvc push

# 从任意提交复现
git checkout v1.0
dvc checkout

最适合： 拥有现有 Git 工作流且希望获得轻量级数据和模型版本控制的团队。

云原生注册表

Vertex AI Model Registry（Google Cloud）：⁸ - 原生 GCP 集成 - 直接部署到端点 - 自动血缘追踪 - 与 Vertex AI Pipelines 集成

Amazon SageMaker Model Registry： - AWS 生态系统集成 - 审批工作流 - 跨账户模型共享 - 与 SageMaker Pipelines 集成

Azure ML Model Registry： - Azure 集成 - MLflow 兼容性 - 托管端点部署

最适合： 已承诺使用特定云提供商并希望获得原生集成的组织。

大语言模型特殊考虑

大语言模型带来了超越传统机器学习的独特版本控制挑战：⁹

需要版本控制的内容

基础模型： 追踪哪个基础模型（Llama 3.1-8B、GPT-4、Claude）作为起点。

微调权重： 全量微调产生全新的权重文件；LoRA 适配器产生引用基础模型的小型增量文件。

提示词模板： 系统提示词、少样本示例和指令格式显著影响模型行为。

检索配置： RAG 系统需要对嵌入模型、分块策略和检索参数进行版本控制。

大语言模型的语义版本控制

采用语义版本控制来传达变更的重要性：¹⁰

主版本（v2.0.0）： - 不同的基础模型 - 架构变更 - 破坏性 API 变更

次版本（v1.3.0）： - 在新数据上微调 - 显著的性能改进 - 新增能力

补丁版本（v1.2.1）： - 错误修复 - 小幅优化 - 配置更新

适配器管理

LoRA 和 QLoRA 创建大量增殖的适配器文件，需要系统化组织：

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

适配器版本控制策略： - 适配器与基础模型独立进行版本控制 - 记录兼容的基础模型版本 - 追踪每个适配器的训练数据和超参数 - 在服务中支持适配器快速切换

部署策略

金丝雀部署

在全面上线前将小比例流量路由到新模型版本：¹¹

# Kubernetes 金丝雀配置
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

流程： 1. 将新版本与生产版本并行部署 2. 将 5-10% 的流量路由到新版本 3. 监控指标（延迟、错误率、业务指标） 4. 如果指标正常则逐步增加流量 5. 根据结果完成上线或回滚

工具： Istio、Argo Rollouts 和 Flagger 自动化渐进式交付，并在指标下降时自动回滚。

A/B 测试

比较模型版本以衡量业务影响：¹²

与金丝雀的关键区别： - 金丝雀检测问题（分钟到小时级） - A/B 测试衡量影响（天到周级） - A/B 结论需要统计显著性

实施： - 对用户 ID 进行哈希以实现一致性路由 - 追踪每个变体的转化指标 - 运行直到达到统计显著性 - 记录结果供未来参考

影子部署

将生产流量路由到新模型但不返回响应：

优势： - 使用真实流量模式进行测试 - 比较输出而不影响用户 - 在部署前识别边缘情况

实施： - 生产模型提供响应 - 影子模型处理相同请求 - 比较输出但不返回给用户 - 差异触发调查

回滚程序

每次部署都需要回滚能力：

即时回滚：

# 流量路由回滚
kubectl set image deployment/model-service model=model:v1.2.0

# 功能开关回滚
feature_flags.disable("new_model_v2")

基于注册表的回滚： ```py

[内容因翻译而截断]