Cuantización con números: calidad vs VRAM vs velocidad

Un modelo que pesa 40 GB corriendo en una GPU de 16 GB. Eso no es un truco de marketing: es cuantización, y en un experimento documentado por Hugging Face fue exactamente el resultado — GPT-NeoX-20B (40 GB) cabiendo en 16 GB usando 4 bits, cuantización anidada y cómputo en bfloat16. - Source: Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA - Hugging Face

Esta pieza son los números de la cuantización: cuánto ahorras, qué pierdes y cómo elegir sin adivinar.

Qué es cuantizar

"La cuantización intercambia precisión del modelo por menor huella de memoria, permitiendo correr modelos grandes en más dispositivos." - Source: Quantization - vLLM Docs

El detalle que casi nadie menciona: los pesos se comprimen, pero el cálculo sigue ocurriendo en 16 o 32 bits. No estás corriendo un modelo "peor" en cada operación; estás guardándolo más chico y descomprimiéndolo al usarlo. - Source: Hugging Face

Los números que importan

Del trabajo de QLoRA (referencia canónica del tema):

Permite afinar (fine-tuning) un modelo de 33B en una GPU de 24 GB y uno de 65B en una de 46 GB.
GPT-NeoX-20B (40 GB) entró completo en 4 bits en una GPU de 16 GB.
La cuantización anidada (double quantization) ahorra 0.4 bits adicionales por parámetro.
Con Llama 7B (14 GB en FP16) y Llama 13B (27 GB en FP16) sobre una T4 de 16 GB: el 13B no cabía sin cuantizar; con NF4 + gradient checkpointing sí cabía.

Fuente: Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA - Hugging Face

Ese último punto es el resumen más honesto del tema: la cuantización no te da velocidad gratis, te da capacidad de que entre.

Los sabores (y cuál elegir)

NF4 vs FP4: el paper recomienda NF4 (normalized float 4) por mejor rendimiento en la práctica.
Double quantization: un segundo paso que cuantiza las constantes de cuantización; útil cuando la memoria es el problema.
Compute dtype: los pesos van en 4 bits, pero las operaciones se hacen en 16 o 32 bits; usar un compute dtype de 16 bits suele ser más rápido.
Formatos actuales: vLLM soporta hoy AutoAWQ, BitsAndBytes, GPTQModel, LLM Compressor (FP8 W8A8, INT4 W4A16, INT8), TorchAO, y también cuantización de la caché KV. - Source: Quantization - vLLM Docs

Lo que pierdes (y cómo saberlo)

En el trabajo de referencia, el fine-tuning con 4 bits igualó al de 16 bits en su rango de experimentos. En inferencia, esa garantía no es universal: depende del modelo, del formato y de tu tarea. La regla: cuantizar es barato; suponer es caro.

Por eso la cuantización se mide con evals: comparas la versión FP16 y la cuantizada contra los mismos casos, y decides con el número, no con la intuición.

Errores comunes

Cuantizar sin medir la calidad. "Se ve bien" no es una eval.
Creer que siempre es más rápido. Menos memoria no implica más tokens/s; a veces el overhead de descomprimir cuesta.
Asumir que funciona en tu hardware sin revisar. En el caso de bitsandbytes, requiere GPU (no CPU) y CUDA ≥ 11.2; y cada formato tiene su tabla de compatibilidad por arquitectura (Volta, Turing, Ampere, Ada, Hopper…). → Quantization - vLLM Docs
Cuantizar la caché KV sin pensarlo: afecta la precisión del contexto, no solo la memoria.

Cómo elegir (mis reglas)

Primero la memoria: si el modelo no cabe en FP16, cuantiza a 8 bits.
Si sigue sin caber, baja a 4 bits (NF4) y suma double quantization si aprietas.
Después la calidad: corre tus evals en FP16 y en cuantizado; compara.
Y al final la velocidad: mide tokens/s; si el cuantizado es más lento y la memoria no era el cuello de botella, retrocede.
Revisa la tabla de tu hardware antes de comprometerte con un formato.

El resto del camino de inferencia está en Inferencia local: de LM Studio a vLLM, ¿Qué hardware necesitas? y la guía Inference Engineering.

¿Cuántizas por necesidad de memoria o por velocidad? Cuéntame en los comentarios con qué modelo y cuánto ahorraste.