Du portable au serveur : choisir, sécuriser et dimensionner votre pile LLM

Quatre moteurs, trois scénarios

Versions au 26 septembre 2026 ; ces projets publient toutes les quelques semaines.

Ollama, LM Studio et llamafile partagent llama.cpp sous le capot, et pour un seul utilisateur la configuration compte plus que l'application, selon le comparatif de Mozilla.ai de septembre 2026. La vraie ligne de partage, c'est la concurrence. Évitez de démarrer sur TGI de Hugging Face (en maintenance depuis décembre 2025), mlx_lm.server ou TabbyAPI, que leurs auteurs déconseillent en production.

Quatre techniques qui font un serveur

Elles expliquent pourquoi un même GPU peut servir un utilisateur ou cinquante.

• Batching continu. Le moteur ajoute et retire des requêtes à chaque étape de génération, sans attendre la fin d'un lot : le GPU ne chôme jamais. C'est la clé du résultat de Red Hat avec Llama 3.1 8B sur une A100 : vLLM a culminé à 793 tokens par seconde (latence P99 de 80 ms), Ollama par défaut à 41 (673 ms). Red Hat a cofondé llm-d, bâti sur vLLM, et a testé Ollama 0.9.2 (2025) : c'est un ordre de grandeur.
• PagedAttention. Le cache KV est rangé en petites pages, comme la mémoire virtuelle, plutôt qu'en un bloc par requête. L'article fondateur (SOSP 2023) rapportait un gaspillage quasi nul et un débit 2 à 4 fois supérieur aux systèmes précédents à latence égale.
• Cache de préfixes. Quand des requêtes partagent le même début (prompt système, outils, documents), le moteur réutilise le cache déjà calculé. vLLM l'active par défaut et RadixAttention, dans SGLang, est construit autour ; SGLang v0.5.20 a porté le taux de réussite de 43,8 % à 60,8 % dans son propre test. Pour les agents et le RAG, c'est souvent le plus gros gain.
• Décodage spéculatif. Un modèle brouillon ou des têtes supplémentaires (EAGLE-3, MTP) proposent plusieurs tokens que le grand modèle vérifie en une passe. Selon vLLM, le gain est élevé à faible charge et modéré à forte charge : il sert surtout la latence de quelques utilisateurs.

API compatibles OpenAI, passerelle et versions de modèles

Vos applications ne devraient pas savoir quel moteur leur répond.

vLLM, SGLang, llama-server, LM Studio et Ollama (en partie) parlent l'API d'OpenAI, et plusieurs l'API Messages d'Anthropic. Passer d'un modèle local à un fournisseur se résume à l'URL de base, mais outils, sorties structurées et certains paramètres diffèrent : testez chaque route.

Placez une passerelle (gateway) entre applications et moteurs. Un proxy compatible OpenAI comme LiteLLM Proxy ajoute clés par équipe, budgets, limites, routage, repli vers un fournisseur sous contrat et journaux ; un reverse proxy (nginx, Envoy) est le minimum. En cluster, llm-d (Sandbox de la CNCF depuis mars 2026) et NVIDIA Dynamo (v1.5.0) routent en tenant compte du cache au-dessus de vLLM ou SGLang.

Versionner les modèles

• Figez le hash du fichier, la quantification, le template de chat, la version du moteur et les paramètres d'échantillonnage.
• Exposez des alias stables sur la passerelle (par exemple chat-default) pour qu'un changement de modèle ne touche jamais au code.
• Anticipez les démarrages à froid : Ollama décharge par défaut un modèle inactif après 5 minutes ; le mode routeur de llama-server en garde 4 au plus.

Que mesurer : latence p95, tokens par seconde, file d'attente

Qui ne regarde que l'usage du GPU apprend la saturation par ses utilisateurs.

llama-server n'expose /metrics qu'avec --metrics, avec des jauges comme llamacpp:requests_deferred pour sa file ; pour Ollama et le reste, mesurez à la passerelle. Avant le lancement, faites des tests de charge à la concurrence visée avec des prompts réels, par exemple avec GuideLLM, utilisé par Red Hat.

Sécurité : un port d'inférence ne donne jamais sur internet

Local ne veut pas dire sûr ; cela veut dire que la sécurité vous revient.

En 2024, Wiz a révélé Probllama (CVE-2024-37032), une faille d'Ollama pouvant mener à l'exécution de code à distance, en rappelant qu'Ollama est livré sans authentification. En janvier 2026, SentinelLABS et Censys ont recensé 175 108 hôtes Ollama exposés dans 130 pays, dont près de la moitié avec les appels d'outils activés.

Les moteurs aussi ont des failles critiques. En 2026 : la CVE-2026-7482 dans Ollama (avant 0.17.1, CVSS 9,1), où un GGUF piégé envoyé sans authentification à /api/create fait fuiter une mémoire pouvant contenir clés d'API et conversations d'autrui ; la CVE-2026-48746 dans vLLM (corrigée en 0.22.0, CVSS 9,1), un contournement de la clé d'API ; et la CVE-2026-34159 dans llama.cpp (avant b8492, CVSS 9,8), une exécution de code à distance via le backend RPC avec un simple accès TCP.

