BentoML

BentoML est un framework Python open source conçu pour créer, packager et déployer des API de service de modèles de machine learning. Fondé par Chaoyu Yang et lancé pour la première fois en 2019, il a franchi le cap de sa version 1.0 en juillet 2022 et s'est depuis développé pour accompagner plus de 10 000 organisations, dont plus de 50 entreprises du Fortune 500. Le projet est sous licence Apache 2.0, maintenu sur github.com/bentoml/BentoML (v1.4.38, avril 2026, 8.6k étoiles), et opère depuis février 2026 sous l'égide de Modular, l'entreprise à l'origine du langage de programmation Mojo et du moteur d'inférence MAX. Son principal atout est le service de modèles agnostique : que votre stack soit PyTorch, TensorFlow, JAX, ONNX, XGBoost ou scikit-learn, BentoML l'encapsule dans une image autonome et conforme à la norme OCI, qui s'exécute de manière cohérente, du développement local jusqu'à la production sur Kubernetes.

L'écosystème BentoML se compose de trois produits. Le framework open source gère la définition des services via les annotations de type Python, l'isolation des dépendances par exécuteur (runner) et la génération automatisée d'images Docker. OpenLLM, lancé en juin 2023, permet d'exécuter n'importe quel LLM open source (Llama 4, DeepSeek, Qwen, Phi3) sous forme de point de terminaison API compatible OpenAI avec une seule commande, en utilisant vLLM, TRT-LLM ou PyTorch comme backend d'inférence. BentoCloud, disponible en version générale depuis juin 2024, est la plateforme d'inférence gérée offrant l'autoscaling, la mise à l'échelle à zéro (scale-to-zero), l'optimisation des démarrages à froid, les déploiements canary et A/B, la surveillance spécifique aux LLM, ainsi que le déploiement Bring-Your-Own-Cloud (BYOC) sur AWS, Azure, GCP, CoreWeave et Lambda Labs. Les équipes peuvent démarrer gratuitement avec le framework open source, ajouter OpenLLM pour des points de terminaison LLM auto-hébergés, puis passer à BentoCloud lorsqu'elles ont besoin d'une infrastructure gérée.

Ce que fait réellement BentoML en mai 2026

Le flux de travail central repose sur le « Bento » : un package versionné et reproductible qui regroupe un modèle, ses dépendances, sa configuration d'exécution et la définition de son API dans un seul artefact conforme à la norme OCI. Vous définissez un service à l'aide d'annotations de type Python standard, décorez les méthodes avec @bentoml.api, et exécutez bentoml build pour produire une image conteneurisée. Cette image peut être servie localement pour des tests ou poussée vers un registre et déployée sur Kubernetes sans nécessiter de Dockerfiles supplémentaires, de charts Helm ou de code YAML écrit à la main pour la couche de service elle-même.

Pour les flux de travail spécifiques aux LLM, OpenLLM réduit la complexité du chargement des modèles, de la sélection du backend et du routage des API à une seule commande. L'exécution de openllm serve meta-llama/Llama-4-Scout-17B-16E démarre un serveur local avec un point de terminaison compatible OpenAI, une interface de chat intégrée et une sélection automatique du backend (vLLM si un GPU est détecté, PyTorch en solution de repli). Les équipes qui créent des pipelines RAG, des chatbots ou des API basées sur des LLM peuvent pointer LangChain ou n'importe quel client SDK OpenAI vers ce point de terminaison sans modifier le code de leur application.

La couche de production de BentoCloud apporte ce que les déploiements Kubernetes auto-hébergés exigent mais gèrent rarement bien par défaut : un autoscaling basé sur la concurrence et adapté aux pics de requêtes des charges de travail d'inférence, une mise à l'échelle à zéro pour la gestion des coûts sur les déploiements inactifs, et des tests canary/shadow/A/B au niveau de l'infrastructure. L'option Bring-Your-Own-Cloud déploie le plan de contrôle de BentoCloud dans le propre VPC du client, offrant aux entreprises soumises aux exigences HIPAA, SOC 2 ou ISO 27001 l'expérience utilisateur d'un service géré sans que les données ne quittent leur environnement. En février 2026, cette stack de déploiement combinée est en cours d'intégration avec le moteur d'inférence MAX de Modular pour optimiser l'ensemble du processus, des poids du modèle jusqu'à la réponse HTTP.

Le positionnement de BentoML face à vLLM et Ray Serve

