SpecForge : entraîner des modèles de décodage spéculatif pour SGLang

Le problème : des drafters qui ne se branchent pas sur le serveur

Le décodage spéculatif fait générer des tokens par un petit modèle, le drafter, puis les fait vérifier par le grand modèle. Le gain vient de là. Mais entraîner ce drafter est une chose, le faire tourner dans le moteur d'inférence en est une autre. Le README de SpecForge est explicite sur ce point : beaucoup de projets open source de décodage spéculatif sont, selon ses termes, mal maintenus ou non compatibles directement avec SGLang. Le projet se présente donc comme un framework d'entraînement dont la sortie est déjà au format attendu par SGLang, sans effort de portage supplémentaire.

La cible est étroite et assumée : une équipe qui sert déjà des modèles avec SGLang et qui veut ajouter un drafter entraîné sur ses propres données ou sur son propre modèle cible. Pour quelqu'un qui sert avec un autre moteur, l'argument de compatibilité directe tombe, et il ne reste qu'un framework d'entraînement parmi d'autres. Le dépôt est publié sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un produit fermé, à condition de conserver la notice de copyright et le texte de licence. Ce n'est pas un avis juridique : faites relire l'usage prévu si la redistribution est commerciale.

Un seul point d'entrée, des recettes par méthode et par topologie

Le README insiste sur un choix d'architecture inhabituel : il n'existe pas de point d'entrée Python propre à chaque méthode. Toutes passent par la même commande typée, specforge train, suivie d'un chemin de configuration. La méthode, la topologie et le mode de service se lisent dans l'arborescence du fichier YAML. Un exemple donné par le README :

specforge train --config examples/configs/online/disaggregated/external/qwen3-8b-eagle3-disaggregated.yaml

Le chemin se décompose en trois informations. online ou offline désigne le mode d'entraînement. colocated ou disaggregated désigne la topologie. external ou managed-local désigne qui possède les services annexes. Dans une recette external, SpecForge supervise le producteur et le consommateur sur un seul nœud d'entraînement, tandis que l'utilisateur ou l'ordonnanceur garde la main sur Mooncake et SGLang. Dans une recette managed-local, ces services sont aussi démarrés sur l'hôte local. Cette séparation est le vrai contenu du projet : elle évite de dupliquer la logique de lancement pour chaque méthode.

Le revers est un couplage fort au nommage des chemins. Renommer un répertoire d'exemples, ou déplacer une recette, casse la lisibilité de la configuration sans qu'aucun vérificateur ne vous prévienne, puisque c'est le chemin lui-même qui porte le sens.

Ce que couvrent réellement les méthodes

Le tableau du README liste six familles. EAGLE3 fait du drafting autorégressif à base de features, avec trois recettes disponibles : online external, offline colocated et offline disaggregated. P-EAGLE est la variante parallèle, avec une seule recette online external. EAGLE3.1 ajoute une dérive d'attention, également en online external. DFlash fait du drafting block-parallel, avec une recette online external, une offline colocated et une online managed-local. DFlash2 ajoute une convolution dynamique groupée et une sélection de chemin top-k, mais une seule recette managed-local est montrée. Domino applique une correction de logits par GRU, avec trois recettes. DSpark, enfin, fait de la génération semi-autorégressive à ordonnancement par confiance, avec une recette online external et une offline colocated.

Deux méthodes portent une optimisation nommée : EAGLE3 avec la perte LK, DFlash et DFlash2 avec D-PACE. Les autres colonnes sont vides dans le tableau, ce qui ne veut pas dire qu'il n'y a rien, mais que le README ne l'annonce pas. C'est une limite de la documentation, pas une affirmation sur le code.

La distribution des recettes est révélatrice. EAGLE3 et Domino sont les mieux couvertes. DFlash2, présentée comme une évolution de DFlash, n'a qu'un exemple managed-local. Si vous visez DFlash2 en topologie external, rien dans le matériel fourni ne permet de dire que c'est pris en charge.

Le runtime : parallélisme de données, de tenseurs et de séquences

Le README décrit un runtime unique pour l'entraînement en ligne désagrégé et pour l'entraînement hors ligne, colocalisé ou désagrégé, avec prise en charge des topologies de parallélisme de données, de tenseurs et de séquences. Le topic fsdp du dépôt indique que le parallélisme de données repose sur FSDP de PyTorch, ce qui est cohérent avec un framework Python construit sur PyTorch.

La répartition des responsabilités est précisée. Le parallélisme de la cible en ligne appartient à SGLang. C'est la clé deployment.trainer qui possède le DP de l'entraîneur et les groupes de processus USP d'EAGLE3 hors ligne. Autrement dit, le réglage du service et le réglage de l'entraîneur sont deux espaces distincts, et vous ne pouvez pas corriger un déséquilibre de l'un en touchant l'autre.

Le point le plus intéressant est la validation. Les combinaisons non prises en charge sont rejetées pendant la validation de configuration ou pendant l'assemblage du run, plutôt que de retomber silencieusement sur un entraîneur plus ancien. C'est un choix défendable : un échec immédiat coûte moins cher qu'un entraînement de plusieurs heures avec la mauvaise topologie. En contrepartie, la courbe d'apprentissage passe par la lecture de la matrice méthode/topologie dans docs/sections/basic_usage/training.md avant d'écrire quoi que ce soit.

Démarrer : commande et clés de configuration

L'installation n'est pas décrite dans le matériel fourni, et je ne l'inventerai pas. Ce qui est documenté, c'est le lancement. La commande unique est specforge train, avec un chemin sous examples/configs. Le README renvoie à docs/sections/basic_usage/training.md pour la matrice méthode/topologie et à docs/sections/basic_usage/disaggregated_training.md pour les flux de lancement en ligne et hors ligne. La documentation complète est sur docs.sglang.io/SpecForge.