Les fichiers de modèles exigent le même soin. Pickle, format historique de PyTorch, peut exécuter du code au chargement (JFrog a trouvé une centaine de modèles malveillants sur Hugging Face en 2024) ; safetensors a passé un audit de Trail of Bits sans faille critique d'exécution de code. Le GGUF ne contient pas de code, mais ses lecteurs ont connu des débordements et ses templates peuvent cacher des instructions (voir la sécurité de la chaîne d'approvisionnement IA).

1. Moteurs sur localhost ou un sous-réseau privé, dans des conteneurs sans privilèges ni accès sortant ; la seule porte est la passerelle, avec TLS, SSO ou clés par application.
2. Bloquez en production le téléchargement et la création de modèles (dans Ollama, /api/pull, /api/create, /api/push) ; chargez les modèles depuis un registre interne aux hashes vérifiés.
3. Correctifs chaque mois : la NVD recense des dizaines de vulnérabilités 2026 pour vLLM, llama.cpp et Ollama.
4. Journalisez par défaut les métadonnées (utilisateur, modèle, tokens, latence), les prompts complets seulement si nécessaire, avec une conservation définie.

Une architecture de référence pour 20 à 200 personnes

Six couches dans votre réseau, avec une seule sortie contrôlée vers un fournisseur.

Attention à la licence : Open WebUI ne permet de retirer sa marque que jusqu'à 50 utilisateurs sur 30 jours ; au-delà, on la garde ou on achète une licence entreprise. Les modèles dans les modèles open-weight en 2026, les machines dans le matériel pour l'IA locale et, pour le faire construire, logiciel sur mesure.

Une méthode de dimensionnement en cinq étapes

Dimensionnez selon les requêtes simultanées et le contexte, puis mesurez.

1. Estimez la concurrence. Requêtes en cours ≈ utilisateurs actifs au pic × requêtes par utilisateur et par minute × durée moyenne en minutes. Hypothèses illustratives : 60 personnes actives sur 200 au pic, une requête toutes les deux minutes, 15 secondes chacune, soit 60 × 0,5 × 0,25 ≈ 8.
2. Mesurez le contexte comme le p95 des tokens d'entrée et de sortie sur des prompts réels, pas le maximum du modèle.
3. Additionnez la mémoire : poids (paramètres × bits ÷ 8), cache KV (taille par token × contexte × requêtes) et marge. Qwen3-32B en FP8 occupe environ 33 Go et son cache 256 Kio par token en 16 bits : 8 requêtes de 16 384 tokens ajoutent 32 Gio, ou 16 Gio en FP8. Un GPU de 80 Go suffit largement (voir la quantification sans mythes).
4. Faites des tests de charge avec le moteur et la quantification retenus, à cette concurrence, et comparez le p95 du délai avant le premier token et de la latence entre tokens à vos objectifs.
5. Gardez de la marge et remesurez. Notre règle : prévoir 1,5 fois le pic mesuré et revoir la file d'attente chaque mois avec le trafic réel.

Quand arrêter d'auto-héberger

L'auto-hébergement est un moyen, pas une fin, et les chiffres penchent souvent vers une API.

Les API de modèles ouverts sont bon marché : le 26 septembre 2026, OpenRouter affichait gpt-oss-120b à 0,15 $ par million de tokens en entrée et 0,60 $ en sortie chez les fournisseurs courants. Une analyse de Pan et al. (2025) juge l'hébergement sur site viable surtout au-delà de 50 millions de tokens par mois ou sous des règles strictes de résidence, même si un petit modèle sur une RTX 5090 est amorti en trois mois environ. Et une étude de cas de 2026 montre que le cache de prompts réduisait la facture API de 88,6 %, sous le coût d'un GPU local partagé.

Notre règle : laissez la charge chez un fournisseur si le volume est inférieur à environ 50 millions de tokens par mois sans exigence de résidence, s'il vous faut des capacités de pointe (Epoch AI situe les modèles ouverts environ quatre mois en retard en 2026), si les GPU resteraient inactifs ou si personne ne peut assumer correctifs et astreintes. Si les données ne peuvent pas sortir ou si le volume est élevé et régulier, restez en local. La réponse habituelle : un hybride routé par la passerelle.

Colombie et Europe. En Colombie, envoyer des données personnelles à un fournisseur étranger est un transfert ou une transmission internationale (loi 1581 de 2012, décret 1377 de 2013) ; les États-Unis figurent sur la liste des pays adéquats de la SIC, sous réserve de responsabilité démontrée. Dans l'UE, le RGPD exige un contrat de sous-traitance (article 28) et une base de transfert (chapitre V). Un serveur local évite ces questions pour les données sensibles, pas vos autres obligations. Voir le vrai coût de l'IA.