Cuantización sin mitos: qué ganas, qué pierdes y qué medir

Qué hace la cuantización, con un ejemplo

Un modelo son miles de millones de pesos; en BF16 cada uno ocupa 16 bits, es decir 2 bytes. Cuantizar es guardar cada peso con menos bits (con 4 bits, uno de 16 valores posibles) más una escala compartida por cada bloque pequeño de pesos. Los formatos difieren en el bloque, las escalas y las capas que conservan más bits.

memoria de pesos (GB) ≈ parámetros (miles de millones) × bits por peso ÷ 8
 8B en BF16:     8 × 16 ÷ 8  = 16 GB
 8B en Q4_K_M:   8 × 4,9 ÷ 8 ≈ 4,9 GB
70B en Q4_K_M:  70 × 4,9 ÷ 8 ≈ 43 GB

Cuadra con llama.cpp: Q4_K_M promedia 4,89 bits por peso y Llama 3.1 70B queda en 43,1 GB. Con un solo usuario, leer los pesos de la memoria es el cuello de botella, así que la velocidad sigue al tamaño: de 29 a 72 tokens por segundo entre F16 y Q4_K_M. A la fórmula le faltan la caché KV y la calidad.

El mapa de formatos: qué corre dónde

Tu motor y tu hardware eligen el formato antes que cualquier clasificación.

Los nombres son recetas: Q4_K_M es una mezcla "medium" de 4 bits que da 6 bits a algunos tensores sensibles, y los i-quants con matriz de importancia (imatrix) usan texto de calibración para decidir dónde duele más el redondeo. En GPU, los archivados AutoGPTQ y AutoAWQ dieron paso a GPTQModel y a llm-compressor de vLLM (v7.5.0 y v0.14.0, septiembre de 2026); ExLlamaV3 (v1.5.2) reemplazó a ExLlamaV2, aunque su servidor, TabbyAPI, se define como un proyecto de hobby.

Cuánta calidad se pierde: la evidencia

La perplejidad dice poco; la divergencia frente al original y las respuestas que cambian dicen más.

Los promedios esconden el daño: en Accuracy is Not All You Need (Microsoft Research, 2024), esquemas que movían la precisión entre 0 % y 2 % cambiaban hasta el 13,6 % de las respuestas. El tamaño también pesa: en el estudio de ACL 2025 Give Me BF16 or Give Me Death?, los pesos en 4 bits conservaban el 99,5 % del puntaje de un modelo de razonamiento de 32B, pero el 93,5 % en uno de 1,5B.

Para nosotros, el idioma es lo que más pesa. El estudio de Cohere sobre modelos multilingües cuantizados (Findings of EMNLP 2024) encontró que, en un modelo de 103B con 4 bits, las métricas automáticas mostraban una caída del 0,3 % en francés y los evaluadores humanos, del 16,6 %.

Por debajo de 4 bits la curva se quiebra, y Unsloth desaconseja 1 bit para agentes: entran en bucle y rompen las llamadas a herramientas. A igual memoria, un modelo más grande en 4 o 5 bits suele ganar: en las pruebas de Unsloth, Gemma 3 27B en Q4_K_M (15,4 GB) marca 71,2 % en MMLU, frente a 67,2 % de Gemma 3 12B en BF16 (unos 24 GB).

FP8, FP4 y los modelos que ya vienen cuantizados

En las GPU recientes el formato está en el silicio, y cada vez más modelos se entrenan para él.

FP8 es la opción segura en servidores: el mismo estudio de ACL 2025 (más de 500.000 evaluaciones sobre Llama 3.1) lo encontró prácticamente sin pérdida en todos los tamaños, con INT8 perdiendo entre 1 % y 3 %. vLLM habla de la mitad de memoria y hasta 1,6 veces más rendimiento, pero calcular en FP8 exige Ada, Hopper o Blackwell; una A100 solo corre checkpoints FP8 como pesos de 8 bits.

MXFP4 y NVFP4 son formatos de coma flotante de 4 bits: MXFP4 comparte una escala potencia de dos entre 32 valores (4,25 bits por peso) y NVFP4, de NVIDIA, una escala FP8 más fina cada 16 (4,5 bits). NVIDIA reporta una degradación de 1 % o menos al pasar DeepSeek-R1-0528 de FP8 a NVFP4. Solo Blackwell acelera NVFP4; MXFP4 también se acelera en la MI355X de AMD.

