🤖 AI

XGrammar-2: Efficient Dynamic Structured Generation Engine for Agentic LLMs

XGrammar-2 est un moteur de génération structurée à haute efficacité conçu pour des charges de travail d'agents dynamiques utilisant des LLM, intégrant une commutation de structure déclenchée par des balises et une réutilisation de cache inter-grammaires pour atteindre une compilation plus de 6 fois plus rapide et une surcharge de bout en bout quasi nulle par rapport aux systèmes antérieurs.

Auteurs originaux : Linzhang Li, Yixin Dong, Guanjie Wang, Ziyi Xu, Alexander Jiang, Tianqi Chen

Publié 2026-05-27

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Linzhang Li, Yixin Dong, Guanjie Wang, Ziyi Xu, Alexander Jiang, Tianqi Chen

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un chef (l'IA) essayant de suivre une recette très stricte. Parfois, la recette est simple : « Faites un sandwich. » Mais dans le monde des agents IA, la recette est souvent un ensemble complexe et changeant d'instructions comme : « Écrivez une phrase, puis passez à un bloc de code JSON pour appeler un outil météo, puis revenez à l'écriture d'une phrase, puis passez à un format spécifique pour une requête de base de données. »

Le problème est que les « cuisines » traditionnelles (les moteurs d'IA) sont excellentes pour suivre une recette fixe, mais elles peinent lorsque la recette change à la volée ou lorsque le chef doit basculer instantanément entre des dizaines de formats complexes différents. Elles doivent souvent s'arrêter, réécrire tout le livre de recettes depuis zéro avant de pouvoir commencer à cuisiner, ce qui ralentit tout.

XGrammar-2 est un nouveau moteur de cuisine ultra-efficace conçu spécifiquement pour ces scénarios de cuisine chaotiques et dynamiques. Voici comment il fonctionne, en utilisant des analogies simples :

1. Le « Commutateur Magique » (TagDispatch)

Le Problème : Imaginez une recette qui dit : « Continuez à écrire normalement jusqu'à ce que vous voyiez le mot 'STOP', puis passez en mode mathématique, puis revenez en arrière. » Faire cela avec les anciennes méthodes revient à essayer d'écrire un manuel d'instructions massif et embrouillé où chaque mot possible mène à une page différente. Cela devient désordonné et énorme.

La Solution XGrammar-2 : Ils ont introduit une fonctionnalité appelée TagDispatch. Imaginez cela comme un commutateur magique ou un feu de circulation.

L'IA écrit normalement (feu vert).
Dès qu'elle voit un déclencheur spécifique (comme une balise <function=weather>), le feu passe instantanément au rouge, et le moteur sait exactement vers quelle « sous-recette » (le format JSON pour la météo) basculer.
Une fois cette sous-recette terminée, le feu redevient vert, et l'IA reprend l'écriture normale.
Pourquoi c'est génial : Au lieu d'écrire un manuel géant et confus, le moteur suit simplement les feux de circulation. Cela rend le passage entre le texte libre et le code strict instantané et facile.

2. La « Bibliothèque Partagée » (Cross-Grammar Cache)

Le Problème : Imaginez que vous cuisinez 100 plats différents. 90 d'entre eux utilisent exactement la même étape de « hacher les oignons », mais l'ancien moteur traite chaque plat comme une tâche entièrement nouvelle. Il réapprend à hacher les oignons depuis zéro pour chaque plat. C'est une perte de temps.

La Solution XGrammar-2 : Ils ont construit une Bibliothèque Partagée (Cross-Grammar Cache).

Même si les plats finaux (la grammaire complète) sont différents, les ingrédients et les étapes (les sous-structures) sont souvent les mêmes.
XGrammar-2 examine les étapes. S'il voit : « Oh, j'ai déjà compris comment hacher les oignons pour un plat similaire », il ne recalculera pas. Il prend simplement les oignons déjà hachés dans la bibliothèque.
Pourquoi c'est génial : Cela empêche le moteur de refaire les mêmes calculs encore et encore. Il réutilise le « travail » qu'il a déjà effectué, même si la demande globale est différente.

3. Le Chef « Juste à Temps » (JIT Compilation)

Le Problème : Autrefois, avant de pouvoir cuisiner une seule bouchée, le moteur devait lire tout le livre de recettes pour chaque demande. Si la recette était énorme (comme une demande d'appel d'outils avec 500 outils possibles), le moteur restait assis pendant des secondes à lire le livre avant que la cuisine ne commence.

La Solution XGrammar-2 : Ils utilisent une approche Juste à Temps (JIT).

Au lieu de lire tout le livre en premier, le chef ne lit que la page dont il a besoin maintenant.
Pendant que l'IA réfléchit aux premiers mots (phase de « préremplissage »), le moteur prépare tranquillement les prochaines pages de la recette.
Pourquoi c'est génial : Il masque le temps de préparation. Au moment où l'IA est prête à prononcer le mot suivant, le moteur a déjà préparé l'étape suivante. Cela fait apparaître le « premier mot » presque instantanément, même pour des tâches complexes.

4. La « Carte Compressée » (Repetition State Compression)

Le Problème : Certaines recettes ont des étapes répétitives, comme « Répétez cette action 1 000 fois ». Les anciens moteurs essaieraient de dessiner une carte avec 1 000 points séparés pour chaque étape. Cette carte devient énorme et ralentit tout.

La Solution XGrammar-2 : Ils utilisent la Compression d'État de Répétition.

Au lieu de dessiner 1 000 points, ils dessinent une grande flèche de « boucle » et disent : « Faites le tour ici 1 000 fois ».
Pourquoi c'est génial : Cela maintient la carte petite et simple, peu importe le nombre de fois où l'IA doit répéter une étape. Cela empêche le moteur de s'enliser dans de longues listes ou boucles.

Les Résultats : Qu'ont-ils Découvert ?

L'article a testé ce nouveau moteur contre les meilleures méthodes actuelles :

Vitesse : Il compile la « recette » (la grammaire) 6 fois plus vite que les moteurs précédents.
Efficacité : Il ajoute presque aucun délai au temps de réponse de l'IA. Il est si rapide que l'IA ne remarque même pas sa présence.
Compatibilité : Il fonctionne de manière transparente avec des systèmes d'IA populaires (comme SGLang et vLLM) et gère des tâches complexes comme l'appel d'outils ou le respect de formats de réponse stricts sans effort.

En résumé, XGrammar-2 revient à passer le cerveau d'une IA d'un bibliothécaire lent et rigide qui doit reclasser chaque livre avant de répondre à une question, à un assistant ultra-rapide et flexible qui sait exactement où trouver la réponse, réutilise les connaissances précédentes et change de sujet instantanément sans perdre le fil.

Résumé Technique : XGrammar-2

Énoncé du Problème

Les agents de modèles de langage (LLM) modernes reposent de plus en plus sur une génération structurée dynamique, en particulier pour l'appel d'outils et les protocoles de réponse. Contrairement aux tâches de génération structurée traditionnelles où le schéma de sortie est statique et connu à l'avance, les charges de travail agiles présentent une dynamique structurelle significative :

Dynamisme inter-demande : Chaque demande peut exposer un ensemble différent d'outils et de schémas (souvent avec un contrôle d'accès par outil), conduisant à un espace combinatoire immense de grammaires de sortie possibles. Les moteurs existants qui mettent en cache des grammaires entières au niveau de la demande deviennent inefficaces, imposant un prétraitement coûteux par demande et augmentant le temps jusqu'au premier token (TTFT).
Dynamisme intra-demande : Au sein d'une seule demande, le modèle doit basculer entre du texte libre et des sous-grammaires structurées en fonction de déclencheurs (par exemple, un nom d'outil spécifique ou un tag de canal). Exprimer ces commutations conditionnelles en utilisant la forme normale de Backus-Naur (BNF) ou la BNF étendue (EBNF) standard est fastidieux, inefficace et s'adapte mal au nombre d'outils.

