Cuantización de modelos y llama.cpp en tu portátil

Actualizado: 2026-07-07

Gracias a llama.cpp^[1] y las técnicas de cuantización, puedes correr Llama 2 13B en un portátil con 16 GB de RAM sin GPU dedicada. Cubrimos cómo funciona la cuantización, qué calidad pierdes (y cuál no), y cuándo esto es opción real frente a APIs gestionadas.

Puntos clave

• La cuantización reduce la precisión de los pesos del modelo (de float16 a Q4/Q5/Q8), reduciendo tamaño y acelerando inferencia con pérdida de calidad menor de lo que la intuición sugiere.

• Llama 2 13B en Q4_K_M ocupa ~7.5 GB frente a los 26 GB en float16, así que cabe en 16 GB de RAM.

• Q4_K_M es el nivel más popular: balance correcto entre calidad y tamaño. Q5_K_M da más calidad si tienes RAM de sobra.

• GGUF es el formato estándar desde agosto de 2023; sustituye al GGML anterior.

• Los casos de uso estrella son privacidad crítica, coste a escala y edge sin conectividad garantizada.

El problema y la idea

Un modelo Llama 2 13B en precisión float16 ocupa unos 26 GB de memoria. Sin GPU con esa cantidad de VRAM, descartado. Y aunque tengas RAM suficiente, la inferencia en CPU sería lentísima por el ancho de banda de memoria.

La cuantización resuelve ambos problemas al mismo tiempo: en lugar de almacenar cada peso del modelo como float16 (16 bits), lo almacenas con menos bits: 8, 5, 4 o incluso 3. El modelo cabe en menos memoria y la inferencia es más rápida porque mueves menos bytes desde RAM a CPU.

A cambio pierdes precisión. El truco está en que esa pérdida es mucho menor de lo que la intuición sugiere. Llama 2 13B en Q4 (4 bits) ocupa ~7.5 GB y la calidad de respuesta es notablemente cercana al modelo original.

Niveles de cuantización en llama.cpp

llama.cpp ofrece varios niveles, identificados en el nombre del fichero GGUF:

Como regla práctica:

• 16 GB RAM, sin GPU: Llama 2 13B en Q4_K_M, o 7B en Q5/Q6_K si quieres más calidad.

• 32 GB RAM: Llama 2 13B en Q5_K_M o 70B en Q3_K_M (lento pero viable).

• MacBook con Apple Silicon: la memoria unificada M1/M2 Pro+ corre 13B Q4 con razonable fluidez.

El formato GGUF

llama.cpp usó inicialmente GGML como formato de fichero. En agosto de 2023 se introdujo GGUF como sucesor, más extensible y con metadatos mejor estructurados. Si descargas modelos de Hugging Face^[2] a partir de 2023, GGUF es el formato estándar.

El formato encapsula los pesos cuantizados, el vocabulario, la configuración del tokenizer y los hiperparámetros, todo en un único fichero autocontenido.

Cómo se usa en la práctica

# Compilar (con soporte Metal en Mac, CUDA en Linux con GPU)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make

# Ejecutar un modelo GGUF (TheBloke publica versiones de prácticamente todos los modelos populares)
./main -m ./models/llama-2-13b-chat.Q4_K_M.gguf 
       -p "Explica la cuantización en una frase" 
       -n 256

Para integrarlo en aplicaciones, llama.cpp expone:

• Servidor HTTP (./server) parcialmente compatible con la API de OpenAI.

• Bindings Python (llama-cpp-python).

• Integración con LangChain y LlamaIndex como LLM local.

Diagrama de red neuronal profunda representando las capas de pesos que se comprimen mediante cuantización

La calidad real que obtienes

Hablando claro: un Llama 2 13B Q4 no es GPT-4.

Donde rinde bien:

• Resúmenes y reescrituras cortas con instrucciones claras.

• Q&A sobre contexto provisto (RAG con documentos), que combina bien con Chroma o pgvector.

• Clasificación y extracción estructurada con pocos ejemplos few-shot.

• Generación de código sencillo en lenguajes populares (Python, JS).

• Conversación general en inglés; decente en otros idiomas.

Donde flaquea:

• Razonamiento multi-paso complejo. La diferencia con GPT-4 es notable.

• Conocimiento factual reciente. Su corpus es estático, sin acceso a internet.

• Idiomas distintos del inglés: funciona, pero notablemente peor.

• Coding no trivial. CodeLlama dedicado supera a Llama 2 base en este área.

Casos de uso donde llama.cpp brilla

Más allá del experimento personal, hay casos de uso reales donde correr local tiene sentido:

• Privacidad crítica. Documentos médicos, legales, código propietario que no puede salir de la red.

• Coste a escala. Si procesas millones de peticiones simples, el coste de API se acumula. Local puede ser dramáticamente más barato.

• Latencia ultra-baja. Sin roundtrip a un proveedor.

• Edge / sin conectividad. Aplicaciones embebidas, terreno, dispositivos médicos sin red garantizada.

• Experimentación libre. Probar fine-tuning, prompts agresivos, escenarios sin preocuparse por consumo de API.

Esto encaja con el perfil de LLMs locales y open source que Llama 2 abrió: la capacidad de correr un modelo razonable en hardware de consumo democratiza la experimentación.

Limitaciones que recordar

• Velocidad: 5-30 tokens/segundo en CPU típica. Comparado con GPT-4 (~50 tps en API), es lento para conversación interactiva.

• Context window: depende del modelo. Llama 2 base es 4K tokens; modelos extendidos llegan a 32K o más, pero a coste de calidad y velocidad.

• Soporte multilingüe limitado sin fine-tuning específico.

• Mantenimiento: tu propia infra de modelos. Actualizar a uno nuevo significa re-descargar y re-evaluar.

Conclusión

llama.cpp más cuantización han democratizado los LLMs en hardware de consumo. La calidad obtenible con un Llama 2 13B Q4_K_M en un portátil de 16 GB es notablemente útil para muchos casos de uso reales. No para todos, pero sí para muchos. Vale la pena tenerlo en el toolkit junto a APIs comerciales: cada uno gana en escenarios distintos.

Lee también la versión en inglés: Model Quantization and llama.cpp on Your Laptop.

Fuentes:

1. llama.cpp (repositorio en GitHub)^[1]
2. GGUF, formato de modelos (documentación de Hugging Face Hub)^[3]
3. llama-cpp-python, bindings de Python para llama.cpp (GitHub)^[4]

Fuentes

1. llama.cpp
2. Hugging Face
3. GGUF, formato de modelos (documentación de Hugging Face Hub)
4. llama-cpp-python, bindings de Python para llama.cpp (GitHub)