最初发表 由 – 经作者同意重新发布
对于 MLOps 工具，在对你的云提供商说“我愿意”之前请三思
如果有人在15年前告诉我我会成为一名 DevOps 工程师，我一定会摸不着头脑，让他们再说一遍。那时，当然，应用程序要么维护在专用服务器上，要么（唉！）安装在终端用户机器上，几乎没有控制或灵活性可言。
如今，这些范例基本上已经过时了；云计算无处不在，而且非常成功。即使是非技术员工也能高效自信地管理 SaaS 产品——但是那些确保一切在幕后顺利运行的人呢？那就是我们，DevOps 人员。
正如我们所知，同样的范式转变现在正发生在 ML 领域……伴随着 MLOps 的出现。
这是一种演变：当我开始在一家 ML 公司工作时，我只是一个 DevOps 人员，帮助数据科学团队组织工作并进行部署。我利用我的实践知识和最佳实践来管理基础设施（主要是 Kubernetes）。
我们一路摸索前进，有一天我醒来 就像格里高尔·萨姆沙 发现自己已经变成了一个 MLOps 工程师。
自建还是购买 vs. “嫁给”你的云提供商
我们都知道技术领域里老生常谈的“自建还是购买”难题，到目前为止，我们也都听过这个实用的建议：“不要自建 MLOps 工具——直接购买最佳的，专注于你真正擅长的事情。” 随着时间的推移，我看到这种普遍的方法在 MLOps 工具领域获得了广泛接受。
但现在焦点转移到选择 合适 你的产品……有趣的地方来了。
在选择 MLOps 提供商时，我们可以选择
- 选择现有云厂商的集成解决方案
- 选择“外部”厂商的专用解决方案
这个决定可以 进一步 分解为选择一个端到端工具来处理 MLOps 工作流程的大部分（甚至所有）方面，或者选择一个最佳的解决方案，而这实际上需要一些集成工作。
乍一看，最初的选择 似乎 显而易见。毕竟，我们已经在使用某个云厂商的服务了。我们知道如何使用他们的 API；我们已经在向他们付费（或使用积分），所以增加另一个服务并不是什么大事。我们会认为他们的解决方案可能会很好地集成我们可能正在使用的计算资源，所以这是一个很容易的选择。对吗？
也许是吧。但让我们退一步仔细思考。
云厂商 MLOps 的阴暗面
是的，开始使用云厂商的产品确实很容易。但从长远来看，我们必须考虑这个决定可能带来的具体影响。
我 不会 深入探讨具体的技术细节和功能，因为对于初创公司和大型公司来说，每个组织的需求、优先级以及现有的工作流程/基础设施可能都与我的不同。相反，我将简单概述在你的特定开发场景中需要考虑的因素。
- 可怕的厂商锁定 – 我想我不需要多说。我们对云提供商的依赖如此之深，以至于几乎不可避免：总有一天（当价格上涨、产品发生变化等），我们将别无选择，只能支付更多费用——或者支付迁移到其他厂商相关的成本（时间多于金钱）。对于 MLOps 来说，这种可能性非常痛苦，因为大量的实验历史记录被保存下来，将其迁移到另一个工具的成本可能介于“我们做不到！”和“天哪，竟然要花那么多钱？”之间。
- 基础成本 – 最初的报价一开始可能看起来不是什么大问题。你通常不会一开始就投入很大，而且在开始 MLOps 时——就像任何新领域一样——快速见效非常重要。是的，云基础设施为你提供了按需扩展的灵活性。但从长远来看，对于中重度工作负载，云服务就是更贵。是的，购买一套 GPU 设备前期成本很高，但它会回本。而且我甚至没有提到托管服务，比如管理 Kubernetes 集群，或者管理训练机器，这些都在裸硬件成本之上增加了额外费用。根据我的经验，投资回报期大约是两年，所以这不是一个明显的财务优势。
- 混合性 – 如果你有本地机器，云厂商的产品根本不好用。如果尝试这种方法，你就必须实现和管理本地机器管理与基于云的 MLOps 解决方案之间的桥梁。是的，这可以做到，但远非理想。毕竟，MLOps 的出现是为了节省 我们的工作，而不是制造更多麻烦。
- 速度 – 当云提供商扩展其服务时，他们会为此开个大会 🙂 这是一个漫长、繁重、渐进的过程，因为他们要开发和推出新的能力和功能。但涉及到解决日常的、通常“微小”但极其烦人的 UI 问题时呢？这很少是他们的优先事项，而且说实话，可能永远不会发生。小厂商，至少从我的经验来看，可以灵活得多。而且说实在的——如果你选择一个开源解决方案（就像我用的，ClearML），你可以自己修改代码，甚至在这样做时获得支持团队的帮助！
简而言之，云服务对每个利益相关者都有着长长的优势清单，从 B2C 终端用户到大型企业的 CTO。但对于这个特定的困境，你的云厂商可能并不是解决技术挑战的最终唯一答案。
