BentoML

BentoML 是一个开源的 Python 框架，用于构建、打包和部署机器学习模型服务 API。该项目由 Chaoyu Yang 创立并于 2019 年首次发布，在 2022 年 7 月达到了 v1.0 里程碑，此后发展壮大，现已支持超过 10,000 家组织，包括 50 多家财富 500 强企业。该项目采用 Apache 2.0 许可，在 github.com/bentoml/BentoML 上维护（v1.4.38，2026 年 4 月，8.6k stars），截至 2026 年 2 月，它在 Modular（Mojo 编程语言和 MAX 推理引擎背后的公司）旗下运营。其核心优势在于与框架无关的模型服务：无论你的技术栈是 PyTorch、TensorFlow、JAX、ONNX、XGBoost 还是 scikit-learn，BentoML 都能将其打包成一个独立的、符合 OCI 标准的镜像，在从本地开发到 Kubernetes 生产环境的各个环节中保持一致运行。

BentoML 生态系统由三款产品组成。开源框架通过 Python 类型提示处理服务定义、每个运行器（runner）的依赖隔离以及自动化的 Docker 镜像生成。OpenLLM 于 2023 年 6 月推出，只需一条命令即可将任何开源 LLM（Llama 4、DeepSeek、Qwen、Phi3）作为兼容 OpenAI 的 API 端点运行，并使用 vLLM、TRT-LLM 或 PyTorch 作为推理后端。BentoCloud 于 2024 年 6 月全面上市，是一个托管推理平台，提供自动缩放、缩放至零（scale-to-zero）、冷启动优化、金丝雀和 A/B 部署、LLM 专属监控，以及跨 AWS、Azure、GCP、CoreWeave 和 Lambda Labs 的自带云（BYOC）部署。团队可以零成本从开源框架起步，添加 OpenLLM 用于自托管 LLM 端点，并在需要托管基础设施时升级到 BentoCloud。

BentoML 在 2026 年 5 月的实际功能

核心工作流是“Bento”：一个版本化、可复现的包，它将模型、依赖项、运行时配置及其 API 定义捆绑到一个符合 OCI 标准的工件中。你可以使用标准的 Python 类型提示定义服务，使用 @bentoml.api 装饰方法，并运行 bentoml build 来生成容器化镜像。该镜像可以在本地提供服务以进行测试，或者推送到注册表并部署到 Kubernetes，而无需为服务层本身编写额外的 Dockerfiles、Helm charts 或手写 YAML。

对于 LLM 专属工作流，OpenLLM 将模型加载、后端选择和 API 路由的复杂性简化为一条命令。运行 openllm serve meta-llama/Llama-4-Scout-17B-16E 会启动一个带有兼容 OpenAI 端点、内置聊天 UI 和自动后端选择（如果检测到 GPU 则使用 vLLM，否则回退到 PyTorch）的本地服务器。构建 RAG 管道、聊天机器人或由 LLM 驱动的 API 的团队，可以将 LangChain 或任何 OpenAI SDK 客户端指向此端点，而无需修改应用程序代码。

BentoCloud 的生产层补充了自托管 Kubernetes 部署所需但开箱即用时很少能做好的功能：针对推理工作负载的突发请求模式进行优化的基于并发的自动缩放、用于空闲部署成本管理的缩放至零功能，以及基础设施级别的金丝雀/影子/A/B 测试。自带云（BYOC）选项将 BentoCloud 的控制平面部署到客户自己的 VPC 中，为有 HIPAA、SOC 2 或 ISO 27001 要求的企业提供托管的用户体验，同时确保数据不离开其环境。截至 2026 年 2 月，这种组合部署栈正在与 Modular 的 MAX 推理引擎集成，以优化从模型权重到 HTTP 响应的完整路径。

BentoML 与 vLLM 和 Ray Serve 的定位对比