Les méthodes de décodage contraint existantes (par exemple, XGrammar, Outlines, llguidance) peinent à gérer ces dynamiques. Elles nécessitent soit une compilation complète de la grammaire au préalable (prohibitif pour des ensembles d'outils dynamiques), soit manquent de mécanismes efficaces pour gérer l'entrelacement de texte libre et de contraintes structurées au sein d'un seul flux de génération.

Méthodologie

XGrammar-2 est un moteur de génération structurée conçu spécifiquement pour les charges de travail agiles dynamiques. Son architecture repose sur deux principes de conception fondamentaux : le support natif des commutations de structure déclenchées par des tags et la réutilisation fine entre des demandes présentant des structures de sortie différentes.

1. TagDispatch : Sémantique de Dispatch Dynamique

Pour répondre au dynamisme intra-demande, XGrammar-2 introduit TagDispatch, une intrinsèque de grammaire permettant une commutation efficace entre texte libre et sous-grammaires structurées.

Mécanisme : TagDispatch est paramétré par une liste de paires tag–grammaire $(t_i, G_i)$ et un ensemble de chaînes d'arrêt.
Fonctionnement : Le moteur opère dans deux modes :
- Mode Dispatch : Le moteur accepte le texte ordinaire tout en utilisant un automate Aho–Corasick (AC) pour faire correspondre progressivement les tags enregistrés au texte généré.
- Mode Dispatché : Une fois un tag correspondant détecté, le moteur bascule vers la sous-grammaire correspondante $G_i$ . Une fois $G_i$ terminée, le contrôle revient au mode dispatch.
Avantage : Cela évite la nécessité d'encoder une logique conditionnelle complexe dans des règles EBNF massives, réduisant considérablement la taille de la grammaire et la complexité de compilation.

2. Cache Inter-Grammaire

Pour répondre au dynamisme inter-demande, XGrammar-2 implémente un Cache Inter-Grammaire afin de réutiliser les caches de masques de tokens à travers différentes grammaires partageant des sous-structures communes.

Défi : Déterminer si deux Machines à États Finis (FSM) sont équivalentes est difficile lorsqu'elles contiennent des références de règles et des cycles. De plus, les caches de masques de tokens dépendent non seulement de la structure FSM, mais aussi de la manière dont cette FSM est référencée (expansion de contexte).
Solution : Le système utilise un algorithme de hachage hiérarchique :
- Il construit un graphe de référence FSM.
- Pour les parties acycliques, il calcule des hachages structurels de bas en haut, intégrant les hachages des FSM référencées.
- Pour les références cycliques, il utilise des hachages provisoires suivis d'un affinage par hachage de cycle pour garantir des identifiants structurels uniques.
Stratégie de Réutilisation : Lorsqu'un nouvel état de grammaire est rencontré, le système vérifie le pool de cache global. Si une correspondance parfaite (même FSM et même regard avant) est trouvée, le cache est réutilisé. Si seule une correspondance partielle existe (même FSM, regard avant différent), le système re-vérifie les tokens incertains et met à jour le cache.

3. Cache de Masque de Token Adaptatif Basé sur Earley

S'éloignant des Automates à Pile (PDA) utilisés dans les versions précédentes, XGrammar-2 utilise un analyseur Earley pour son cache de masques de tokens adaptatif.

Raison d'être : Les états PDA peuvent croître de manière exponentielle dans les grammaires non déterministes. L'analyseur Earley maintient un ensemble d'états de parsing partiels (frontière) plus efficace pour les grammaires hors contexte complexes.
Implémentation : Le cache est construit uniquement pour les états scannables (où le symbole suivant est un terminal). Les états non scannables sont étendus via des opérations de prédiction et de complétion à l'exécution. Les tokens sont catégorisés comme acceptés, rejetés ou dépendants du contexte, ces derniers nécessitant des vérifications de contexte à l'exécution.

4. Compilation Juste-à-Temps (JIT)

Pour atténuer le coût élevé de compilation des grammaires grandes et dynamiques :

Stratégie : Au lieu de matérialiser le cache complet de masques de tokens au préalable, XGrammar-2 emploie un système JIT configurable.
Exécution : Pendant la phase de préremplissage, le système estime le coût de génération des caches pour des états spécifiques. Il priorise la compilation des $K$ états les plus coûteux en temps durant le préremplissage, en chevauchant la compilation avec le préremplissage. Les états restants sont compilés à la demande pendant la phase de décodage, en chevauchant la génération de masques avec le décodage. Cela vise à masquer la latence de compilation.

5. Compression d'État de Répétition

Pour gérer les structures de répétition courantes dans les schémas JSON (par exemple, MinLength, MaxItems) :

Problème : L'expansion naïve des règles de répétition entraîne une augmentation linéaire des états de grammaire par rapport au nombre de répétitions.
Solution : Le moteur compresse les états de répétition. Pour de grandes plages de répétition, il transforme la structure en une séquence d'une règle de base répétée $t$ fois, suivie d'un état compressé représentant la plage restante. Cela borne le nombre d'états à une constante, indépendamment de la limite de répétition, réduisant considérablement la taille du cache et l'incertitude.

Résultats Clés

Des expériences ont été menées en utilisant des jeux de données tels que BFCL-v3 et JSONSchemaBench, comparant XGrammar-2 à des moteurs de pointe (XGrammar, llguidance, Outlines) sur divers modèles (Qwen, série Llama).

Vitesse de Compilation : XGrammar-2 atteint une compilation plus de 6 fois plus rapide par rapport aux moteurs de génération structurée précédents dans des contextes dynamiques. Par exemple, alors que XGrammar nécessitait >1000 ms pour compiler des grammaires dynamiques, XGrammar-2 a atteint ~10 ms.
Surcharge de Bout en Bout : Le système engendre une surcharge de bout en bout quasi nulle dans les systèmes de service LLM modernes. Dans les scénarios d'appel de fonctions, l'écart de latence entre la génération contrainte (XGrammar-2) et la génération non contrainte était inférieur à 6 %.
Débit : XGrammar-2 a démontré un débit de tokens supérieur à celui de XGrammar à travers différentes tailles de lot et échelles de modèles (par exemple, une amélioration de débit de 2,5× sur Llama-3.2-1B avec une taille de lot de 16).
Évolutivité : La surcharge mémoire du cache inter-grammaire reste faible et évolue avec le nombre total d'outils uniques utilisés plutôt qu'avec le nombre de demandes, empêchant l'explosion mémoire dans les environnements dynamiques.
Ablation : La suppression du JIT a augmenté le temps de prétraitement de 8,1× ; la suppression du Cache Inter-Grammaire a considérablement augmenté le temps de génération de masques ; la Compression d'État de Répétition a réduit le temps de prétraitement de 99,6× pour les cas de répétition à longue traîne.

Importance et Revendications

L'article revendique que XGrammar-2 fournit une évolution nécessaire pour les systèmes de service LLM afin de supporter les applications agiles. En découplant la gestion des ensembles d'outils dynamiques de la compilation statique de grammaires, il permet :

Fiabilité : Application stricte de la validité structurelle (par exemple, Format de Réponse OpenAI Harmony, schémas d'appel d'outils) sans recourir à une correction a posteriori.
Efficacité : La capacité de servir des charges de travail dynamiques avec des coûts de compilation et d'exécution comparables à ceux des charges de travail statiques.
Adoption : Le moteur a été intégré dans des frameworks open-source comme SGLang et vLLM, démontrant sa viabilité pratique dans des systèmes d'inférence de niveau production.

Les auteurs positionnent XGrammar-2 non pas comme un remplacement des techniques d'entraînement de modèles, mais comme un moteur d'inférence complémentaire qui peut être combiné avec des stratégies existantes de fine-tuning ou de prompting pour garantir une sortie structurée robuste dans des scénarios d'agents complexes.