BentoML

BentoML es un framework de Python de código abierto para crear, empaquetar y desplegar API de servicio de modelos de machine learning. Fundado por Chaoyu Yang y lanzado por primera vez en 2019, alcanzó su hito v1.0 en julio de 2022 y desde entonces ha crecido para respaldar a más de 10,000 organizaciones, incluidas más de 50 empresas de la lista Fortune 500. El proyecto tiene licencia Apache 2.0, se mantiene en github.com/bentoml/BentoML (v1.4.38, abril de 2026, 8.6k estrellas) y, a partir de febrero de 2026, opera bajo Modular, la empresa detrás del lenguaje de programación Mojo y el motor de inferencia MAX. Su propuesta principal es el servicio de modelos independiente del framework: ya sea que su stack sea PyTorch, TensorFlow, JAX, ONNX, XGBoost o scikit-learn, BentoML lo empaqueta en una imagen autónoma compatible con OCI que se ejecuta de manera consistente desde el desarrollo local hasta la producción en Kubernetes.

Tres productos conforman el ecosistema de BentoML. El framework de código abierto maneja la definición de servicios a través de sugerencias de tipo (type hints) de Python, el aislamiento de dependencias por ejecutor (runner) y la generación automatizada de imágenes de Docker. OpenLLM, lanzado en junio de 2023, ejecuta cualquier LLM de código abierto (Llama 4, DeepSeek, Qwen, Phi3) como un endpoint de API compatible con OpenAI con un solo comando, utilizando vLLM, TRT-LLM o PyTorch como backend de inferencia. BentoCloud, que alcanzó la disponibilidad general en junio de 2024, es la plataforma de inferencia gestionada que ofrece autoescalado, escalado a cero, optimización de arranque en frío, despliegues canary y A/B, monitorización específica para LLM y despliegue Bring-Your-Own-Cloud (BYOC) en AWS, Azure, GCP, CoreWeave y Lambda Labs. Los equipos pueden comenzar con el framework de código abierto sin coste alguno, añadir OpenLLM para endpoints de LLM autoalojados y dar el salto a BentoCloud cuando necesiten infraestructura gestionada.

Lo que BentoML hace realmente en mayo de 2026

El flujo de trabajo central es el "Bento": un paquete versionado y reproducible que agrupa un modelo, sus dependencias, su configuración de tiempo de ejecución y su definición de API en un único artefacto compatible con OCI. Se define un servicio utilizando sugerencias de tipo estándar de Python, se decoran los métodos con @bentoml.api y se ejecuta bentoml build para producir una imagen en contenedores. Esa imagen se puede servir localmente para pruebas o enviarse a un registro y desplegarse en Kubernetes sin necesidad de Dockerfiles adicionales, Helm charts o YAML escrito a mano para la capa de servicio en sí.

Para los flujos de trabajo específicos de LLM, OpenLLM reduce la complejidad de la carga de modelos, la selección del backend y el enrutamiento de la API a un solo comando. Al ejecutar openllm serve meta-llama/Llama-4-Scout-17B-16E se inicia un servidor local con un endpoint compatible con OpenAI, una interfaz de chat integrada y selección automática de backend (vLLM si se detecta una GPU, PyTorch como alternativa). Los equipos que construyen pipelines RAG, chatbots o API impulsadas por LLM pueden apuntar LangChain o cualquier cliente del SDK de OpenAI a este endpoint sin modificar el código de la aplicación.

La capa de producción de BentoCloud añade lo que los despliegues de Kubernetes autoalojados requieren pero rara vez hacen bien desde el principio: autoescalado basado en concurrencia ajustado para los patrones de solicitudes en ráfaga de las cargas de trabajo de inferencia, escalado a cero para la gestión de costes en despliegues inactivos y pruebas canary/shadow/A/B a nivel de infraestructura. La opción Bring-Your-Own-Cloud despliega el plano de control de BentoCloud en la propia VPC del cliente, brindando a las empresas con requisitos HIPAA, SOC 2 o ISO 27001 la experiencia de usuario gestionada sin que los datos salgan de su entorno. A partir de febrero de 2026, este stack de despliegue combinado se está integrando con el motor de inferencia MAX de Modular para optimizar la ruta completa desde los pesos del modelo hasta la respuesta HTTP.

Dónde se sitúa BentoML frente a vLLM y Ray Serve