大多数开发者面临的比较不是“选 BentoML 还是 vLLM”，而是“它们各自负责技术栈的哪一层”。vLLM 是一个纯粹的推理引擎，其基础创新是 PagedAttention：它借鉴了操作系统的虚拟内存管理，将 KV 缓存拆分为非连续的块，从而将 GPU 内存浪费减少高达 80%。vLLM 的 V1 架构（2024 年重写）采用多进程设计，调度器、引擎核心和 GPU 工作节点之间通过 ZeroMQ 进行通信，其 C++ 路由可处理远超 150 个并发请求，而不会让 Python 的 GIL 成为瓶颈。vLLM 目前拥有约 75,000 个 GitHub stars，是事实上的推理引擎标准。BentoML 并非与 vLLM 竞争，而是对其进行封装：官方的 BentoVLLM 项目 (github.com/bentoml/BentoVLLM) 允许团队使用 vLLM 作为 token 生成后端，而 BentoML 则负责容器化、多模型编排、BYOC 云部署和可观测性。两者的分工非常清晰：vLLM 负责最大化吞吐量；BentoML 负责其上方的部署和生命周期层。如果团队只需要在单台机器上最大化原始 LLM token 吞吐量，可以单独使用 vLLM。如果团队需要打包异构模型、编排多步推理管道并跨云部署，则需要 BentoML。

Ray Serve 采用不同的架构理念。它构建在 Ray 分布式计算框架（由 Anyscale 支持，参见 Anyscale）之上，使用 Ray 的 actor 模型在节点之间分配工作。Ray Serve LLM（2024-2025）添加了一流的 vLLM 集成、兼容 OpenAI 的端点以及用于前缀缓存局部性的自定义请求路由。机制上的差异在于基础设施占用：Ray Serve 要求团队在 Kubernetes 上部署和操作 Ray 集群（通过 KubeRay 或其他方式），并且它对已经使用 Ray 进行分布式数据处理或训练的团队非常有利。BentoML 是与框架无关的，不需要 Ray。它的打包模型是 OCI 原生的（标准 Docker 容器），而不是 Ray 基于 actor 的运行时，这意味着 BentoML 的 Bentos 可以直接嵌入现有的 Kubernetes 基础设施中，而无需采用更广泛的 Ray 生态系统。对于已经运行 Ray 任务的团队来说，Ray Serve 是正确的选择；而 BentoML 则适合那些希望获得 Kubernetes 原生服务，又不想承担 Ray 集群运维负担的团队。

“BentoML 最近对我来说比 torchserve 工作流好用得多。” —— komatsu，Hacker News，2022 年 7 月

“我最喜欢的模型部署工具之一。” —— kelseyfrog，Hacker News，2022 年 7 月

部署工作流的实际情况

在开发环境中让模型提供服务只需几分钟：定义一个 Python 类，注释输入和输出类型，然后运行 `bentoml serve`。该框架会生成一个 REST 端点，处理序列化，并启动一个带有 Swagger UI 的本地服务器。容器化同样直接：`bentoml build` 会生成一个 OCI 镜像，将模型、其 pip 依赖项和服务代码隔离捆绑在一起。团队反馈说，他们能够在一个下午用 BentoML 替换基于 Flask 的模型服务脚本，并免费获得动态批处理、并行运行器执行和结构化日志记录功能。

生产环境的复杂性往往在边缘情况中显现。配置繁琐是最常见的抱怨：bentofile.yaml 格式提供了对运行器资源、批处理参数和容器设置的细粒度控制，但非标准配置需要对 BentoML 的内部机制有深入的了解。服务配置选项的文档历来存在不一致的情况，GitHub Discussion #3560 就指出了关于何时适合在生产环境（而非仅限开发环境）使用 `bentoml serve` 的指导存在冲突。自定义模型架构（自定义加载器、与标准模式不匹配的预处理管道）需要编写超出框架自动生成范围的样板代码。

