La compresión de KV cache es una decisión de infraestructura, no un debate de modelos
La compresión de KV cache ya no es un debate sobre calidad de modelos. Es una decisión de compra de infraestructura con un problema matemático adjunto.
Lo digo claramente porque demasiados equipos siguen tratando la memoria de LLMs de contexto largo como una carrera de benchmarks: TurboQuant vs OSCAR vs EpiCache, elige un ganador y sigue adelante. En la práctica, así no fallan los despliegues. Fallan porque un equipo optimiza el ancho de bits, otro la portabilidad, y un tercero descubre demasiado tarde que el historial de chat multi-turno es un problema distinto al de un único prompt de 128K. Según el resumen de MarkTechPost del 18 de junio, los tres enfoques resuelven cuellos de botella adyacentes, no el mismo.
La compresión de KV cache duele cuando el HBM, no los FLOPs, es tu techo
La matemática de memoria es la parte que los operadores no pueden ignorar. El ejemplo fuente usa Llama-3.1-70B en BF16: unos 0,31 MB de KV cache por token, unos 40 GB con 128K tokens, y más de 300 GB con 1M de tokens. Ahí es cuando la caché puede superar los propios pesos del modelo. Si sirves peticiones de contexto largo con concurrencia, cada token decodificado arrastra esa caché de vuelta por la memoria de alto ancho de banda.
Ese cambio importa más que otro punto en un leaderboard. Una vez que la decodificación se vuelve limitada por ancho de banda, tu curva de costes cambia. Ya no preguntas: ¿Puede este modelo responder bien? Preguntas: ¿Cuántas sesiones puedo mantener activas antes de que el tráfico de memoria arruine la latencia?
En una prueba de carga de cliente que ejecuté el mes pasado, la elección del modelo no fue la restricción principal. La reutilización de prefijos funcionaba bien en aislamiento, pero cuando subió el número de sesiones concurrentes, la latencia de cola saltó porque el movimiento de memoria, no el cómputo, era el limitador. Por eso el trabajo de KIVI con línea base de 2 bits sigue siendo relevante en 2026: enmarcó la cuantización de KV cache como un problema de sistemas de inferencia, no solo como un truco de compresión.
TurboQuant es la apuesta por portabilidad, no el ganador universal
TurboQuant es impresionante por una razón. Google Research y NYU construyeron un enfoque data-oblivious que ataca los canales outlier sin calibración. Primero rota vectores aleatoriamente para que las coordenadas se comporten más como variables gaussianas independientes. Luego aplica un cuantizador escalar precomputado y una transformada QJL de 1 bit al residual. La afirmación teórica es sólida: la distorsión se mantiene dentro de un factor constante pequeño respecto al límite inferior.
Esa es la herramienta correcta cuando te importa la portabilidad del modelo y no puedes permitirte una calibración personalizada para cada objetivo de servicio. El punto óptimo reportado es el rango de 3 a 4 bits, donde la calidad se mantiene casi sin pérdida en las cargas de trabajo que el artículo enfatiza. Eso hace a TurboQuant atractivo para equipos que ejecutan flotas mixtas o experimentan entre múltiples arquitecturas.
Pero aquí viene la parte polémica: la gente sigue repitiendo la promesa equivocada. La afirmación más ruidosa sobre TurboQuant es la línea de "atención 8x más rápida en H100" del post del blog de Google Research sobre TurboQuant, pero el artículo fuente señala correctamente que esto se refiere a un microbenchmark estrecho, no al servicio de extremo a extremo. He visto este patrón antes con kernels de inferencia: una victoria dentro de una etapa se convierte en argumento de compra para toda la pila. Así es como los equipos se compran una decepción.
OSCAR importa porque alguien realmente embarcó las partes feas
Si tu objetivo es una compresión de KV cache en INT2 desplegable, OSCAR es la historia práctica ahora mismo. El sistema de Together AI no solo propone una rotación consciente de la atención; empaqueta paginación de precisión mixta, kernels de Triton e integración con SGLang alrededor de ella. Eso es importante porque las ganancias en producción suelen venir del paquete, no del artículo.
Los detalles importan. OSCAR mantiene los tokens de sink y recientes en BF16 mientras comprime los tokens históricos a INT2, dejando solo alrededor del 0,24% de tokens sin comprimir a 128K de contexto según el resumen. También embarca rotaciones precomputadas para los modelos soportados, lo que elimina un paso feo del despliegue. La mejora reportada es sustancial: hasta 7,83x de throughput a nivel de trabajo, una reducción de memoria de KV cache de unos 8x a 100K de contexto, y hasta 3x de decodificación más rápida en las configuraciones probadas.
Por eso creo que OSCAR gana actualmente el argumento de desplegabilidad en el extremo de bajo bit. No porque la idea sea más elegante. Sino porque alguien cerró la brecha entre la teoría de cuantización y la realidad del servicio.
El mejor argumento a favor de un ganador directo sigue sin sostenerse
Un contraargumento justo es que las empresas sí necesitan una respuesta simple. Si un método supera a otro en calidad de benchmark y throughput, elegir al líder reduce la complejidad. Hay lógica ahí. Cada ruta de inferencia adicional suma sobrecarga de pruebas, lógica de rollback, trabajo de observabilidad y carga de soporte. Estandarizarse en un método suele ser la elección operativa sensata.
Estoy de acuerdo con ese instinto. Solo que no creo que la evidencia actual apoye un ganador universal.
La comparación reportada de OSCAR sugiere que TurboQuant cae fuertemente con presupuestos similares, pero esa lectura viene con advertencias que el artículo fuente acertó en señalar: la comparación corre dentro del framework de OSCAR, cuantiza todas las capas, usa una única semilla aleatoria y evalúa a TurboQuant por debajo de su régimen previsto de 3 a 4 bits. Eso no basta para un veredicto general. A su vez, la historia de portabilidad de TurboQuant no responde si puedes obtener un comportamiento estable de INT2 en producción con tu pila exacta la semana que viene.
Así que la decisión real es más estrecha y más aburrida:
- Elige TurboQuant cuando la despliegue agnóstico al modelo y el comportamiento casi sin pérdida a 3-4 bits importen más que la compresión absoluta.
- Elige OSCAR cuando necesites INT2 en modelos soportados, integración de producción y ahorros de memoria inmediatos a contexto largo.
- No fuerces a ninguno a resolver la gestión de memoria multi-turno, porque esa no es su función.
EpiCache es el recordatorio de que los prompts largos y las conversaciones largas son problemas de sistemas distintos
Esta es la parte que muchos equipos pasan por alto. Un único prompt de 128K y una conversación de dos horas no son la misma carga de trabajo, aunque ambos parezcan "contexto largo" en una diapositiva.
EpiCache de Apple aborda directamente el caso conversacional. En lugar de preguntar solo qué tan precisamente almacenar tokens, pregunta qué historial mantener activo, cómo segmentarlo en episodios coherentes, y cómo recuperar el episodio correcto durante la inferencia. El framework añade prefill por bloques, clustering episódico, recuperación sobre episodios y presupuestación de memoria por capas.
Operativamente, eso es un eje distinto de la cuantización de KV cache. Es gestión de caché, no solo reducción de caché. Las ganancias reportadas en el material fuente son exactamente por lo que importa esa distinción: hasta 40% más de precisión que las líneas base de evicción, precisión casi de caché completa a compresión de 4-6x, hasta 3,5x menos memoria pico, y unos 2,4x menos de latencia en los benchmarks de conversación evaluados.
Mi réplica a la mentalidad de "solo elige un ganador" es simple: EpiCache se compone con TurboQuant o OSCAR. Así que si tu carga de trabajo es un copiloto de soporte, asistente de investigación o agente interno con historial de chat profundo, la mejor pila puede ser un método para retención más otro para precisión de almacenamiento. Eso no es indecisión. Es diseño de sistemas.
La pregunta correcta es qué restricción te está costando dinero primero
Cuando entro a una revisión de inferencia, no empiezo con los nombres de los artículos. Empiezo con tres preguntas.
Primera, ¿la flota de servicio está limitada por memoria en tiempo de decodificación, o aún estamos limitados por cómputo? Segunda, ¿necesitamos portabilidad entre modelos, o podemos optimizar fuerte para una pila soportada? Tercera, ¿la carga de trabajo está dominada por un prompt largo o por muchos turnos conversacionales?
Esas preguntas suelen reducir el campo rápido. Si domina la portabilidad, TurboQuant tiene el argumento más limpio. Si tu equipo ya está en una pila que OSCAR soporta y necesitas ahorros agresivos de INT2 ahora, OSCAR se ve más fuerte. Si las sesiones de soporte o la memoria de agentes son el punto de dolor, EpiCache pertenece al diseño incluso si también cuantizas.
Por eso vuelvo siempre a la misma tesis contraria: la compresión de KV cache no es realmente una carrera. Es un problema de diseño de pila que se vendió como pelea de jaula.
Lecturas relacionadas
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation