【万字长文】模型推理服务工具综述

摘要：

模型服务是构建机器学习产品的重要步骤。它包括打包模型、构建 API、监控性能以及扩展以适应传入的请求。

模型服务工具的选择取决于特定的项目和团队需求，例如：框架和基础设施兼容性、易用性、推理优化功能、监控功能和所需的部署策略。

从广义上讲，模型服务工具可以分为两类：将机器学习模型打包到推理优化容器中的模型服务运行时，以及专注于部署和扩展这些模型的模型服务平台。

当今市场上存在各种工具，每种工具都有特定的优点和缺点。BentoML、TensorFlow Serving、TorchServe、Nvidia Triton 和 Titan Takeoff 是模型服务运行时的领导者。在模型服务平台方面，KServe、Seldon Core、Bento Cloud 和云提供商的集成解决方案是最有力的竞争者。

• 了解模型服务

• 你需要模型服务运行时吗？

• 需要模型服务运行时的三个原因

• 避免使用模型服务运行时的三个原因

• 选择模型服务工具的标准

• 框架兼容性

• 一体化

• 实施的复杂度

• 性能

• 监控

• 成本和许可

• 支持和文档

• 最流行模型服务工具汇总

• 模型服务运行时

• BentoML

• TensorFlow Serving (TFX)

• TorchServe

• Triton Inference Server

• Titan Takeoff 推理服务

• 模型服务运行时的比较

• 模型服务平台

• 云提供商平台（Amazon SageMaker、Vertex AI、Azure Machine Learning）

• KServe

• Seldon Core

• BentoCloud

• 模型服务平台比较

• 总结

选择正确的模型服务工具对于任何机器学习项目的成功都至关重要。将模型部署到生产中是机器学习生命周期中的关键步骤。毕竟，我们训练模型是为了解决问题，只有部署的模型才能为下游消费者提供预测。

模型服务的核心涉及使训练的机器学习模型可用于接收输入并提供预测结果。提供机器学习模型的挑战在于对其进行打包、通过推理 API 公开并保持其性能。每个项目在 延迟、吞吐量和可扩展性 方面都有独特的要求，这增加了复杂性。

业界已经开发了许多框架和平台。但很难获得概览、理解不同框架之间的差异并选择正确的解决方案。读完本文后，您将：

• 了解为您的团队和项目选择正确工具的最重要标准。
• 对模型服务框架的有更深入的了解。
• 了解市场上领先的模型服务工具的优缺点。

了解模型服务

在MLOps社区中，与模型服务相关的术语经常令人困惑。专业人士经常互换使用服务和部署，这可能会导致误解。

这里尝试定义和区分不同的组件及其角色。

• 模型服务运行时：将训练有素的机器学习模型打包到容器中并设置 API，以便它可以处理传入的请求。这允许模型在生产环境中使用，通过预测（推理）响应数据输入。
• 模型服务平台：旨在动态扩展模型容器数量以响应传入流量的环境。像 KServe 这样的工具就是服务平台的例子。他们管理有效部署和扩展模型所需的基础设施，无需人工干预即可响应变化的流量。
• 模型部署：将打包模型集成到服务平台并将其连接到更广泛的基础设施（例如：数据库和下游服务）的过程。这确保模型可以访问必要的数据、执行其预期功能并向消费者提供推理结果。

为了更好地理解角色和关系，来看一下这个典型的 ML 模型生命周期：

• 训练：假设有一个智能客服系统，我们训练了一个 LLM ，以协助用户做出决策。
• 打包：使用像 BentoML 这样的模型服务运行时将我们的LLM打包到 Docker 镜像中，并用标准化的功能 API 包装。
• 部署：将用 BentoML 打包的模型部署到 KServe 模型服务平台。这个基于 Kubernetes 的平台可根据传入请求自动缩放模型容器。
• 集成：将模型与智能客服系统连接起来，以便用户可以输入问题并接收LLM生成的答案。这要求我们将必要的 API 请求集成到网站前端代码中，并确保模型的 API 可以通过互联网公开访问。
• 带来价值：最后，该模型已准备好同时为许多用户提供帮助。

你需要模型服务运行时吗？

当您可以使用 Docker 基础镜像将模型与使用Flask或FastAPI快速编码的简单 API 打包在一起时，为什么还需要服务运行时？

需要模型服务运行时的三个原因

• 优化的基础镜像：模型服务运行时提供专为推理而定制的优化的 Docker 镜像。这些镜像支持针对您正在使用的硬件和机器学习框架的智能优化，确保您的模型尽可能高效地运行。机器学习优化的 Docker 基础镜像中所积累的多年智慧和优化经验是您自己很难复制的。
• 节省时间的实用程序：模型服务运行时简化了将模型打包到优化的 Docker 镜像中的任务。它们通常包含将模型转换为更适合快速、高效推理的格式的实用程序。这使得部署过程比您手动完成所有这些工作更加顺利。
• 设计良好、定义明确的 API：这些框架通过提供专为 ML 模型推理量身定制的统一、设计良好的 API，简化了集成模型的过程。模型服务运行时通常涵盖广泛的机器学习场景，包括对数据帧、图像和 JSON 有效负载的支持。

但是，在某些情况下，最好使用自定义的解决方案或寻找完全托管的产品。

避免使用模型服务运行时的三个原因

• 技能差距：某些模型服务运行时需要您的团队具备丰富的软件工程技能。如果您的团队没有足够的经验，这可能会导致设置、持续维护和集成方面的挑战。
• 批处理：当您不需要实时推理，但所有计算都可以批处理时，更简单的解决方案可能比使用成熟的服务运行时实现解决方案更直接且更具成本效益。
• 无需扩展：如果您的模型由于推理时间或请求量较低而不需要扩展，则使用 ML 优化容器的好处可能不会超过其工程成本。

选择模型服务工具的标准

找到满足团队和项目特定需求的模型服务工具可能具有挑战性。本节将指导您了解在调查模型服务框架并做出决策时要考虑的各种标准。

框架兼容性

选择模型服务工具时，考虑它支持的机器学习框架的范围至关重要，例如：scikit-learn 、 TensorFlow或PyTorch 。最不幸的是，选择并开始安装 TorchServe 后却发现它不支持您同事训练的 Keras 模型。

此外，还必须考虑该工具是否提供 GPU 支持以及是否适用于您所使用的 CUDA 版本。如果您使用大型深度学习模型，这一点尤其重要。

如果您计划跨多台机器扩展模型以处理更大的工作负载，那么对分布式处理的支持至关重要。

一体化

评估模型服务工具如何与您当前的 MLOps 堆栈和计算基础设施或云环境保持一致至关重要。假设您已经有一个正在运行的 Kubernetes 集群。这将是使用 KServe 等 Kubernetes 原生解决方案而不是 Google Vertex AI 等完全托管解决方案的有力论据。

这不仅适用于您的基础设施，也适用于框架级别。例如，如果您计划使用ArizeAI来实现模型可观察性，那么最好使用具有开箱即用集成功能的 BentoML，而不是没有开箱即用集成功能的 Tensorflow Serving。

实施的复杂度

在评估模型服务工具时，重要的是要认识到并非每个框架都适合每个团队，因为实施的复杂性和所需的背景知识可能会有很大差异。

在决定服务工具之前，请考虑所涉及的学习曲线和您团队的技术技能。难以使用的工具可能会减慢进度，尤其是在您不熟悉所需技术的情况下。

一般来说，提供高灵活性的工具往往更复杂并且学习曲线更陡。这种复杂性的出现是因为这些工具为用户提供了更多的选项和控制。虽然这可以更好地适应特定需求，但也需要更深入的理解。

理想情况下，您应该选择满足您的团队和项目需求的最简单的工具。这种方法可确保您不会因不必要的功能而使设置变得过于复杂，也不会因工具的限制而无法满足您的要求。

性能

模型服务工具旨在优化推理性能。然而，这种优化的程度因框架而异。在实施之前确定框架的效率具有挑战性，因为效率取决于许多因素，包括特定的场景、模型和硬件。

但是，可以通过检查工具的文档来获得工具性能的初步估计。讨论该工具的架构、关键概念或特定推理功能可以提供对预期性能的深入了解。

当谈到模型服务运行时时，以下是需要关注的主要功能：

