Quantization de LLMs: Guía Completa GGUF vs GPTQ vs AWQ (Tutorial 2025)

Meta descripción: Guía completa de quantization de LLMs 2025. GGUF vs GPTQ vs AWQ vs BitsAndBytes. Aprende a reducir VRAM 75%, ejecutar Llama 70B en 24GB, benchmarks reales y código funcional.

¿Qué es la Quantization de LLMs y Por Qué Cambia Todo?

Imagina tener un modelo de 70 mil millones de parámetros que normalmente requiere 280 GB de VRAM funcionando perfectamente en tu RTX 4090 de 24GB. Eso es lo que hace posible la quantization.

La quantization (cuantización) es el proceso de reducir la precisión numérica de los pesos de un modelo de lenguaje (y también funciona para modelos de imagen como Stable Diffusion, que cubrimos en nuestra guía ComfyUI vs SD WebUI). En vez de usar números de 32 bits (FP32) o 16 bits (FP16), usamos 8, 4 o incluso 2 bits. El resultado:

• Reducción de tamaño del 50-87%: Un modelo de 140GB se convierte en 21GB
• Menos VRAM necesaria: Ejecuta modelos que antes eran imposibles en tu GPU
• Inferencia más rápida: Operaciones de menor precisión son más eficientes
• Democratización de LLMs: Modelos enterprise accesibles en hardware consumer

La Matemática Básica

La fórmula es simple:

VRAM necesaria = Parámetros × Bytes por Parámetro × 1.2 (overhead)

Ejemplo con Llama-70B:

Regla práctica: Aproximadamente 2GB de VRAM por cada 1B parámetros en FP16. Con quantization 4-bit, se reduce a ~0.5GB por 1B.

El Trade-off: Precisión vs Recursos

No hay magia: reducir bits significa perder algo de precisión. Pero con los métodos modernos de quantization (2024-2025), la pérdida es mínima:

• 8-bit: Prácticamente sin pérdida de calidad (perplexity +0.1%)
• 4-bit (bien hecho): Pérdida mínima (+0.5-2% en benchmarks)
• 3-bit: Pérdida notable pero usable (+2-5%)
• 2-bit: Degrada calidad (+5-15%), solo para casos extremos

La clave está en cómo se hace la quantization, no solo cuántos bits usas.

Formatos de Quantization: GGUF vs GPTQ vs AWQ vs Más

Existen múltiples formatos de quantization, cada uno optimizado para casos de uso diferentes. Aquí la guía definitiva:

GGUF (GPT-Generated Unified Format)

Lo que es:

• Sucesor de GGML (deprecado desde agosto 2023)
• Formato desarrollado por el equipo de llama.cpp
• Optimizado para CPU + GPU híbrido
• El formato más versátil y compatible

Ventajas:

• ✅ Funciona en CPU, GPU o mezcla de ambos
• ✅ Soporta todas las arquitecturas (Llama, Mistral, Qwen, Phi, etc.)
• ✅ Múltiples niveles de quantization (2-bit a 8-bit)
• ✅ Compatible con Ollama, LM Studio, llama.cpp, text-generation-webui
• ✅ Tiempos de carga rápidos (usa memory mapping)
• ✅ No requiere CUDA (funciona en Apple Silicon, AMD, CPU-only)

Limitaciones:

• ❌ Velocidad inferior a GPTQ/AWQ en GPUs NVIDIA potentes
• ❌ Requiere conversión desde formatos Hugging Face

Cuándo usar GGUF:

• Tienes GPU consumer (RTX 3060-4090)
• Quieres flexibilidad CPU/GPU
• Usas Mac con Apple Silicon
• Priorizar compatibilidad sobre máxima velocidad
• Usar con Ollama o LM Studio

Tipos de Quantization GGUF

GGUF ofrece 24 tipos diferentes de quantization. Los más importantes:

K-Quants (Recomendados):

Implementación técnica de Q4_K_M:

• Usa Q6_K para tensors sensibles (attention.wv, feed_forward.w2)
• Q4_K para el resto
• Balance inteligente automático entre compresión y calidad

IQ-Quants (Importance Quantization):

Usan una Importance Matrix para preservar pesos más críticos:

Nota: IQ-quants requieren que el modelo haya sido quantizado con una importance matrix. Busca modelos de bartowski en Hugging Face, que incluye imatrix en todos sus quants.

GPTQ (Gradient Post-Training Quantization)

Lo que es:

• Método que usa gradientes para minimizar error de quantization
• Optimizado para GPUs NVIDIA
• Ampliamente soportado en el ecosistema

Algoritmo técnico:

# Pseudocódigo simplificado
1. Para cada capa del modelo:
   2. Calcular matriz Hessiana aproximada (sensibilidad de pesos)
   3. Quantizar pesos en bloques (group_size=128)
   4. Minimizar error L2 entre pesos originales y quantizados
   5. Reordenar activaciones (desc_act) para mejor compresión

