导语
MLOps可满足数据科学和ML工程团队的特定需求，而不会影响Kubernetes。
正文
如果您的组织已经开始学习机器学习，那么您肯定会与以下内容有关。如果您的组织正在迈入数据科学的第一步，那么以下内容将说明您将要掌握的内容。
如果上述方法都无法解决，那么您可能会感兴趣，因为AI是新的前沿领域，而且直到您需要解决以下挑战也不会太久。
数据科学家也是科学家。如果您问他们，他们的重点应该放在发展科学，神经网络以及他们要建立的AI预测变量背后的模型上。他们都有自己偏爱的工作方式，并且可能需要特殊的环境来完成所需的任务。当然，您的同事，数据科学家希望能够在笔记本电脑上开发代码。对于他们来说不幸的是，这是不可能的。他们的机器缺少内存或存储，或者需要GPU或几个GPU来增强功能。毕竟，AI工作负载可能是庞大的计算工作。因此，他们必须在远程计算机上工作。他们的代码将运行几个小时到几天，由于时间太长，他们显然想尝试不同的配置，参数等。
DevOps来拯救您的一天！为他们分配一个Kubernetes集群，并让他们运行自己的容器。
问题解决了！
如果只是那么简单……
问题的症结在于一个事实，即人工智能开发和部署是不一样的标准软件。在研究差异之前，让我们记住K8s集群是为生产而构建的。因此，有很多我们都熟悉的大禁忌。具体来说，在K8s集群上，我们绝对不应：
将所有Pod放在相同的名称空间中。
手动管理太多不同类型的容器/仓库工作负载。
假设我们可以控制K8s调度程序的顺序。
留下许多陈旧（使用一次）的容器。
允许节点自动缩放根据挂起的作业自动执行。
基本上，我要说的是DevOps的第一条规则是：不允许研发团队访问您的K8s集群。这是您的集群（阅读：生产集群），而不是它们的集群。
但是，在深度学习（DL）以及有时在机器学习（ML）的情况下，从开发过程的较早阶段就需要运行繁重的工作负载，并且此后一直如此。最重要的是，与在K8s集群上部署并复制经过测试且通常稳定的版本的传统软件不同，在ML / DL中，需要同时运行多个不同的实验，有时同时进行成百上千个。从定义上讲，它们是未经生产级测试的稳定软件。
换句话说，除非我们想为数据科学团队的不断变化的需求而不断设置权限和资源，否则我们必须为他们提供一个接口，以使用他们分配给他们的资源。
最后，由于我们通常是K8和编排方面的专家，因此数据科学团队将立即与我们联系，以支持他们对Docker的代码和环境进行Docker处理。
当事情变得简单时，一切都会起作用，但是事情很快就会失控。由于ML / DL代码不稳定，并且打包有时会花费一些时间，因此我们需要将其作为CI的一部分。这意味着数据科学团队将必须维护需求/ YAML文件。由于这些实验大部分都是短暂的，因此我们最终将构建大量只能使用一次的Docker。看到集群上有成千上万个或更多Docker的集群并不少见。
总而言之，我们需要一个可以轻松地对数据科学团队无休止的环境设置进行Docker化的人或事物。不断地。
让我们将需求列表分解成不同的成分：
资源访问
对于DevOps，资源访问意味着权限/安全性，可靠性，位置等。
对于数据科学家而言，资源访问意味着要使用哪种资源类型及其可用性。而已。从开发团队的角度来看，甚至可以以低粒度定义的资源类型也通常是过大的选择。他们关心的是CPU还是GPU机器以及内核数量。这些资源的三级或四级设置（例如CPU，1xGPU，2xGPU，8xGPU等）对于大多数AI团队来说可能就足够了。
环境包装
通常认为环境打包是容器化您的代码库。从DevOps角度来看，这是一个合理的假设。
对于AI数据科学团队而言，可以维护Docker文件，requirement.txt并更新Conda YAML。但是，这分散了他们的核心工作，需要花费时间，并且很容易留下旧的设置，因为它们没有在编码环境中使用。开发环境在不断变化，因此关键是提取信息而无需手动保持更新。此外，还需要轻松地将环境从本地计算机复制到远程执行Pod。
监控方式
对于DevOps，监视通常意味着硬件监视，CPU使用率，RAM使用率等。
对于数据科学团队而言，监视与模型性能，速度，准确性等有关。AI团队需要能够使用自己的指标和易于使用的界面监视其应用程序（过程/实验，无论我们称其为什么）。
不幸的是，这种监视没有标准，并且经常添加更多特定于用例的指标为数据科学团队提供了了解黑匣子的巨大优势。这也是一个不断变化的环境，需要允许数据科学家进行自定义。
作业调度
对于DevOps，使用K8的作业调度类似于资源分配，例如，作业需要可无限使用的资源。如果我们没有足够的资源，则需要扩展。
对于数据科学团队而言，作业调度实际上是HPC的挑战。几乎根据定义，永远不会有足够的资源来同时执行所有作业（阅读：实验）。另一方面，作业是短命的（至少相对于服务器的寿命而言），问题是首先执行哪个作业以及在哪个资源集上执行？
营救的MLOps
Kubernetes是DevOps管理组织硬件集群的绝佳工具，但对于数据科学和ML工程团队而言，管理AI工作负载却是错误的工具。
那么，有没有更好的方法？
为了满足数据科学和ML工程团队的特定需求，已经设计了一种新型的工具：MLOps或AIOps。
MLOps是数据科学团队的理想工具。在以K8s为中心的组织中，它将交互或运行在K8s之上。从K8s的角度来看，它应该是另一种可以旋转的服务，它具有精确的多个副本和在不同资源上的复制设置，就像我们在K8s上运行的任何其他应用程序一样。
这些工具为数据科学团队和ML工程师提供了与K8s节点完全不同的接口。理想情况下，AI团队应该能够将分配的硬件资源视为自己“集群”上的节点，为此，他们可以将其作业（实验）直接启动到专用队列中，而不会干扰任何K8s调度程序。
MLOps解决方案提供了由数据科学团队管理的队列与K8之间的粘合：Kubernetes提供的资源分配以及专用MLOps解决方案执行的作业分配和执行。
该解决方案应该能够从专用的ML / DL团队队列中选择一项工作（具有优先级，工作顺序等），然后在Docker内部或同级Docker中设置该工作的环境，并进行监控工作（包括在需要时终止工作）。
仅当需要分配新的硬件资源或需要更改资源分配时，才需要DevOps团队。对于其他所有方面，用户（阅读：AI团队）通过MLOps解决方案进行自助服务，该解决方案是专门为满足他们的需求而构建的，同时让DevOps团队管理整个操作。
这听起来不是比24*7呼叫调配好，然后再清理所有东西好吗？