La comparaison à laquelle la plupart des développeurs sont confrontés n'est pas « BentoML ou vLLM », mais plutôt « quelle couche de la stack chacun gère-t-il ». vLLM est un pur moteur d'inférence dont l'innovation fondamentale est PagedAttention : il emprunte la gestion de la mémoire virtuelle des systèmes d'exploitation pour diviser les caches KV en blocs non contigus, réduisant ainsi le gaspillage de mémoire GPU jusqu'à 80 %. L'architecture V1 de vLLM (réécrite en 2024) utilise une conception multi-processus avec une communication ZeroMQ entre un planificateur, un cœur de moteur et des workers GPU, ainsi qu'un routage C++ capable de gérer bien plus de 150 requêtes simultanées sans que le GIL de Python ne devienne un goulot d'étranglement. vLLM compte actuellement environ 75 000 étoiles sur GitHub et constitue le standard de facto des moteurs d'inférence. BentoML enveloppe vLLM plutôt que de le concurrencer : le projet officiel BentoVLLM (github.com/bentoml/BentoVLLM) permet aux équipes d'utiliser vLLM comme backend de génération de tokens, tandis que BentoML gère la conteneurisation, l'orchestration multi-modèles, le déploiement cloud BYOC et l'observabilité. La division mécanique est claire : vLLM se charge de maximiser le débit ; BentoML gère la couche de déploiement et de cycle de vie qui se trouve au-dessus. Une équipe qui a seulement besoin de maximiser le débit brut de tokens LLM sur une seule machine peut utiliser vLLM de manière autonome. Une équipe qui doit packager des modèles hétérogènes, orchestrer des pipelines d'inférence en plusieurs étapes et déployer sur plusieurs clouds a besoin de BentoML.

Ray Serve repose sur une philosophie architecturale différente. Il est construit sur le framework de calcul distribué Ray (soutenu par Anyscale, voir Anyscale), utilisant le modèle d'acteur de Ray pour répartir le travail entre les nœuds. Ray Serve LLM (2024-2025) a ajouté une intégration de premier ordre avec vLLM, des points de terminaison compatibles OpenAI et un routage de requêtes personnalisé pour la localité du cache de préfixes. La différence mécanique réside dans l'empreinte de l'infrastructure : Ray Serve oblige les équipes à déployer et à exploiter des clusters Ray (via KubeRay ou autre) sur Kubernetes, et il récompense les équipes qui utilisent déjà Ray pour le traitement de données distribué ou l'entraînement. BentoML est agnostique vis-à-vis des frameworks et ne nécessite pas Ray. Son modèle de packaging est natif OCI (conteneurs Docker standards) plutôt que basé sur le runtime d'acteurs de Ray, ce qui signifie que les Bentos de BentoML s'intègrent dans l'infrastructure Kubernetes existante sans avoir à adopter l'écosystème Ray dans son ensemble. Ray Serve est le bon choix pour les équipes qui exécutent déjà des tâches Ray ; BentoML convient aux équipes qui souhaitent un service natif Kubernetes sans la lourdeur opérationnelle d'un cluster Ray.

« BentoML a récemment bien mieux fonctionné pour moi que les flux de travail torchserve. » -- komatsu, Hacker News, juillet 2022

« L'un de mes outils préférés pour le déploiement de modèles. » -- kelseyfrog, Hacker News, juillet 2022

À quoi ressemble la réalité du flux de déploiement

Mettre un modèle en service en développement prend quelques minutes : définissez une classe Python, annotez les types d'entrée et de sortie, et exécutez `bentoml serve`. Le framework génère un point de terminaison REST, gère la sérialisation et démarre un serveur local avec une interface Swagger. La conteneurisation est tout aussi directe : `bentoml build` produit une image OCI qui regroupe le modèle, ses dépendances pip et le code de service de manière isolée. Les équipes signalent pouvoir remplacer des scripts de service de modèles basés sur Flask par BentoML en une après-midi et obtenir gratuitement le traitement par lots dynamique, l'exécution parallèle des runners et la journalisation structurée.

La complexité en production s'insinue à la marge. La verbosité de la configuration est la plainte la plus courante : le format bentofile.yaml offre un contrôle granulaire sur les ressources des runners, les paramètres de traitement par lots et les paramètres des conteneurs, mais les configurations non standard nécessitent une connaissance approfondie des rouages internes de BentoML. La documentation des options de configuration de service a historiquement manqué de cohérence, la discussion GitHub #3560 signalant des directives contradictoires sur le moment où `bentoml serve` est approprié pour la production par rapport au développement uniquement. Les architectures de modèles personnalisées (chargeurs personnalisés, pipelines de prétraitement qui ne correspondent pas aux modèles standard) nécessitent d'écrire du code passe-partout (boilerplate) au-delà de ce que le framework génère automatiquement.

