MLflow

MLflow 是一个用于管理完整机器学习生命周期的开源平台，涵盖从实验跟踪到模型部署和生产监控的各个环节。它最初由 Databricks 工程师构建并于 2018 年 6 月发布，随后在 2020 年 6 月捐赠给 Linux Foundation，目前作为 Apache 2.0 许可下的中立开源项目运营。凭借每月超过 3000 万次的下载量、20,000 个 GitHub 星标以及 900 多名开发者的贡献，它是企业环境中最广泛采用的 MLOps 平台，被财富 500 强公司和数千家构建生产级机器学习系统的组织所使用。

该平台涵盖四个核心领域：实验跟踪（记录训练运行中的参数、指标和工件）、模型注册表（用于模型晋升的版本控制、阶段管理和审批工作流）、模型部署（打包到 Docker、REST APIs、Kubernetes 以及 AWS SageMaker 和 Azure ML 等云平台），以及（自 MLflow 3 起）生产级的 GenAI 可观测性。MLflow 3 为 LLM 应用程序添加了基于 OpenTelemetry 的追踪、LLM-as-a-judge 评估、带有版本差异对比的 Prompt Registry、通过 ResponsesAgent 类实现的流式传输支持，以及针对 PydanticAI、smolagents 和 20 多个 GenAI 框架的自动追踪集成。它支持 Python、TypeScript、JavaScript、Java 和 R，并与所有主流机器学习库（包括 PyTorch、TensorFlow、scikit-learn、XGBoost 和 LightGBM）兼容。您可以将其与 Databricks Mosaic AI 结合使用以实现全托管部署，或者完全在您自己的基础设施上自托管运行。

MLflow 在 2026 年 5 月的实际功能

于 2025 年 6 月 11 日发布的 MLflow 3 标志着其从纯粹的实验账本向全面的 AI 工程平台转变的转折点。核心架构从以运行为中心的模型转变为以 LoggedModel 为中心的模型，其中模型成为一等实体，与塑造它们的运行、追踪、提示词和评估指标相连接。这使得跨实验比较模型变体、跟踪从训练数据到评估再到生产部署的血缘关系，以及用以前专属于经典机器学习模型的严谨性来管理 GenAI 代理的版本历史变得更加容易。

在经典机器学习方面，工作流已经非常成熟。数据科学家只需通过 pip install mlflow 安装 MLflow，在训练前调用 mlflow.sklearn.autolog()，该次运行的每个超参数、指标和工件就会被自动捕获。随后，追踪 UI 允许团队并排比较数百次运行，按指标阈值进行过滤，并一键将最佳模型注册到 Model Registry。从那里，模型通过带有审批关卡的预发布和生产阶段，然后部署为 REST 端点、Docker 容器或批量推理作业。

MLflow 3 中引入的 GenAI 功能解决了一个原始架构从未预料到的问题：大规模调试非确定性代理行为。基于 OpenTelemetry 构建的追踪系统在结构化追踪中捕获每个提示词、工具调用、检索步骤和 LLM 响应。当代理出现幻觉或失败时，工程师可以在 UI 中重放完整的追踪，以准确定位上下文出错的具体步骤。LLM 裁判系统提供了有研究支持的评估器，用于系统地衡量自由格式文本的质量，包括在 MLflow 3.10（2026 年 2 月）中添加的多轮对话评估，以及在 3.9（2026 年 1 月）中添加的带有裁判在环（judge-in-the-loop）警报的持续监控。

“MLflow 3.0 的追踪功能对于扩展我们由 AI 驱动的安全平台至关重要。它为我们提供了对每个模型决策的端到端可见性，帮助我们更快地调试、监控性能，并确保我们的防御措施随着威胁的发展而演进。” - Sam Chou，Barracuda Networks 首席工程师，Databricks 博客，2025 年 6 月

“MLflow 3.0 为我们提供了所需的可见性，使我们能够充满信心地调试和改进我们的问答代理。过去需要数小时猜测的问题，现在只需几分钟即可诊断出来。” - Daisuke Hashimoto，Woven by Toyota 技术主管，Databricks 博客，2025 年 6 月

MLflow 与 Weights and Biases 及 Comet ML 的定位对比

Weights and Biases 是实验跟踪领域最直接的竞争对手，但这两种工具在托管架构上截然相反。W&B 是云优先的 SaaS：所有实验数据实时同步到 W&B 的服务器，无需任何基础设施工作。MLflow 默认是自托管的，这意味着团队完全拥有他们的数据，但同时也需要负责数据库、工件存储、身份验证设置和升级路径。W&B 的可视化层也强大得多：它提供平行坐标图、嵌入投影仪、混淆矩阵，以及面向非技术利益相关者的可共享研究风格报告。MLflow 的 UI 则提供基本的折线图和直方图。对于超参数优化，W&B 包含 Sweeps，这是一个内置的贝叶斯优化系统；MLflow 没有原生的等效功能，依赖于 Optuna 或 Ray Tune 等外部库。成本权衡非常直接：W&B 的 Team 计划每用户每月 50 美元，而 MLflow 免费运行，但需要基础设施预算和 DevOps 工时。拥有 Databricks 投资的团队通常将 MLflow 与 Anyscale 结合用于分布式训练工作负载，在将计算扩展到外部的同时将实验数据保留在内部。

