SGLang : servir des LLM open source

SGLang : servir des LLM open source plus vite que vLLM grâce à RadixAttention

Une fois posée la question du quel modèle servir, vient celle, plus structurante, du moteur d’inférence. Dans l’écosystème open source, vLLM s’est imposé comme le choix par défaut. SGLang, projet né à Berkeley et porté par la communauté LMSYS, propose une alternative crédible : un moteur plus rapide sur les charges agentiques et RAG, avec une syntaxe Python pensée pour la génération structurée, et une licence Apache 2.0.

Ce que SGLang change concrètement

SGLang ne se contente pas de servir un modèle, il propose une couche au-dessus de l’inférence. Trois briques techniques expliquent les gains mesurés.

RadixAttention. SGLang indexe automatiquement les préfixes de prompts déjà vus dans un arbre radix, et réutilise leur KV cache au lieu de le recalculer. Sur un workload typique d’agent (système prompt fixe, conversation qui s’allonge), le gain est immédiat : entre 3 et 6x sur le TTFT selon les charges. La logique est proche de ce que LMCache propose en cache distribué, mais ici intégrée nativement au moteur.

Génération structurée par grammaire compilée. SGLang embarque un moteur de contraintes (FSM compilée) qui pilote le décodage, token par token, pour forcer du JSON, du SQL, une regex, ou une grammaire libre. Là où Outlines ajoute une couche externe, SGLang intègre la contrainte dans la boucle d’inférence : le coût est presque nul, et la sortie est garantie syntaxiquement valide.

Le frontend Python SGL. Le moteur expose un DSL léger qui permet d’écrire des programmes d’inférence avec branchement, parallélisation et fork de générations. Cela ressemble à du LangGraph minimaliste, mais exécuté côté serveur, sans aller-retour réseau entre étapes.

Comparaison rapide avec les autres moteurs

Pour situer SGLang dans le paysage des moteurs d’inférence open source :

vLLM : référence généraliste, PagedAttention, écosystème Hugging Face très complet, support multi-GPU mûr. Avantage sur les workloads de batch et de throughput pur.
SGLang : meilleur sur prompts répétitifs, agents, structured output, multi-tours. Adopté par xAI et plusieurs labs.
TGI (Text Generation Inference, Hugging Face) : très bien intégré à l’écosystème HF, plus simple à déployer, un peu en retrait sur les performances brutes depuis vLLM 0.6.
llama.cpp : non comparable, c’est un moteur pour matériel modeste, sans batching dynamique pensé pour la production multi-utilisateurs.

Cas d’usage où SGLang fait la différence

SGLang devient particulièrement intéressant quand le workload présente l’un de ces traits :

un système prompt long et stable (instructions d’agent, persona, contexte produit),
des conversations multi-tours qui réutilisent l’historique,
du RAG où les mêmes chunks reviennent souvent dans les requêtes,
une sortie qui doit être JSON, XML ou suivre une grammaire métier,
de la génération en parallèle (chain-of-thought avec plusieurs branches, vote majoritaire).

Sur des charges de chat à faible diversité de prompts, vLLM reste compétitif. Plus le workload est agentique ou RAG, plus SGLang creuse l’écart.

Mise en route, version courte

Le déploiement est volontairement proche de vLLM, ce qui facilite la migration. Un serveur compatible OpenAI se lance en une commande :

pip install "sglang[all]"

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --port 30000 \
  --enable-cache-radix-attention

Le serveur expose une API /v1/chat/completions compatible OpenAI, branchable directement depuis LiteLLM, LangGraph, Pydantic AI, Smolagents ou n’importe quel client OpenAI standard. Aucun changement côté application.

Pour exploiter pleinement la génération structurée, on passe par le SDK Python :

import sglang as sgl

@sgl.function
def extract_invoice(s, document):
    s += "Document : " + document + "\n"
    s += "Numéro : " + sgl.gen("num", regex=r"FA-\d{6}")
    s += "Montant TTC : " + sgl.gen("ttc", regex=r"\d+\.\d{2}")

state = extract_invoice.run(document=texte_facture, backend=sgl.RuntimeEndpoint("http://localhost:30000"))

Le gain par rapport à un prompt libre suivi d’un parsing : la sortie est garantie, sans étape de validation post-hoc, et la latence est plus basse car le modèle a moins de tokens à explorer.

Intégration dans une stack open source

Dans un dispositif type, SGLang remplace ou complète vLLM sans rien changer en amont. Plusieurs combinaisons sont éprouvées :

SGLang + LiteLLM : LiteLLM route certaines requêtes vers SGLang pour la génération structurée, et garde vLLM pour le batch.
SGLang + Langfuse : observabilité standard via OpenTelemetry, traces, coûts, latences par préfixe.
SGLang + Open WebUI : interface chat standard pointant vers le serveur SGLang, expérience utilisateur identique à un déploiement vLLM.
SGLang + LMCache : si la mémoire GPU est saturée, LMCache offload le KV cache sur RAM ou disque, là où RadixAttention l’organise dans la VRAM.

Limites à connaître

SGLang reste un projet plus jeune que vLLM. Quelques points de vigilance :

Le support multi-noeuds est moins mûr que sur vLLM, surtout pour les très gros modèles (200B+).
La documentation est correcte mais moins fournie que celle de vLLM ou TGI.
Tous les modèles ne sont pas optimisés au même niveau : Llama, Qwen, DeepSeek et Mixtral sont premium, d’autres restent fonctionnels mais moins ajustés.
La génération structurée par FSM ajoute une compilation initiale ; sur des grammaires très complexes, le coût de mise en cache n’est rentable qu’à partir d’un certain volume.

En résumé

SGLang ne remplace pas vLLM pour tout le monde, mais devient un choix par défaut sérieux dès que la charge devient agentique, structurée ou multi-tours. Pour une stack open source qui s’oriente vers les agents IA, il mérite sa place en parallèle, voire à la place, du moteur d’inférence standard. Et comme tout est sous Apache 2.0, l’expérimentation se fait sans engagement.

Liens utiles : github.com/sgl-project/sglang, documentation et benchmarks sur le site officiel du projet.