KVarN: 5x más KV-cache en vLLM, según Huawei

Huawei publicó KVarN, un back end de cuantización de KV-cache nativo para vLLM que promete meter entre 3 y 5 veces más caché en la misma GPU sin tocar el throughput ni la precisión. La cuantización KVarN apunta justo al cuello de botella de los modelos grandes: la memoria que se come el contexto largo.

KVarN es un back end de cuantización de KV-cache desarrollado por el laboratorio CSL de Huawei e integrado de forma nativa en vLLM. Comprime las claves (keys) y los valores (values) que el modelo guarda durante la inferencia, usando rotación Hadamard y normalización de varianza, para que un servidor pueda atender contextos más largos y más usuarios concurrentes con la misma placa, sin recalibrar el modelo.

¿Qué es el KV-cache y por qué consume tanta memoria?

Ponele que tenés un chatbot con Qwen3-32B y un usuario te manda una conversación de 40.000 tokens. Cada token que el modelo ya procesó deja una huella: dos tensores, las claves y los valores de cada capa de atención, que el modelo guarda para no recalcular todo en cada paso. Eso es el KV-cache.

El problema es cómo crece. La memoria del KV-cache escala de forma lineal con la longitud de la secuencia y con la cantidad de pedidos en paralelo. En un modelo de 32 mil millones de parámetros, con contexto largo y varios usuarios a la vez, el caché se come más VRAM que los propios pesos del modelo. ¿Y qué pasa cuando se llena? Exacto: la GPU empieza a rechazar pedidos o a recortar batches, y el throughput se desploma. Para profundizar en cómo funciona el cálculo de atención, mirá nuestro análisis de arquitecturas de modelos.

Acá viene lo bueno: si lográs comprimir ese caché sin romper la calidad de las respuestas, ganás capacidad gratis.

¿Cuál es el problema con los métodos de cuantización existentes?

La idea de cuantizar el KV-cache no es nueva. Bajás los tensores de FP16 a 8, 4 o hasta 2 bits y, en teoría, entran muchos más datos. El tema es que casi todos los enfoques arrastran un trade-off molesto.

Algunos métodos ganan capacidad pero te frenan el throughput, porque el proceso de descuantización en cada paso de generación agrega latencia. Otros van rápido pero a 2 bits la precisión se cae, sobre todo en los valores extremos (los famosos outliers) que aparecen en ciertos canales de las claves. Y varios necesitan una fase de calibración con datos representativos, lo que complica el deploy.

El cuello clásico está en la distribución de las claves: tienen outliers concentrados en pocos canales, y cuando cuantizás todo con la misma escala, esos picos se llevan puesta la precisión del resto.

¿Cómo funciona técnicamente la cuantización KV-cache de KVarN?

KVarN ataca ese problema en cuatro pasos, según la documentación del repositorio oficial en GitHub:

• Rotación Hadamard: aplica una transformación que “esparce” los outliers de las claves entre todos los canales, en vez de dejarlos concentrados. Así ningún canal monopoliza el rango dinámico.
• Normalización iterativa de varianza: es el corazón del método. Iguala la varianza entre canales de forma iterativa, de modo que la cuantización trate a todos con una escala más pareja. Sin este paso, los 2 bits de los valores no aguantarían la precisión.
• Cuantización asimétrica round-to-nearest: en vez de asumir distribuciones simétricas, ajusta el cero y la escala a cada bloque. El redondeo al más cercano evita el costo de búsquedas complejas.
• Scale folding: pliega los factores de escala dentro de las operaciones existentes, para que descuantizar no agregue pasos extra que maten el throughput.

La gracia es que todo esto es calibration-free. No necesitás un dataset de calibración ni reentrenar nada. Subís el modelo, activás el back end y listo.

¿Qué gana KVarN frente a FP16 estándar?

Los números que reporta Huawei sobre Qwen3-32B con la configuración kvarn_k4v2_g128 (4 bits para las claves, 2 bits para los valores, grupos de 128):

• Capacidad de KV-cache: entre 3 y 5 veces más que FP16, según el largo de secuencia.
• Throughput: igual o hasta 1.3 veces superior al baseline FP16, gracias al scale folding.
• Precisión: se mantiene en nivel FP16 en las tareas evaluadas.

Ahora bien, una salvedad honesta: estos benchmarks son del propio fabricante. Que la precisión “se mantenga” en FP16 suena demasiado lindo para 2 bits en los valores, así que habría que ver verificaciones independientes antes de cantar victoria. ¿Alguien lo midió fuera de Huawei? A junio 2026, lo que hay es el paper y el repo oficial.

¿Cómo activar KVarN en vLLM?

Esta es la parte que de verdad importa para quien lo va a usar. KVarN es plug-and-play: no cambiás el modelo, solo le decís a vLLM qué tipo de KV-cache querés.

from vllm import LLM, SamplingParams

llm = LLM(
 model="Qwen/Qwen3-32B",
 kv_cache_dtype="kvarn_k4v2_g128",
 block_size=128,
)

out = llm.generate(["Explicame qué es el KV-cache"], SamplingParams(max_tokens=256))
print(out.outputs.text)

Dos detalles que conviene tener en la cabeza: el block_size tiene que ser compatible con el tamaño de grupo de la cuantización (de ahí el 128), y necesitás una versión de vLLM que ya incluya el back end de KVarN. Si tu vLLM es viejo, no va a reconocer el kv_cache_dtype y vas a comer un error de configuración. Más sobre los modos de KV-cache cuantizado en la documentación oficial de vLLM.

