ReaDy accélère de 3,16 fois le décodage des LLM hybrides sur une seule B200

Des chercheurs ont présenté ReaDy, une méthode de décodage spéculatif pour les modèles à attention linéaire hybride. Sur sept benchmarks de mathématiques, de génération de code et de dialogue, elle accélère en moyenne la génération de 3,16 fois par rapport au décodage autorégressif classique. Le test a été réalisé sur Qwen3.8-27B et une seule NVIDIA B200. Par rapport à la solution précédente, DSpark, ReaDy se distingue par un avantage constant : elle fait mieux sur les sept tests, avec en moyenne +7,97% de débit et +8,50% de longueur de séquence acceptée.

Pourquoi le brouillon regarde au mauvais endroit

Le principe du décodage spéculatif est simple. Un brouillon léger (drafter) prédit plusieurs tokens à l'avance, puis le modèle principal les vérifie en une seule passe et accepte le préfixe correct. Plus la chaîne acceptée est longue, moins le gros modèle exécute d'étapes coûteuses.

Beaucoup de brouillons actuels s'appuient sur les caractéristiques cachées du modèle cible. Les auteurs de ReaDy pointent la faiblesse de cette approche : ces caractéristiques portent leur propre « accent contextuel », qui ne coïncide pas forcément avec ce dont les positions suivantes du brouillon ont besoin. Pour le premier token, une partie de l'historique compte davantage ; pour le quatrième, il peut en falloir une autre. Un seul jeu de caractéristiques répond de façon inégale à ces besoins.

Comment fonctionne ReaDy

Les modèles linéaires hybrides conservent des états récurrents compacts, dans lesquels s'accumulent des associations historiques. Pour l'accélération, c'est une source de contexte supplémentaire commode : le modèle cible l'a déjà calculée et elle occupe peu de place. Selon les auteurs, ReaDy est le premier à employer ces états pour retrouver le contexte adapté à chaque position du brouillon.

Le mécanisme est le suivant :

• Chaque position du brouillon reçoit sa propre requête apprenable.
• Cette requête lit le contexte supplémentaire directement dans les états récurrents validés (committed) du modèle cible.
• Un module léger de lecture d'états (state reader) ajoute ce qui a été trouvé aux représentations du brouillon par des mises à jour résiduelles.
• Une lecture d'états de faible rang et des opérateurs fusionnés (fused) maintiennent à un faible niveau le surcoût de calcul et la charge d'entrées-sorties.

Le backbone parallèle et la tête de prédiction séquentielle viennent de DSpark. L'adaptation se fait en deux étapes. Dans leurs ablations, les auteurs ont testé la capacité du reader, les sources d'états et l'emplacement d'insertion des mises à jour résiduelles. L'abstract ne donne aucun résultat chiffré pour ces ablations.

Les chiffres

• Benchmarks : sept, couvrant mathématiques, code et dialogue.
• Modèle et matériel : Qwen3.8-27B, une seule NVIDIA B200.
• Accélération moyenne par rapport à l'autorégression : 3,16x.
• Face à DSpark : throughput +7,97%, acceptance length +8,50% en moyenne.
• Résultat supérieur à DSpark sur chacun des sept tests.

Il faut regarder les deux métriques ensemble. Une longueur d'acceptation en hausse de 8,50% pour un débit en hausse de 7,97% signifie que presque tout le gain vient de brouillons plus précis, et que les calculs supplémentaires liés à la lecture des états n'en consomment qu'une faible part. Cela concorde avec l'accent mis par les auteurs sur la lecture de faible rang et les opérateurs fused.

Ce qu'il faut vérifier avant le déploiement

La méthode est liée à l'architecture. Elle exige des états récurrents : elle convient donc aux modèles linéaires hybrides, mais n'est pas applicable en l'état aux transformers classiques à attention complète. Si votre production tourne sur des modèles HLA, ReaDy mérite de figurer parmi les candidats : le code est ouvert sur GitHub (StartLuxLabs/ReaDy). L'adaptation en deux étapes implique toutefois que le brouillon doit être réentraîné pour votre modèle cible, et non utilisé tel quel.

La description ne fournit pas certaines données pourtant décisives pour une exploitation réelle. On ignore comment la méthode se comporte avec de gros batchs, sur de longs contextes et sous contrainte de mémoire. Toutes les mesures ont été faites sur une seule B200, et la comparaison avec DSpark repose sur un seul jeu de tests. Avant d'intégrer le 3,16x dans votre calcul du coût d'inférence, testez la méthode sur votre propre trafic : la répartition entre code, mathématiques et dialogue peut différer chez vous, et la vitesse des méthodes spéculatives dépend fortement de la prévisibilité du texte.