OpenLLM : servir un modèle ouvert derrière une API compatible OpenAI

Le problème : un modèle ouvert n'est pas un service

Télécharger des poids sur un disque ne produit pas une API. Entre les deux, il faut un serveur HTTP, un format de requête et de réponse, une gestion du streaming, un tokenizer chargé correctement et un backend d'inférence qui exploite le GPU. Chaque équipe qui auto-héberge un modèle réécrit cette couche, souvent en divergence avec le format attendu par ses propres clients. OpenLLM prend en charge cette partie et expose le résultat sous forme d'API compatible OpenAI. Le public visé est précis : des équipes plateforme ou MLOps qui ont déjà des machines GPU et qui veulent que leurs applications existantes, écrites contre le SDK OpenAI, pointent vers un modèle qu'elles contrôlent. Le README cite le client Python OpenAI et LlamaIndex comme exemples de clients, ce qui confirme cette cible. Une personne qui veut simplement discuter avec un modèle sur son portable n'est pas concernée par ce projet.

Ce que fait réellement la commande openllm serve

Le mécanisme tient en une commande : openllm serve llama3.2:1b. Le README indique que le serveur devient accessible sur http://localhost:3000 et qu'il fournit des API compatibles OpenAI. Les clients doivent connaître trois éléments : l'adresse de l'hôte, le nom du modèle et, éventuellement, une clé d'API. L'exemple du README utilise base_url='http://localhost:3000/v1' et api_key='na', ce qui montre que l'authentification est facultative dans la configuration par défaut. Le nom de modèle à transmettre n'est pas l'alias court utilisé en ligne de commande mais l'identifiant Hugging Face complet, par exemple meta-llama/Llama-3.2-1B-Instruct dans l'appel client. Cette distinction entre l'alias de service et le nom attendu par l'API est la principale source d'erreur au premier essai. Le serveur expose aussi une interface de chat sur /chat, utile pour vérifier manuellement qu'un modèle répond avant de brancher une application.

Le catalogue de modèles est un dépôt Git, pas un registre intégré

OpenLLM ne code pas en dur la liste des modèles qu'il sait servir. Il s'appuie sur ce que le README appelle un model repository, un catalogue hébergé dans le dépôt GitHub bentoml/openllm-models. La commande openllm model list affiche les modèles disponibles dans le dépôt par défaut et dans ceux que vous avez ajoutés. openllm repo update synchronise la liste locale avec les mises à jour des dépôts connectés, et openllm model get llama3.2:1b affiche les informations d'un modèle précis. Ce choix a une conséquence pratique : ajouter un modèle interne ne passe pas par un registre propriétaire mais par un dépôt que vous référencez. Le README mentionne la possibilité d'ajouter un model repository pour exécuter des modèles personnalisés, sans détailler la procédure dans l'extrait fourni. Si votre organisation impose une revue des artefacts avant déploiement, c'est ce dépôt qu'il faut versionner et auditer, pas l'installation d'OpenLLM elle-même.

Les poids ne sont pas inclus, et le matériel n'est pas négociable

Le README est explicite : OpenLLM ne stocke pas les poids des modèles. Un jeton Hugging Face est donc nécessaire pour les modèles soumis à autorisation. La procédure décrite comporte trois étapes : créer un jeton, demander l'accès au modèle restreint, puis exporter ce jeton dans la variable d'environnement HF_TOKEN. Sans cela, le serveur ne peut pas récupérer les poids au démarrage. Le tableau des modèles pris en charge donne des besoins GPU qui écartent d'emblée une grande partie des machines de développement. gemma2:2b est annoncé à 12G, llama3.1:8b et qwen2.5:7b à 24G, phi4:14b et qwq:32b à 80G. Les modèles plus gros passent à plusieurs cartes : llama3.3:70b à 80Gx2, mistral-large:123b-2407 à 80Gx4, llama4:17b16e à 80Gx8 et deepseek:r1-671b à 80Gx16. Ces chiffres proviennent du tableau du README et décrivent le matériel attendu, pas une mesure de débit. Une équipe qui dispose d'une seule carte de 24 Go peut servir un modèle 7B ou 8B, et rien de plus dans cette liste.

