Le 21 août 2026, l’équipe SGLang de RadixArk et l’équipe Ant Ling Infra ont annoncé les résultats d’optimisation du décodage à demande unique pour Ling-3.0-flash sur le blog officiel de LMSYS. Dans un environnement fixe avec 4 GPU NVIDIA Blackwell, TP4, bf16 et la concurrence réglée à 1, le chemin NEXTN optimisé augmentait le débit moyen de sortie de 288 tok/s à 606 tok/s, et réduisait le temps moyen de sortie des jetons de sortie de 3,33 millisecondes à 1,53 milliseconde.
Pourquoi le Batch 1 est-il difficile à optimiser ?
Ce résultat s’applique à un scénario de faible concurrence où une seule requête est décodée en continu. Sans requêtes à grande échelle pour partager la surcharge de démarrage et de planification, la synchronisation entre CPU et GPU ainsi que de petits délais de démarrage du noyau reflètent directement les temps d’attente des utilisateurs, rendant plus difficile la masquation de la surcharge système que le traitement par lots à haut débit.
La performance ne se limite pas à doubler avec un seul cœur
L’équipe a d’abord supprimé la synchronisation de la longueur de la séquence CPU qui figeait l’hôte à chaque étape, permettant ainsi à la préparation de l’hôte de se chevaucher avec l’exécution du GPU ; Ensuite, l’initiation de dépendance programmatique est utilisée pour connecter les chemins MoE, le routage, le KDA et la réduction totale afin de réduire les espaces entre les petits cœurs. Les autres optimisations incluent également la fusion des opérateurs, la recalibration KDA, ainsi que l’ajustement des calculs de la porte de routage et de la tête de sortie de fp32 à bf16.
Ces changements ont collectivement raccourci les chemins critiques. Selon l’explication officielle, la porte du routeur BF16 et la tête de sortie sont les plus grands changements individuels après l’ajustement structurel, entraînant une amélioration d’environ 10 %. L’équipe ne s’est pas concentrée uniquement sur les pics à court terme mais a évalué la stabilité en utilisant le temps moyen par jeton et la durée d’acceptation.
DSpark a également inclus l’optimisation du « deviner plus de jetons »
Le même rapport a également testé le décodage spéculatif de la planification de la confiance DSpark. Dans une comparaison contrôlée de la même machine, de la même commande et de 1000 requêtes, DSpark a atteint une moyenne de 1120 tok/s, 0,78 ms TPOT et une durée d’acceptation moyenne de 9,95. Son avantage est non seulement plus rapide en une seule étape, mais aussi la capacité de soumettre plus de jetons de prédiction par validation.
Mais 1120 tok/s ne peut pas être directement considéré comme la vitesse universelle pour toutes les tâches. Les tests utilisent une entrée fixe de jetons 8192, une sortie de jetons 1024, un décodage gourmand et des charges aléatoires synthétiques ; Le contenu des pourboires, la distribution des sorties, la longueur du contexte, les paramètres d’échantillonnage et le matériel influencent tous le taux d’acceptation des jetons spéculatifs. La déclaration officielle considère également clairement 9,95 comme le résultat de cette charge de travail, et non comme une constante inhérente au modèle.
Qu’est-ce que cela signifie pour les équipes de déploiement ?
Cette optimisation n’a pas modifié les paramètres du modèle ni la qualité des réponses ; ce qui a changé, c’est la façon dont le système d’inférence organise le travail hôte, les noyaux GPU et la validation des brouillons. La faible latence de concurrence s’étend souvent à la planification, à la communication, à la précision numérique et aux stratégies spéculatives, rendant difficile l’explication de la vraie vitesse uniquement sur la puissance de calcul de la carte graphique.
Les expériences de reproduction doivent verrouiller le matériel, la version SGLang, la longueur d’entrée/sortie et les paramètres de décodage, puis comparer TPOT, débit et correction. Appliquer directement des chiffres expérimentaux à différents GPU ou au trafic métier conduit facilement à des estimations de capacité trop optimistes.