¿Qué casos de uso se benefician más?

No todos los deploys ganan lo mismo. Dónde KVarN brilla:

• Contexto largo: agentes, RAG con documentos extensos o chats que arrastran historial. Cuanto más largo el contexto, más pesa el caché y más ganás al comprimirlo.
• Batch inference en producción: si servís a muchos usuarios concurrentes, meter 3 a 5 veces más caché significa más pedidos en paralelo por GPU.
• Modelos 32B+ con GPU justa: el caso típico de querer correr un modelo grande en una placa que no sobra. Si tu infra vive en un servidor o VPS con GPU dedicada, como los que podés armar en donweb.com, exprimir la VRAM deja de ser un lujo.

Si tu caso es un solo usuario con prompts cortos, la verdad es que el beneficio es marginal. Ahí ni te calentés.

KVarN vs KIVI, INT8 y KVQuant

Para ubicarlo en el mapa, una comparativa con los métodos más conocidos de cuantización de KV-cache:

Método	Bits típicos	Calibración	Impacto en throughput	Integración vLLM
KVarN	4 bits keys / 2 bits values	No (calibration-free)	Igual o hasta 1.3× más rápido	Nativa
KIVI	2 bits asimétrico	No (tuning-free)	Buena, con overhead de descuantización	Vía integraciones externas
INT8 / FP8	8 bits	No	Mínimo	Nativa
KVQuant	Sub-4 bits	Sí, requiere calibración	Variable según implementación	Externa

El INT8 es lo más conservador: poca compresión (2× nominal), casi cero riesgo. KIVI ya empuja a 2 bits sin calibrar, y fue una de las referencias del área (ver el paper de KIVI en arXiv). Lo que KVarN pone sobre la mesa es un esquema mixto 4/2 bits, sin calibración y, según Huawei, sin pagar el peaje de throughput que suele venir con la cuantización agresiva.

Errores comunes al usar KVarN

• Usar un block_size incompatible: si ponés un block_size que no es múltiplo del tamaño de grupo (128 en k4v2_g128), vLLM tira error o cae a un back end por defecto sin avisarte demasiado. Alineá los dos valores.
• Asumir que sirve para cualquier modelo: los benchmarks publicados son sobre Qwen3-32B. En arquitecturas distintas el comportamiento de los outliers cambia, y la precisión podría no replicarse. Medilo en tu modelo antes de producción.
• No medir la calidad real: mucha gente activa la cuantización, ve que “anda” y se olvida de evaluar. A 2 bits en los valores, conviene correr tu propio set de pruebas y comparar contra FP16 en tareas reales, no solo perplexity.
• Confundir capacidad con velocidad: “3 a 5 veces más caché” no es “5 veces más rápido”. Es más contexto o más concurrencia en la misma GPU. El throughput por pedido se mantiene parejo.

Preguntas Frecuentes

¿Qué es KVarN y para qué sirve?

KVarN es un back end de cuantización de KV-cache de Huawei integrado en vLLM. Sirve para comprimir la memoria de claves y valores durante la inferencia, permitiendo contextos más largos y más usuarios concurrentes en la misma GPU.

¿Cuánta mejora de capacidad da KVarN en Qwen3-32B?

Según Huawei, entre 3 y 5 veces más capacidad de KV-cache que FP16, con la configuración kvarn_k4v2_g128. El throughput se mantiene igual o hasta 1.3 veces superior, sin pérdida apreciable de precisión en las tareas evaluadas.

¿KVarN necesita calibración?

No. KVarN es calibration-free: no requiere un dataset de calibración ni reentrenar el modelo. Activás el back end en vLLM y funciona directo, lo que simplifica el deploy en producción.

¿En qué se diferencia KVarN de KIVI?

KIVI usa cuantización asimétrica a 2 bits sin calibración, pero arrastra overhead al descuantizar. KVarN combina 4 bits en claves y 2 en valores, agrega normalización iterativa de varianza y scale folding, y reporta throughput igual o mejor que FP16.

¿Cómo se activa KVarN en vLLM?

Pasando kv_cache_dtype="kvarn_k4v2_g128" al crear el objeto LLM() en vLLM, con un block_size compatible (128). Necesitás una versión de vLLM que incluya el back end de KVarN; no hay que modificar el modelo.

Conclusión

KVarN ataca el problema más concreto del serving de modelos grandes: la VRAM que se come el KV-cache cuando el contexto crece. Si los números de Huawei se sostienen fuera del laboratorio, 3 a 5 veces más capacidad sin perder throughput ni precisión es un golazo para cualquiera que corra Qwen3-32B en GPU limitada.

El consejo práctico: probalo en tu propio modelo y con tu propio set de evaluación antes de confiar en los benchmarks del fabricante. Activarlo cuesta una línea, así que el experimento es barato. Lo que no es gratis es asumir que “mantiene FP16” sin medirlo vos mismo.

Fuentes

• KVarN – Repositorio oficial de Huawei CSL en GitHub
• vLLM – Documentación de KV-cache cuantizado
• vLLM Blog – FP8 KV-cache
• arXiv – Paper técnico sobre cuantización de KV-cache
• arXiv – KIVI: cuantización asimétrica 2 bits para KV-cache