Ventajas:

• ✅ Excelente velocidad en GPUs NVIDIA (kernel exllamav2)
• ✅ Soporte para fine-tuning con LoRA/PEFT
• ✅ Compatible con vLLM, TGI, text-generation-webui
• ✅ Group size ajustable (trade-off tamaño/calidad)

Limitaciones:

• ❌ Solo GPUs NVIDIA (no AMD, no Apple, no CPU)
• ❌ Requiere dataset de calibración (128-1024 samples)
• ❌ Puede overfittear al dataset
• ❌ Más VRAM que AWQ en algunos casos

Parámetros importantes:

BaseQuantizeConfig(
    bits=4,              # 2, 3, 4, 8
    group_size=128,      # Bloques de pesos (-1 = sin agrupamiento)
    desc_act=False,      # True = mejor calidad, más lento
    damp_percent=0.01    # Dampening para estabilidad
)

Cuándo usar GPTQ:

• GPU NVIDIA (RTX 20xx+, no Maxwell)
• Priorizar velocidad de inferencia
• Trabajar con vLLM en producción
• Fine-tuning con LoRA después de quantizar

AWQ (Activation-aware Weight Quantization)

Lo que es:

• Método que protege canales de activación importantes
• Mejor accuracy que GPTQ al mismo nivel de bits
• Más reciente (2023) y moderno

Algoritmo diferenciador:

1. Analizar activaciones del modelo con datos de calibración
2. Identificar canales con activaciones >umbral
3. Escalar esos pesos para preservarlos mejor
4. Quantizar todo a 4-bit pero con pesos escalados protegidos

Resultado: Mejor perplexity y accuracy que GPTQ a 4-bit.

Ventajas:

• ✅ Mejor calidad que GPTQ (hasta 1% mejor en benchmarks)
• ✅ Menor uso de VRAM que GPTQ
• ✅ Soporte en vLLM, TGI, text-generation-webui
• ✅ Buen balance calidad/velocidad

Limitaciones:

• ❌ Solo GPUs NVIDIA
• ❌ Principalmente 4-bit (2-bit/3-bit limitado)
• ❌ Menos modelos pre-quantizados que GPTQ/GGUF
• ❌ No soporta fine-tuning post-quantization (aún)

Cuándo usar AWQ:

• Priorizar accuracy sobre todo
• Modelos para producción donde calidad importa
• VRAM limitada (usa menos que GPTQ)
• No necesitas fine-tuning después

Benchmark real (Llama-70B):

AWQ gana en accuracy y memoria, GPTQ en velocidad pura.

BitsAndBytes (8-bit, 4-bit NF4)

Lo que es:

• Biblioteca de quantization integrada en Transformers
• Popularizada por QLoRA (fine-tuning eficiente)
• Quantization dinámica en carga

Modos:

8-bit (LLM.int8()):

from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-70b-hf",
    load_in_8bit=True,  # Quantiza al cargar
    device_map="auto"
)

4-bit NF4 (Normal Float 4):

from transformers import BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_use_double_quant=True,  # Double quantization
    bnb_4bit_quant_type="nf4",       # Normal Float 4
    bnb_4bit_compute_dtype=torch.bfloat16
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-70b-hf",
    quantization_config=bnb_config
)

Ventajas:

• ✅ Integración perfecta con Hugging Face
• ✅ Ideal para QLoRA fine-tuning (entrenar modelos grandes con poca VRAM)
• ✅ No requiere conversión previa
• ✅ Double quantization (ahorra 0.37 bits/parámetro extra)

Limitaciones:

• ❌ Solo en RAM/VRAM (no guarda modelo quantizado)
• ❌ Slower que GPTQ/AWQ en inferencia pura
• ❌ No para servir modelos en producción

Cuándo usar BitsAndBytes:

• Fine-tuning con QLoRA (caso de uso principal)
• Experimentación rápida
• Cargar modelo grande para inference ocasional
• No necesitas velocidad máxima

EXL2 (ExLlamaV2)

Lo que es:

• Formato específico de text-generation-webui
• Kernel de inferencia ultra-rápido para NVIDIA
• Permite bits por peso variables (2.0-8.0 bits/peso granular)

Ventajas:

• ✅ Velocidad récord en RTX 40xx (14,000 t/s vs 7,500 GPTQ)
• ✅ Control granular de bits/peso
• ✅ Optimizado para generación de texto largo

Limitaciones:

• ❌ Solo text-generation-webui y tabbyAPI
• ❌ Pocos modelos pre-quantizados
• ❌ Ecosistema limitado

Cuándo usar:

• Usas text-generation-webui exclusivamente
• GPU RTX 30xx/40xx
• Priorizas velocidad máxima sobre compatibilidad

Tabla Comparativa Completa

Cómo Quantizar Tus Propios Modelos (Tutorial Paso a Paso)