La voie SageMaker est fermée depuis le 25 février 2024 : BentoML a archivé le dépôt aws-sagemaker-deploy. Les équipes sur une infrastructure exclusivement SageMaker doivent migrer vers un déploiement de conteneurs OCI ou trouver des alternatives. L'option BYOC de BentoCloud couvre de nombreuses exigences d'entreprise pour lesquelles SageMaker était auparavant utilisé, mais elle nécessite d'adopter BentoCloud plutôt que de rester nativement dans l'écosystème AWS.

Pour les flux de travail LLM en particulier, OpenLLM élimine la plupart des frictions. Le point de terminaison compatible OpenAI signifie que le code d'application existant utilisant le SDK OpenAI fonctionne sans modification. L'équipe BentoML a publié un benchmark complet des backends d'inférence LLM en juin 2024 comparant vLLM, LMDeploy, MLC-LLM, TensorRT-LLM et TGI, en utilisant BentoML comme couche de service cohérente. Le benchmark a confirmé que BentoML n'ajoute qu'une surcharge minimale par rapport au service Python natif tout en offrant l'observabilité en production et la cohérence de déploiement qui font défaut aux moteurs d'inférence bruts. Cela le positionne très bien aux côtés d'outils comme vLLM pour les équipes qui ont besoin à la fois de performances et de facilité de déploiement.

À qui s'adresse BentoML

La cible la plus évidente est constituée des équipes d'ingénierie ML chargées de faire passer les modèles du notebook ou de l'entraînement à l'API de production, qui doivent servir des types de modèles hétérogènes (pas seulement des LLM), et qui souhaitent déployer sur leur propre infrastructure ou cloud privé. Si votre stack mélange des modèles PyTorch, des exports ONNX et des pipelines scikit-learn et que vous avez besoin qu'ils s'exécutent tous sous forme d'API fiables et conteneurisées avec des outils partagés, BentoML est l'un des rares frameworks qui répond à ce besoin sans nécessiter de code de liaison (glue code) important.

Une deuxième cible de choix concerne les équipes qui souhaitent auto-héberger des points de terminaison LLM pour éviter les coûts d'API par token des fournisseurs commerciaux. Le déploiement en une commande des modèles Llama, DeepSeek ou Qwen par OpenLLM offre à ces équipes une API compatible OpenAI fonctionnant sur leurs propres GPU, avec la possibilité d'évoluer via le BYOC de BentoCloud si la charge de travail augmente. Comparé à des outils comme Modal ou Replicate, BentoML offre plus de contrôle sur l'infrastructure au prix d'une plus grande responsabilité opérationnelle. Pour les organisations qui suivent le lignage des modèles en parallèle du service, associer BentoML à MLflow est une pratique courante pour la gestion de bout en bout du cycle de vie ML.

Les équipes d'entreprise soumises à des exigences de conformité bénéficient du modèle de déploiement BYOC. La prise en charge des normes SOC 2 Type II, ISO 27001 et HIPAA signifie que les secteurs réglementés (santé, services financiers) peuvent obtenir une orchestration d'inférence gérée sans violer les exigences de résidence des données. L'acquisition par Modular en février 2026 renforce ce positionnement en ajoutant l'optimisation de l'inférence au niveau matériel à la couche de déploiement.

Ce que BentoML n'est pas

BentoML n'est pas un moteur d'inférence prêt à l'emploi (plug-and-play). Il n'implémente pas ses propres mécanismes d'attention, la gestion du cache KV ou le traitement par lots de tokens. Il s'appuie sur des backends comme vLLM, TRT-LLM ou PyTorch pour cette couche. Les équipes dont la seule exigence est de maximiser le débit de tokens LLM sur une configuration GPU fixe devraient évaluer vLLM de manière autonome, qui, avec plus de 75 000 étoiles et l'efficacité mémoire prouvée de PagedAttention, est l'outil le plus ciblé pour cette tâche spécifique.

Ce n'est pas une plateforme no-code. Chaque étape du flux de travail nécessite d'écrire du Python. Il n'y a pas d'interface visuelle de déploiement de modèles ni de constructeur de pipeline par glisser-déposer. Les équipes ne disposant pas d'ingénieurs ML Python en interne ne sont pas la cible.

Ce n'est pas une intégration AWS SageMaker. Depuis février 2024, cette voie est archivée. Les équipes engagées dans l'écosystème SageMaker doivent évaluer des alternatives ou passer séparément à un déploiement de conteneurs natifs OCI.

Ce n'est pas un framework d'entraînement. BentoML prend le relais une fois l'entraînement terminé. Pour le suivi des expériences pendant l'entraînement, des outils comme MLflow couvrent la première partie du cycle de vie ML. BentoML gère la phase de service et de déploiement, et non les phases d'expérimentation ou d'entraînement.