Huawei lanza KVarN: un backend nativo de vLLM para la cuantización del KV-Cache

El 80 %. Esa es aproximadamente la cantidad de VRAM que se evapora en el KV-Cache una vez que empiezas a empujar las ventanas de contexto más allá de 32k tokens en un servidor de alto rendimiento. Si alguna vez has intentado servir un modelo a más de tres personas simultáneamente, sabes que los pesos son la parte fácil. Los pesos son estáticos. El KV-Cache es la bestia hambrienta que crece con cada token generado, hasta que finalmente choca contra el muro del OOM y hace que tu instancia se crashee justo cuando la salida se estaba poniendo interesante.

Huawei acaba de lanzar KVarN, un backend nativo de vLLM para la cuantización del KV-Cache. Para los que no estén al tanto (aunque probablemente ya lo sepáis), vLLM es actualmente el estándar de oro para servir modelos de pesos abiertos gracias a PagedAttention. Pero ni siquiera PagedAttention puede salvarte si los tensores reales en ese caché son demasiado voluminosos. KVarN intenta solucionar esto cuantizando el KV-Cache, reduciendo la huella de memoria por token sin destruir la capacidad del modelo para recordar lo que ocurrió hace diez páginas.

El objetivo técnico aquí es simple: reducir la precisión del KV-Cache para encajar más peticiones en la misma cantidad de VRAM. Pasar de FP16 a una precisión menor es como intentar meter un colchón king size en un estudio: pierdes un poco de “comodidad” en términos de precisión bruta, pero al menos puedes entrar en la habitación. ¿A quién le gusta gestionar manualmente los offsets de PagedAttention? A nadie.

Al implementarlo como un backend nativo de vLLM, KVarN evita la sobrecarga de los wrappers externos. Esto es crítico porque cualquier latencia añadida durante el proceso de cuantización/descuantización puede comerse fácilmente las ganancias de throughput que obtienes al tener un batch size mayor. (Huawei probablemente tenga más GPUs que nosotros, así que pueden permitirse optimizar para la gama alta).

La verdadera pregunta es si esto aguanta frente al orden jerárquico actual de los pesos abiertos. Si estás ejecutando Llama 3.3 o Qwen 2.5, estás lidiando con modelos que ya son bastante eficientes. Sin embargo, cuando escalas al rango de 70B+, el KV-Cache se convierte en el cuello de botella principal. Si KVarN puede mantener la perplexity mientras recorta drásticamente el uso de VRAM, cambia las reglas del juego para cualquiera que intente ejecutar una API de nivel producción con un presupuesto limitado.

Es una corrección necesaria para un modelo de memoria roto.

Desde el punto de vista legal, esto es una victoria para la licencia Apache 2.0. Estamos cansados de ver lanzamientos de “pesos abiertos” que vienen con una licencia tan restrictiva que básicamente necesitas el permiso de un abogado para ejecutar un generador de tarjetas de felicitación. Apache 2.0 significa que puedes usar esto realmente en una pipeline comercial sin complicarte la vida.

Pero, ¿puedes ejecutar esto en tu equipo? Si eres un aficionado con una única RTX 4090, probablemente estés usando Ollama o llama.cpp con cuantizaciones GGUF. vLLM es un animal distinto: está diseñado para throughput y serving. Si has montado tu 4090 en un entorno de vLLM para servir a un pequeño grupo de usuarios, KVarN es relevante. Te permite aumentar tu batch size o empujar tu ventana de contexto más allá antes de que la GPU empiece a gritar.

Para los que usen Mac M3 o M4 Ultra con MLX, este backend específico no os ayudará directamente, ya que está ligado al ecosistema de vLLM y CUDA. Pero la lógica es lo que importa. Estamos viendo un cambio donde el foco se desplaza de cuantizar solo los pesos (que ya hemos resuelto básicamente con AWQ y GGUF) hacia cuantizar los estados de activación y caché.

La ganancia de rendimiento será más visible en A100 o H100, pero el efecto cascada para los dueños de 3090/4090 es la capacidad de manejar secuencias más largas sin el temido error de “Out of Memory”. Veremos esta lógica fusionada en la rama principal de vLLM para el Q4. Hasta entonces, sigue siendo una herramienta especializada para aquellos dispuestos a construir desde un backend concreto.