Opción 1: Usar Modelos Pre-Quantizados (Recomendado)

La forma más fácil y rápida:

HuggingFace:

# Buscar modelos quantizados
# Filtro: "GGUF" o "GPTQ" o "AWQ" en el nombre
# Autores recomendados:
# - bartowski (GGUF con imatrix, actualizado 2024)
# - TheBloke (legacy pero extenso)
# - casperhansen (AWQ)

Ejemplos directos:

# Llama 3.1 70B GGUF Q4_K_M (bartowski)
huggingface-cli download \
  bartowski/Meta-Llama-3.1-70B-Instruct-GGUF \
  Meta-Llama-3.1-70B-Instruct-Q4_K_M.gguf

# Llama 3.1 70B GPTQ 4-bit
huggingface-cli download \
  meta-llama/Llama-3.1-70B-Instruct-GPTQ-4bit \
  --include "*.safetensors"

# Qwen 2.5 72B AWQ
huggingface-cli download \
  Qwen/Qwen2.5-72B-Instruct-AWQ \
  --include "*.safetensors"

Ollama (más fácil aún):

Si aún no conoces Ollama, te recomendamos leer nuestra guía comparativa entre Ollama y LM Studio para elegir la mejor herramienta para ejecutar LLMs locales.

# Descarga automática en formato GGUF optimizado
ollama pull llama3.1:70b-instruct-q4_K_M
ollama pull qwen2.5:72b-instruct-q4_0
ollama pull mixtral:8x7b-instruct-v0.1-q5_K_M

Opción 2: Quantizar a GGUF con llama.cpp

Paso 1: Instalar llama.cpp

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# Compilar con soporte CUDA (NVIDIA)
make LLAMA_CUDA=1

# O con Metal (Apple Silicon)
make LLAMA_METAL=1

# O solo CPU
make

Paso 2: Convertir modelo HF a GGUF FP16

# Descargar modelo original de HuggingFace
huggingface-cli download meta-llama/Llama-3.1-8B-Instruct \
  --local-dir models/llama-3.1-8b

# Convertir a GGUF FP16
python llama.cpp/convert_hf_to_gguf.py \
  models/llama-3.1-8b \
  --outfile models/llama-3.1-8b-f16.gguf \
  --outtype f16

Paso 3: Quantizar a nivel deseado

# Q4_K_M (recomendado para balance)
./llama.cpp/llama-quantize \
  models/llama-3.1-8b-f16.gguf \
  models/llama-3.1-8b-Q4_K_M.gguf \
  Q4_K_M

# Q5_K_M (máxima calidad)
./llama.cpp/llama-quantize \
  models/llama-3.1-8b-f16.gguf \
  models/llama-3.1-8b-Q5_K_M.gguf \
  Q5_K_M

# IQ4_XS (con importance matrix - requiere generar imatrix primero)
# Paso extra: generar importance matrix
./llama.cpp/llama-imatrix \
  -m models/llama-3.1-8b-f16.gguf \
  -f datasets/calibration.txt \
  -o models/llama-3.1-8b.imatrix

# Quantizar con imatrix
./llama.cpp/llama-quantize \
  models/llama-3.1-8b-f16.gguf \
  models/llama-3.1-8b-IQ4_XS.gguf \
  IQ4_XS \
  --imatrix models/llama-3.1-8b.imatrix

Tiempos esperados (Llama 8B en CPU i9-13900K):

• Conversión HF→GGUF: ~5 minutos
• Quantización Q4_K_M: ~3 minutos
• Generación imatrix: ~30 minutos (depende del dataset)
• Quantización con imatrix: ~5 minutos

Opción 3: Quantizar a GPTQ

Usar GPTQModel (reemplazo moderno de AutoGPTQ):

from gptqmodel import GPTQModel, QuantizeConfig
from transformers import AutoTokenizer

# Configuración de quantization
quantize_config = QuantizeConfig(
    bits=4,                      # 2, 3, 4, 8
    group_size=128,              # Tamaño de grupo
    desc_act=False,              # True = mejor calidad, más lento
    static_groups=False,
    sym=True,                    # Symmetric quantization
    damp_percent=0.01
)

# Cargar modelo
model = GPTQModel.from_pretrained(
    "meta-llama/Llama-3.1-8B-Instruct",
    quantize_config=quantize_config,
    device_map="auto"
)

# Cargar dataset de calibración
from datasets import load_dataset
dataset = load_dataset("wikitext", "wikitext-2-raw-v1", split="train")
calibration_data = [
    tokenizer(example["text"])
    for example in dataset.select(range(1024))
]

# Quantizar (tarda ~10-30 minutos según GPU y modelo)
model.quantize(calibration_data)

# Guardar
model.save_quantized("./llama-3.1-8b-gptq-4bit")
tokenizer.save_pretrained("./llama-3.1-8b-gptq-4bit")

