Cuantización de modelos en Ollama: formato GGUF y pérdida de precisión

RTX 3060, 12 GB VRAM, ¿Llama 3 70B? CUDA out of memory — ni 14B arranca. La cuantización comprime 70B de 140 GB a ~40 GB. ¿Cuánta precisión se pierde?

Red Hat con 500.000 evaluaciones: 8-bit recupera >99%, 4-bit 98,9%. En el día a día casi imperceptible.

Este artículo explica GGUF, niveles de cuantización y elección en GPU de consumo.

1. ¿Qué es la cuantización?

Como comprimir una foto HD a unos cientos de KB para WhatsApp: hay pérdida, pero se entiende.

1.1 Esencia

Los pesos del modelo suelen ir en FP16 (16 bits). Un 7B en FP16 ≈ 14 GB (2 bytes por parámetro).

La cuantización baja la precisión: INT4 ≈ 0,5 byte por parámetro → ~3,5 GB para 7B.

FP16 es «decimal muy fino» (0,12345678); INT4 es «entero aproximado» (3). Se pierde precisión, queda información.

1.2 Compresión

Datos Will It Run AI, 7B:

Nivel	VRAM	Ahorro	Calidad
F16	14,0 GB	Base	Óptima
Q8_0	7,4 GB	47%	Excellent
Q5_K_M	4,8 GB	65%	Good
Q4_K_M	3,9 GB	72%	Acceptable
Q3_K_M	3,1 GB	78%	Poor
Q2_K	2,6 GB	81%	Very Poor

Q4_K_M ahorra 72%: un modelo de 14 GB en una GPU de 4 GB.

La primera vez que corrí 7B en RTX 3060 fue como turbo en un coche viejo: antes solo 3B, ahora 7B.

1.3 ¿Cuál es el costo?

• Pérdida de precisión numérica
• Pérdida de continuidad (INT4 discreto vs FP16 continuo)

¿Cuánto? Los datos de Red Hat más adelante.

2. Formato GGUF

Al descargar modelos cuantizados suele verse .gguf.

2.1 Qué es

GPT-Generated Unified Format — empaquetado para inferencia, de llama.cpp.

Ventajas:

Un solo archivo — pesos, tokenizer, config en un .gguf.

mmap — mapeo a memoria, lectura bajo demanda. 70B: segundos vs decenas de segundos cargando todo.

Multiplataforma — Ollama, LM Studio, llama.cpp, KoboldCPP.

2.2 GGUF vs otros

Formato	Uso	Característica	Herramientas
GGUF	Inferencia	Un archivo, cuantización	Ollama, LM Studio, llama.cpp
Safetensors	Entrenamiento	Sin pickle	PyTorch, HF
GGML	Inferencia (viejo)	Obsoleto	llama.cpp antiguo
PyTorch	Entrenamiento	Flexible, menos seguro	PyTorch

Para inferencia: GGUF.

2.3 Ollama y GGUF

Ollama usa llama.cpp; solo GGUF. ollama pull llama3 descarga GGUF, por defecto Q4_K_M.

Más adelante: otros niveles desde Hugging Face.

3. Niveles Q2 a Q8

3.1 Tabla (Will It Run AI, Llama 3 8B)

Nivel	VRAM	Calidad	Escenario
Q8_0	~8,5 GB	Excellent	VRAM holgada
Q6_K	~6,1 GB	Very Good	Equilibrio
Q5_K_M	~5,3 GB	Good	Recomendado
Q5_K_S	~5,0 GB	Good	Más agresivo
Q4_K_M	~4,4 GB	Acceptable	Mainstream
Q4_K_S	~4,1 GB	Acceptable	Más agresivo
Q3_K_M	~3,5 GB	Poor	Último recurso
Q3_K_S	~3,2 GB	Poor	No recomendado
Q2_K	~2,7 GB	Very Poor	Evitar

3.2 K-quant y S/M/L

K = k-quant, precisión mixta por capas.

• S: más compresión, más pérdida
• M: equilibrio (recomendado)
• L: más calidad, más tamaño

