大模型部署难？手把手教你选对推理工具！

大模型.

于 2025-04-24 10:10:58 发布

阅读量522

点赞数 9

文章标签：人工智能 langchain microsoft 大模型算法

本文链接：https://blog.csdn.net/EnjoyEDU/article/details/147470716

版权

1、了解模型服务

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

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

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

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

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

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

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

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

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

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

2.2、不合适使用模型服务运行时的三个原因

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

3、选择模型服务工具的标准

选择模型服务工具的关键标准概述

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

3.1、框架兼容性

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

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

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

3.2、一体化

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

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

3.3、实施的复杂度

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

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

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

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

3.4、性能

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

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

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

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

3.5、监控

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

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

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

3.6、成本和许可

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

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

3.7、支持和文档

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

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

4、最流行模型服务工具汇总

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

模型服务运行时和模型服务平台概述

5、模型服务运行时

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

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

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

5.1、BentoML

BentoML 组件

Bento包含为模型构建 Docker 镜像所需的所有组件：定义依赖项的需求文件、用于加载和运行模型的源代码、推理 API、模型制品、以及 ML 模型定义。

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 容器。

5.2、TensorFlow Serving (TFX)

TensorFlow Serving 模型的生命周期

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 框架，但这种方法缺乏明显的优势，因为它需要额外的实现，而其他的模型服务运行时则提供开箱即用的本机支持。

5.3、TorchServe

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++ 运行时是一个巨大的优势。

5.4、Triton Inference Server

Triton 推理服务器的架构

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 实例以获得更好的性能。

5.5、Titan Takeoff 推理服务

Titan Takeoff Playground，用户可以在此提示 LLM

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服务化的人关注。

5.6、模型服务运行时的比较

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

推理服务运行时	多框架支持	复杂性	原生高性能运行时支持	并发模型执行	支持模型版本	支持LLM	价格
BentoML	√	低	×	√	√	√	免费 + 全托管付费
TensorFlow Serving	×	中	√	×	√	×	免费
TorchServe	×	中	√	×	×	×	免费
Nvidia Triton	√	高	√	√	√	√	免费
TitanML	×	低	√	×	×	√	付费

6、模型服务平台

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

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

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

以Vertex AI服务平台为例：

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

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

请添加图片描述

AWS、Azure 和 GCP 上模型服务组件的比较

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

选择云提供商平台的原因

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

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

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

小结

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

6.2、KServe

请添加图片描述

KServe ModelMesh 架构，控制器 Pod 协调多个 Kubernetes 部署，这些部署加载并服务多个模型。路由层生成运行时 Pod 并分发传入请求。

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

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

选择KServe的理由

自动缩放：该平台提供开箱即用的自动缩放功能。此外，它还支持扩展到零以优化资源成本。
在线预测：KServe架构实现高效的实时推理。
批量预测：KServe 实现了复杂的推理批处理器，提供高性能批量预测。
复杂的推理图：KServe 提供了优雅的设计来有效地处理复杂的推理图。
ML框架支持：支持多种ML框架，例如：TensorFlow和PyTorch。
集成：与 ZenML、Kafka、Nvidia Triton、Grafana 等多种工具完美集成。
部署策略：KServe 提供高级部署策略，例如：Multi-Armed Bandits、A/B 测试和金丝雀部署。
社区支持：该平台社区活跃。

KServe 的主要限制和缺点

Kubernetes 的复杂性：KServe 要求您部署和维护自己的 Kubernetes 集群，如果没有专门的 DevOps 团队，这可能会具有挑战性。
缺乏内置监控：KServe 不包含用于模型监控的内置解决方案。KServe 容器生成 Prometheus 日志，但用户需要安装和维护 Prometheus 服务。然而，由于 KServe 已经在 K8s 上运行，添加额外的组件应该不成问题。

小结

该平台非常适合具有扎实 Kubernetes 基础的团队，这些团队优先考虑高级部署功能和定制，以根据其应用程序定制 MLOps 基础设施。

6.3、Seldon Core

请添加图片描述

使用 Seldon Core 进行简单和复杂推理的示意图

Seldon Core是一个模型服务平台，用于在Kubernetes上部署和扩展机器学习模型。该平台以其先进的部署功能而闻名。