• 并发模型执行：生成同一模型的多个实例，以在单个硬件处理器（GPU 或 CPU）上同时运行，并在实例之间对传入请求进行负载平衡。这样，多个较小的型号就可以共享一个处理器，从而节省成本。
• 推理并行：将推理任务分配到多个硬件处理器（GPU 或 CPU）以加快处理速度。
• 自适应批处理：允许服务器动态地将多个推理请求组合成单个批处理，从而优化吞吐量和延迟。
• 高性能运行时支持：计算密集型模型受益于转换为更高效的运行时（例如：TensorRT） 。
• 异步API ：启用非阻塞请求，允许系统同时处理多个请求。这提高了响应能力，因为系统不按顺序处理请求。
• gRPC 推理协议：为服务之间的通信提供传统 HTTP/REST 的更有效替代方案。事实上， gRPC 协议在响应时间方面已证明优于 REST 。

监控

评估模型服务工具的内置监控和日志记录功能至关重要。这些功能使您能够确保模型容器的运行状况和性能、帮助诊断问题并有效优化资源的使用。在分析监控需求时，请考虑您需要的详细程度以及访问监控数据的难易程度。

本文中讨论的模型服务运行时都会生成 Prometheus 指标。要监控生产中的模型性能，您需要一个可以使用日志的 Prometheus 服务。为此，您有两个主要选项：部署 Prometheus 服务或使用完全托管的工具。

另一个需要研究的方面是与外部监控系统和可观测平台的集成。使用完全托管的监控工具（例如：Arize AI 、 Fiddler AI或Evidently）可以显著提高您在生产中管理模型性能的能力，而无需支持复杂的基础设施。

成本和许可

下一个标准是预测与模型服务工具相关的成本：

• 定价结构：一些模型服务工具是基于订阅的，一些需要一次性付费，一些根据资源利用率收费，还有一些是开源的。
• 许可：某些模型服务工具对模型容器的部署或分发施加限制，特别是在商业环境中。例如，在 2024 年初，Seldon Core 将其许可证更改为商业源许可证 v1.1 (BSL)，使其免费供非生产使用，但需要每年订阅才能用于生产部署。
• 总成本：评估与模型服务工具相关的总成本涉及的不仅仅是价格标签。这很容易被忘记，特别是在选择可免费下载和运行的开源工具时。您必须考虑持续活动的成本，例如：支持、更新和基础设施要求。例如，KServe 是开源的，因此可以免费使用，但它需要部署和管理 Kubernetes 集群才能运行。

支持和文档

最后的标准围绕支持和文档：

• 支持：选择具有活跃社区或提供商支持的工具是有益的，因为在实施过程中从专家那里获得建议或错误修复非常宝贵。对于开源工具，您可以通过调查 Slack 上的交互或开发人员对其 GitHub 存储库上的问题的响应来评估支持质量。
• 文档：在安装工具之前，检查文档的清晰度和可读性不会有什么坏处。不可低估它，因为文档将在一段时间内成为您的主要伴侣。
• 学习资源：丰富的学习材料（例如：教程、常见问题解答和代码示例）至关重要。这些资源可以显著简化团队的学习过程，并增强该工具的整体用户体验。

最流行模型服务工具汇总

根据其功能和使用程度，下图展示了流行的一些模型服务工具。将这些工具分为两类：服务运行时和服务平台。

模型服务运行时

服务运行时的作用是将模型代码和制品打包到容器中，并构建针对模型推理优化的 API。

此类别中讨论的每个工具都支持以下功能：

• 并行处理：支持并行处理，同时处理多个任务。
• 异步 API ：允许非阻塞请求，可同时处理请求，响应速度比顺序处理更快。
• 自适应批处理：使服务能够将传入的推理请求合并为一个批次，以获得更好的吞吐量并减少延迟。
• REST API ：使用 POST、GET、PUT 和 DELETE 等 HTTP verbs处理客户端-服务器通信。
• gRPC：基于 HTTP/2 的高性能、低延迟的远程过程调用框架，用于服务通信。
• 监控日志：审查的每个模型服务运行时都会生成Prometheus日志，可以提取这些日志来分析硬件和模型性能指标。

BentoML

BentoML是一个开源框架，可简化将模型打包为 ML 优化的 Docker 镜像的过程。

BentoML 于 2019 年首次发布，引入了“Bentos”的概念：包含打包模型所需的所有组件的存档，例如：源代码、模型架构和配置。

该工具提供了一个 Python SDK，其中包含用于构建 Bentos 的实用程序。用户开发继承自BentoML接口的Python类来生成API服务。这非常方便，因为它允许您在创建模型的容器化版本之前测试和调试这些类。

选择 BentoML 的理由

