Xiaomi publica HySparse2, atención dispersa con KV compartido en dos niveles
El equipo LLM-Core de Xiaomi cifra en unas 5 veces menos FLOPs de prefill con un millón de tokens frente a Hybrid SWA sobre un MoE de 80B con 3B activos.
Xiaomi ha publicado HySparse2, un diseño de atención dispersa híbrida que reparte el KV en dos niveles en lugar de uno. El equipo LLM-Core de la compañía cifra el ahorro en torno a 5× menos FLOPs de prefill al procesar una ventana de un millón de tokens, y toma como referencia Hybrid SWA sobre un MoE de 80B de parámetros totales y 3B activos. El objetivo declarado son los modelos agénticos de la clase MiMo-V3.
El problema que ataca
En cualquier transformer, el prefill obliga a calcular la atención sobre todo el contexto de entrada antes de emitir el primer token. La memoria KV crece de forma lineal con la longitud de esa entrada, y con un millón de tokens el coste computacional y de memoria se dispara. La ventana deslizante (sliding window attention) recorta el problema limitando cada token a mirar solo una franja reciente, pero paga un precio: el contexto viejo se pierde o hay que recuperarlo por otras vías. Los esquemas híbridos mezclan capas de atención completa con capas de ventana deslizante para quedarse con lo mejor de cada lado.
HySparse2 añade encima un segundo nivel de compartición de KV. La nota de Xiaomi no detalla cómo se implementa ese segundo nivel ni qué se comparte exactamente con qué, así que de momento solo tenemos la cifra de ahorro y el tipo de modelo al que apunta, no la receta.
Los números que da la compañía son suyos y no vienen acompañados de una verificación independiente. Tampoco hay por ahora referencias a código, a un repositorio ni a una implementación que alguien pueda reproducir. Eso no invalida el resultado, pero lo deja en el terreno de lo anunciado.
Por qué importa
El prefill es la parte cara de servir modelos de contexto largo, y quien despliega inferencia lo sabe: cada token de entrada que se procesa se traduce en tiempo de espera antes de que el usuario vea nada. Si la reducción de FLOPs se sostiene, afecta directamente a cuántas GPUs hacen falta para atender una carga dada y a cuánto contexto se puede ofrecer sin que la factura se desmadre. Los modelos agénticos, que acumulan historial de herramientas y pasos intermedios, son el caso donde más duele.
Queda por ver si el diseño escala hacia abajo, es decir, si mantiene la ventaja en modelos pequeños y en ventanas de 32K o 128K, que es donde vive la mayoría del tráfico real. También falta la comparación contra las técnicas de atención dispersa que ya están en producción. Sin paper, sin código y sin trazas de rendimiento medidas por terceros, la cifra de 5× es un punto de partida, no una conclusión.