Là où OpenLLM n'est pas le bon outil

Le cas d'usage mal servi est celui du poste de travail. Si vous voulez exécuter un modèle quantifié sur un portable sans GPU dédié, le tableau des besoins matériels suffit à trancher : les entrées les plus légères demandent déjà 12 Go de mémoire GPU. Un autre cas défavorable est celui du modèle absent du catalogue et sans dépôt personnalisé : le README renvoie à la section sur l'ajout d'un dépôt de modèles, mais l'extrait disponible s'arrête avant d'en détailler la mécanique, donc je ne peux pas affirmer ce que cette procédure exige exactement. Enfin, l'authentification par défaut est facultative. Un serveur lancé avec openllm serve sans configuration supplémentaire et exposé sur une interface réseau publique n'offre aucune barrière à l'entrée. Le README ne décrit pas de mécanisme de clé obligatoire, seulement une clé d'API présentée comme optionnelle côté client. C'est un point à traiter au niveau du réseau ou du proxy, pas dans OpenLLM lui-même d'après les éléments fournis.

Face à un serveur d'inférence classique

L'alternative la plus directe est un serveur d'inférence générique comme vLLM, qui expose lui aussi une API compatible OpenAI. La différence d'approche porte sur le périmètre. vLLM se concentre sur le moteur d'inférence et son ordonnancement de requêtes ; OpenLLM ajoute une couche de packaging et de catalogue par-dessus le moteur, avec un dépôt de modèles consultable en ligne de commande, une interface de chat intégrée sur /chat, et un chemin de déploiement décrit vers Docker, Kubernetes et BentoCloud. Si vous n'avez qu'un modèle, une seule machine et aucun besoin de catalogue, cette couche supplémentaire apporte peu. Si vous gérez plusieurs modèles, plusieurs environnements et une équipe qui doit retrouver la même commande de démarrage d'un poste à l'autre, la normalisation par openllm serve et openllm model list a une valeur réelle. Le README positionne d'ailleurs le projet explicitement dans une logique de cloud plutôt que de poste local, ce qui confirme cette lecture.

Maintenance, licence et coût de mise à jour

Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et de copyright. Ce texte n'est pas un avis juridique ; faites relire le fichier LICENSE du dépôt si votre organisation a des contraintes particulières. Sur le rythme de publication, les trois versions listées dans le matériel fourni sont v0.6.28, v0.6.29 et v0.6.30, toutes datées d'avril 2025, et le dernier push sur la branche main est daté du 7 septembre 2026. L'écart entre ces deux dates est un élément à vérifier de votre côté : je ne dispose pas des notes de version pour savoir ce que contiennent les commits postérieurs à avril 2025. Le coût de mise à jour ne se limite pas au paquet openllm. Il inclut la synchronisation du dépôt de modèles via openllm repo update, la vérification des identifiants Hugging Face, et la compatibilité des clients avec le nom de modèle renvoyé par l'API. Un changement d'alias dans le catalogue peut casser une application qui transmet un nom figé.

Conclusion éditoriale

OpenLLM s'adresse aux équipes qui disposent déjà de GPU de classe serveur et qui veulent exposer un modèle ouvert derrière une API compatible OpenAI sans écrire de serveur HTTP. Ce n'est pas l'outil adapté à une station de travail mono-GPU ou à un premier essai sur un modèle de 7B. Avant d'adopter, vérifiez trois points concrets : la mémoire requise pour la variante visée dans le tableau du README, la présence de HF_TOKEN si le modèle est sous accès restreint, et le contenu du dépôt bentoml/openllm-models pour la révision exacte que vous comptez servir.

Sources officielles

1. bentoml/OpenLLM on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases