Les LLMs open-source ont atteint un niveau de qualité qui justifie leur déploiement en production. Mais entre "faire tourner Ollama en local sur son laptop" et "déployer une stack IA fiable pour des utilisateurs en production", il y a une série de décisions d'architecture qui conditionnent tout le reste. Certaines se rattrapent facilement. D'autres coûtent cher à revoir.
Cet article documente les décisions que j'ai prises en construisant et en déployant des stacks LLM on-premise, et les raisons derrière chacune. Pas un tutoriel pas-à-pas : les décisions de design, leurs compromis, et ce qu'on sous-estime systématiquement.
Pourquoi auto-héberger
La question mérite d'être posée avant l'architecture. Auto-héberger un LLM a du sens dans ces cas :
- Souveraineté des données. Les données sensibles (contrats, RH, données clients, code propriétaire) ne doivent pas transiter sur des serveurs tiers. C'est souvent non-négociable en industrie, santé, finance, ou simplement par choix stratégique.
- Coût à volume. À partir d'un certain nombre d'utilisateurs intensifs, la facture cloud devient supérieure au coût amorti du matériel. Le seuil dépend des abonnements en place (avec ChatGPT Pro à 200$/user/mois, il est bas).
- Personnalisation profonde. System prompts permanents, RAG sur documents internes, agents métier, fine-tuning : tout ça est possible en cloud, mais complexe et coûteux. On-premise, c'est votre infrastructure, vous faites ce que vous voulez.
- Indépendance. Pas de changement d'API unilatéral, pas de discontinuation de modèle, pas de dépendance à la disponibilité d'un service externe.
Si aucun de ces critères ne s'applique, le cloud est probablement le bon choix, et la complexité opérationnelle d'une stack on-premise n'est pas justifiée.
L'architecture en trois couches
Une stack LLM on-premise se découpe naturellement en trois couches avec des responsabilités distinctes :
┌─────────────────────────────────────┐
│ Couche automation │ n8n, workflows, connecteurs métier
├─────────────────────────────────────┤
│ Couche interface │ Open WebUI, gestion comptes, RAG
├─────────────────────────────────────┤
│ Couche inférence │ vLLM / Ollama, API OpenAI-compatible
└─────────────────────────────────────┘Le découplage est important. Chaque couche expose une API standard (OpenAI-compatible pour l'inférence, REST pour l'automation) et peut être remplacée indépendamment. Si vous décidez dans six mois de passer de vLLM à un autre moteur, ou d'Open WebUI à une autre interface, les autres couches ne bougent pas.
Ce découplage a un coût : il faut orchestrer trois services au lieu d'un. Docker Compose gère ça correctement pour un déploiement single-node. Kubernetes si vous avez plusieurs nœuds ou des contraintes de disponibilité.
Le moteur d'inférence : les compromis qui comptent
C'est la décision qui a le plus d'impact sur les performances et sur ce que vous pouvez faire.
Ollama est le point d'entrée naturel. Installation en une commande, support GGUF natif, multi-modèles, fonctionne sur Linux/macOS/Windows, API OpenAI-compatible. Pour du développement, du prototypage, ou un déploiement sur Apple Silicon (Mac Studio), c'est le bon choix.
Ses limites apparaissent en production à charge : pas de batching de requêtes (chaque requête est traitée séquentiellement par défaut), gestion du KV cache moins fine, pas de tensor parallelism multi-GPU.
vLLM est conçu pour la production. Continuous batching, PagedAttention pour le KV cache, tensor parallelism, quantization INT8/FP8, API OpenAI-compatible. La différence de throughput sous charge est significative, plusieurs fois supérieure à Ollama sur GPU dédié.
Ses contraintes : GPU NVIDIA uniquement (CUDA), RAM système minimale plus élevée, temps de démarrage plus long (chargement du modèle complet en VRAM au lancement), configuration plus complexe.
| Critère | Ollama | vLLM |
|---|---|---|
| Mise en route | Minutes | Dizaines de minutes |
| Hardware | CPU, GPU, Apple Silicon | GPU NVIDIA uniquement |
| Throughput sous charge | Moyen | Élevé |
| Multi-modèles simultanés | Oui | Non (un modèle par instance) |
| Quantization avancée | GGUF (Q4/Q8) | AWQ, GPTQ, FP8, INT8 |
| Cible | Dev, Micro (Mac) | Production |
Le format du modèle et la quantization
La quantization réduit la précision des poids pour économiser de la VRAM. Q4_K_M (4 bits) est le point de départ raisonnable : la perte de qualité sur les tâches métier courantes est imperceptible, le gain en VRAM est significatif (environ 2,5× vs BF16), et la vitesse d'inférence est supérieure car moins de données à lire depuis la mémoire par token.
Un exemple concret sur un modèle 26B :
BF16 : ~52 Go VRAM → KV cache disponible sur GPU 64 Go : ~12 Go
Q4_K_M : ~18 Go VRAM → KV cache disponible sur GPU 64 Go : ~46 GoLe KV cache, c'est la mémoire allouée aux conversations actives. Plus il est grand, plus vous pouvez gérer de sessions simultanées avec un contexte long. La quantization ne dégrade pas la qualité, mais double ou triple votre capacité de charge.
L'interface utilisateur : ce que les développeurs sous-estiment
La tendance naturelle est de se concentrer sur le moteur d'inférence et de traiter l'interface comme secondaire. C'est une erreur.
Pour des utilisateurs non-techniques en production, l'interface conditionne l'adoption. Un modèle excellent avec une interface confuse ne sera pas utilisé. Open WebUI est aujourd'hui le projet le plus mature : gestion des comptes, groupes, permissions par collection RAG, agents configurables, historique des conversations, intégration de modèles multiples.
Deux points qu'on néglige souvent :
Le RBAC. Dans une PME, le service RH ne doit pas voir les documents du service juridique. La comptabilité ne doit pas avoir accès aux projets R&D. Open WebUI gère le cloisonnement des collections RAG par groupe. Configurez ça dès le déploiement : le retrofitter après coup demande de recréer les collections et les permissions.
Le RAG. La vraie valeur d'un assistant interne n'est pas la génération de texte générique, c'est la capacité à répondre sur les documents de l'entreprise. Cahier des charges, procédures internes, contrats cadre, fiches produit. Sans RAG bien configuré, vous avez un ChatGPT plus compliqué à déployer. Avec un RAG sur les bonnes sources, vous avez un assistant qui connaît votre entreprise.
L'automation : le levier de valeur réel
L'interface utilisateur couvre le cas d'usage "un humain pose une question, le modèle répond". C'est le point d'entrée, pas la destination.
La valeur opérationnelle réelle vient des intégrations : l'assistant qui surveille une boîte mail et rédige des réponses type, le workflow qui analyse chaque nouveau contrat entrant, l'agent qui génère un rapport hebdomadaire à partir des données du CRM.
n8n est mon choix pour cette couche : open-source, self-hostable, nœud HTTP natif pour appeler l'API LLM, connecteurs pour les outils courants (Google Workspace, Slack, Airtable, webhooks). La logique des workflows est visuelle, des équipes non-techniques peuvent l'adapter sans toucher au code.
Le point d'architecture qui compte ici : ne coupler pas l'automation au modèle spécifique. Vos workflows n8n appellent l'API OpenAI-compatible exposée par votre moteur d'inférence. Si vous changez de modèle demain, les workflows ne bougent pas. C'est la même raison pour laquelle LiteLLM comme proxy unifié a du sens dans les organisations qui utilisent plusieurs modèles, j'ai documenté ce pattern chez Evaneos.
Sizing : les pièges courants
Trois erreurs reviennent systématiquement.
Confondre VRAM modèle et VRAM totale nécessaire. Charger un modèle de 18 Go sur une carte de 24 Go ne laisse que 6 Go pour le KV cache. Avec des contextes de 8K tokens, c'est peut-être 3 sessions simultanées. Sur une carte de 32 Go, vous avez 14 Go pour le KV cache, soit 8 à 12 sessions. Le sizing se fait en partant du nombre de sessions simultanées cibles, pas de la taille du modèle seule.
Sous-estimer les sessions simultanées. 20 utilisateurs ne signifient pas 20 sessions en parallèle. En pratique, le pic d'utilisation d'une PME représente 20 à 30% des utilisateurs actifs simultanément. Mais prévoyez une marge : un pic à l'heure du déjeuner ou lors d'une réunion collective peut saturer une configuration sous-dimensionnée.
Oublier le RAM système. vLLM charge le modèle en VRAM GPU, mais utilise la RAM CPU pour les tenseurs temporaires, les embeddings RAG, et le prefill de longs contextes. 32 Go de RAM système est un minimum raisonnable. 64 Go si vous faites du RAG intensif ou des contextes très longs.
Ce que cette stack ne résout pas
Quelques points que les déploiements on-premise n'adressent pas nativement, et qui méritent une décision explicite.
La haute disponibilité. Un serveur GPU unique est un single point of failure. Si la carte tombe, le service s'arrête. Pour des usages critiques, un second nœud en hot standby ou un basculement vers une API cloud de secours doit être prévu explicitement.
Les mises à jour de modèle. Passer à une nouvelle version du modèle nécessite de le télécharger (souvent 15 à 50 Go), de redémarrer le moteur d'inférence, et de valider que les comportements attendus n'ont pas changé. Ce n'est pas complexe, mais ce n'est pas automatique non plus. Un process de mise à jour doit être documenté.
L'observabilité. Tokens générés par minute, latence par requête, taux d'erreur, utilisation VRAM en temps réel : sans instrumentation, vous volez à l'aveugle. Uptime Kuma pour la supervision de disponibilité, et les métriques vLLM exposées via son endpoint Prometheus pour les métriques d'inférence.
Conclusion
Une stack LLM on-premise n'est pas plus complexe qu'une stack applicative classique, c'est juste une stack avec des contraintes matérielles supplémentaires (GPU, VRAM) et des décisions d'architecture qui méritent d'être pensées avant, pas après.
Les décisions qui comptent le plus : le choix du moteur d'inférence (Ollama vs vLLM selon le hardware et le volume), la quantization Q4 comme défaut raisonnable, le cloisonnement RAG par équipe dès le départ, et le découplage de la couche automation du modèle sous-jacent.
Si vous construisez ce type de stack pour des clients PME plutôt que pour votre propre infrastructure, j'ai monté Sover.tech précisément pour ça : déploiement clé en main, matériel sélectionné, modèle qualifié sur des tâches métier réelles, maintenance incluse.
