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.

#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 forcé à CUDA 13 depuis la version 0.5.19 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