La comparación a la que se enfrentan la mayoría de los desarrolladores no es "BentoML o vLLM", sino "qué capa del stack posee cada uno". vLLM es un motor de inferencia puro cuya innovación fundamental es PagedAttention: toma prestada la gestión de memoria virtual del sistema operativo para dividir las cachés KV en bloques no contiguos, reduciendo el desperdicio de memoria de la GPU hasta en un 80%. La arquitectura V1 de vLLM (reescrita en 2024) utiliza un diseño multiproceso con comunicación ZeroMQ entre un programador, un núcleo de motor y trabajadores de GPU, y un enrutamiento en C++ que maneja muy por encima de 150 solicitudes concurrentes sin que el GIL de Python se convierta en un cuello de botella. vLLM cuenta actualmente con alrededor de 75,000 estrellas en GitHub y es el estándar de facto en motores de inferencia. BentoML envuelve a vLLM en lugar de competir con él: el proyecto oficial BentoVLLM (github.com/bentoml/BentoVLLM) permite a los equipos usar vLLM como el backend de generación de tokens, mientras que BentoML maneja la contenedorización, la orquestación multimodelo, el despliegue en la nube BYOC y la observabilidad. La división mecánica es clara: vLLM se encarga de maximizar el rendimiento; BentoML se encarga de la capa de despliegue y ciclo de vida por encima de él. Un equipo que solo necesita maximizar el rendimiento bruto de tokens LLM en una sola máquina puede usar vLLM de forma independiente. Un equipo que necesita empaquetar modelos heterogéneos, orquestar pipelines de inferencia de múltiples pasos y desplegar en varias nubes necesita BentoML.

Ray Serve opera con una filosofía arquitectónica diferente. Está construido sobre el framework de computación distribuida Ray (respaldado por Anyscale, consulte Anyscale), utilizando el modelo de actores de Ray para distribuir el trabajo entre nodos. Ray Serve LLM (2024-2025) añadió integración de primer nivel con vLLM, endpoints compatibles con OpenAI y enrutamiento de solicitudes personalizado para la localidad de la caché de prefijos. La diferencia mecánica es la huella de infraestructura: Ray Serve requiere que los equipos desplieguen y operen clústeres de Ray (a través de KubeRay o de otro modo) en Kubernetes, y recompensa a los equipos que ya usan Ray para el procesamiento de datos distribuidos o el entrenamiento. BentoML es independiente del framework y no requiere Ray. Su modelo de empaquetado es nativo de OCI (contenedores Docker estándar) en lugar del tiempo de ejecución basado en actores de Ray, lo que significa que los Bentos de BentoML encajan en la infraestructura de Kubernetes existente sin adoptar el ecosistema más amplio de Ray. Ray Serve es la opción correcta para los equipos que ya ejecutan trabajos de Ray; BentoML se adapta a los equipos que desean un servicio nativo de Kubernetes sin el peso operativo de un clúster de Ray.

"BentoML me funcionó recientemente mucho mejor que los flujos de trabajo de torchserve." -- komatsu, Hacker News, julio de 2022

"Una de mis herramientas favoritas para el despliegue de modelos." -- kelseyfrog, Hacker News, julio de 2022

Cómo es la realidad del flujo de trabajo de despliegue

Poner un modelo en servicio en desarrollo lleva minutos: defina una clase de Python, anote los tipos de entrada y salida, y ejecute `bentoml serve`. El framework genera un endpoint REST, maneja la serialización e inicia un servidor local con una interfaz de usuario de Swagger. La contenedorización es igualmente directa: `bentoml build` produce una imagen OCI que agrupa el modelo, sus dependencias de pip y el código de servicio de forma aislada. Los equipos informan que pueden reemplazar los scripts de servicio de modelos basados en Flask con BentoML en una tarde y obtener procesamiento por lotes dinámico, ejecución paralela de ejecutores y registro estructurado de forma gratuita.

La complejidad de producción se cuela en los márgenes. La verbosidad de la configuración es la queja más común: el formato bentofile.yaml ofrece un control detallado sobre los recursos del ejecutor, los parámetros de procesamiento por lotes y la configuración del contenedor, pero las configuraciones no estándar requieren una profunda familiaridad con el funcionamiento interno de BentoML. La documentación de las opciones de configuración de servicio ha sido históricamente inconsistente, y la discusión de GitHub #3560 señala orientaciones contradictorias sobre cuándo `bentoml serve` es apropiado para producción frente a solo desarrollo. Las arquitecturas de modelos personalizadas (cargadores personalizados, pipelines de preprocesamiento que no coinciden con los patrones estándar) requieren escribir código repetitivo (boilerplate) más allá de lo que el framework genera automáticamente.