# Subir a HuggingFace (opcional)
model.push_to_hub("tu-username/llama-3.1-8b-gptq-4bit")

Kernels disponibles:

# exllamav2 (default, más rápido para RTX 30xx/40xx)
from gptqmodel import exllamav2

# Marlin (para Ada/Ampere NVIDIA, aún más rápido)
quantize_config = QuantizeConfig(
    bits=4,
    group_size=128,
    format="marlin"  # Requiere GPU Ampere+ (RTX 30xx+)
)

Opción 4: Quantizar a AWQ

from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Llama-3.1-8B-Instruct"
quant_path = "llama-3.1-8b-awq-4bit"

# Cargar modelo
model = AutoAWQForCausalLM.from_pretrained(
    model_path,
    device_map="auto",
    safetensors=True
)
tokenizer = AutoTokenizer.from_pretrained(model_path)

# Configuración quantization
quant_config = {
    "zero_point": True,      # Zero-point quantization
    "q_group_size": 128,     # Group size
    "w_bit": 4,              # 4-bit
    "version": "GEMM"        # Kernel (GEMM o GEMV)
}

# Quantizar (tarda ~10-20 minutos)
model.quantize(
    tokenizer,
    quant_config=quant_config,
    calib_data="pileval"  # Dataset de calibración (pileval o wikitext)
)

# Guardar
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)

Casos de Uso Reales: RTX 3090 / 4090 / 5090

Caso 1: Llama 3.1 70B en RTX 4090 24GB

Problema: Llama-70B en FP16 requiere 140GB. Tu 4090 tiene 24GB.

Si estás montando tu homelab con GPUs de 24GB o más, consulta nuestra guía completa de homelab con GPU 24GB+ donde cubrimos hardware, refrigeración, y stack completo de herramientas IA.

Solución 1: GGUF Q4_K_M (Recomendada)

# Descargar modelo
ollama pull llama3.1:70b-instruct-q4_K_M

# O manualmente
huggingface-cli download \
  bartowski/Meta-Llama-3.1-70B-Instruct-GGUF \
  Meta-Llama-3.1-70B-Instruct-Q4_K_M.gguf

# Ejecutar con llama.cpp
./llama.cpp/llama-cli \
  -m models/Meta-Llama-3.1-70B-Instruct-Q4_K_M.gguf \
  -ngl 99  # Offload all layers to GPU

Memoria usada:

• VRAM: ~21GB (cabe perfecto)
• Velocidad: ~15-20 tokens/s (RTX 4090)
• Calidad: Perplexity +0.05 vs FP16 (casi imperceptible)

Solución 2: AWQ 4-bit (Mejor calidad)

huggingface-cli download \
  casperhansen/llama-3.1-70b-instruct-awq \
  --include "*.safetensors"

Usar con text-generation-webui o vLLM:

from vllm import LLM

model = LLM(
    "casperhansen/llama-3.1-70b-instruct-awq",
    quantization="awq",
    gpu_memory_utilization=0.90
)

Memoria usada:

• VRAM: ~23GB (al límite)
• Velocidad: ~18-22 tokens/s
• Calidad: Mejor que GGUF Q4_K_M (~1% mejor en benchmarks)

Solución 3: GGUF IQ2_M (VRAM mínima)

Para casos extremos donde necesitas dejar VRAM para otras cosas:

ollama pull llama3.1:70b-instruct-iq2_m

Memoria usada:

• VRAM: ~12GB (deja 12GB libres!)
• Velocidad: ~20-25 tokens/s
• Calidad: Degradada +5-10%, pero usable

Caso 2: Fine-tuning con QLoRA

Objetivo: Fine-tunar Llama 70B con dataset custom en 24GB VRAM.

Para una guía completa de fine-tuning para principiantes, consulta nuestro tutorial paso a paso de fine-tuning de LLMs donde explicamos LoRA, QLoRA, y todo el proceso desde cero.

from transformers import (
    AutoModelForCausalLM,
    AutoTokenizer,
    BitsAndBytesConfig,
    TrainingArguments
)
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer

# Configuración 4-bit
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16
)

# Cargar modelo quantizado
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-70B-Instruct",
    quantization_config=bnb_config,
    device_map="auto"
)

# Configuración LoRA
lora_config = LoraConfig(
    r=16,                  # Rank
    lora_alpha=32,         # Scaling
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

# Aplicar LoRA
model = get_peft_model(model, lora_config)

# Entrenar
trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=1,
        gradient_accumulation_steps=16,
        num_train_epochs=3,
        learning_rate=2e-4,
        fp16=False,
        bf16=True,
        logging_steps=10,
        output_dir="./llama-70b-qlora"
    )
)

trainer.train()

Memoria usada:

• VRAM: ~22GB durante entrenamiento
• Sin QLoRA: Imposible (requeriría >400GB)
• Resultado: Modelo fine-tuned guardado como adaptador LoRA (< 1GB)

