Ingénierie

Passerelles d'IA et serveurs d'inférence open source à héberger soi-même

Les outils open source qu'on appelle « passerelles d'IA » font deux métiers différents. Les routeurs comme LiteLLM placent un seul point d'accès au format OpenAI devant des modèles qui tournent ailleurs ; les serveurs d'inférence comme vLLM, SGLang, Ollama et Xinference chargent les poids sur votre propre matériel et produisent les tokens. La plupart des déploiements en production associent l'un et l'autre, et tous parlent le format d'API d'OpenAI. Les héberger vous-même vous donne la maîtrise de tout le trajet des données, au prix des GPU, des mises à jour et des astreintes — et quand la juridiction est la seule raison, une API dont les opérateurs sont sous contrôle européen y mène souvent plus simplement.

Publié le 6 oct. 2026 · vérifié le 20 oct. 2026

Deux métiers : router et exécuter

Partez du travail à accomplir. Un routeur ne contient aucun modèle : il reçoit votre requête, applique clés, budgets et nouvelles tentatives, puis la transmet à un fournisseur ou à votre propre moteur. Un moteur d'inférence charge les poids en mémoire et calcule la réponse. Les outils ci-dessous, tels que leurs dépôts les décrivaient le 6 octobre 2026 :

Outil	Métier	Exécute lui-même les modèles	API au format OpenAI	Licence
LiteLLM	Routeur : serveur proxy et SDK Python	Non — transmet à plus de 100 fournisseurs	Oui	MIT, sauf un dossier « enterprise »
vLLM	Moteur d'inférence de production	Oui — GPU, CPU, autres accélérateurs	Oui	Apache-2.0
SGLang	Moteur d'inférence de production	Oui	Oui	Apache-2.0
Ollama	Exécution locale	Oui — CPU ou GPU	Oui, sous /v1	MIT
TGI	Serveur d'inférence, désormais archivé	Oui	Oui	Apache-2.0
Xinference	Plateforme multimodèle	Oui — GPU ou CPU	Oui	Apache-2.0

Une organisation courante en production place un routeur devant un ou plusieurs moteurs : LiteLLM gère les clés et les dépenses, vLLM ou SGLang fait le calcul.

Pourquoi auto-héberger, et ce que vous prenez en charge

La maîtrise du trajet des données. Prompts et réponses restent sur des machines que vous exploitez, et aucune société extérieure ne les détient. Sur un cloud américain, cette maîtrise n'est que partielle : le fournisseur doit communiquer les données en sa « possession, custody, or control », où qu'elles soient stockées (18 U.S.C. § 2713).
Des poids sur mesure. Des modèles affinés ou rares qu'aucun fournisseur ne sert.
Un coût fixe. Au-delà d'un certain volume, louer des GPU coûte moins cher que payer au token — le seuil est calculé plus bas.

Ce que vous prenez en charge : acheter ou louer les GPU, télécharger et mettre à jour les modèles, répartir la charge, superviser, appliquer les correctifs de sécurité, et gérer l'incident de 2 heures du matin quand un GPU manque de mémoire. Sans personnes qui font déjà ce travail, il peut coûter plus qu'il ne rapporte.

LiteLLM : une seule porte d'entrée pour de nombreux fournisseurs

LiteLLM appelle plus de 100 fournisseurs de LLM au format OpenAI, comme bibliothèque Python ou comme serveur proxy ; les exemples de son README font tourner le proxy sur le port 4000. Le proxy ajoute ce dont une équipe a besoin autour des modèles : clés virtuelles, suivi des coûts et des dépenses par projet ou par utilisateur, nouvelles tentatives et bascules entre déploiements, répartition de charge, journalisation vers des outils d'observabilité, et cache. Il est sous licence MIT, sauf un dossier « enterprise » sous une licence propre.

Sa limite est structurelle : il n'exécute aucun modèle. Router vers un fournisseur américain envoie toujours le prompt à cette société ; LiteLLM centralise le choix du fournisseur, il ne change pas qui traite les données. Si la juridiction est l'enjeu, placez derrière lui des fournisseurs sous contrôle européen.

vLLM et SGLang : des moteurs pour la production