La ruta de SageMaker está cerrada a partir del 25 de febrero de 2024: BentoML archivó el repositorio aws-sagemaker-deploy. Los equipos en infraestructura exclusiva de SageMaker deben migrar al despliegue de contenedores OCI o encontrar alternativas. La opción BYOC de BentoCloud cubre muchos requisitos empresariales para los que antes se usaba SageMaker, pero requiere adoptar BentoCloud en lugar de permanecer de forma nativa en el ecosistema de AWS.

Para los flujos de trabajo de LLM específicamente, OpenLLM elimina la mayor parte de la fricción. El endpoint compatible con OpenAI significa que el código de la aplicación existente que utiliza el SDK de OpenAI funciona sin modificaciones. El equipo de BentoML publicó un benchmark exhaustivo de backends de inferencia de LLM en junio de 2024 comparando vLLM, LMDeploy, MLC-LLM, TensorRT-LLM y TGI, utilizando BentoML como la capa de servicio consistente. El benchmark confirmó que BentoML añade solo una sobrecarga mínima sobre el servicio nativo de Python, al tiempo que proporciona la observabilidad de producción y la consistencia de despliegue de las que carecen los motores de inferencia puros. Esto lo posiciona bien junto a herramientas como vLLM para los equipos que necesitan tanto rendimiento como capacidad de despliegue.

Para quién está diseñado BentoML

El ajuste más claro es para los equipos de ingeniería de ML responsables de llevar los modelos desde el notebook o la ejecución de entrenamiento hasta la API de producción, que necesitan servir tipos de modelos heterogéneos (no solo LLM) y que desean desplegar en su propia infraestructura o nube privada. Si su stack mezcla modelos de PyTorch, exportaciones de ONNX y pipelines de scikit-learn y necesita que todos ellos se ejecuten como API fiables y en contenedores con herramientas compartidas, BentoML es uno de los pocos frameworks que aborda esto sin un código de integración (glue code) significativo.

Un segundo ajuste sólido es para los equipos que desean autoalojar endpoints de LLM para evitar los costes de API por token de los proveedores comerciales. El despliegue con un solo comando de OpenLLM de modelos Llama, DeepSeek o Qwen brinda a esos equipos una API compatible con OpenAI que se ejecuta en sus propias GPU, con la opción de escalar a través de BentoCloud BYOC si la carga de trabajo crece. En comparación con herramientas como Modal o Replicate, BentoML ofrece más control de la infraestructura a costa de una mayor responsabilidad operativa. Para las organizaciones que rastrean el linaje del modelo junto con el servicio, combinar BentoML con MLflow es un patrón común para la gestión integral del ciclo de vida del ML.

Los equipos empresariales con requisitos de cumplimiento se benefician del modelo de despliegue BYOC. El soporte para SOC 2 Tipo II, ISO 27001 e HIPAA significa que las industrias reguladas (atención médica, servicios financieros) pueden obtener orquestación de inferencia gestionada sin violar los requisitos de residencia de datos. La adquisición por parte de Modular en febrero de 2026 fortalece este posicionamiento al añadir optimización de inferencia a nivel de hardware a la capa de despliegue.

Lo que BentoML no es

BentoML no es un motor de inferencia plug-and-play. No implementa sus propios mecanismos de atención, gestión de caché KV o procesamiento por lotes de tokens. Depende de backends como vLLM, TRT-LLM o PyTorch para esa capa. Los equipos cuyo único requisito es maximizar el rendimiento de tokens LLM en una configuración de GPU fija deberían evaluar vLLM de forma independiente, que con más de 75,000 estrellas y con la probada eficiencia de memoria de PagedAttention es la herramienta más enfocada para ese trabajo específico.

No es una plataforma sin código (no-code). Cada parte del flujo de trabajo requiere escribir en Python. No hay una interfaz visual de despliegue de modelos ni un constructor de pipelines de arrastrar y soltar. Los equipos que no cuentan con ingenieros de ML en Python en su plantilla no son el público objetivo.

No es una integración de AWS SageMaker. A partir de febrero de 2024, esa ruta está archivada. Los equipos comprometidos con el ecosistema de SageMaker deben evaluar alternativas o cambiar al despliegue de contenedores nativos de OCI por separado.

No es un framework de entrenamiento. BentoML entra en acción una vez que se completa el entrenamiento. Para el seguimiento de experimentos durante el entrenamiento, herramientas como MLflow sirven para la parte inicial del ciclo de vida del ML. BentoML maneja la fase de servicio y despliegue, no las fases de experimentación o entrenamiento.