ReaDy acelera 3,16 veces la decodificación de LLM híbridos en una sola B200

Un grupo de investigadores ha presentado ReaDy, un método de decodificación especulativa para modelos híbridos con atención lineal. En siete benchmarks de matemáticas, generación de código y diálogos, acelera la generación de media 3,16 veces respecto a la decodificación autorregresiva convencional. La prueba se hizo con Qwen3.8-27B y una sola NVIDIA B200. Frente a la solución anterior, DSpark, ReaDy ofrece una mejora consistente: la supera en las siete pruebas, con una media del 7,97% en rendimiento y del 8,50% en longitud de la secuencia aceptada.

Por qué el borrador mira donde no debe

La decodificación especulativa funciona con un principio sencillo. Un borrador ligero (drafter) predice varios tokens por adelantado, y el modelo principal los verifica en una sola pasada y acepta el prefijo correcto. Cuanto más larga es la cadena aceptada, menos pasos costosos tiene que dar el modelo grande.

Muchos borradores actuales se apoyan en las características ocultas del modelo objetivo. Los autores de ReaDy señalan el punto débil de este enfoque: esas características llevan su propio «énfasis contextual», que no tiene por qué coincidir con lo que necesitan las posiciones posteriores del borrador. Para el primer token puede ser más importante una parte del historial, y para el cuarto, otra distinta. Un único conjunto de características cubre esas necesidades de forma desigual.

Cómo funciona ReaDy

Los modelos lineales híbridos almacenan estados recurrentes compactos en los que se acumulan asociaciones históricas. Para acelerar la decodificación, son una fuente cómoda de contexto adicional: el modelo objetivo ya los ha calculado y ocupan poco espacio. Según los autores, ReaDy es el primero en usar estos estados para buscar el contexto adecuado para cada posición concreta del borrador.

El mecanismo es el siguiente:

• Cada posición del borrador recibe su propia consulta entrenable.
• La consulta lee el contexto adicional directamente de los estados recurrentes fijados (committed) del modelo objetivo.
• Un módulo ligero de lectura de estados (state reader) incorpora lo encontrado a las representaciones del borrador mediante actualizaciones residuales.
• La lectura de estados de bajo rango y los operadores fusionados (fused) mantienen en un nivel bajo el cómputo adicional y la carga de entrada/salida.

Como base se toman el backbone paralelo y la cabeza de predicción secuencial de DSpark. La adaptación se hace en dos etapas. En las ablaciones, los autores comprobaron la capacidad del reader, las fuentes de los estados y el punto de inserción de las actualizaciones residuales. El resumen no incluye resultados concretos de estas ablaciones.

Las cifras

• Benchmarks: siete, que abarcan matemáticas, código y diálogos.
• Modelo y hardware: Qwen3.8-27B, una NVIDIA B200.
• Aceleración media respecto a la autorregresión: 3,16x.
• Frente a DSpark: throughput +7,97% y acceptance length +8,50% de media.
• El resultado supera a DSpark en cada una de las siete pruebas.

Conviene fijarse en la relación entre las métricas. Que la longitud de aceptación crezca un 8,50% y el rendimiento un 7,97% significa que casi toda la ganancia procede de borradores más precisos, mientras que el cómputo adicional de la lectura de estados se lleva solo una parte pequeña. Esto concuerda con el énfasis de los autores en la lectura de bajo rango y en los operadores fused.

Qué comprobar antes de desplegarlo

El método está ligado a la arquitectura. Necesita estados recurrentes, así que sirve para modelos lineales híbridos, pero no se puede aplicar en esta forma a los transformers clásicos con atención completa. Si su producción funciona con modelos HLA, conviene añadir ReaDy a la lista de candidatos: el código es abierto y está en GitHub (StartLuxLabs/ReaDy). Además, la adaptación en dos etapas implica que el borrador hay que reentrenarlo para su propio modelo objetivo, y no usarlo tal cual.

La descripción no ofrece datos que importan para la explotación real. No está claro cómo se comporta el método con batches grandes, contextos largos o memoria limitada. Todas las mediciones se hicieron en una sola B200, y la comparación con DSpark se hace sobre un único conjunto de pruebas. Antes de incluir el 3,16x en el cálculo del coste de inferencia, pruebe el método con su propio tráfico: el código, las matemáticas y los diálogos pueden repartirse de otra forma en su caso, y la velocidad de los métodos especulativos depende mucho de lo predecible que sea el texto.