vLLM repose sur PagedAttention, sa façon de gérer le cache d'attention, avec le traitement par lots continu et le cache de préfixes. À son lancement, en juin 2023, son équipe mesurait un débit jusqu'à 24 fois supérieur à celui de Hugging Face Transformers et 3,5 fois supérieur à celui de TGI (annonce). Il répartit les modèles sur plusieurs GPU (parallélisme de tenseurs, de pipeline et d'experts), sert une API compatible OpenAI, et tourne sur GPU NVIDIA, AMD et Intel comme sur CPU, avec des extensions pour d'autres accélérateurs comme les TPU de Google. Apache-2.0.

SGLang, lui aussi sous Apache-2.0, est l'autre moteur vers lequel renvoient désormais les mainteneurs de TGI, avec des API compatibles OpenAI pour le chat, la vision et les embeddings. Aucun des deux ne gère comptes, budgets ou clés par équipe : c'est le rôle du routeur.

Ollama : des modèles sur le poste du développeur

Ollama télécharge et lance un modèle en une commande sur macOS, Windows ou Linux, ou dans Docker. Il répond sur localhost:11434, avec son propre point d'accès /api/chat et des points d'accès compatibles OpenAI sous /v1 (compatibilité OpenAI). Un modèle trop grand pour un GPU est réparti sur les GPU disponibles, et le nombre de requêtes parallèles par modèle est un réglage qui vaut un par défaut. Licence MIT.

C'est le bon outil pour les prototypes et pour essayer des modèles sur vos propres questions. Un service partagé en production demande de la montée en charge automatique et de la répartition de charge, qu'Ollama ne fournit pas ; les équipes passent en général à vLLM, à SGLang ou à une API managée, et gardent leur code, puisque le format d'API est le même.

TGI est archivé ; Xinference sert de nombreux types de modèles

Text Generation Inference, de Hugging Face, a longtemps fait tourner les services de chat et d'inférence de Hugging Face. Son README indique désormais qu'il est en maintenance et recommande vLLM, SGLang, llama.cpp ou MLX à la place, et son dépôt est archivé, en lecture seule, sa dernière modification datant du 21 mars 2026. Ne démarrez pas de nouveau déploiement dessus.

Xinference, de l'équipe Xorbits, sert des modèles de langage, d'embeddings, d'images et d'audio depuis un seul déploiement, par une API compatible OpenAI qui inclut l'appel de fonctions. Il peut répartir l'inférence sur plusieurs machines, utilise GPU et CPU, et peut s'appuyer sur vLLM ; il est sous Apache-2.0, avec une édition commerciale pour la production. Il convient aux chaînes de recherche documentaire qui ont besoin d'un modèle de chat et d'un modèle d'embeddings côte à côte.

Ce que coûte l'auto-hébergement

Commencez par la mémoire. En 16 bits, un modèle occupe environ deux octets par paramètre : Llama 3.3 70B demande environ 140 Go pour ses poids, soit deux NVIDIA H100 de 80 Go ; en 8 bits, environ 70 Go, qui tiennent sur une carte avec peu de place pour le contexte. Ce que sont les poids ouverts donne les chiffres des modèles plus grands.

Puis le loyer. Le 6 octobre 2026, OVHcloud affichait une instance à un H100 à 2,80 € de l'heure hors TVA (tarifs) : 2 452,80 € pour un mois de 730 heures, TVA comprise. Au prix d'Evanesca pour Llama 3.3 70B, 1,512 € par million de tokens, en entrée comme en sortie, TVA comprise, ce mois représente environ 1,6 milliards de tokens. En dessous de ce volume, la carte louée coûte plus cher que l'API ; et comme une carte ne tient pas le modèle en 16 bits, le seuil pour deux cartes est d'environ 3,2 milliards de tokens par mois.

Ajoutez ce que la facture de GPU ne montre pas : le temps d'ingénieur, les heures creuses, et une mise à jour à chaque meilleur modèle publié. La tarification au token n'a rien de tout cela, et ne coûte rien quand personne ne s'en sert — les prix d'Evanesca, modèle par modèle, sont sur la page des tarifs, et auto-héberger ou payer au token détaille le calcul du seuil.

Quand une API européenne managée est la voie la plus légère

Auto-hébergez si vous avez besoin d'un réseau isolé ou entièrement privé, si vous utilisez des poids sur mesure ou affinés, ou si votre volume dépasse le seuil ci-dessus et que vous avez une équipe pour l'exploiter. Sinon — pas d'équipe GPU, des volumes encore inconnus, ou la juridiction comme raison principale —, une API dont les opérateurs sont sous contrôle européen y mène avec moins de travail.

Les deux se combinent. LiteLLM peut router vers l'API compatible OpenAI d'Evanesca comme vers n'importe quel fournisseur : des modèles servis par des opérateurs européens — Scaleway en France pour la plupart, avec OVHcloud en relais —, aucune trace des prompts gardée par Evanesca, et les règles propres des opérateurs : Scaleway peut conserver et lire les requêtes qui provoquent des erreurs ou paraissent abusives, jusqu'à 14 jours, et Mistral AI garde 30 jours les entrées et sorties de ses modèles. Une configuration LiteLLM minimale :

config.yaml (LiteLLM)

model_list:
  - model_name: gemma-4-26b
    litellm_params:
      model: openai/gemma-4-26b
      api_base: https://evanesca.app/api/v1
      api_key: os.environ/EVANESCA_API_KEY

Un prototype bâti sur Ollama passe à la même API en changeant l'URL de base. Voir la documentation, les intégrations et les modèles. L'API d'Evanesca n'est pas encore ouverte ; cette configuration fonctionnera dès son ouverture.

Questions fréquentes

Quelle différence entre une passerelle d'IA et un serveur d'inférence ?

Une passerelle, ou routeur, comme LiteLLM n'exécute aucun modèle : elle transmet les requêtes à des fournisseurs ou à vos propres moteurs, et ajoute clés, budgets, nouvelles tentatives et journaux. Un serveur d'inférence comme vLLM, SGLang ou Ollama charge les poids et calcule les réponses. En production, on place souvent un routeur devant un ou plusieurs moteurs.

LiteLLM est-il gratuit en auto-hébergement ?

Oui : il est sous licence MIT, à part un dossier « enterprise » sous une licence distincte. Vous payez les serveurs sur lesquels il tourne et les fournisseurs qu'il appelle.

Peut-on utiliser Ollama en production ?

Pour un usage interne léger, certaines équipes le font. Il est conçu pour faire tourner des modèles sur le poste d'un développeur : il sait répartir un modèle sur plusieurs GPU et servir des requêtes parallèles, mais n'offre ni montée en charge automatique ni répartition de charge. Les services partagés en production tournent en général sur vLLM ou SGLang, ou appellent une API managée.

Auto-héberger dans une région cloud européenne suffit-il à la souveraineté ?

Pas si le cloud est exploité par une société américaine : le droit américain peut l'obliger à communiquer les données qu'elle détient, où que soient ses serveurs. Hébergez chez un fournisseur sans contrôle américain, ou utilisez une API dont les opérateurs sont sous contrôle européen, comme ceux d'Evanesca : Scaleway, en France, pour la plupart de ses modèles, avec OVHcloud en relais.