¿Funciona realmente la cuantización de KV cache a 2 bits sin convertir tu modelo en un desastre divagante? Sí, pero solo si dejas de fingir que las transformaciones ciegas a los datos son suficientes para salvar tu VRAM.
Para cualquiera que ejecute pesos locales, el KV cache es el muro invisible. Puedes cuantizar los pesos del modelo a 4 bits o incluso a 2 bits para que quepa en la tarjeta, pero en el momento en que empiezas a empujar la ventana de contexto hacia los 32k o 128k tokens, el KV cache se infla y devora cada byte restante de memoria. Together AI intenta solucionar esto con OSCAR, que reduce el KV cache a INT2.
Es un poco como intentar meter un colchón king size en un Mini Cooper: puedes hacerlo, pero tendrás que doblar las cosas de formas que se sienten fundamentalmente incorrectas. El truco aquí es la rotación «Attention-Aware». En lugar de usar una transformación de Hadamard genérica para suavizar los valores atípicos antes de la cuantización, OSCAR analiza la covarianza espectral real de las cabezas de atención. Deriva rotaciones específicas para las claves y los valores que realmente respetan los datos.
En teoría, sí. Si estás ejecutando un modelo de tamaño medio—piensa en Llama 3.3 o una variante de Qwen 2.5—el KV cache suele convertirse en el cuello de botella principal mucho antes que los pesos. Al comprimir el cache a 2 bits, estás cuadruplicando efectivamente la cantidad de contexto que puedes meter en la misma huella de VRAM en comparación con FP16. Para una 3090 o 4090 con 24 GB de VRAM, esto es la diferencia entre recibir un error Out-Of-Memory (OOM) a los 16k tokens y poder procesar realmente un manual técnico completo.
Sin embargo, la fricción del mundo real proviene de la precomputación. Dado que OSCAR es «offline», necesitas calcular esas matrices de rotación antes de empezar a servir el modelo. (Lo cual es un intercambio justo por las ganancias de memoria, pero añade un paso al pipeline). Si estás usando un Mac M3 Ultra con memoria unificada masiva, quizás no te importe tanto, pero para nosotros, que luchamos por cada megabyte en hardware de NVIDIA, esta es la única vía a seguir.
La mayoría de los métodos de «rotación» para cuantización son básicamente simples mezclas matemáticas. Intentan distribuir los valores de alta varianza a lo largo del vector para que una cuantización de 2 bits o 4 bits no pierda demasiada información. El problema es que estos métodos son ciegos a los datos; tratan cada cabeza y cada modelo por igual. Es un instrumento demasiado tosco.
OSCAR adopta un enfoque más quirúrgico analizando la covarianza real de la atención. Al adaptar la rotación a las propiedades espectrales específicas de las claves y los valores, preserva la «señal» que el modelo necesita realmente para mantener la coherencia a largas distancias. O quizás no la preserva por completo: hemos visto afirmaciones de cuantización «lossless» que se desmoronan en el momento en que le pides al modelo que recupere un dato concreto del medio de un prompt de 100k tokens. Aun así, es un enfoque significativamente más inteligente que el estándar actual de la industria.
Aquí es donde la teoría se enfrenta a la realidad. Ahora mismo, la mayoría de nosotros vivimos en el mundo de llama.cpp, Ollama o vLLM. Para que OSCAR importe, necesita salir de un artículo de investigación y entrar en un kernel que no arruine tus tokens por segundo. Si se integra en vLLM o sglang, se convierte en una victoria masiva para cualquiera que sirva modelos de contexto largo con un presupuesto ajustado.
Ya estamos viendo un cambio hacia una cuantización más agresiva en la jerarquía de los pesos abiertos. Aunque Llama 3.3 es una bestia, sus requisitos de memoria para contextos largos son exigentes. Si OSCAR se convierte en el estándar para el cache INT2, reduce efectivamente el umbral mínimo de hardware necesario para la IA local de «contexto largo». Espero ver una implementación funcional de OSCAR en un motor de inferencia importante para el Q4.
Un mal necesario para la comunidad de despliegue local.