• 易于使用：BentoML 是最简单易用的框架之一。自从 1.2 版本发布以来，用几行代码构建一个 Bento 已经成为可能。
• ML 框架支持：BentoML 支持所有领先的机器学习框架，例如：PyTorch、Keras、TensorFlow 和 scikit-learn。
• 并发模型执行：BentoML 支持 GPU 分配比例。换句话说，您可以在单个 GPU 上生成模型的多个实例来分散处理。
• 集成：BentoML 集成了 ZenML、Spark、MLflow、fast.ai、Triton 推理服务等。
• 灵活性：BentoML 是“Pythonic”，允许您打包任何可以使用 Python 导入的预训练模型，例如：大型语言模型 ( LLMs )、扩散模型或 CLIP。
• 清晰的文档：该文档易于阅读、结构良好，并且包含大量有用的示例。
• 监控：BentoML 与 ArizeAI 和 Prometheus 指标集成。

BentoML 的主要限制和缺点

• 需要额外的实现：由于 BentoML 是“Pythonic”，因此您需要自己实现模型加载和推理方法。
• 对高性能运行时的本机支持：BentoML 在 Python 上运行。因此，它不如 Tensorflow Serving 或 TorchServe 那样优化，后两者都运行在用 C++ 编写并编译为机器代码的后端上。但是，可以使用ONNX Python API来加快推理时间。

小结

总的来说，BentoML 是一个很棒的工具，适合大多数场景和团队。主要缺点是需要为每个模型重新实现 Python 服务，以及从高性能运行时集成模型的潜在复杂性。

此外，该组织还提供了 BentoCloud，这是一个完全托管的模型服务平台，专门用于扩展 BentoML 容器。

TensorFlow Serving (TFX)

TensorFlow Serving (TFX) 是一个开源的高性能服务运行时，专门用于打包 TensorFlow 和 Keras 模型。它提供了一个优化的 Docker 镜像，可将 TensorFlow 导出的模型连接到 REST API。

选择 TensorFlow Serving的原因

• 易于使用：对于 TensorFlow 模型，打包过程就像使用Docker 的一个 CLI 命令和几行 Python一样简单。但是，如果您想将自定义预处理或后处理包含到服务中，则需要构建自定义签名。
• 高性能运行时：从Python导出模型后，可以使用Docker将其打包。TensorFlow Serving 容器在底层使用 C++ 运行时，使 TensorFlow Serving 成为性能最佳的模型服务运行时之一。
• 定制：该框架为定制服务模块提供了清晰的抽象。但是，要支持具有自定义操作的模型、提供与模型关联的特定数据或实现自定义特征转换逻辑，需要具备一些 C++ 知识。

TensorFlow Serving 的主要限制和缺点

• ML框架支持：该工具仅支持TensorFlow和Keras模型。
• 文档：文档有些简单而且不太直观。它不会按顺序引导您了解这些概念，感觉就像您需要自己探索。
• 无并发模型执行：TensorFlow Serving 不支持每个设备上多个模型的智能负载平衡。

小结

如果您使用 TensorFlow 或 Keras 进行模型训练，TensorFlow Serving (TFX) 是您的首选框架。该工具提供了一种将模型转换为 TensorFlow 特定的高性能运行时的简单方法。

但是，如果 TensorFlow 或 Keras 不是您选择的框架，那么 TensorFlow Serving 就不是一个选择。虽然可以将其扩展为支持其他 ML 框架，但这种方法缺乏明显的优势，因为它需要额外的实现，而其他的模型服务运行时则提供开箱即用的本机支持。

TorchServe

TorchServe是一个模型服务运行时，旨在为生产环境中的 PyTorch 模型提供服务。它旨在提供实用程序来简化为模型构建 Docker 镜像的过程，配备 API 并专为最佳模型推理而设计。

在 PyTorch 中提供模型的步骤如下：

• 导出：根据模型的 PyTorch 定义，需要使用TorchScript将模型导出为 TorchServe 可以处理的格式。
• 打包：接下来，使用“torch-model-archiver”实用程序来存档模型。
• 构建容器：最后，我们使用 Docker CLI 从存档中创建一个 Docker 镜像。

选择TorchServe的理由

• 易于使用：对于简单的用例，只需几个 CLI 命令即可使用 TorchServe 提供模型。但是，如果默认处理程序不支持您的用例，您将需要使用 Python 开发自己的处理程序。
• 高性能运行时：TorchServe 在模型推理方面是表现最好的。容器在用 C++ 实现的本机运行时上运行模型，从而产生惊人的性能。
• 定制：TorchServe 定制服务指南提供了许多如何扩展其抽象的示例。

TorchServe 的主要限制和缺点

• ML 框架支持：该工具仅支持 PyTorch 模型。
• 无并发模型执行：TorchServe 不支持在单个 GPU 或 CPU 上提供同一模型的多个实例。
• 文档：TorchServe 的文档是 PyTorch 文档的一部分，很难浏览。

小结

TorchServe 是一款成熟且强大的工具，PyTorch 训练的模型可以选择 TorchServe。与 TensorFlow Serving 类似，能够轻松将模型转换为 C++ 运行时是一个巨大的优势。

Triton Inference Server

Triton Inference Server 是 Nvidia 开发的开源服务运行时。它是性能最高的框架，因为它充分利用了底层硬件。

无可否认， Triton 架构是服务运行时中最复杂的一种。毕竟，在优化方面，谁比领先的 GPU 制造商 Nvidia 更值得信赖呢？

选择 Triton Inference Server 的理由

• 并发模型执行：Triton 的实例组功能允许将模型的多个实例加载到单个 GPU 上。这使得性能的提高与同一硬件上的副本数量成正比。但是，请务必记住，此方法不会增加 GPU 的 vRAM。换句话说，您的 GPU 必须有足够的内存来处理至少两个模型副本，才能以这种方式实现性能增益。
• ML 框架支持：Triton 提供了广泛的 ML 框架支持。如：PyTorch、OpenVINO、ONNX Runtime、TensorRT-LLM、vLLM等
• 高级优化：Triton 具有许多高级功能，例如：有状态模型的序列批处理或在模型之间传递张量的集成调度程序。
• 深度监控：Triton 提供 Prometheus 高级监控指标。
• 先进的实用程序：Triton 在设计时就考虑到了性能。它提供了多个实用程序来减少延迟并提高模型的吞吐量：
• 通过模型分析器查找硬件的最佳配置（例如：最大批量大小、动态批处理和实例组参数）来帮助您优化模型性能。
• 通过性能分析器调试性能问题。
• 通过模型预热减少模型的加载时间。
• 文档：该框架具有深入而全面的文档。

Triton Inference Server的主要限制和缺点

• 复杂性：设置和配置 Triton 可能具有挑战性。在模型服务领域中，该框架具有最苛刻的学习曲线，因为用户必须熟悉多个概念和抽象。
• 硬件依赖性：该工具主要针对高端 Nvidia GPU 设计。不支持在 AMD 上运行。

小结

对于拥有强大软件技能、需要在 Nvidia GPU 上获得最佳性能的团队来说，Triton 是首选。对于需要高吞吐量和低延迟的大规模场景，它没有竞争者，因为它是唯一在推理优化运行时提供并发模型执行的工具。然而，与 Triton 相关的开发成本和维护成本也不容低估。

多种模型服务工具提供与 Triton 的集成。将 BentoML 与 Triton集成可以标准化模型打包过程和版本控制，同时与标准 BentoML 相比提高推理速度。另一方面， Vertex AI 上的 Triton 并没有减少 Triton 的开发和维护开销，而是扩展了 Triton 实例以获得更好的性能。

Titan Takeoff 推理服务

Titan Takekoff 是一个专为大语言模型 (LLMs) 的部署和托管而定制的闭源服务运行时。它专为有数据隐私问题的团队而设计，支持云和本地部署。

该工具提供专门用于LLM推理的专有 Docker 镜像。它支持 HuggingFace 的大多数文本生成和嵌入模型。

Titan Takeoff 提供了一个模型内存计算器来帮助您选择硬件。此外，它使用量化技术来压缩您的LLMs ，以支持在现有硬件上使用更大的模型。

选择Titan Takeoff推理服务的理由

• LLMs推理：具有专有的推理引擎，可实现针对LLMs优化的顶级推理速度和吞吐量。然而，TitanML 并未分享有关其引擎的任何细节。
• 简化部署：该工具提供现成的 Docker 镜像，以便轻松自托管。对于支持的模型，容器附带已打包在其中的模型。对于自定义模型，有文档可将模型导入TitanML 容器。
• 推理优化：Titan Takeoff 工具提供多 GPU 支持和量化，以及额外的实用程序来优化特定硬件的模型性能。
• 用户友好的界面：Titan Takeoff 包括用于模型测试和管理的 GUI。
• 不绑定云提供商：此框架使您能够在 Amazon SageMaker、Vertex AI、EC2、CloudRun、LangChain API 或 Kubernetes 集群上部署模型。

