Xiaohongshu acelera el indexador de atención dispersa: DoSA reduce a la mitad el TTFT

La red social china Xiaohongshu (RedNote) ha abordado el cuello de botella que aparece tras adoptar la atención dispersa. Su equipo Dots desarrolló DoSA, un método que en las pruebas filtró de antemano cerca del 97% de los candidatos en el indexador, no alteró el Top-K final y, según el titular de la publicación de Jiqizhixin, redujo a la mitad la latencia del primer token (TTFT) con un contexto de alrededor de 1M de tokens.

Dónde está el cuello de botella

La atención dispersa recorta el cómputo de este modo: cada consulta no mira todos los tokens anteriores, sino solo los K más relevantes. Los selecciona un módulo ligero e independiente, el indexador. Este evalúa cada par «consulta–token» y elige los mejores. La atención principal se abarata, pero el indexador sigue recorriendo todo el contexto. Su coste crece de forma cuadrática con la longitud de la secuencia y, con un millón de tokens, es él quien empieza a marcar el tiempo de procesamiento del prompt. Este esquema lo usan, entre otros, los modelos de la familia DeepSeek V3.2 con su indexador «relámpago» (lightning indexer).

El problema se nota más en el primer token. En la fase de prefill, el indexador tiene que recorrer todo el prompt largo, y el usuario espera la respuesta más de lo deseable.

Cómo funciona DoSA

El texto completo del material al que hemos tenido acceso está truncado, así que los detalles de la implementación se basan en la descripción de los autores. DoSA calcula para los candidatos una cota superior y una inferior de la puntuación. Es una operación barata en comparación con el cálculo exacto. La lógica de este descarte es sencilla: si la cota superior de un candidato es inferior a la cota inferior que ya garantiza un puesto entre los K primeros, ese candidato no entrará en el Top-K. No hace falta calcular su puntuación exacta.

La propiedad clave es que el método no aproxima el resultado, sino que devuelve el mismo conjunto de tokens que la búsqueda exhaustiva. Por eso la fórmula «提速不降智» («más rápido sin perder inteligencia») es apropiada aquí: la calidad del modelo no debería depender de la aceleración, porque la selección de tokens no cambia.

Qué se sabe de las pruebas

• Se descartó cerca del 97% de los candidatos antes del cálculo exacto de las puntuaciones.
• El resultado del Top-K coincide con el del algoritmo original.
• El contexto en las pruebas fue de alrededor de 1M de tokens.
• La latencia del primer token bajó aproximadamente a la mitad (según el titular de la publicación).

En el fragmento disponible faltan varios datos: el nombre del modelo (el texto se corta en «Dots3…»), el hardware, el tamaño del batch, los valores absolutos de latencia y el reparto de la mejora por etapas. La cifra de «la mitad» corresponde a una configuración concreta y no puede trasladarse a otros stacks sin verificarla. Es probable que la proporción de candidatos filtrados dependa de los datos: cuanto más marcada sea la distribución de las puntuaciones, más eficaces serán las cotas.

El lado práctico

Para los equipos que sirven modelos de contexto largo con atención dispersa, DoSA resulta interesante porque acelera la inferencia sin reentrenamiento y sin riesgo de cambiar el comportamiento del modelo. Como la selección de tokens es la misma, las pruebas de regresión de calidad deberían pasar sin cambios. Es un argumento de peso para producción, donde cualquier desviación en la salida exige una verificación aparte.

Lo primero es medir qué proporción del tiempo de prefill ocupa el indexador en vuestro stack. Si es notable con 128K–1M de tokens, el método aportará mejora. Si el grueso del tiempo lo consume la parte MoE o la transferencia de datos entre GPU, el efecto será más modesto. También conviene esperar al código abierto o a un informe técnico: a nivel de kernels CUDA, la sobrecarga del cálculo de las cotas puede cambiar mucho el panorama final.

Para la propia Xiaohongshu es además una cuestión de economía. Cuanto más barato sea procesar prompts largos, más fácil resulta mantener en el producto escenarios con contextos amplios: búsqueda en feeds, análisis de documentos, cadenas de agentes.