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?"