介绍
机器学习现在被成千上万的企业所使用。它的无处不在有助于推动越来越难以预测的创新，并为企业的产品和服务构建智能体验。虽然机器学习随处可见，但它在实际实施时也带来了许多挑战。其中一个挑战是能够快速、可靠地从开发机器学习模型的实验阶段过渡到生产阶段，在生产阶段可以为模型提供服务，从而为业务带来价值。
行业提供了许多解决这一挑战的工具。公共云产品有自己的机器学习模型托管解决方案，同时，也有大量的开源项目专注于此。在本系列的第一篇文章中，我们比较了在Kubernetes上运行的开源工具，以帮助您决定使用哪种工具为您公司的机器学习模型服务。
对比设置
我们重点研究了模型服务工具的9个主要方面：
- 能够为标准框架中的模型提供服务能力，包括Scikit Learn、PyTorch、Tensorflow和XGBoost
- 为定制模型/来自不同框架的模型提供服务的能力
- 预处理/后处理数据的能力
- 对开发工作流程和现有代码库的影响
- 技术文档的可用性
- DevOps可操作性
- 自动缩放能力
- 模型预测的可用接口
- 基础设施管理能力
我们在本文中选择的比较工具是：KServe、Seldon Core和BentoML。
为了比较这些工具，我们建立了一个包含标准流水线的机器学习项目，包括：数据加载、数据预处理、数据集拆分和回归模型训练与测试。流水线要求模型推理包含一个预处理步骤（调用自定义Python函数），以便测试服务工具的不同方面。流水线本身允许轻松更换模型，因此可以使用各种建模框架。
机器学习模型服务工具概述
KServe
KServe（在0.7版本之前被命名为KFServing）是一个基于Kubernetes的开源工具，提供自定义抽象（Kubernetes custom Resource Definition）来定义机器学习模型服务功能。它的主要重点是隐藏这种部署的潜在复杂性，这样用户只需要关注与ML相关的部分。它支持许多高级功能，如自动缩放、零缩放、金丝雀部署、自动请求批处理，以及许多流行的现成ML框架。它被彭博社、英伟达、三星SDS、思科等公司使用。
Seldon Core
Seldon Core是由Seldon Technologies Ltd开发的开源工具，是大型（付费）Seldon部署解决方案的构建块。就方法而言，它与KServe类似——它提供高级Kubernetes CRD，支持金丝雀部署、A/B测试以及多武装强盗部署。
BentoML
BentoML是一个Python框架，用于将机器学习模型包装到可部署服务中。它提供了一个简单的面向对象接口，用于打包ML模型并为它们创建HTTP（s）服务。BentoML提供了与流行的ML框架的深度集成，因此隐藏了与打包模型及其依赖项相关的所有复杂性。BentoML打包模型可以在许多运行时部署，包括普通Kubernetes集群、Seldon Core、KServe、Knative以及云管理的无服务器解决方案，如AWS Lambda、Azure Functions或Google loud Run。
该比较包括对每个工具内每个区域的描述，以及该工具如何处理该区域的可视化。量化是主观的，基于实现给定目标所需的努力，越向右（绿色区域），工具就越能更好地解决这一方面。
服务标准模型的能力
这一比较领域的重点是这些工具为在其中一个流行框架中训练的模型提供服务的能力，包括：Scikit Learn、PyTorch、TensorFlow和XGBoost。
KServe
所有经过测试的框架都很容易提供服务。标准框架是KServe中的头等公民，因为它提供了运行它们的预构建docker镜像，以及推断服务（KServe定义的Kubernetes的自定义资源）中的直接定义。
通常，为了正确启动模型，需要准备一个配置文件。
Seldon Core
Seldon Core可以方便地为Scikit Learn、XGBoost和TensorFlow模型提供服务。PyTorch没有内置的支持，可以通过Triton Server实现，但需要大量额外的工作，并且需要使用Seldon的v2协议。在使用MLServer（使用Seldon Core部署模型的新推荐方法）时，也会强制使用v2协议，这会给下游带来一些挑战——请参阅下面关于预处理/后处理的部分。
BentoML
使用BentoML可以归结为实现一个自定义Python类，该类继承自框架的类，这意味着可以使用任何Python框架。所有处理模型序列化、反序列化、依赖关系以及输入/输出处理的标准框架都有内置支持。实现BentoML的BentoService类接口非常容易，通常只需几行代码。
服务定制化模型的能力
数据科学家的工作不能受到所用框架集的限制。对于服务解决方案来说，支持任何自定义框架和代码都很重要。
KServe
KServe允许在部署中使用任何docker镜像，因此基本上可以使用任何框架/代码/语言（在某种程度上）。该工具为Python SDK提供了一个可以继承的抽象类（KFModel），以便更容易地集成自定义代码。
Seldon Core
与KServe类似，可以使用任何docker镜像。Seldon Core和KServe在这方面的区别在于，虽然KServe为SDK提供了必须实现的类，但Seldon为SDK提供了可以实现的类（SeldonComponent），但也可以选择使用Python的duck类型。
BentoML
由于使用BentoML需要实现Python代码，因此可以使用它进行任何定制。
支持预处理和后处理数据的能力
现实世界的机器学习模型通常需要以某种方式对输入数据进行预处理，以提取特征、标准化值或转换数据。对于模型服务工具来说，在数据到达模型之前/之后，提供一种插入数据预处理/后处理的方法至关重要。
KServe
KServe中的推理服务抽象允许指定转换器，它可以处理数据的预处理和后处理。实现需要使用从KServe的SDK继承的类准备自定义docker镜像，类似于实现自定义模型。
Seldon Core
除了标准的预处理和后处理（可以定义为TRANSFORMER，并作为Python类实现）（使用继承或duck类型，请参阅“服务自定义模型”），Seldon Core还提供了推理图的抽象。这可能不仅包括数据转换，还包括自定义路由器（例如，动态决定将数据发送到属于同一SeldonDeployment的多个模型中的哪一个），以及允许您直接从deployment中创建集成模型的COMBINER。
多亏了这一功能，多臂老虎机部署很容易实现。必须记住，当使用MLServer或Triton Server时，转换是不可能的——请参阅相关的GitHub问题。https://github.com/SeldonIO/MLServer/issues/287
BentoML
与前述一样，任何代码都可以作为BentoML部署的一部分运行。
对开发工作流程和现有代码库的影响
在这里，我们关注使用这些工具是否需要更改开发工作流程（例如，调整到一组新的API、对现有CI/CD设置进行一些更改、修改培训代码以及为模型使用新的工件存储等）。
KServe
由于部署需要简单的资源定义，KServe可以很好地与现有的两个DevOps流水线进行集成以进行部署（无论是直接来自Kubernetes清单、Helm chart还是其他）。从数据科学家/机器学习工程师的角度来看，调整是相当小的——模型可以从任何云存储服务，比如S3或GCS。构建Docker镜像的现有CI/CD流水线可以保持不变。对docker镜像本身的更改是可选的，只有在需要启动自定义代码时才需要更改。
Seldon Core
与KServe类似，Seldon Core不会影响现有的DevOps/软件工程工作流。从Kubernetes清单执行部署。只要使用其中一个受支持的框架，就只需要数据科学家/机器学习工程师付出最小的努力，但是任何定制或使用非标准框架都可能会使工作流复杂化，并且一些功能可能变得不可用（由于尚未实现，请参阅“数据预处理/后处理能力”）。
BentoML
尽管实现Python类并不困难，但向执行环境（例如Kubernetes集群）交付基于BentoML的服务的过程将需要更改CI/CD流水线。BentoML将带有序列化模型、Python代码和所有依赖项的BentoService继承类保存到一个单独的归档/目录中。归档文件包含Dockerfile，可用于构建独立的服务容器镜像。因为BentoML归档是作为工件创建的，所以CI/CD流水线需要使用它并触发另一个构建。从部署的角度来看，一切都需要手动处理，对于Kubernetes来说，这意味着编写部署定义。
技术文档的可用性
只有提供良好的文档，才能快速调整服务工具。还考虑了通过GitHub/Slack提供社区支持。
KServe
文档涵盖了重要的方面。复杂的用例需要通过GitHub问题进行研究，或者在社区非常活跃的 Slack 频道上询问其他人。
Seldon Core
文档涉及的大多是简单的用例，大量链接会导致404页。在GitHub上可以找到高级方案，但其中一些已被弃用。
BentoML
相当健壮的文档，有很多最新的例子。代码和概念都得到了很好的描述。
DevOps可操作性
部署之后，DevOps团队通常负责监控和维护生产应用程序。DevOps需要能够访问模型服务工具，以允许重复部署，提供监控和方法来诊断在高负载下运行时可能出现的问题。
KServe
KServe的堆栈基于成熟的开源工具：KNative和Istio，它们是DevOps优先，Kubernetes原生的。监测基于广泛采用的 Prometheus。可以使用任何与Kubernetes兼容的解决方案进行部署，无论是直接从kubectl、Helm还是Helmsman。日志记录很容易配置，消息通常是描述性的。金丝雀部署是现成的。
Seldon Core
Seldon只要求Istio或Ambassador可用才能操作。监测也通过 Prometheus 完成。与KServe类似，可以使用任何Kubernetes部署解决方案。日志可以很容易地配置，但对于某些部分，根本没有日志。金丝雀部署和A/B测试部署都是现成的。
BentoML
由于BentoML是代码优先的，可以配置对DevOps的支持，这要归功于许多与跟踪工具（例如Jaeger）、监控（Prometheus）的集成。不过，Kubernetes中的配置和部署需要手动实现。然而，BentoML可以与许多现有的服务解决方案甚至无服务服务一起使用，因为最终的结果是一个简单的Docker镜像。
自动缩放功能
部署的模型不仅应该满足业务需求，包括预测的质量，还应该满足吞吐量。服务解决方案应该允许模型在流量峰值时放大，在流量恢复正常时缩小。
KServe
由于与KNative的紧密集成，KServe提供了同类最佳的自动缩放功能。部署的模型不仅可以通过利用Kubernetes的CPU利用率指标来扩大规模，还可以通过高级别指标来扩大规模，比如每秒请求数或并发性（有模型的单个容器可以同时处理多少个请求）。
KServe还提供了快速激活的零扩展功能，从而更容易保持集群的总体成本较低。还内置了对自动请求批处理的支持，这有助于更好地利用POD的资源。
Seldon Core
由于Seldon Core是Kubernetes原生的，因此可以使用标准的水平Pod自动缩放器，其中包含CPU和内存利用率等指标。如果需要使用基于事件的指标，则需要额外安装KEDA并与之集成。通过与KEDA集成，可以通过KEDA本机事件源缩放到零。HTTP scale to zero还需要KEDA的其他附加组件。
BentoML
由于BentoML是一个代码优先的框架，它不提供任何自动缩放功能，因为它们完全依赖于所选的运行时（BentoML可以部署到KServe、Seldon Core、SageMaker端点和许多其他云解决方案）。然而，该框架支持请求的自动批处理，这允许在部署后调整服务性能（在一定程度上）。
可用的模型预测接口
通常，模型作为基于HTTP（s）的服务使用JSON输入/输出。不同的用例可能需要不同的请求/响应格式，或者使用更快的二进制协议，比如GRPC，所以服务工具也应该支持它们。
KServe
虽然KServe没有对使用的协议施加限制，但默认的服务方法是基于HTTP的。非json输入/输出需要自定义转换器。配置允许使用GRPC或任何其他协议，但处理此类协议需要手动定制实现。
Seldon Core
与KServe类似，Seldon Core不限制协议的使用。此外，它还为HTTP和GRPC服务方法提供了默认实现，因此每个部署的模型都可以自动响应HTTP和GRPC请求。请求和响应格式可以通过TRANSFORMER中的自定义实现来处理。
BentoML
只支持HTTP（GRPC似乎处于过时状态）。同样，由于BentoML是代码优先的，所以处理任何类型的请求都是可能的。该框架提供了一些预先实现的处理方法，因此可以从CSV、JSON和其他方面解析请求。https://github.com/bentoml/BentoML/issues/703
基础设施管理能力
最后但并非最不重要的一点是，模型服务工具比较中的这一重点领域集中在基础设施管理上——它考虑了在生产和规模上运行给定工具所需的工作。
KServe 和 Seldon Core
这两种工具都完全依赖于底层的Kubernetes集群进行基础设施管理。如果使用云管理的Kubernetes，该过程可能包括基础设施即代码的方法。这些工具本身在现有集群中部署时不会对资源需求造成太大压力。
BentoML
BentoML依赖于所选的部署目标，因此在该领域不考虑它，因为它可能会在低到高的工作强度之间变化。
机器学习服务工具的特征矩阵
总结
将机器学习模型从实验阶段转移到生产环境中运行的API是一个复杂的过程。本文比较的工具都试图使其某些方面更容易、更快甚至更轻松。
同时，这些工具都有其缺点——这就是为什么了解这些工具的不同功能以及在考虑到项目的主要目标和约束的情况下，它们可以实现什么是很重要的。我们希望这种比较能帮助你在为机器学习模型服务时做出明智的决定。
原文作者：Marcin Zabłocki