El KV cache es el elefante de memoria en el serving de LLM de largo contexto. Cada token produce un tensor de claves y valores que queda residente mientras dura la secuencia, y en largo contexto más modelos grandes el cache suele consumir 20 a 30 por ciento del VRAM total. Los workarounds existentes (grouped-query attention, PagedAttention, cuantización INT4/INT8) ayudan pero se estancan. TurboQuant, publicado esta semana como arxiv 2504.19874 desde Google, reclama aproximadamente 4,5 a 5x de compresión versus las líneas base FP16 con pérdida de precisión casi nula, lo que, si aguanta en producción, es la compresión de KV cache usable más agresiva a la fecha.
El truco es un pipeline en dos etapas. La etapa uno rota aleatoriamente los vectores de entrada, lo que concentra los valores de coordenadas en una distribución Beta y permite aplicar un cuantizador escalar óptimo por coordenada. La etapa dos aplica un cuantizador MSE seguido de una transformación Johnson-Lindenstrauss cuantizada a 1 bit sobre el residuo. El almacenamiento por token se reduce a índices de cuantización, bits de signo y un escalar de norma L2. A 3,5 bits por canal el paper reporta "neutralidad de calidad absoluta", es decir la pérdida de precisión es estadísticamente nula en su evaluación. A 2,5 bits por canal reporta "degradación de calidad marginal". La etapa de rotación es la idea arquitectónica: pagas un pequeño costo de cómputo para hacer la distribución de coordenadas amigable a la cuantización, y luego la cuantización escalar por coordenada hace la compresión en lugar de los enfoques tradicionales por grupo o por tensor.
Para quien sirve LLM con largo contexto, la cuenta es directa. Si tu stack actual cachea KV en FP16 y estás limitado por VRAM (el caso común en serving mono-nodo con 32k+ de contexto), 4,5 a 5x de compresión se traduce en aproximadamente 5x requests concurrentes al mismo presupuesto de memoria, o 5x longitud de contexto por request. La salvedad es que el abstract no enumera qué modelos se probaron, así que antes de llevar TurboQuant a producción, verifica que la evaluación cubra tu familia de modelos y tus longitudes de secuencia. El paper también apunta a búsqueda del vecino más cercano como segunda aplicación, lo que sugiere que el patrón rotación-más-cuantización generaliza más allá de los caches de atención.
El camino práctico para un equipo de serving en producción es vigilar implementaciones de referencia y hacer benchmarks contra lo que ya corres. TurboQuant encaja en el mismo lugar de tu stack de inferencia donde irían KIVI, KVQuant o Atom, así que el costo de integración es similar. Si ya cuantizaste el KV cache, compara 3,5 bits por canal a pérdida de calidad cero contra tu setup actual; es un piso competitivo para 2026. Si aún no has cuantizado, este paper es el mejor argumento actual para empezar ya. La tendencia más amplia es que la compresión del KV cache ya no es una optimización opcional. En cargas de largo contexto es la restricción limitante, y la investigación de los labs de frontera converge rápidamente en esquemas sub-4-bits que preservan la precisión.