Caso 3: Serving en Producción con vLLM

Setup: RTX 5090 48GB sirviendo Mixtral 8x7B

from vllm import LLM, SamplingParams

# Cargar modelo AWQ 4-bit
llm = LLM(
    "casperhansen/mixtral-8x7b-instruct-awq",
    quantization="awq",
    gpu_memory_utilization=0.85,
    max_num_seqs=8,          # Batch size
    max_model_len=32768      # Context length
)

# Generar respuestas
prompts = [
    "Explain quantum computing in simple terms.",
    "Write a Python function to calculate fibonacci.",
    # ... hasta 8 prompts en paralelo
]

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.95,
    max_tokens=512
)

outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    print(output.outputs[0].text)

Performance:

• VRAM: ~40GB (deja margen para KV cache)
• Throughput: ~450 tokens/s (batch de 8)
• Latencia: ~30ms time to first token
• Calidad: Equivalente a FP16 gracias a AWQ

Caso 4: Desarrollo Local Multi-Modelo

Objetivo: Tener 3 modelos cargados simultáneamente en 24GB.

Setup con Ollama:

(Para más detalles sobre configuración de Ollama, revisa nuestra comparativa Ollama vs LM Studio)

# Modelo 1: Llama 3.1 8B Q5_K_M (~5.5GB)
ollama pull llama3.1:8b-instruct-q5_K_M

# Modelo 2: Qwen 2.5 14B Q4_K_M (~8.5GB)
ollama pull qwen2.5:14b-instruct-q4_K_M

# Modelo 3: Phi-3 Mini 3.8B Q8_0 (~4GB)
ollama pull phi3:3.8b-mini-instruct-q8_0

# Total: ~18GB, quedan 6GB para KV cache

Usar con API:

# Terminal 1: Coding con Qwen
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:14b-instruct-q4_K_M",
  "prompt": "Write a Rust function for binary search"
}'

# Terminal 2: Chat general con Llama
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1:8b-instruct-q5_K_M",
  "prompt": "Explain the Monty Hall problem"
}'

# Terminal 3: Tasks rápidas con Phi-3
curl http://localhost:11434/api/generate -d '{
  "model": "phi3:3.8b-mini-instruct-q8_0",
  "prompt": "Summarize: [long text]"
}'

Ollama hace model swapping automático, descarga el menos usado si necesita VRAM.

Benchmarks Reales: Números que Importan

Perplexity (WikiText2) – Llama-7B

Observaciones:

• Q5_K_M: Calidad casi idéntica a FP16, solo 1.2% pérdida
• Q4_K_M: Sweet spot (2.6% pérdida es imperceptible en uso real)
• AWQ: Mejor calidad que GPTQ al mismo tamaño
• Q2_K: Solo para casos extremos, degrada mucho

Velocidad (Tokens/segundo) – Llama-70B

Hardware: RTX 4090 24GB

Hardware: RTX 3090 24GB

Hardware: M2 Ultra 192GB (CPU)

Conclusión: Apple Silicon con GGUF es sorprendentemente rápido gracias a unified memory y Metal.

Accuracy en Tareas Específicas – Llama-70B

Observación clave: AWQ mantiene mejor accuracy en todas las tareas. GGUF Q4_K_M está entre GPTQ y AWQ.

Troubleshooting: Problemas Comunes y Soluciones

Error: “CUDA out of memory” con modelo quantizado

Síntoma:

RuntimeError: CUDA out of memory. Tried to allocate 2.34 GiB
(GPU 0; 23.69 GiB total capacity; 21.45 GiB already allocated)

Causas y soluciones:

1. KV Cache demasiado grande

El KV cache escala con batch_size × sequence_length. Reducir:

# vLLM
llm = LLM(
    model="...",
    max_model_len=8192,  # Reducir de 32K
    gpu_memory_utilization=0.80  # Reducir de 0.90
)

# llama.cpp
./llama-cli -m model.gguf \
  -c 4096  # Context reducido de 8192

2. Batch size alto

# Reducir concurrent requests
max_num_seqs=1  # De 8 a 1

3. Quantization insuficiente

Si usas Q5_K_M en modelo grande, baja a Q4_K_M o IQ4_XS.

4. Overhead del sistema

# Liberar VRAM antes de cargar
sudo fuser -v /dev/nvidia0  # Ver procesos usando GPU
kill <PID>  # Matar procesos

# O reiniciar todo
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm

Error: “Illegal instruction (core dumped)” con GGUF

Causa: Modelo compilado para CPU con instrucciones que tu CPU no tiene (AVX2, AVX512).

Solución:

# Recompilar llama.cpp sin flags específicos
cd llama.cpp
make clean
make  # Sin LLAMA_CUDA ni flags AVX

# O usar binarios pre-compilados genéricos

Accuracy degradada más de lo esperado

Síntomas:

• Modelo Q4_K_M da respuestas notoriamente peores que FP16
• Alucinaciones frecuentes
• Lógica incorrecta en matemáticas

Causas:

1. Quantization sin importance matrix

Usar IQ-quants sin imatrix degrada calidad. Solución:

# Descargar modelos de bartowski (siempre incluye imatrix)
# O generar imatrix propio
./llama-imatrix -m model-fp16.gguf -f calibration.txt
./llama-quantize model-fp16.gguf model-iq4.gguf IQ4_XS --imatrix model.imatrix

2. Dataset de calibración pobre (GPTQ/AWQ)

# Usar dataset más representativo
from datasets import load_dataset

# Mal: solo Wikipedia
dataset = load_dataset("wikitext", "wikitext-2-raw-v1")

# Mejor: mezcla de dominios
dataset = load_dataset("Open-Orca/OpenOrca")  # Instrucciones
dataset += load_dataset("HuggingFaceH4/ultrachat_200k")  # Chat
dataset += load_dataset("codeparrot/github-code")  # Code

3. Group size muy grande

# GPTQ con group_size=-1 degrada mucho
quantize_config = QuantizeConfig(
    bits=4,
    group_size=128  # Cambiar de -1 a 128
)

Velocidad muy lenta (CPU bottleneck)

Síntomas:

• GPU al 30% uso
• Tokens/s mucho menor de lo esperado

Causas y soluciones:

1. Layers no offloaded a GPU

# llama.cpp: forzar todas las layers a GPU
./llama-cli -m model.gguf -ngl 99  # O número de layers del modelo

# Verificar que dice "llama_kv_cache_init: CUDA_Host..."
# Si dice "CUDA0" es correcto

2. Paginación a RAM (overflow)

# Verificar uso de VRAM
nvidia-smi

# Si usa >90%, reducir context o model size

3. Kernel lento

# GPTQ: cambiar de triton a exllamav2
from gptqmodel import exllamav2
# Al cargar automáticamente usa exllamav2 si está disponible

# O forzar Marlin (RTX 30xx+)
model = GPTQModel.from_quantized(
    "model-gptq",
    device="cuda:0",
    backend="marlin"  # Requiere Ampere+
)

Dónde Descargar Modelos Pre-Quantizados

HuggingFace (Principal fuente)

Autores recomendados 2024-2025:

1. bartowski (GGUF con imatrix, actualizado)

# Buscar
https://huggingface.co/bartowski

# Modelos:
# - Todos los Llama 3/3.1/3.2
# - Qwen 2.5
# - Mistral/Mixtral
# - Phi-3
# Siempre incluye: IQ-quants + K-quants con imatrix

2. TheBloke (Legacy, no actualizado desde 2024)

https://huggingface.co/TheBloke

# Enorme catálogo pero desactualizado
# Útil para modelos viejos
# No tiene Llama 3.1+

3. casperhansen (AWQ especialista)

https://huggingface.co/casperhansen

# Mejores AWQ para producción
# Modelos principales en 4-bit AWQ

4. Meta/Official repos (GPTQ oficial)

# Meta a veces lanza quantizations oficiales
https://huggingface.co/meta-llama/Llama-3.1-70B-Instruct-GPTQ-4bit

Cómo buscar:

# En HuggingFace web
# Filtros:
# - Buscar: "llama 3.1 70b GGUF"
# - Task: Text Generation
# - Sort by: Most downloads
# - Verificar fecha: Último mes (actualizado)

Ollama Library (Más fácil)

Para una comparativa completa entre Ollama y otras alternativas, lee nuestra guía Ollama vs LM Studio.

# Listar modelos disponibles
ollama list

# Buscar modelos
https://ollama.com/library

# Descargar con quantization específica
ollama pull llama3.1:70b-instruct-q4_K_M
ollama pull qwen2.5:72b-instruct-q5_K_M
ollama pull mixtral:8x7b-instruct-v0.1-q4_0

# Ver tags disponibles
ollama show llama3.1 --modelfile

Ventajas Ollama:

• Quantization optimizada automática
• Modelo + sistema prompt + parámetros en un solo archivo
• Pull/push como Docker
• API compatible con OpenAI

LM Studio (GUI friendly)

• Abrir LM Studio
• Buscar modelo (ej: “Llama 3.1 70B»)
• Filtrar por quantization (Q4_K_M, Q5_K_M)
• Download directo

LM Studio descarga de HuggingFace pero con UI más amigable.

Cómo Identificar Buen Quantization

Checklist:

✅ Modelo actualizado (últimos 3 meses)
✅ Autor conocido (bartowski, casperhansen, oficial)
✅ Incluye imatrix (para IQ-quants)
✅ Varios niveles (Q4, Q5, Q6 disponibles)
✅ Descripción detallada (config, dataset calibración)
✅ Descargas >100 (comunidad lo valida)
✅ Benchmark scores (si están disponibles)

