L'équipe SGLang et l'équipe Ling Infra d'Ant Group ont publié le 21 août un rapport d'optimisation conjoint : en faisant tourner Ling-3.0-flash sur quatre GPU Blackwell, ils ont réduit le temps par token de sortie (TPOT) à concurrence 1 de 3,33 millisecondes à 1,53 milliseconde, soit une baisse de 54 %, tandis que le débit passait de 288 à 606 tokens par seconde. Avec leur propre modèle brouillon DSpark, le TPOT moyen est encore descendu à 0,78 milliseconde, le débit a atteint 1120 tokens par seconde, et en moyenne 9,95 tokens brouillons ont été acceptés par tour.
Ling-3.0-flash est un modèle MoE à attention linéaire hybride : sur 42 couches, 35 utilisent l'attention linéaire KDA et 7 l'attention complète MLA, avec 512 experts de routage, une largeur de couche cachée de 2560 et un vocabulaire d'environ 157 000 tokens. En bf16, chaque carte doit charger environ 63 Go de poids. Pour le test, le modèle a été découpé en 4 parties par parallélisme de tenseurs, également en bf16.
C'est en fait le GPU qui est inactif
Cette optimisation cible le scénario où la taille de lot est égale à 1. La plupart des résultats publics d'optimisation d'inférence visent à maximiser le débit total à forte concurrence, car c'est ainsi que les fournisseurs cloud facturent. Un autre type de charge se ressent plus directement : la concurrence égale à 1 — exécution locale d'un modèle, complétion de code, un agent qui exécute en série une longue chaîne — une seule requête tourne à la fois et l'utilisateur fixe l'écran en attendant que les mots apparaissent.
Quand la concurrence baisse, le GPU devient inactif. La charge de calcul de chaque étape de décodage est si faible qu'elle en devient négligeable ; le GPU termine son travail et attend le prochain lot d'instructions, envoyé par le CPU. Dès qu'un point du côté hôte doit relire une valeur en mémoire GPU pour décider de l'étape suivante, tout le pipeline doit s'arrêter et attendre cette synchronisation.
"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."
À concurrence 1, il faut d'abord chercher les lectures bloquantes de valeurs mémoire GPU sur le chemin hôte, car chacune transforme ce travail hôte habituellement invisible en une bulle GPU.
Éliminer les attentes une par une
La première catégorie est l'inactivité côté hôte. La méthode consiste à supprimer les points de synchronisation GPU à chaque étape : dans le backend d'attention KDA, on déclare qu'il n'est pas nécessaire de relire la longueur de séquence vers le CPU, de sorte que les index correspondants restent en permanence en mémoire GPU. Ainsi, les instructions de l'étape k+1 peuvent être envoyées avant même de savoir combien de tokens brouillons ont été acceptés à l'étape k, et l'hôte n'a plus besoin d'attendre le résultat.
La deuxième catégorie raccourcit le travail sur le chemin critique du GPU. Le lancement dépendant programmatique (PDL) permet d'envoyer par anticipation le chargement des poids qui ne dépend pas de la sortie du noyau précédent ; le routage et le MoE sont fusionnés de deux lancements de noyau en un seul — à l'échelle de 512 experts, le seul coût de lancement est déjà considérable ; la précision de calcul de la porte de routage et du lm_head est passée de fp32 à bf16, ce qui a apporté à lui seul environ 10 % d'amélioration. L'état cyclique de KDA sous décodage spéculatif est désormais mis à jour par étapes et n'est validé qu'après vérification réussie.
Tous ces changements ont été intégrés à SGLang : la capture des métadonnées avec le graphe, un noyau de vérification KDA fusionné, un plan FlashInfer émis directement par l'hôte (évitant les relectures bloquantes de la mémoire GPU), ainsi qu'un ordre d'ordonnancement fusionnant les étapes de brouillon, de vérification et d'extension.
Converti en temps perceptible par un humain
Calcul approximatif pour une réponse longue de 5000 tokens : à 3,33 millisecondes par token, il faut 16,6 secondes pour tout écrire ; à 1,53 milliseconde, 7,7 secondes ; à 0,78 milliseconde, 3,9 secondes. Même machine, même modèle, même personne qui attend : la différence passe de « le temps de se faire un thé » à « c'est fini avant même d'avoir fini sa phrase ». Cette différence ne vient pas d'un changement de GPU, mais de l'élimination complète de l'attente côté hôte.
Le chiffre clé pour DSpark est la longueur d'acceptation moyenne de 9,95. La logique du décodage spéculatif consiste à laisser le petit modèle deviner d'abord une séquence, que le grand modèle vérifie en une seule fois : plus il devine juste, plus d'étapes sont gagnées gratuitement. Une longueur d'acceptation proche de 10 signifie que chaque vérification du grand modèle équivaut à près de dix étapes de décodage classique. Ce chiffre est directement lié à la méthode d'entraînement du modèle brouillon : le modèle brouillon de DSpark a été distillé à partir de la distribution de sortie de Ling-3.0-flash après son post-entraînement, et sa fonction de perte inclut un terme d'optimisation spécifique à la longueur d'acceptation. Deviner juste est donc le fruit de l'entraînement, pas de la chance.
Une collaboration en amont
Derrière ce rapport figurent trois signataires : RadixArk côté SGLang, l'équipe Ling Infra d'Ant, et inclusionAI d'Ant. Les poids du modèle et les commandes de reproduction ont été publiés ensemble, y compris la variante DSpark.
Voir des modèles open source chinois figurer dans les classements n'a plus rien d'étonnant ces dernières années ; ce qui l'est davantage, c'est leur poids au niveau de la pile d'inférence. Cette optimisation ne s'est pas contentée d'attendre que le framework en amont s'adapte : elle est partie de sa propre facture matérielle et de sa charge réelle pour modifier le code en amont, avant de le réintégrer. Pour ceux qui déploient avec le même framework en aval, ces options sont directement disponibles, peu importe à qui appartient le modèle.
Sources : blog technique officiel de SGLang, CocoLoop, fiche de modèle publique d'Ant inclusionAI ; le TPOT, le débit et la longueur d'acceptation ont été vérifiés à partir des commandes de reproduction et des résultats de référence publiés dans le blog, tous mesurés à concurrence 1, parallélisme de tenseurs sur 4 cartes et bf16.