Comet ML 占据了中间地带。与 W&B 一样，它是云优先的，具有实时交互式仪表板、平行坐标图以及 MLflow 开箱即用所缺乏的协作工具。Comet 在机制上的不同之处在于工件血缘：Comet 的工件层明确跟踪哪些实验产生和消耗了每个数据集或模型工件，在工件级别而不是运行级别维护来源。MLflow 的血缘是运行级别的；要在 MLflow 中获得工件级别的血缘，您需要 Databricks Unity Catalog 集成，这需要托管层。Comet 还提供基于 REST API 的模型服务作为轻量级部署路径；MLflow 的部署模型更丰富（Docker、Kubernetes、SageMaker、MLServer），但基础设施负担更重。对于在没有完整编排的情况下探索模型服务的团队，BentoML 提供了一个补充的部署层，可以与 MLflow 的注册表很好地协同工作。评估微调工作流的团队通常将 MLflow 与 Predibase 一起使用，后者处理基于 LoRA 的微调，并将实验跟踪集成回兼容 MLflow 的注册表中。

MLflow 工作流的现实情况

对于一个从头开始的团队来说，实验跟踪的设置确实很快：安装、配置指向 PostgreSQL 数据库和 S3 存储桶的跟踪 URI，几分钟内第一次运行就会出现在 UI 中。痛点始于规模化以及功能集的边缘地带。

自托管的复杂性是最持久的摩擦点。除了基于本地文件的跟踪器之外，生产级的 MLflow 设置还需要关系型数据库后端（PostgreSQL 或 MySQL）、用于工件的对象存储、用于多用户访问的网络配置以及某种形式的身份验证。开源版本没有内置的 RBAC；多用户团队访问要么默认开放，要么需要自定义身份验证代理。没有专门基础设施工程师的团队经常发现自己把原本以为只需几个小时的工作花了好几天时间。

UI 是另一个现实考验。它功能齐全，足以进行单个实验比较，但不支持团队评论、共享报告或 W&B 的 Reports 功能所支持的那种叙述性文档。向非技术利益相关者展示模型评估的数据科学团队需要将结果导出到其他地方。同时，查询 API 一直是人们反复抱怨的问题：存储在 SQL 后端中的实验无法直接使用 SQL 进行查询，这让期望以数据库原生方式访问自己数据的工程师感到沮丧。

一旦克服了这些设置障碍，MLflow 作为生命周期平台的深度在开源领域是难以匹敌的。Model Registry 带有审批工作流的预发布和生产转换，结合 MLflow 3.11.1（2026 年 4 月）添加的用于检测已部署代理质量回归的自动问题识别功能，为企业团队提供了可供审计的模型治理，而无需支付供应商订阅费用。AWS SageMaker、Azure ML 和 Google Vertex AI 都提供用于托管跟踪的原生 MLflow 集成，这消除了已经在云机器学习平台上的团队的大部分自托管负担。

MLflow 是为谁构建的

MLflow 适合那些对数据所有权和基础设施控制权不可妥协的团队：无法将训练数据发送到第三方 SaaS 平台的受监管行业（医疗保健、金融、国防），以及已经建立起运行自身服务的 DevOps 能力的企业。它是任何在 Databricks 上运行的团队的默认选择，其中包含了 Managed MLflow，并且 Unity Catalog 提供了无需额外工具的模型治理。同时构建经典机器学习管道和 GenAI 应用程序的团队将受益于 MLflow 3 的统一平台：跟踪梯度提升模型超参数搜索的同一工具，现在可以追踪多步 LLM 代理并使用裁判指标评估其输出质量。在拥有 Databricks 投资的公司中，研究人员和机器学习工程师还会发现它与 Databricks Mosaic AI 自然集成，用于基础模型微调和服务工作流。

采用数据讲述了一个连贯的故事。每月 3000 万次的下载量绝非偶然；它反映了 MLflow 作为实验记录阻力最小的路径，已深深嵌入 Python 机器学习工具链中。教授 MLOps 课程的大学、构建托管机器学习平台的云提供商以及在 Databricks 上实现标准化的企业数据团队，都默认将 MLflow 作为其共享注册表和跟踪层。这种引力使其成为一个合理的默认选择，即使对于可能更喜欢 W&B UI 的团队也是如此，因为组织一致性和现有集成通常胜过产品偏好。将 MLflow 与 Predibase 等微调平台结合使用的团队，可以在不离开开源生态系统的情况下，获得从基于 LoRA 的微调到生产注册表的完整生命周期体验。那些在实验治理的同时优化 LLM 服务效率的团队，可以将 MLflow 的注册表与 BentoML 结合使用，以获得完全受其控制的自托管部署堆栈。

MLflow 不是什么

对于没有基础设施资源的小型团队来说，MLflow 不是一个开箱即用的解决方案。如果您的团队希望实验跟踪在十分钟内运行，而无需配置数据库和对象存储，Weights and Biases 或 Comet ML 会更适合您。它不是一个超参数优化工具：没有内置的等同于 W&B Sweeps 的功能，与外部优化器的集成需要额外的设置。它不是一个管道编排器：MLflow 不会像 Airflow 或 Prefect 那样调度训练作业、管理数据管道或协调多步工作流。期望拥有包含可共享报告和团队评论的全功能协作层的团队，会对开源 UI 感到失望。尽管 MLflow 3 增加了 GenAI 功能，但主要构建 LLM 应用程序而没有任何经典机器学习工作负载的团队可能会发现，Langfuse 或类似专用 LLM 可观测性工具是更专注的选择。2024 年 12 月的 JFrog 安全披露（CVE-2024-27132，CVSS 7.2）还强调，运行不受信任的配方（recipes）的自托管 MLflow 实例可能会通过 XSS 暴露于客户端远程代码执行，这是接受外部模型提交或运行共享笔记本环境的团队需要关注的问题。