SGLang : servir un LLM local à plusieurs utilisateurs

#Ce que fait SGLang

SGLang se présente comme un framework de service haute performance pour LLM et modèles multimodaux, conçu pour une inférence à faible latence et haut débit, d'un seul GPU jusqu'à de larges clusters distribués. Le projet revendique des déploiements de production générant des trillions de tokens chaque jour sur plus de 400 000 GPU dans le monde, et est hébergé par l'organisation open source à but non lucratif LMSYS.

Compatible avec les API OpenAI et Hugging Face, SGLang prend en charge une large gamme de modèles (Llama, Qwen, DeepSeek, GLM, Mistral, Gemma) et de matériels (GPU NVIDIA, AMD, CPU Intel Xeon, TPU Google, NPU Ascend). La dernière version au 28 septembre 2026 est v0.5.20, publiée le 18 septembre 2026.

#Installer et lancer le serveur

L'installation recommandée par la documentation officielle passe par uv, plus rapide que pip classique. Le drapeau --prerelease=allow est nécessaire car certaines dépendances de SGLang ne publient que des pré-versions sur PyPI.

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Le lancement en conteneur Docker reste la voie la plus reproductible pour un déploiement serveur, avec le port 30000 utilisé par défaut pour l'API.

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

La documentation précise que SGLang exige désormais CUDA 13 : les images et roues CUDA 12 (cu129) sont retirées depuis que PyTorch 2.14 ne publie plus de build CUDA 12.9, et la version 0.5.19 reste la dernière à proposer une voie CUDA 12. Un déploiement sur du matériel plus ancien doit donc figer cette version ou vérifier le pilote GPU avant de mettre à jour.

#RadixAttention et le cache de préfixes

