Héberger un LLM open source : vLLM, Ollama et la souveraineté

Utiliser un LLM via une API (OpenAI, Mistral) est simple. Mais dès qu'on parle de souveraineté stricte ou de très gros volume, une autre voie s'ouvre : héberger soi-même un modèle open source. Deux outils dominent, Ollama et vLLM, pour deux usages différents.

Pourquoi auto-héberger un LLM

Trois raisons, rarement une seule :

• Souveraineté : les données ne quittent jamais votre infrastructure. Décisif en santé, finance, défense, secteur public.
• Coût : à très haut volume, le coût à l'appel d'une API dépasse celui d'un GPU dédié bien utilisé.
• Contrôle : version du modèle figée, pas de dépendance à un fournisseur qui change ses prix ou ses modèles.

Ce raisonnement gagne à être posé sur des faits vérifiables plutôt que sur une intuition, car la crainte la plus répandue n’est pas la bonne. OpenAI indique dans sa documentation sur les données de l’API que les données envoyées via l’API ne servent pas à entraîner ses modèles, sauf opt-in explicite ; en revanche, les contenus transitent par des journaux de surveillance des abus conservés jusqu’à 30 jours, et l’exclusion de ces journaux est soumise à approbation préalable. C’est là que se situe l’arbitrage réel : non pas « le modèle apprend-il mes données ? », mais « où sont hébergés les journaux, combien de temps, sous quelle juridiction ? ». L’auto-hébergement fait disparaître la question ; il en crée d’autres.

Ollama : simple, pour démarrer et le local

Ollama rend trivial le fait de faire tourner un modèle open source (Llama, Mistral, etc.) sur une machine. Idéal pour prototyper, pour des usages locaux ou un volume modéré. Sa limite : il n'est pas pensé pour servir des milliers de requêtes concurrentes en production.

Une précision utile sur le périmètre d’Ollama, pour éviter une déception classique : l’outil est excellent pour développer, tester des modèles et faire tourner un assistant sur un poste, mais il n’est pas conçu pour servir des dizaines d’utilisateurs simultanés. Il traite les requêtes essentiellement les unes après les autres. Sur une machine de développement, c’est parfait ; en production multi-utilisateurs, la latence s’effondre dès quelques requêtes concurrentes. Un modèle à poids ouverts sous licence Apache 2.0, comme une partie du catalogue Mistral, peut d’ailleurs se déployer avec l’un ou l’autre moteur : le choix du moteur est indépendant du choix du modèle.

vLLM : la production à débit élevé

vLLM est un moteur d'inférence optimisé pour le débit. Sur GPU (Scaleway, OVH), il sert beaucoup de requêtes en parallèle avec une latence maîtrisée, grâce à des techniques comme le continuous batching. C'est l'outil quand l'auto-hébergement doit tenir une vraie charge.

Ce gain de débit repose sur deux mécanismes qu’il vaut la peine de nommer, parce qu’ils expliquent l’écart. vLLM gère la mémoire d’attention par pages plutôt que par blocs contigus, ce qui évite de réserver de la mémoire pour des contextes qui ne seront jamais remplis, et il regroupe les requêtes en continu : une requête terminée libère immédiatement sa place à une nouvelle, sans attendre la fin du lot. Résultat, un même GPU sert nettement plus de requêtes par seconde qu’avec une exécution séquentielle. C’est ce qui fait la différence entre une démonstration et un service.

Quand auto-héberger, quand utiliser une API

• API (Mistral en UE) pour la plupart des projets : démarrage rapide, derniers modèles, pas d'ops GPU. Voir notre page Agence Mistral.
• Self-hosted (Ollama/vLLM) quand la souveraineté est stricte, le volume très élevé, ou les deux.

Le calcul de coût mérite d’être fait dans les deux sens, car il s’inverse selon le volume. Une API se paie au jeton : la facture est nulle quand personne n’utilise le service, et croît linéairement avec l’usage. Un GPU se paie à l’heure : le coût est le même à vide qu’à pleine charge. Il existe donc un seuil de bascule, propre à chaque projet, qu’on obtient en divisant le coût mensuel du GPU par le prix au million de jetons de l’API équivalente. En dessous de ce seuil, l’API est moins chère ; au-dessus, l’auto-hébergement le devient. À quoi s’ajoutent, côté auto-hébergé, des coûts rarement budgétés : supervision, mises à jour de modèles, et une astreinte.

Le choix se cadre sur le niveau de confidentialité requis et le coût réel à votre volume : c'est l'un des arbitrages de nos assistants IA connectés à vos données.

Une contrainte de souveraineté sur vos données IA ? On dimensionne l'infra avec vous.

Au-delà de l'hébergement, nous concevons votre RAG d'entreprise sur vos données internes.