❌ Red flags:

• Autor desconocido con 1 modelo
• Sin descripción de método
• Modelo de hace >6 meses con versión nueva disponible
• Solo 1 quantization (falta variedad)

Preguntas Frecuentes (FAQs)

¿Cuánta calidad pierdo con quantization 4-bit?

Con métodos modernos (Q4_K_M, AWQ 4-bit), 1-3% en benchmarks pero imperceptible en uso real.

Prueba práctica: La mayoría de usuarios no pueden distinguir entre FP16 y Q4_K_M en chat ciego. La diferencia aparece en:

• Matemáticas complejas (+2-4% error rate)
• Código muy preciso (+1-2% fallos)
• Razonamiento multi-step (+1-3% degradación)

Para uso general (chat, summarización, Q&A), Q4_K_M es indistinguible de FP16.

¿GGUF o GPTQ para mi RTX 4090?

GPTQ si:

• Priorizas velocidad máxima (18-22 t/s)
• Usas vLLM en producción
• Vas a fine-tunear con LoRA después

GGUF si:

• Quieres más opciones de quantization (IQ-quants)
• Usas Ollama o LM Studio
• Quieres flexibilidad CPU/GPU
• Modelo muy grande que necesita offload parcial a RAM

Para RTX 4090 con modelo 70B: GGUF Q4_K_M es la mejor opción (balance perfecto).

¿Puedo quantizar un modelo ya quantizado?

No, no funciona bien. Quantizar un modelo 8-bit a 4-bit degrada calidad más que quantizar FP16→4-bit directamente.

Siempre partir de FP16/BF16 original.

¿Qué quantization usar para fine-tuning?

BitsAndBytes 4-bit NF4 con QLoRA:

BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",  # Normal Float 4
    bnb_4bit_use_double_quant=True
)

No uses GGUF (no soporta fine-tuning). GPTQ soporta LoRA pero BitsAndBytes es más eficiente.

¿Cuánto VRAM necesito para modelo X?

Fórmula:

VRAM = (Parámetros × Bytes/param × 1.2) + KV_cache

Tabla rápida (con context 8K):

Para RTX 4090 24GB:

• 7B: Cualquier quantization
• 13B: Q4_K_M o superior
• 34B: IQ3_M máximo
• 70B: IQ2_M o Q4_K_M con offload parcial

¿Quantization afecta long context (128K tokens)?

Sí, el KV cache también se quantiza. Opciones:

1. KV cache quantization (llama.cpp):

./llama-cli -m model.gguf \
  -c 128000 \  # Context 128K
  --cache-type-k q8_0 \  # Key cache en 8-bit
  --cache-type-v q8_0    # Value cache en 8-bit

Ahorra ~50% VRAM del KV cache con pérdida mínima.

2. FP8 KV cache (vLLM):

llm = LLM(
    model="...",
    kv_cache_dtype="fp8",
    max_model_len=128000
)

Benchmark (Llama-70B, context 128K):

• KV cache FP16: ~60GB VRAM
• KV cache Q8: ~30GB VRAM
• KV cache FP8: ~22GB VRAM

¿Modelos quantizados son más lentos que FP16?

Depende del hardware:

GPU NVIDIA con kernels optimizados:

• GPTQ 4-bit: ~1.2x más rápido que FP16 (menos data movement)
• AWQ 4-bit: ~1.15x más rápido
• GGUF: Similar o ligeramente más lento

CPU:

• GGUF Q4: 2-3x más rápido que FP16 (cabe en cache)

Apple Silicon:

• GGUF Q4/Q5 con Metal: Más rápido que FP16 por unified memory

La quantization suele ser más rápida o igual, no más lenta.

¿Puedo servir modelos quantizados en producción?

Sí, es la práctica estándar. Empresas usan:

• OpenAI: Usa quantization interna (no confirmado pero probable)
• Anthropic: Usa quantization para Claude
• Meta: Recomienda GPTQ/AWQ para deploy de Llama

Setup producción típico:

# vLLM con AWQ (mejor calidad)
from vllm import LLM

llm = LLM(
    "modelo-awq-4bit",
    quantization="awq",
    tensor_parallel_size=2,  # Multi-GPU
    gpu_memory_utilization=0.85
)

Ventajas producción:

• Menor costo (GPUs más pequeñas)
• Mayor throughput (más modelos por GPU)
• Latencia similar o mejor

¿Qué es “importance matrix” (imatrix)?

Una matriz que indica qué pesos son más sensibles y deben preservarse con mayor precisión.

Cómo funciona:

# 1. Generar imatrix con dataset representativo
./llama-imatrix \
  -m model-fp16.gguf \
  -f calibration-data.txt \  # Dataset importante
  -o model.imatrix

