DCOCO accélère l'inférence des LLM jusqu'à 6,6x et devance ses concurrents de 6 à 23 %

Des chercheurs ont publié sur arXiv la méthode DCOCO (DFlash Contextual Corrector), qui s'attaque à la principale faiblesse des drafters à diffusion dans le décodage spéculatif. Il s'agit d'un correcteur léger qui conserve la génération parallèle du brouillon et réintroduit dans le bloc les dépendances entre tokens. Sur quatre modèles vérificateurs et dix benchmarks, il affiche le débit moyen le plus élevé dans chaque configuration testée. L'accélération maximale atteint 6,6x par rapport au décodage classique. Avec 4 à 32 requêtes simultanées, la méthode devance le meilleur concurrent de 6 à 23 %.

Où le brouillon parallèle déraille

Le principe du décodage spéculatif est simple. Un petit modèle drafter propose plusieurs tokens à l'avance, puis un modèle cible, plus gros, les vérifie en une seule passe parallèle. Tout ce qui coïncide avec sa propre prédiction est accepté. Plus la séquence acceptée est longue, plus la vitesse augmente.

Les drafters à diffusion ont rendu ce schéma plus séduisant. Ils reposent sur un backbone d'attention profond, qui produit de bonnes prédictions, et remplissent les positions futures en parallèle, sans payer le coût de l'autorégression séquentielle. Mais ce parallélisme a un prix. Le token en troisième position du bloc est prédit sans savoir quel token occupe la deuxième. Les dépendances internes au bloc, qui apparaissent naturellement en autorégression, disparaissent.

En pratique, chaque token est plausible isolément, mais les tokens voisins ne s'enchaînent pas bien. Le vérificateur rejette la fin du bloc et la longueur du brouillon accepté diminue. Le gain du drafting parallèle est en partie annulé.

Ce que fait DCOCO

Les auteurs ne sont pas revenus à la génération séquentielle. Au lieu de retenir un unique favori pour chaque position, DCOCO conserve plusieurs candidats. Il évalue ensuite en parallèle la compatibilité entre les candidats des positions voisines, puis choisit les tokens en tenant compte du contexte. Selon les auteurs, le surcoût reste faible.

La différence clé avec les correcteurs existants tient à leur fonctionnement séquentiel. Eux aussi rétablissent les dépendances, mais ils réinjectent dans le pipeline le coût séquentiel dont le drafter à diffusion avait justement débarrassé le processus. D'après l'article, avec 4 à 32 requêtes simultanées, ces correcteurs passent sous le niveau de DFlash de base, sans aucune correction.

Les chiffres de l'abstract :

• 4 modèles vérificateurs et 10 benchmarks dans les tests ;
• débit moyen le plus élevé dans chaque configuration évaluée ;
• modes : décodage glouton et stochastique, avec et sans raisonnement étendu ;
• accélération jusqu'à 6,6x par rapport au décodage classique ;
• avantage de 6 à 23 % sur le meilleur concurrent avec 4 à 32 requêtes parallèles.

Point important : le résultat tient aussi dans les modes à longues chaînes de raisonnement. C'est là que la génération coûte le plus cher et que l'accélération de l'inférence rapporte le plus.

Ce qu'il faut regarder avant de déployer

Il s'agit d'un preprint, et tous les chiffres proviennent des auteurs eux-mêmes. L'abstract ne contient ni vérification indépendante ni données sur des modèles ou du matériel précis. Les 6,6x sont donc à lire comme un plafond, et non comme le résultat attendu sur votre trafic.

Une équipe qui exploite un service LLM peut retenir deux enseignements de ce travail. Premièrement, il ne faut pas comparer les méthodes d'accélération sur une seule requête. Un correcteur qui gagne avec un batch size de 1 peut perdre avec 8 à 32 requêtes concurrentes, et l'étude le montre explicitement.

Deuxièmement, si vous utilisez déjà DFlash ou un drafter à diffusion similaire, DCOCO se présente comme une surcouche, et non comme un remplacement de tout le schéma. Il vaut la peine de le tester sur vos propres prompts et votre profil de charge : séparément pour les réponses courtes et pour les longs raisonnements, séparément pour l'échantillonnage glouton et stochastique. Il faut surveiller la longueur moyenne du bloc accepté et les tokens par seconde finaux sur GPU, et non une seule métrique.