DCOCO acelera la inferencia de LLM hasta 6,6x y supera a la competencia en un 6–23%

Un grupo de investigadores ha publicado en arXiv DCOCO (DFlash Contextual Corrector), un método que resuelve la principal debilidad de los drafters de difusión en la decodificación especulativa. Se trata de un corrector ligero que mantiene la generación paralela del borrador y devuelve al bloque las dependencias entre tokens. En cuatro modelos verificadores y diez benchmarks, logró el mayor rendimiento medio en todas las configuraciones evaluadas. La aceleración máxima fue de 6,6x respecto a la decodificación convencional. Con 4–32 solicitudes simultáneas, el método supera en un 6–23% al competidor más fuerte.

Dónde falla el borrador paralelo

La decodificación especulativa funciona de forma sencilla. Un modelo pequeño, el drafter, propone varios tokens por adelantado y un modelo objetivo más grande los verifica en una sola pasada paralela. Se acepta todo lo que coincide con su propia predicción. Cuanto más largo es el tramo aceptado, mayor es la velocidad.

Los drafters de difusión han hecho más atractivo este esquema. Cuentan con un backbone de attention profundo y predicciones sólidas, rellenan las posiciones futuras en paralelo y no pagan el coste de la autorregresión secuencial. Pero el paralelismo tiene un precio. El token de la tercera posición del bloque se predice sin saber qué token ocupa la segunda. Las dependencias dentro del bloque, que en la autorregresión surgen por sí solas, desaparecen.

En la práctica, cada token es plausible por separado, pero los tokens vecinos no encajan entre sí. El verificador descarta la cola del bloque y la longitud del borrador aceptado se reduce. Parte de la ganancia del borrador paralelo se pierde.

Qué hace DCOCO

Los autores no optaron por volver a la generación secuencial. En lugar de fijar un único favorito para cada posición, DCOCO conserva varios candidatos. Después evalúa en paralelo hasta qué punto son compatibles entre sí los candidatos de posiciones contiguas y elige los tokens teniendo ya en cuenta el contexto. Según los autores, el coste adicional es reducido.

La diferencia clave con los correctores existentes es que estos trabajan de forma secuencial. También restauran las dependencias, pero reintroducen en el pipeline justo el coste secuencial del que el drafter de difusión se había librado. Según el artículo, con una carga de 4–32 solicitudes simultáneas, esos correctores caen por debajo del DFlash básico sin ninguna corrección.

Cifras del abstract:

• 4 modelos verificadores y 10 benchmarks en las pruebas;
• el mayor rendimiento medio en cada configuración evaluada;
• modos: decodificación greedy y estocástica, con razonamiento extendido y sin él;
• aceleración de hasta 6,6x respecto a la decodificación convencional;
• ventaja del 6–23% sobre el competidor más fuerte con 4–32 solicitudes paralelas.

Además, es importante que el resultado se mantiene también en los modos con cadenas de razonamiento largas. Es justo ahí donde la generación resulta más cara y donde acelerar la inferencia aporta más.

Qué tener en cuenta al implantarlo

Se trata de un preprint y todas las cifras las han obtenido los propios autores. El abstract no incluye verificación independiente ni datos sobre modelos o hardware concretos, así que conviene leer el 6,6x como un techo y no como el resultado esperable con su tráfico.

Un equipo que opere un servicio de LLM debería extraer del trabajo dos conclusiones. Primero, los métodos de aceleración no se deben comparar solo con una única solicitud. Un corrector que gana con batch size 1 puede perder con 8–32 solicitudes concurrentes, y el trabajo lo demuestra de forma explícita.

Segundo, si ya usa DFlash u otro drafter de difusión similar, DCOCO parece una capa adicional y no un reemplazo de todo el esquema. Tiene sentido probarlo con sus propios prompts y su perfil de carga: por separado para respuestas cortas y para razonamientos largos, y por separado para sampling greedy y estocástico. Hay que fijarse en la longitud media del bloque aceptado y en los tokens por segundo resultantes en la GPU, y no en una sola métrica.