Deux clés apparaissent nommément. deployment.trainer contrôle le DP de l'entraîneur et les groupes de processus USP d'EAGLE3 hors ligne. Le choix external ou managed-local dans le chemin décide qui démarre Mooncake et SGLang : vous, ou SpecForge sur l'hôte local. C'est le premier arbitrage à faire, car il détermine si votre nœud d'entraînement doit aussi héberger le service cible.

Le dépôt ne fournit aucune release récente d'après les informations disponibles, ce qui signifie concrètement que vous installerez depuis la branche main. Ce n'est pas anodin pour un projet qui valide ses configurations à l'exécution : une mise à jour de main peut modifier une clé ou un chemin de recette sans qu'un numéro de version ne vous alerte. Épinglez un commit si vous industrialisez.

SpecBundle, et ce qu'il ne faut pas en attendre

SpecForge s'accompagne de SpecBundle, une collection de modèles de décodage spéculatif publiés par l'équipe et ses partenaires industriels. Le README annonce un taux d'acceptation supérieur à celui des checkpoints open source existants sur un large éventail de domaines, et jusqu'à 4x d'accélération en inférence avec SGLang. Ce sont des chiffres avancés par le projet, pas des mesures indépendantes, et le matériel fourni ne contient pas de protocole permettant de les reproduire. Le dashboard de performance est lié depuis la documentation.

L'intérêt pratique de SpecBundle est ailleurs : il donne un point de comparaison. Si votre drafter entraîné fait moins bien qu'un checkpoint SpecBundle sur votre domaine, la question devient celle de vos données, pas celle du framework. C'est un usage légitime du catalogue, à condition de traiter les chiffres annoncés comme une revendication et non comme une référence.

Le lien SpecBundle est aussi la seule indication de gouvernance du projet : une équipe identifiée, un blog LMSYS, un canal Slack, une documentation hébergée. Aucun de ces éléments ne dit quoi que ce soit sur la fréquence des correctifs.

Quand SpecForge est le mauvais outil

Trois cas de figure ressortent du matériel fourni. Le premier est le choix du moteur de service : si vous ne servez pas avec SGLang, l'argument central du projet disparaît, et vous payez la complexité d'un runtime désagrégé sans contrepartie. Le deuxième est le matériel. Toutes les recettes montrées supposent une topologie distribuée, avec un nœud d'entraîneur, un service cible, et dans le cas managed-local des services Mooncake et SGLang sur le même hôte. Rien n'indique qu'un entraînement sur une seule carte soit pris en charge, et je ne peux pas l'affirmer dans un sens ou dans l'autre.

Le troisième cas est plus subtil : la méthode que vous voulez. Le tableau est inégal. DFlash2 n'apparaît qu'en managed-local, DSpark n'a pas de recette désagrégée hors ligne, P-EAGLE et EAGLE3.1 seulement en external. Si votre contrainte d'infrastructure impose une topologie absente de la liste, SpecForge vous rejettera à la validation. Ce n'est pas un bug, c'est la conception, mais cela peut vous coûter une journée de configuration avant de le découvrir.

Enfin, la documentation est mince sur les cas d'échec. Le README ne décrit pas ce qui se passe quand un service externe tombe pendant un run external, ni comment reprendre un entraînement interrompu. Ce sont des questions à poser sur le canal Slack avant d'engager des ressources.

Face à un entraîneur spéculatif générique

L'alternative évidente est un framework d'entraînement spéculatif non adossé à un moteur d'inférence particulier. La différence n'est pas dans la qualité de l'entraînement, elle est dans ce qui se passe après. Un tel framework vous laisse produire un drafter, puis vous écrivez la couche qui le charge dans votre moteur, en gérant le format des poids, la tokenisation et le schéma d'acceptation. SpecForge supprime cette couche pour SGLang uniquement, et rien d'autre.

Le second point de comparaison est l'écosystème EAGLE d'origine, dont EAGLE3 et EAGLE3.1 sont issus. SpecForge ne réimplémente pas la méthode : il l'enveloppe dans un runtime qui gère les topologies et le service. Vous gagnez l'orchestration, vous perdez la liberté de modifier l'entraînement sans passer par la validation de configuration du projet.

C'est le vrai arbitrage. SpecForge est un framework opinionated : un point d'entrée, des recettes nommées, un rejet strict des combinaisons non prévues. Si votre organisation a besoin de faire varier la topologie au-delà de ce que la matrice autorise, cette rigidité devient un obstacle, et un entraîneur plus bas niveau sera plus confortable, au prix du portage.

Conclusion éditoriale

SpecForge convient aux équipes déjà sur SGLang, qui ont un cluster multi-GPU pour l'entraînement et qui veulent un seul point d'entrée typé pour EAGLE3, P-EAGLE, DFlash, DFlash2, Domino ou DSpark. Ceux qui cherchent un entraînement mono-GPU, ou qui ne servent pas via SGLang, n'y trouveront pas leur outil : aucune recette de ce type n'apparaît dans le dépôt. Avant de vous engager, vérifiez dans docs/sections/basic_usage/training.md que le couple méthode/topologie visé figure dans la matrice, puis contrôlez que les clés deployment.trainer de votre YAML correspondent bien au découpage DP et aux groupes de processus USP hors ligne, puisque la validation de configuration rejette les combinaisons non prises en charge au lieu de retomber sur un ancien entraîneur.

Sources officielles

1. Issues
2. License: MIT
3. Project website
4. README
5. sgl-project/SpecForge on GitHub