RBS-Attention recorta seis veces el tiempo hasta el primer token a 128K

Un prompt de 128.000 tokens en un modelo Qwen3-30B-A3B-Instruct-2507-FP8 sobre GPU H100 tarda casi seis veces menos en producir su primer token si se aplica RBS-Attention. Es el dato principal de un paper publicado hoy en arXiv por un grupo que ataca el cuello de botella menos glamuroso de la inferencia con contextos largos: el prefill.

El prefill es la fase en la que el modelo procesa el prompt completo antes de generar nada. Con atención densa, su coste crece de forma cuadrática con la longitud de la entrada, así que a 128K tokens la espera hasta el primer token se convierte en el problema dominante. Los autores reportan 20,65x de aceleración en la atención del prefill medida de forma aislada, 11,92x dentro de vLLM y 5,97x en el tiempo total hasta el primer token.

El problema: la dilución de la media

La idea de recortar el prefill con atención sparse por bloques no es nueva. Se agrupan las claves en bloques, se calcula un centroide por bloque y se conservan solo los bloques cuyo centroide parece relevante para la consulta. Funciona bien cuando la información útil está repartida, pero falla en un caso muy concreto: un bloque con un único token muy relevante rodeado de decenas irrelevantes tiene un centroide anodino y se descarta.

El paper bautiza este fallo como mean dilution, dilución de la media. Es un problema serio para tareas de recuperación de tipo aguja en un pajar, donde el dato que necesita el modelo puede vivir en una sola posición del contexto.

Dos ramas de selección en lugar de una

RBS-Attention, siglas de Radius-Bounded Sparse, responde con dos ramas complementarias que se ejecutan sin entrenar nada:

Rama base por centroide: captura la relevancia media de cada bloque, como los métodos existentes.
Rama de rescate por radio: usa el radio máximo de cada bloque de claves, es decir, cuánto se aleja el token más extremo de su centroide. Un radio grande indica que el centroide puede estar ocultando algo. La distribución de ese radio depende del prompt, de la capa y de la cabeza de atención, y el método la modela para decidir qué bloques están en riesgo de subestimación.

Cada rama se umbraliza por separado y las dos máscaras se combinan. Eso permite controlar cuánto peso tienen los bloques rescatados sin romper la ejecución block-sparse estándar de FlashAttention, que es justo donde se obtiene la ganancia de velocidad. No hace falta un kernel nuevo ni un fine-tuning previo.

Qué pierde en calidad

En el modelo denso Qwen3-32B, RBS-Attention obtiene 88,65 puntos de precisión global en RULER, el benchmark de referencia para contextos largos, frente a 89,52 con atención densa. Menos de un punto de diferencia a cambio de una reducción de coste de un orden de magnitud en la atención del prefill. El abstract no detalla el desglose por subtarea de RULER ni el comportamiento en longitudes superiores a 128K, así que conviene leer el paper completo antes de extrapolar.

Por qué importa y para quién

Los modelos con ventanas de contexto grandes se han vuelto habituales. Claude Opus 4.8 ofrece una ventana opcional de 1M tokens y los modelos abiertos como los Qwen3 del paper ya se evalúan a 128K. El coste de usar esas ventanas no está solo en el precio por token, sino en la latencia hasta la primera respuesta, que es lo que el usuario percibe.

RBS-Attention interesa sobre todo a tres perfiles:

Equipos que sirven modelos abiertos con vLLM o infraestructura propia y quieren reducir latencia en cargas con prompts largos: RAG con muchos documentos, análisis de repositorios de código, resúmenes de transcripciones.
Investigadores de eficiencia de inferencia que trabajan en atención sparse y necesitan una explicación clara de por qué los métodos basados en centroide fallan en recuperación puntual.
* Quien diseña agentes con contexto acumulado, donde cada turno reprocesa un prompt que crece sin parar y el prefill se repite decenas de veces por sesión.

Para quien consume modelos a través de una API cerrada, como la de Anthropic, el impacto es indirecto: este tipo de técnicas acaban integradas en el servidor y se notan como menor latencia, no como una opción que se active.

Lo que queda por comprobar

Las cifras se han medido en H100 y con un modelo MoE cuantizado a FP8, una configuración favorable para este tipo de aceleración. Faltan resultados en hardware más modesto y en modelos densos grandes fuera de la evaluación de calidad. Tampoco sabemos, por ahora, cuánto cuesta calcular los radios por bloque en la práctica ni si el método se lleva bien con el prefix caching que usan los servidores de producción.

Desde ElephantPink hemos visto en proyectos con RAG que la latencia del prefill limita más que el precio por token cuando el contexto pasa de 50K, así que cualquier técnica sin reentrenamiento que la reduzca merece atención. Pero un punto de RULER es un punto, y en tareas de recuperación fina esa diferencia puede ser exactamente el dato que el cliente necesitaba.