SGLang
Pourquoi c’est important
En profondeur
Pour comprendre SGLang, il aide de comprendre le problème auquel fait face chaque moteur d'inférence. Le décodage autorégressif génère un token à la fois, et chaque token doit lire l'ensemble des poids du modèle plus le cache clé-valeur de tout ce qui a été généré jusque-là, ce qui rend le décodage limité par la bande passante mémoire plutôt que par le calcul. Le levier qui compte n'est donc pas les FLOPS bruts mais le nombre de requêtes que vous pouvez regrouper par lot et la quantité de travail redondant que vous évitez. SGLang attaque les deux côtés : il regroupe et ordonnance les requêtes efficacement comme tout moteur moderne, et il va plus loin en reconnaissant que le vrai trafic de production regorge de structure partagée — le même prompt système, les mêmes exemples, le même historique de conversation — que les moteurs naïfs recalculent à partir de zéro à chaque requête.
RadixAttention et la réutilisation de préfixe
RadixAttention est la contribution déterminante de SGLang. Le moteur garde le cache clé-valeur dans un arbre radix indexé par séquences de tokens, si bien que lorsqu'une nouvelle requête arrive avec un prompt partageant un préfixe avec quelque chose de récemment calculé — un prompt système, un document, un tour antérieur de la conversation — le moteur réutilise les entrées de cache existantes au lieu de les recalculer. SGLang jumelle ça à un ordonnancement conscient du cache qui préfère faire tourner sur la même réplique les requêtes aux préfixes qui se chevauchent, ce qui fait monter les taux de succès du cache. Sur des charges à longs prompts partagés ou à fort trafic multitours, ça peut réduire la latence et hausser le débit substantiellement par rapport à un service sans état. L'idée s'apparente à ce que les fournisseurs d'API vendent comme mise en cache de prompts, mais ici ça se passe automatiquement dans le moteur, et d'autres moteurs dont vLLM ont depuis adopté leurs propres mécanismes de réutilisation de préfixe.
La sortie structurée à pleine vitesse
L'autre fonction vedette de SGLang, c'est la sortie structurée rapide. Le décodage contraint force le modèle à suivre une grammaire ou un schéma JSON en masquant les tokens illégaux à chaque étape, et les implémentations naïves ajoutent une surcharge notable par token. SGLang optimise ça avec un automate fini compressé pour la grammaire et une technique qui saute par-dessus les passages déterministes de la sortie — clés fixes, crochets, espaces — en émettant plusieurs tokens d'un coup plutôt qu'un à la fois. Ça compte plus qu'il n'y paraît : les chaînes d'agents, l'appel de fonctions et les travaux d'extraction de données génèrent d'énormes volumes de JSON, et une accélération de 2 à 5 fois sur ce décodage se traduit directement en agents moins chers et plus vifs.
SGLang contre vLLM
La comparaison évidente, c'est vLLM, l'autre moteur de service de modèles à code source ouvert dominant. Les deux sont en Python, les deux font du traitement par lots continu, du parallélisme de tenseurs entre GPU, de la quantification et du décodage spéculatif, et les deux exposent une API compatible avec OpenAI. vLLM est le projet le plus ancien avec le plus grand écosystème et il est bâti autour de PagedAttention, son approche par blocs de la gestion mémoire du cache clé-valeur; SGLang prend souvent les devants sur le trafic lourd en préfixes et sur la sortie structurée grâce à RadixAttention et à sa pile de décodage contraint. Les bancs d'essai entre les deux basculent à chaque publication, à chaque famille de modèles et à chaque génération de matériel, donc la réponse du praticien est ennuyeuse mais vraie : retenez les deux et mesurez sur votre propre charge. Bien des plateformes d'inférence prennent discrètement en charge les deux dorsales pour exactement cette raison.
Plus rapide ne veut pas dire plus intelligent
Une idée fausse répandue veut que changer de moteur de service change ce que le modèle peut faire. Ce n'est pas le cas. SGLang est une couche de service, pas un modèle ni un cadriciel d'entraînement — les mêmes poids servis par SGLang, vLLM ou n'importe quel autre moteur produisent essentiellement les mêmes réponses. Quand des gens rapportent qu'un modèle est devenu « meilleur » ou « pire » après un changement de moteur, le vrai coupable est habituellement des réglages de quantification différents, une fenêtre de contexte tronquée, ou des valeurs d'échantillonnage modifiées comme la température. Ce qu'un bon moteur vous achète, c'est de l'efficacité : plus de requêtes par GPU, un temps jusqu'au premier token plus court, plus de tokens par seconde. C'est une histoire de coût et de latence produit, pas de capacité, et c'est pourquoi le choix du moteur est une décision d'infrastructure plutôt qu'une décision de qualité de modèle.
L'effet DeepSeek
Le profil de SGLang s'est élevé fortement avec l'arrivée de très grands modèles à mélange d'experts, surtout les V3 et R1 de DeepSeek, qui sont pénibles à servir : des centaines de milliards de paramètres au total, du parallélisme d'experts sur de nombreux GPU, et une conception d'attention qui brise des hypothèses inscrites dans les piles de service plus anciennes. SGLang a investi tôt et fortement pour bien prendre en charge ces modèles, et il est devenu un moteur de prédilection pour les déploiements de l'échelle de DeepSeek autant dans la communauté ouverte que chez les fournisseurs d'inférence. Cette réputation est restée : quand un gros nouveau modèle en poids ouverts sort, la prise en charge dès le premier jour dans SGLang est maintenant quelque chose que les praticiens cherchent activement, de la même façon qu'ils guettent la prise en charge par vLLM. Les origines du projet dans l'écosystème LMSYS — la même communauté derrière Chatbot Arena — lui ont aussi donné une crédibilité auprès du milieu de la recherche dès le premier jour.