3.3 Sensibilidad por tarea (Will It Run AI)

1. Coding: muy sensible → Q5_K_M+
2. Reasoning/Math: muy sensible → Q5_K_M+
3. Creative writing: media → Q4_K_M OK
4. Chat: baja → Q4_K_M OK
5. Summarization: baja → Q4_K_M OK

Experiencia: Q4_K_M en código a veces nombres raros o lógica rota; Q5_K_M mejora. En chat, poca diferencia Q4 vs Q5.

4. Verdad sobre pérdida de precisión

4.1 Estudio Red Hat

Octubre 2024: «We ran over half a million evaluations on quantized LLMs».

"We ran over half a million evaluations on quantized LLMs to determine the impact of quantization on model quality across multiple benchmarks and real-world tasks."

Benchmarks académicos (MMLU, HellaSwag, ARC), tareas reales (Arena-Hard, HumanEval), similitud (ROUGE, BERTScore).

4.2 Recuperación de precisión

Nivel	Recuperación media	Confianza
8-bit	>99%	IC 95% solapa BF16
4-bit	98,9%	Ligeramente bajo baseline
3-bit	~96%	Caída visible pero usable

4.3 Grande vs pequeño

Modelos grandes toleran más cuantización: 70B Q4 casi como original; 7B Q4 baja más.

• Grande → Q4 suele bastar
• Pequeño → Q5+ si hay VRAM

4.4 Malentendidos

Muchos dicen «el modelo se volvió tonto». Red Hat: a menudo el método de evaluación — un solo benchmark (MMLU -5%) no refleja uso real.

En chat, código y resumen, cuantizado ≈ original. Diferencias en benchmarks extremos.

4.5 Experiencia propia

Q4_K_M fluido en chat y resumen; en código errores puntuales, no «tonto». Q5_K_M corrige la mayoría.

5. Práctica en Ollama

5.1 Por defecto

ollama pull llama3 → Llama 3 8B Q4_K_M (equilibrio oficial).

5.2 Desde Hugging Face

ollama run hf.co/{usuario}/{repo}:{nivel}

Ejemplo Q8_0:

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

Repositorios: bartowski, MaziyarPanahi (70B+), TheBloke (parcialmente detenido).

5.3 Por VRAM (NVIDIA)

VRAM	Modelo	Cuantización	Nota
4 GB	3B	Q4_K_M	Justo
6 GB	7B	Q4_K_M (ajustado)	3B Q5_K_M más estable
8 GB	7B	Q5_K_M	8B Q4_K_M con margen
12 GB	7B	Q6_K / Q8_0	14B Q5_K_M
16 GB	14B	Q6_K	7B Q8_0; 30B MoE Q4_K_M
24 GB	30B+	Q5_K_M	70B Q4_K_M

Reserva 10-20% para KV cache y contexto largo. MoE (Mixtral 8x7B) usa menos RAM activa que parámetros totales.

5.4 Pequeño alta cuantización > grande baja

8 GB VRAM:

• 7B Q5_K_M (~5,3 GB)
• 13B Q2_K (~5,0 GB)

Gana 7B Q5_K_M: Q2 degrada demasiado.

5.5 RTX 3060 12 GB

• Chat diario: Llama 3.2 3B Q8_0
• Código: Llama 3 8B Q5_K_M
• Probar grande: Mixtral 8x7B Q4_K_M

Conclusión

La cuantización hace viable el LLM local: 70B de 140 GB a ~40 GB.

Red Hat: 8-bit casi sin pérdida, 4-bit 98,9%. Uso normal: imperceptible.

Reglas:

• Máxima cuantización dentro de VRAM
• Código Q5+, chat Q4
• Modelos grandes toleran Q4 más bajo

Prueba Q5_K_M primero — +20% RAM vs Q4, calidad notablemente mejor.

Más en la serie: Introducción a Ollama y Modelfile.

La cuantización equilibra memoria y calidad. Domínala y tu GPU hará más.