在 2024 年 1 月 22 日之前，Seldon Core 作为免费开源工具提供。但是，它已过渡到商业源许可证 (BSL) 1.1。现在，公司需要每年缴纳 18,000 美元的订阅费，才能将 2024 年 1 月 22 日之后发布的 Seldon Core 版本进行产品商业化。

选择 Seldon Core 的理由

在线预测：通过原生 Kafka 集成提供强大的在线预测解决方案。
批量预测：该工具为批量预测提供了一种结构良好的方法。
高级部署：支持 Multi-Armed Bandit、金丝雀部署和 A/B 测试。

Seldon Core 的主要限制和缺点

昂贵的订阅费用：Seldon 的起价为每年 18,000 美元，没有提供商支持。
Kubernetes 的复杂性：Seldon Core 要求您部署和维护自己的 Kubernetes 集群，如果没有专门的 DevOps 团队，这可能会具有挑战性。
自动缩放：自动缩放需要通过KEDA进行额外设置，并且不支持缩放到零。

小结

对于希望在 Kubernetes 上扩展机器学习模型并使用高级部署功能的团队来说，Seldon Core 是一个可行且可靠的替代方案。

6.4、BentoCloud

请添加图片描述

BentoCloud 用户界面显示支持的预打包 ML 模型

BentoCloud是一个用于扩展 BentoML 容器的专有模型服务平台，由构建 BentoML 的同一家公司设计和运营。其目标是性能和成本效率。

BentoCloud 利用 BentoML 服务运行时提供预构建的模型容器和高级 API，只需几行代码即可扩展机器学习模型。

选择BentoCloud的理由

易于使用：BentoCloud 为开发人员在各种云提供商上部署 BentoML 容器提供了简单而有效的 CLI 体验。
复杂的推理图：BentoCloud 允许使用多个模型构建分布式推理图。
自动缩放：BentoCloud 平台支持开箱即用的自动缩放，并且可以缩放到零。
高级部署策略：BentoCloud 支持金丝雀部署和 A/B 测试。
ML 框架支持：对机器学习框架提供了广泛的支持。
无供应商锁定：企业客户可以将 BentoCloud 部署到他们选择的云提供商。此外，团队始终可以在 BentoCloud 之外部署其 BentoML Docker 镜像。
内置监控：可以从 BentoCloud UI 访问模型指标，无需额外设置。

BentoCloud 的主要限制和缺点

成本：BentoCloud 平台不是开源的。完全托管的变体采用即用即付的定价模式。企业订阅（定价未公开）允许在您自己的云基础设施上部署 BentoCloud。
需要 BentoML：BentoCloud 仅支持与 BentoML 模型服务运行时打包的模型
没有 multi-armed bandits：BentoCloud不支持multi-armed bandits部署策略

小结

对于愿意使用 BentoML 作为服务运行时并正在寻找易于使用的完全托管平台的团队来说，BentoCloud 是一个不错的选择。

6.4、模型服务平台比较

下表汇总了不同模型服务平台的核心功能：

服务平台	多框架支持	复杂度	自动缩放	需要K8S	支持缩放至零	供应商锁定	支持 Multi-Armed Bandits	支持 A/B 测试	支持金丝雀支持	内置监控	价格
Amazon SageMaker	√	中	√	×	√	√	√	√	√	√	付费
Vertex AI	√	中	√	×	×	√	√	√	√	√	付费
Azure Machine Learning	√	中	√	×	×	√	×	√	√	√	付费
KServe	√	中	√	√	√	×	√	√	√	×	免费
Seldon Core	×	中	√	√	×	×	√	√	√	×	付费
BentoCloud	√	低	√	×	√	×	×	√	√	√	付费

总结

选择正确的模型服务工具对于将机器学习模型转化为带来价值的应用程序至关重要。

本文概述了服务运行时和平台，重点介绍了它们的功能、优点和局限性。可以看到找到公司最佳模型服务堆栈的难度并不小。您的选择应该基于项目的需求、团队的技能以及您需要对部署和扩展进行多少控制、框架兼容性、集成能力以及复杂性和功能之间的权衡等因素进行决策。

建议：首先，缩小哪些工具可以匹配您的特定场景。然后，花一些时间为每个潜在工具构建概念验证 (PoC)。没有比快速实现更好的方式来感受框架了。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】