# 2. Quantizar usando imatrix
./llama-quantize \
  model-fp16.gguf \
  model-iq4.gguf \
  IQ4_XS \
  --imatrix model.imatrix

Resultado: IQ4_XS con imatrix > Q4_K_M sin imatrix en calidad.

Buscar modelos: bartowski siempre incluye imatrix.

¿Se puede convertir GPTQ a GGUF o viceversa?

GPTQ/AWQ → GGUF: Posible pero no recomendado.

# De-quantizar primero a FP16 (requiere VRAM completa)
python dequantize.py modelo-gptq → modelo-fp16

# Luego convertir
python convert_hf_to_gguf.py modelo-fp16
./llama-quantize ... Q4_K_M

Mejor: Descargar GGUF original desde HuggingFace.

GGUF → GPTQ: No hay herramienta standard.

¿Quantization funciona en AMD GPUs?

Limitado:

• GGUF: ✅ Sí, vía ROCm (compilar llama.cpp con HIPBLAS)
• GPTQ: ❌ No, kernels solo CUDA
• AWQ: ❌ No, solo CUDA
• BitsAndBytes: ⚠️ Soporte experimental ROCm

Para AMD: GGUF es la única opción real en 2024-2025.

# Compilar llama.cpp para AMD
git clone https://github.com/ggerganov/llama.cpp
make LLAMA_HIPBLAS=1  # Para ROCm/AMD

./llama-cli -m model.gguf -ngl 99  # Offload a AMD GPU

¿Es legal descargar y quantizar modelos?

Depende de la licencia del modelo:

• Llama 3.1: ✅ Comercial OK (Meta Community License)
• Qwen 2.5: ✅ Apache 2.0 (totalmente libre)
• Mistral/Mixtral: ✅ Apache 2.0
• Gemma: ✅ Comercial OK con restricciones
• Claude/GPT-4: ❌ No disponibles para self-host

Quantizar: Si tienes derecho a usar el modelo original, puedes quantizarlo.

Distribuir quantizations: Mismo license que modelo original.

Conclusión: Tu Guía Rápida de Decisión

Por Caso de Uso

Quiero ejecutar Llama 70B en mi RTX 4090:
→ GGUF Q4_K_M (balance perfecto)

Quiero la mejor calidad posible en 24GB:
→ AWQ 4-bit (mejor accuracy que GPTQ)

Quiero servir modelos en producción con vLLM:
→ AWQ 4-bit o GPTQ 4-bit con kernel Marlin

Quiero fine-tunear modelo grande con poca VRAM:
→ BitsAndBytes 4-bit NF4 con QLoRA (tutorial completo de fine-tuning aquí)

Tengo Mac con Apple Silicon:
→ GGUF Q4_K_M o Q5_K_M (Metal es muy rápido)

Tengo GPU AMD:
→ GGUF con ROCm (única opción real)

Quiero experimentar rápido con Ollama:
→ ollama pull modelo:70b-instruct-q4_K_M

Necesito máxima velocidad en RTX 40xx:
→ GPTQ 4-bit con kernel exllamav2

Por Nivel de Quantization

8-bit (Q8_0): Prácticamente sin pérdida, usa si tienes VRAM de sobra

6-bit (Q6_K): Indistinguible de FP16, excelente opción

5-bit (Q5_K_M): Calidad excelente, solo 1% pérdida

4-bit (Q4_K_M / AWQ / GPTQ): Sweet spot universal

3-bit (IQ3_M): Usable, degradación notable pero aceptable

2-bit (IQ2_M): Solo casos extremos, calidad comprometida

Herramientas Recomendadas

Quantizar GGUF: llama.cpp (standard de facto)

Quantizar GPTQ: GPTQModel (reemplazo moderno de AutoGPTQ)

Quantizar AWQ: AutoAWQ (oficial)

Fine-tuning: BitsAndBytes + PEFT (QLoRA)

Serving producción: vLLM con AWQ

Desarrollo local: Ollama (más fácil)

Recursos Finales

Documentación oficial:

• llama.cpp: https://github.com/ggerganov/llama.cpp
• GPTQ: https://github.com/IST-DASLab/gptq
• AWQ: https://github.com/mit-han-lab/llm-awq
• vLLM: https://docs.vllm.ai

Modelos pre-quantizados:

• bartowski en HF: https://huggingface.co/bartowski
• Ollama library: https://ollama.com/library

Benchmarks:

• Open LLM Leaderboard: https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard

La quantization ha democratizado los LLMs grandes. Lo que antes requería data centers enterprise ahora corre en tu desktop. Con esta guía, tienes todo lo necesario para empezar.

Siguiente paso: Descarga Ollama, haz ollama pull llama3.1:70b-instruct-q4_K_M, y experimenta. La teoría está bien, pero ejecutar un 70B en tu GPU es otra experiencia completamente.

¡Bienvenido al futuro de los LLMs locales!