MLflow - 开源 AI 工程全栈平台

解决什么

MLflow 解决 AI 应用从实验到生产的全流程管理难题。传统机器学习项目常面临实验结果难追溯、模型版本混乱、生产部署缺乏监控等问题,而 LLM 时代又新增了 Prompt 版本管理、Agent 行为追踪、成本控制等需求。MLflow 提供统一平台整合实验追踪、模型注册、部署服务、LLM 可观测性等功能,让团队用标准化流程管理 AI 资产。其核心价值在于打通开发到运维的数据流,通过 SQL 数据库(默认 SQLite)存储元数据,支持多用户协作和审计。

为何火

月下载量超 6000 万次的背后是企业级 MLOps 的刚需。一方面,MLflow 是少数覆盖传统 ML 和 LLM 双场景的开源方案,既能追踪 scikit-learn 模型超参数,也能记录 GPT-4 调用的完整 trace;另一方面,其 Apache 2.0 许可和 Databricks 商业支持形成"开源+企业服务"双保险,大厂可自部署控制数据,中小团队能快速上手。HN 社区讨论热度高(252 点)反映出其普及度,但争议同样激烈——不少开发者吐槽其 API 设计混乱、文档晦涩,认为简单场景用 SQLite 直接存实验结果更清晰。

核心功能

LLM 可观测性:基于 OpenTelemetry 标准捕获 Agent 和 LLM 应用的完整调用链,支持 OpenAI/Anthropic/本地模型等任意提供商,可视化展示每步输入输出、延迟和成本。评估系统:内置 50+ 评估指标(如 BLEU/ROUGE/自定义 LLM Judge),支持批量测试和回归检测。Prompt 管理:版本化存储 Prompt 模板,追踪每次修改的效果变化,并提供自动优化算法改进性能。AI Gateway:统一 API 网关管理多个 LLM 提供商,处理请求路由、限流、降级和凭证管理。模型注册表:为传统 ML 模型提供版本控制、阶段管理(Staging/Production)和血缘追踪。

安装

推荐通过 pip 安装:pip install mlflow,然后运行 mlflow server 启动本地服务(默认端口 5000)。生产环境需配置外部数据库(PostgreSQL/MySQL)替代默认 SQLite,并通过 --backend-store-uri 和 --default-artifact-root 指定存储路径。Docker 部署可参考社区镜像,但官方未提供 docker-compose 配置。对于 LLM 应用,需额外安装 mlflow[genai] 并配置 OpenAI API Key 等环境变量(国内用户需配置代理)。快速体验可用 uvx mlflow server 一键启动临时实例。

适合谁

最适合:已采用 Databricks 或需要企业级审计的中大型 AI 团队,尤其是同时维护传统 ML 模型和 LLM 应用的场景。次适合:需要标准化实验流程的研究团队,能接受一定学习曲线换取长期可维护性。不适合:个人开发者或 5 人以下小团队——社区普遍反馈其复杂度过高,简单需求用 SQLite + 自定义脚本更高效;追求极简 API 的团队会被其 Pandas 风格的接口劝退。中文用户需注意文档主要为英文,且调用 OpenAI 等服务需自备梯子。

社区评价

HN 讨论(252 点,110 评论)呈现两极分化。批评方认为 MLflow 是"设计灾难":API 比 Pandas 还混乱,文档故意绕晕人,内部数据模型暴露过多实现细节;有评论直言"用 SQLite 直接存实验结果比 MLflow 清晰十倍"。支持方承认其复杂但强调现实必要性:金融/保险等行业因合规需求被 IT 部门强推 Databricks,MLflow 作为其内置组件成为事实标准;虽然难用但"在纸面上勾选了所有 MLOps 需求框"。争议焦点在于规模阈值:小模型用 SQLite 够用,但多服务器超参数优化或多用户协作时需要 PostgreSQL 等多用户数据库,此时 MLflow 的架构优势才显现。有趣的是,多位评论者提到其在 Azure 生态的强势地位——微软大力推广 Databricks 导致许多企业被动接受 MLflow。

选型对比

vs Weights & Biases(商业对标):W&B 提供更精致的 UI 和开箱即用体验,但闭源且按席位收费;MLflow 开源可自部署,适合数据敏感场景,代价是需自行维护基础设施。vs Optuna(超参数优化):Optuna 专注优化算法本身,默认也用 SQLite 但支持 PostgreSQL;MLflow 覆盖更广但优化能力较弱,两者常组合使用。vs 自建方案(SQLite + 脚本):小团队(<5 人)用 SQL 直接存实验结果确实更简单,但缺乏 UI、权限管理和审计能力;MLflow 的价值在 10 人以上团队协作时才凸显。技术栈方面,MLflow 基于 Python/Flask 生态,与 PyTorch/TensorFlow 集成紧密,但 TypeScript/Java 支持较新,稳定性待观察。

已知坑

1. 学习曲线陡峭:社区公认文档组织混乱,新手常在 Tracking/Projects/Models 等概念间迷失,建议先跑官方 Quickstart 再读源码。2. API 设计争议:方法命名不一致(如 log_param vs set_tag),pandas 风格的链式调用易出错,需仔细阅读返回值类型。3. 默认 SQLite 不支持并发:多进程同时写入会锁表,生产环境必须换 PostgreSQL/MySQL。4. Databricks 绑定:虽然开源,但部分高级功能(如 Model Serving)在 Databricks 平台体验更好,自部署需额外配置。5. 中文生态薄弱:Stack Overflow 中文问答少,遇到问题主要靠英文文档和 GitHub Issues。6. 资源占用:UI 加载大量实验时会卡顿,建议定期归档历史数据。

---

信息来源: GitHub 仓库 mlflow/mlflow + Hacker News 讨论 "Who needs MLflow when you have SQLite?"