Titan Takeoff 推理服务的主要限制和缺点

• 定价：TitanML 网站上的定价部分不提供有关定价结构或范围的任何具体信息。
• 专注的重点：Titan Takeoff 主要为LLMs设计。
• 新产品和公司：Titan Takeoff 相对较新，其背后的公司仍然是一家小型初创公司。该产品及其开发人员是否能成为一个强有力的竞争者还有待观察。

小结

对于优先考虑自定义LLM部署的数据隐私的团队来说，Titan Takeoff 推理服务是一个可靠的选择。无论如何，鉴于其处于早期阶段和增长潜力，这个平台值得每个有兴趣为LLMs服务化的人关注。

模型服务运行时的比较

下表是各个模型服务运行时核心功能的概览，考虑到所有模型推理服务运行时都支持 REST API、gRPC、自适应批处理、异步 API 并生成 Prometheus 日志。因此，不在比较表中添加这些功能的列，以保持其简洁和信息丰富。

模型服务平台

模型服务平台的作用是管理用于部署和扩展机器学习模型的基础设施。

因此，在技术选型时，决策不是在选择服务平台还是服务运行时之间做出的。在大多数情况下，两者都需要。事实上，与服务运行时打包的模型可以部署在模型服务平台上以进行扩展和监控。

另外，大多数服务平台都有自己的原生服务运行时，您也可以选择使用外部服务运行时。

以Vertex AI服务平台为例：

• 原生服务运行时：可以使用 Google 提供的预构建模型容器来部署模型。
• 外部服务运行时：另一种选择是使用您通过模型服务运行时（例如：BentoML）创建的自定义容器。

云提供商平台（Amazon SageMaker、Vertex AI、Azure Machine Learning）

三大云提供商（Amazon SageMaker、Vertex AI 和 Azure Machine Learning）的模型服务平台非常相似。它们是端到端机器学习平台的一部分，管理从数据准备、实验、训练到部署的整个生命周期。

选择云提供商平台的原因

• 易于使用：这些平台的简单性使得即使规模较小且相对缺乏经验的团队也能够快速部署、监控和扩展 ML 模型。
• 集成更紧密：简化了机器学习模型与相应云提供商的服务和工具的集成。例如，Vertex AI 与 Google Cloud Platform 完全集成，而 SageMaker 则与许多其他 AWS 服务无缝协作。
• 托管基础设施：只需很少的设置和维护即可扩展 ML 模型。该平台将代表您委托和管理必要的计算资源。
• 自动缩放端点：模型端点会根据传入流量以最小的工作量自动调整。（在这三个解决方案中，Amazon SageMaker 是唯一能够使其机器学习推理端点扩展到零的解决方案。）
• 支持：通过额外订阅可以获得相应提供商的广泛支持。
• 内置监控：这些平台不需要额外的基础设施来监控模型容器，具有在许多场景下的模型指标。
• 文档：提供全面且定期更新的文档。然而，大量的文档导航起来非常麻烦。

云提供商平台的主要限制和缺点

• 供应商锁定：紧密的集成造成了对各自云提供商的强烈依赖。迁移到其他平台通常相当于重新设计大部分设置。
• 高成本：这些平台比自我管理的基础设施更昂贵，特别是当您的应用程序需要高端 GPU 时。与常规基础设施价格相比，云提供商收取很高的溢价。
• 复杂的定价：通常很难全面评估成本，因为影响总体费用的因素有多种，例如：计算资源、存储需求和网络带宽，以及使用完全托管解决方案收取的费用。
• 操作限制：云提供商平台强制执行特定于供应商的格式和程序。这限制了灵活性和可定制性，因为您有义务遵循云提供商的限制。

小结

云提供商平台非常适合 MLOps 专业知识有限的中小型团队。它们也非常适合长期使用云平台并将大部分环境维护工作委派出去的公司。然而，他们必须准备好支付与之相关的高额成本。

KServe

KServe 是一个开源工具，专注于在Kubernetes上提供和扩展机器学习模型。

该工具以前称为 KFServing，源自开源Kubeflow项目。它已更名为 KServe，现在作为独立服务运行。

选择KServe的理由

• 自动缩放：该平台提供开箱即用的自动缩放功能。此外，它还支持扩展到零以优化资源成本。