Le cœur de la promesse de débit de SGLang est RadixAttention : les préfixes de séquences déjà calculés (un system prompt partagé, le début d'une conversation multi-tours) sont organisés dans un arbre radix et réutilisés entre requêtes, au lieu d'être recalculés à chaque appel. L'annonce d'origine du projet, en janvier 2024, revendiquait jusqu'à 5x d'inférence plus rapide grâce à ce mécanisme — un chiffre d'annonce du projet sur son propre banc de test de l'époque, pas une mesure indépendante récente sur votre matériel.

Ce gain profite surtout aux scénarios à préfixes partagés : plusieurs utilisateurs interrogeant le même system prompt, un agent qui relit le même contexte à chaque tour, ou du few-shot avec les mêmes exemples. Un flux de requêtes sans aucun préfixe commun (questions totalement indépendantes, sans historique) profite beaucoup moins de RadixAttention.

Le runtime combine RadixAttention à un ordonnanceur CPU à zéro surcoût, une disagrégation prefill-decode, le décodage spéculatif, l'ordonnancement continu des requêtes (continuous batching) et la pagination de l'attention (paged attention) — un empilement de techniques d'optimisation plutôt qu'un mécanisme isolé.

#Régler la concurrence et la mémoire

Trois paramètres de lancement gouvernent la façon dont SGLang absorbe plusieurs utilisateurs en parallèle. --mem-fraction-static fixe la part de mémoire GPU réservée aux poids du modèle et au cache KV ; la documentation recommande de la réduire en cas d'erreur de mémoire saturée, faute de quoi elle est calculée automatiquement à partir de la mémoire GPU disponible.

Sans limite explicite sur --max-running-requests, SGLang accepte autant de requêtes que la mémoire du cache KV le permet, ce qui peut dégrader la latence par requête sous forte charge plutôt que de refuser poliment les nouvelles connexions. Fixer une limite explicite, cohérente avec la VRAM disponible, est le premier réglage à faire avant d'ouvrir le serveur à plusieurs utilisateurs réels.

#Quand choisir SGLang plutôt que vLLM ou Ollama

Les trois outils répondent à des besoins différents. Ollama vise l'usage personnel mono-utilisateur avec une prise en main minimale ; SGLang et vLLM ciblent le service à plusieurs utilisateurs sur GPU serveur, avec des philosophies proches (cache de préfixes, batching continu) mais des historiques et des écosystèmes distincts.

Un seul utilisateur, poste personnel

Ollama ou llama.cpp restent plus simples à installer et à faire tourner sur CPU ou GPU grand public, sans configuration de service réseau.

Plusieurs utilisateurs, système déjà construit autour de vLLM

Rester sur vLLM évite une migration ; notre guide dédié couvre son déploiement en production.

Plusieurs utilisateurs, priorité au débit sous préfixes partagés

SGLang, avec RadixAttention, est le candidat naturel — à condition de disposer d'un GPU CUDA compatible.

Compatibilité client Ollama souhaitée sans installer Ollama

SGLang expose une API compatible avec la CLI et la librairie Python Ollama, ce qui permet de réutiliser des scripts existants sans faire tourner le serveur Ollama lui-même.

Pour un panorama plus large des architectures d'inférence (llama.cpp, vLLM, Exllama), le comparatif de backends du site détaille les compromis hors du seul cas SGLang.

#Ce que le matériel impose

Le guide de démarrage rapide de SGLang est explicite : un GPU NVIDIA avec support CUDA sm80 ou supérieur (A10, A100, L4, L40S, H100) est un prérequis pour la voie d'installation standard sous Linux, la plateforme recommandée. Le projet annonce par ailleurs une prise en charge matérielle plus large — GPU AMD (MI355, MI300), CPU Intel Xeon, TPU Google, NPU Ascend — via des voies d'installation dédiées et distinctes du chemin GPU NVIDIA principal.

#Ce que coûte la mémoire par requête

« Servir plusieurs utilisateurs » se traduit très concrètement par une consommation de VRAM qui grossit avec le nombre de requêtes actives, pas seulement avec la taille du modèle. Le cache KV que --mem-fraction-static et --max-total-tokens gèrent stocke, pour chaque token déjà généré d'une requête, deux vecteurs (clé et valeur) par couche d'attention. La formule générale est : octets par token = 2 × nombre de couches × têtes d'attention KV × dimension d'une tête × octets par valeur (2 en FP16/BF16, 1 en FP8).

Calcul illustratif pour une architecture proche de Llama-3.1-8B-Instruct (32 couches, 8 têtes KV en attention groupée, dimension de tête 128) : en FP16, cela donne 2 × 32 × 8 × 128 × 2 = 131 072 octets par token, soit environ 128 Ko par token. Pour une requête avec 8 192 tokens de contexte (prompt et réponse cumulés), le cache KV de cette seule requête pèse alors environ 1 Go de VRAM — avant même de compter les poids du modèle. Sur un GPU de 24 Go avec environ 16 Go réservés aux poids en Q4 et au socle du runtime, la marge restante ne laisse la place qu'à quelques requêtes actives simultanées à ce niveau de contexte, ce qui explique pourquoi une limite explicite sur --max-running-requests évite une dégradation plutôt qu'un refus propre des nouvelles connexions.

#Sécurité et observabilité

Par défaut, l'API SGLang lancée avec sglang.launch_server n'exige aucune authentification : quiconque atteint le port 30000 peut envoyer des requêtes. L'option --api-key définit une clé exigée par le serveur, y compris sur son endpoint compatible OpenAI ; sans elle, exposer le serveur au-delà de localhost ou d'un réseau interne de confiance revient à laisser un accès ouvert à l'inférence, et donc à la facture GPU associée.

Pour le suivi en production, l'option --enable-metrics (désactivée par défaut) publie des métriques au format Prometheus sur un endpoint /metrics : débit de requêtes, latence d'inférence, vitesse de génération de tokens et efficacité du cache y sont exposés pour un scraping régulier, plutôt que de deviner l'état du serveur à partir des seuls journaux.

• Principes de sécurisation d'un serveur d'inférence exposé
• Source : référence des arguments du serveur (--api-key, --enable-metrics)

#Dépannage : symptômes, cause, correction

#Limites et points de vigilance

Le chiffre « jusqu'à 5x plus rapide » qui accompagne encore la présentation de RadixAttention date de l'annonce initiale du projet en janvier 2024 : il illustre l'apport du mécanisme sur le banc de test de l'époque, pas un gain garanti sur un déploiement récent avec des modèles et des GPU différents. Le dimensionnement réel dépend du taux de partage de préfixes entre requêtes, du modèle choisi et du GPU utilisé — à mesurer sur son propre trafic plutôt qu'à déduire de l'annonce d'origine.

Le passage obligatoire à CUDA 13 (la version 0.5.19 étant la dernière à proposer une voie CUDA 12) mérite une vérification du pilote GPU et de la version CUDA installée avant toute mise à jour vers une version récente, sous peine d'échec d'installation sur un serveur resté en CUDA 12.

Le cadence de publication du projet est également à surveiller pour un déploiement de production : SGLang enchaîne des versions mineures toutes les deux à trois semaines environ (v0.5.20 le 18 septembre 2026, v0.5.19 le 5 septembre, v0.5.18 le 22 août), ce qui impose de figer une version précise dans les images Docker plutôt que de suivre le tag latest sur un service en production, au risque d'un changement de comportement non anticipé lors d'un redéploiement.

• Déployer vLLM en production
• vLLM : c'est quoi, pour qui, et quand l'utiliser ?
• llama.cpp vs vLLM vs Exllama
• Source : documentation officielle SGLang
• Source : README officiel du dépôt SGLang
• Source : référence des arguments du serveur