一、为什么 MLOps 选型最容易踩坑？
每次有人在社区问「MLflow、ClearML、W&B 到底选哪个」，底下总能吵起来。吵了几年，结论还是没共识——因为问题本身就问错了。
MLOps 根本不是一个品类，而是好几件正交的事堆在一起。
你想追踪实验指标？那是「实验跟踪层」。你想把数据处理→训练→评估串成 DAG 跑在集群上？那是「流水线编排层」。你想把训好的模型挂个 endpoint 提供推理？那是「模型服务层」。你做 LLM Agent，想看每次调用的 trace、token 成本、prompt 版本？那是「LLM·Agent 可观测层」。
这四层互相之间是可以解耦的。MLflow 可以只做跟踪，把编排交给 ZenML；Metaflow 可以只管流水线，把跟踪结果写到 Aim；Langfuse 专攻 LLM trace，跟你用哪个编排器无关。
踩坑的人，几乎都犯了同一个错：指望一个工具把四层全包了。结果要么是被 Kubeflow 的运维成本劝退，要么是发现 W&B 的团队协作要付费、又不想被 SaaS 绑死。
这篇横评的核心论点就一句：真实选型是「组合」，不是「替换」。先看清分层，再按层选件。
二、评测维度：我们拿什么标准横评？
既然是横评，得先把尺子亮出来。本文从九个维度对比：
| 维度 | 看什么 |
|---|---|
| 开源程度 / 自托管 | 服务端是否真开源、能否完全离线私有部署 |
| 上手成本 | 几行代码能跑通，还是先得配好 K8s |
| 实验跟踪 | 指标/参数/产物记录、对比 UI 体验 |
| 流水线编排 | 是否原生 DAG、分布式执行能力 |
| 模型服务 | 能否直接提供推理 endpoint |
| LLM·Agent 支持 | trace、token/成本、prompt 管理、评估 |
| 多用户与权限 | RBAC、团队协作是否付费门 |
| 社区生态 | 集成数量、活跃度、文档质量 |
| 运维成本 | 自托管要养多少基础设施 |
三、分层视角：把工具归位
这一步最关键。先看每个工具真正的主场在哪一层，别让一个编排器去干跟踪的活。
实验跟踪层
- MLflow（3.x）：事实标准。新架构引入
LoggedModel实体，从「以 run 为中心」转向「以模型为中心」。 - Aim：纯开源、轻量，强项是大规模实验的对比 UI——成千上万次 run 一起看也不卡。
- ClearML：跟踪只是它的一块，但跟踪本身够用。
流水线编排层
- Metaflow：Netflix 出品，Python 原生，本地一行命令跑、云端无缝扩，对数据科学家最友好。
- ZenML：「胶水层」定位，提供 stack 抽象，让你在本地、K8s、云之间切换，常和 MLflow 配对。
- Kubeflow / Flyte：K8s 原生的重型平台，分布式编排能力强，但运维门槛高。Flyte 胜在强类型与可复现。
模型服务层
- 这层开源里没有绝对主角，MLflow 能做基础 model serving，但生产级推理大家常用独立的 TGI、vLLM、BentoML、Seldon 等。横评里没有银弹。
LLM·Agent 可观测层
- Langfuse：MIT 开源，自托管与云端同代码库，强项是 prompt 版本管理 + 评估闭环。
- Arize Phoenix：基于 OpenTelemetry，本地优先，强项是 trace 可视化与排障。
四、横向对比大表
| 工具 | 开源/自托管 | 主场层 | 上手成本 | LLM·Agent | 运维成本 |
|---|---|---|---|---|---|
| MLflow 3.x | ✅ Apache 2.0，自托管 | 跟踪+注册 | 低 | ✅ Tracing/AI Gateway/LLM-judge | 中（UI 大规模吃力） |
| Aim | ✅ 开源，自托管 | 跟踪 | 低 | ❌ 基本无 | 低 |
| ClearML | ✅ Apache 2.0，自托管最全 | 跟踪+数据+编排+Agent | 中 | ⚠️ 较弱 | 中 |
| ZenML | ✅ Apache 2.0 | 编排（胶水） | 中 | ⚠️ 借外部 | 低-中 |
| Metaflow | ✅ Apache 2.0 | 编排 | 低 | ⚠️ 借外部 | 低 |
| Kubeflow | ✅ 开源 | 编排+平台 | 高 | ❌ 弱 | 高（吃 K8s） |
| Flyte | ✅ Apache 2.0 | 编排 | 中-高 | ❌ 弱 | 高（吃 K8s） |
| Langfuse | ✅ MIT，自托管 | LLM 可观测 | 低 | ✅ 强（prompt+评估） | 中 |
| Phoenix | ✅ Apache 2.0，本地优先 | LLM 可观测 | 低 | ✅ 强（trace+排障） | 低 |
| W&B | ⚠️ 客户端 MIT，服务端闭源 | 跟踪（SaaS） | 低 | ✅ 有（付费） | —（SaaS） |
| Neptune | ⚠️ 客户端 MIT，服务端闭源 | 跟踪（SaaS） | 低 | ⚠️ 一般 | —（SaaS） |
| Comet | ⚠️ 核心闭源，Opik 开源 | 跟踪/LLM（SaaS） | 低 | ✅ Opik | —（SaaS） |
五、开源 vs SaaS：先把归属说清楚
这一步能直接砍掉一半的纠结。很多人的「开源 MLOps」清单里混着 W&B、Neptune、Comet——但它们服务端都是闭源的，本质是 SaaS。
- W&B：Python SDK 是 MIT，但 server 闭源；能「自托管」但要 license key，免费档不支持团队协作。
- Neptune：SDK MIT，server 闭源，可私有部署（已被 OpenAI 收购，后续走向待观察）。
- Comet：核心平台闭源，但其 LLM 可观测子产品 Opik 是开源、可自托管 的（这是它为数不多的开源抓手）。
判断标准很简单：服务端代码是否开源、能否完全离线跑起来。 按这个硬约束，W&B / Neptune / Comet 的核心都得出局，真正「开源 + 自托管」的候选是：MLflow、Aim、ClearML、ZenML、Metaflow、Kubeflow、Flyte、Langfuse、Phoenix。
这并不代表 SaaS 差——如果你的约束是「团队开箱即用、不想养基础设施」，W&B 依然是体验最顺的之一。只是它不在「开源自托管」这条赛道里，别放在一起比。
六、分场景选型：你属于哪一类？
光分层还不够，落到具体场景才有用。本文面向三类工程师，分别给组合方案。
场景 A：做 LLM Agent / LLM 应用
核心需求： 看清每次 LLM 调用的 trace、token 与成本、prompt 版本、自动评估。
推荐组合： 编排用轻量方案（甚至直接用 Agent 框架自带流程）+ Langfuse 或 Phoenix 做可观测 + MLflow 做模型/实验记录（如果还涉及微调）。
- 重 prompt 迭代和评估闭环 → 倾向 Langfuse。
- 重 trace 排障、本地快速起 → 倾向 Phoenix（OpenTelemetry 原生，接各种框架顺手）。
- 如果已经在 Databricks 生态里、想要统一的 AI Gateway 管多 provider 和限流 → MLflow 3.x 的 Tracing + AI Gateway 也很能打。
注意：MLflow 的 GenAI 能力在快速补齐（3.x 后加了 Tracing、LLM-as-judge、Prompt 工程 UI、AI Gateway，近期版本还补了 RBAC 和 trace 归档），它正在从「经典 ML 跟踪」往「AI 工程平台」靠。但它不是编排器，复杂 Agent 流程还是得配专门的编排。
场景 B：嵌入式 AI / TinyML
核心需求： 训练侧记录之外，更头疼的是编译部署和片上性能。
推荐组合： 训练侧用 MLflow / Aim 做轻量记录；编译部署（TFLite Micro / ONNX Runtime / 各家 NPU 工具链）和片上 benchmark 交给专门的工具链。
坦白讲，这一层没有开源银弹。 模型量化、算子适配、内存占用、片上延迟——这些高度依赖具体硬件（如地平线 RDK、各家 MCU/NPU），往往要靠厂商工具链 + 自研脚本。MLOps 通用工具在 TinyML 这里的价值，基本止步于「训练记录」和「产物版本管理」，别指望它们解决部署。
场景 C：机器人软件
核心需求： 训练记录 + 运行时多模态数据回放。
推荐组合： 训练记录层照常用 MLflow / ClearML；运行时数据走 ROS 生态（ROS bag 录制）或 rerun.io 做多模态时序可视化。
MLOps 工具与 ROS 生态重叠很弱——前者管「模型怎么训出来」，后者管「机器人跑起来时传感器/控制流怎么记录和复盘」。两者是互补的两套记录体系，别试图用 MLflow 去 replay 一段 rosbag。rerun.io 这类工具正在成为机器人团队复盘感知/规划链路的新标配。
七、结论：按层组合，而非钦定
如果把这篇横评压成一句话：
没有最强工具，只有最合适的组合。先分层，再按层选件，最后看你能不能接受每个件的运维成本。
几个实操判断：
- 只想快速记录实验、又想完全开源自托管 → MLflow 或 Aim 起步，成本低。
- 要把整套研发流程跑在自建集群、要数据版本 + 远程队列 + 调度 → ClearML 是自托管里最完整的一体化方案。
- 编排是刚需、团队偏数据科学家、不想碰 K8s → Metaflow；想要可移植抽象层 → ZenML。
- 已经在 K8s 重度运营、要强类型和可复现的大规模流水线 → Flyte；生态最全但最重 → Kubeflow。
- 做 LLM/Agent，要 trace、成本、评估 → Langfuse 或 Phoenix，按「重评估闭环」还是「重本地排障」二选一。
- 不在乎开源、要团队开箱即用 → W&B 依然最省心，但要接受 SaaS 绑定。
最后给一句清醒话：工具决定下限，架构决定上限。 把四层拆清楚、各层选趁手的件、预留好替换接口（比如跟踪层用标准协议而不是某个工具的私有 API），比纠结「到底选哪个」重要得多。MLOps 这件事，从来不是选一个赢家，而是搭一套能演化的栈。
参考链接： [1] MLflow 官方文档与 GenAI 能力 https://mlflow.org/docs/latest/genai/
[2] MLflow 3 发布博客 https://mlflow.org/blog/mlflow-3-launch/
[3] Aim 开源实验跟踪（GitHub） https://github.com/aimhubio/aim
[4] ClearML 开源平台（GitHub） https://github.com/clearml/clearml
[5] ZenML 官网 https://zenml.io
[6] Metaflow（Netflix 开源，GitHub） https://github.com/Netflix/metaflow
[7] Kubeflow 官网 https://www.kubeflow.org
[8] Flyte 官网 https://flyte.org
[9] Langfuse 开源 LLM 可观测（GitHub） https://github.com/langfuse/langfuse
[10] Arize Phoenix 开源 AI 可观测（GitHub） https://github.com/Arize-ai/phoenix
[11] rerun.io 多模态数据可视化（机器人/视觉） https://github.com/rerun-io/rerun
[12] W&B 自托管部署说明（服务端闭源） https://docs.wandb.ai/platform/hosting/hosting-options/self-managed