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

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 se mantiene cerca de la del modelo original.

Niveles de cuantización en llama.cpp

llama.cpp ofrece estos 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.

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 suficiente 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]

Preguntas frecuentes

¿Qué nivel de cuantización elijo para un portátil con 16 GB de RAM sin GPU?

Llama 2 13B en Q4_K_M, que ocupa unos 7,5 GB frente a los 26 GB en float16 y es el nivel más popular por su balance entre calidad y tamaño. Si prefieres más calidad, usa un modelo 7B en Q5 o Q6_K. Con 32 GB de RAM puedes subir a 13B en Q5_K_M o incluso a 70B en Q3_K_M, lento pero viable. En un MacBook con Apple Silicon M1/M2 Pro o superior, 13B Q4 corre con razonable fluidez.

¿Cuánta calidad se pierde al cuantizar a 4 bits?

Menos de lo que la intuición sugiere: un Llama 2 13B en Q4 da respuestas cercanas a las del modelo original. Q8_0 tiene pérdida mínima frente a fp16, y Q5_K_M y Q6_K ofrecen buen balance. Q4_0 es más rápido que Q4_K_M pero menos preciso, y Q3_K_M o Q2_K degradan la calidad y solo compensan con memoria limitada. Aun así, un 13B Q4 no es GPT-4: flaquea en razonamiento multi-paso, conocimiento reciente e idiomas distintos del inglés.

¿A qué velocidad responde llama.cpp en CPU?

Entre 5 y 30 tokens por segundo en una CPU típica, frente a los ~50 tps de GPT-4 vía API, así que resulta lento para conversación interactiva. La ventana de contexto depende del modelo: Llama 2 base es de 4K tokens y los modelos extendidos llegan a 32K o más a costa de calidad y velocidad. Para integrarlo en aplicaciones, llama.cpp expone un servidor HTTP (./server) parcialmente compatible con la API de OpenAI y bindings Python (llama-cpp-python).

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)