Las versiones nativas cambian las reglas. OpenAI publicó gpt-oss (5 de agosto de 2025) con los pesos de expertos en MXFP4, así que el 120b cabe en una GPU de 80 GB, y sus puntajes publicados son los del modelo cuantizado. Kimi K2 Thinking usa INT4 nativo, DeepSeek-V4 (abril de 2026) trae expertos en FP4 y la versión de Gemma 4 con entrenamiento consciente de la cuantización (QAT, 5 de junio de 2026) lleva el 31B de 69,9 GB a 17,5 GB.

La caché KV: la memoria que nadie presupuesta

Con contextos largos, la memoria de trabajo de la conversación puede pesar más que el modelo.

Cada token del contexto guarda claves y valores en cada capa de atención; el tamaño sale del config.json del modelo:

KV por token = 2 × capas × cabezas KV × dimensión de cabeza × bytes por valor
Qwen3-32B, 16 bits: 2 × 64 × 8 × 128 × 2 B = 256 KiB
32.768 tokens ≈ 8 GiB, 131.072 tokens ≈ 32 GiB (por petición)

La arquitectura cambia el resultado: gpt-oss-120b, con capas de ventana deslizante, necesita 36 KiB por token, y Qwen3.8-27B, con capas de atención lineal, 64 KiB. Cada petición en paralelo lleva su propia caché, así que la memoria crece con los slots en paralelo multiplicados por el contexto, como advierte Ollama.

Cuantizar la caché es la siguiente palanca: q8_0 o q4_0 en Ollama (OLLAMA_KV_CACHE_TYPE) y llama-server (--cache-type-k, --cache-type-v), FP8 en vLLM (--kv-cache-dtype). Un estudio de COLM 2025 halló sin pérdida una caché de 4 bits en modelos de 14B y 32B, pero una de 3 bits costaba más del 5 % en los de 1,5B y 7B, y recomienda 8 bits; Unsloth vio degradarse las respuestas con 4 bits.

Qué formato para qué hardware

Nuestros puntos de partida a septiembre de 2026; decide tu propia evaluación.

Las filas de servidor siguen el estudio de ACL 2025: 4 bits rinde más cuando pocos usuarios esperan y 8 bits gana con batching continuo. En Mac y DGX Spark manda el ancho de banda, así que los modelos de mezcla de expertos (MoE) con pocos parámetros activos corren mucho más rápido. Más en hardware para IA local en 2026 y del portátil al servidor.

Cómo validar un cuantizado con tus propias tareas

Medio día de pruebas evita semanas de fallas silenciosas.

1. Fija un set de evaluación con trabajo real y respuestas esperadas. En Slash usamos 30 prompts fijos por cliente en español, inglés y francés (método en nuestra guía de evaluaciones de LLM).
2. Define una referencia: el mismo modelo en BF16 o FP8, o la versión nativa, con decodificación greedy.
3. Mide la KLD y las respuestas que cambian sobre tus textos, por tarea y por idioma, no sobre el texto de calibración: Unsloth advierte que eso infla la calidad.
4. Lee el español y el francés a mano: tildes, concordancia, registro (tú o usted, vous), saltos al inglés.
5. Prueba las llamadas a herramientas y el JSON con la plantilla de chat de producción, validando cada salida contra su esquema.
6. Prueba el contexto largo con la caché KV de producción, y registra hash, tipo de cuantizado, versión del motor y plantilla para repetir todo cuando algo cambie.

Cinco errores comunes

• La plantilla de chat equivocada. Un GGUF trae su propia plantilla Jinja, que llama-server aplica por defecto. Si no corresponde al formato de entrenamiento, las respuestas se degradan sin error visible y las llamadas a herramientas fallan primero. Una plantilla también puede esconder instrucciones (Pillar Security, 2025): revísala como código.
• Cuantizar de más los modelos pequeños. IQ1_S lleva la perplejidad de Llama 3 8B de 6,2 a 60,7. Por debajo de 8B, quédate en 4 bits o más.
• Olvidar el contexto por defecto. Según Ollama, con menos de 24 GiB de VRAM usa 4K tokens: un documento largo no cabe hasta que lo subas.
• Recuantizar lo ya cuantizado: pesos nativos MXFP4 o INT4, o un GGUF hecho desde un checkpoint cuantizado en vez del BF16. Y deja el proyector de visión (mmproj) en BF16 o Q8, como aconseja llama.cpp.
• Confiar en el número de otro. Una perplejidad medida con otro texto y otro motor dice poco de tu caso. Para elegir primero el modelo, mira los modelos de pesos abiertos en 2026.