截至 2024 年 2 月 25 日，SageMaker 路径已关闭：BentoML 归档了 aws-sagemaker-deploy 存储库。仅使用 SageMaker 基础设施的团队需要迁移到 OCI 容器部署或寻找替代方案。BentoCloud 的 BYOC 选项涵盖了以前使用 SageMaker 的许多企业需求，但它要求采用 BentoCloud，而不是原生留在 AWS 生态系统中。

特别是对于 LLM 工作流，OpenLLM 消除了大部分摩擦。兼容 OpenAI 的端点意味着使用 OpenAI SDK 的现有应用程序代码无需修改即可运行。BentoML 团队在 2024 年 6 月发布了一份全面的 LLM 推理后端基准测试，比较了 vLLM、LMDeploy、MLC-LLM、TensorRT-LLM 和 TGI，并使用 BentoML 作为一致的服务层。基准测试证实，与原生 Python 服务相比，BentoML 仅增加了极小的开销，同时提供了原始推理引擎所缺乏的生产可观测性和部署一致性。这使其与 vLLM 等工具并驾齐驱，非常适合既需要性能又需要可部署性的团队。

BentoML 适合哪些人群

最明确的适用对象是负责将模型从 notebook 或训练运行转化为生产 API 的 ML 工程团队，他们需要提供异构模型类型（不仅限于 LLM）的服务，并希望部署在自己的基础设施或私有云上。如果你的技术栈混合了 PyTorch 模型、ONNX 导出和 scikit-learn 管道，并且你需要将它们全部作为可靠的、容器化的 API 运行并共享工具，那么 BentoML 是少数几个无需大量胶水代码即可解决此问题的框架之一。

第二个非常契合的群体是希望自托管 LLM 端点以避免商业提供商按 token 收取 API 费用的团队。OpenLLM 一键部署 Llama、DeepSeek 或 Qwen 模型，为这些团队提供了在自己的 GPU 上运行的兼容 OpenAI 的 API，如果工作负载增加，还可以选择通过 BentoCloud BYOC 进行扩展。与 Modal 或 Replicate 等工具相比，BentoML 提供了更多的基础设施控制权，代价是需要承担更多的运维责任。对于在提供服务的同时跟踪模型血统的组织来说，将 BentoML 与 MLflow 结合使用是端到端 ML 生命周期管理的常见模式。

有合规性要求的企业团队可以从 BYOC 部署模型中受益。对 SOC 2 Type II、ISO 27001 和 HIPAA 的支持意味着受监管的行业（医疗保健、金融服务）可以在不违反数据驻留要求的情况下获得托管推理编排。2026 年 2 月 Modular 的收购通过在部署层增加硬件级推理优化，进一步巩固了这一地位。

BentoML 不是什么

BentoML 不是即插即用的推理引擎。它没有实现自己的注意力机制、KV 缓存管理或 token 批处理。它依赖于 vLLM、TRT-LLM 或 PyTorch 等后端来实现该层功能。如果团队的唯一要求是在固定的 GPU 设置上最大化 LLM token 吞吐量，则应评估单独使用 vLLM，它拥有 75,000 多个 stars，并且凭借 PagedAttention 经过验证的内存效率，是针对该特定任务更专注的工具。

它不是一个无代码平台。工作流的每个部分都需要编写 Python 代码。没有可视化的模型部署界面，也没有拖拽式的管道构建器。没有 Python ML 工程师的团队不是其目标用户。

它不是 AWS SageMaker 集成。截至 2024 年 2 月，该路径已归档。致力于 SageMaker 生态系统的团队需要评估替代方案，或单独切换到 OCI 原生容器部署。

它不是一个训练框架。BentoML 在训练完成后接手。对于训练期间的实验跟踪，像 MLflow 这样的工具服务于 ML 生命周期的早期部分。BentoML 处理的是服务和部署阶段，而不是实验或训练阶段。