Cuantización de modelos de IA: la guía técnica para correr LLMs en tu propio PC

Por Joaquín Ruiz — autor, divulgador y experto en IA · Zaragoza

Un modelo como Llama 3.1 70B ocupa, en su forma nativa, alrededor de 140 gigabytes de memoria. Eso es hardware de datacenter: imposible ejecutarlo en un ordenador normal. Y, sin embargo, miles de desarrolladores lo están corriendo ahora mismo en sus propias máquinas, reduciendo ese tamaño a apenas 40 gigabytes, sin perder prácticamente calidad. La técnica que lo hace posible se llama cuantización, y es probablemente el concepto más importante que un desarrollador puede entender hoy si quiere construir IA local de verdad.

En este artículo te explico, desde un plano técnico pero accesible, qué es la cuantización, por qué funciona sin destrozar el modelo, qué formatos existen, cuál elegir según tu hardware y por qué es la pieza clave para montar agentes de IA totalmente privados y sin coste recurrente de API.


¿Qué es la cuantización?

La cuantización es el proceso de reducir la precisión numérica con la que se almacenan los pesos de un modelo de inteligencia artificial. En su forma nativa, cada uno de los miles de millones de parámetros de un LLM ocupa 16 bits (formato FP16 o BF16). Cuantizar consiste en representar ese mismo peso con menos bits: 8, 5, 4 o incluso 3.

Pongamos números concretos. Llama 3.1 70B tiene 70.000 millones de parámetros. Si cada uno ocupa 16 bits (2 bytes), el modelo entero pesa 140 GB. Si cuantizamos a 4 bits, cada peso ocupa medio byte y el modelo pasa a unos 40 GB. El factor real de la cuantización a 4 bits es aproximadamente 4×: reduce el tamaño a la cuarta parte.

La analogía más clara es la fotografía. Cuando guardas una foto en formato RAW, ocupa decenas de megas y conserva cada detalle de la captura. Cuando la guardas en JPEG, pesa una fracción. ¿Se ve peor? Casi imperceptiblemente. Has perdido información, sí, pero información que tu ojo no procesa. La cuantización es exactamente eso aplicado a redes neuronales: tiras información que, en la práctica, el modelo no necesita para funcionar.

Por qué funciona: la intuición técnica

La pregunta legítima es: si tiramos información, ¿no debería romperse el modelo? La respuesta corta es no, y la larga es fascinante.

Las redes neuronales son profundamente redundantes. Durante el entrenamiento, miles de millones de pesos aprenden a representar patrones, y muchos terminan en rangos muy estrechos o cerca de cero. Esa redundancia es lo que permite cuantizar sin colapsar el comportamiento del modelo.

La métrica estándar para medir la pérdida es la perplejidad: cuán «sorprendido» está el modelo al predecir el siguiente token. Cuando se compara un modelo en FP16 con su versión cuantizada a 4 bits usando un método decente, la diferencia de perplejidad es inferior al 1%. Has reducido el modelo a la cuarta parte de su tamaño y la pérdida es estadísticamente despreciable.

Hay una conexión bonita con el entrenamiento que muchas veces no se explica. El descenso del gradiente afina cada peso con una precisión enorme durante el entrenamiento, buscando el mínimo de la función de coste decimal a decimal. La cuantización viene después y demuestra algo profundo: la superficie de pérdida alrededor de ese mínimo es lo bastante plana como para que redondear los pesos a 4 bits apenas mueva la aguja. Entrenas fino, ejecutas redondeado.

Eso sí, hay un límite. Por debajo de 3 bits la degradación se dispara. La zona de oro está entre 4 y 5 bits por peso.

Formatos de cuantización: GGUF, EXL2, AWQ, GPTQ y MLX

No toda cuantización es igual. Cada formato tiene su filosofía y su hardware óptimo:

  • GGUF. El formato del ecosistema llama.cpp. Su superpoder es el offloading: puede repartir el modelo entre GPU y RAM del sistema, permitiendo ejecutar modelos que no caben enteros en VRAM. Es el formato dominante en Ollama y LM Studio. Ideal para empezar y para hardware mixto.
  • EXL2. Formato de ExLlamaV2. Solo GPU, sin offloading, pero mucho más rápido que GGUF cuando todo cabe en VRAM. Permite cuantización fraccional (5.0, 5.5, 6.0 bits por peso), lo que da una granularidad enorme para ajustar al hardware.
  • AWQ y GPTQ. Métodos de cuantización post-entrenamiento con datos de calibración. AWQ es el más moderno y suele dar mejores resultados. Se usan sobre todo en servidores de inferencia con vLLM o TGI.
  • MLX. El framework de Apple para Apple Silicon. Conceptualmente la cuantización en MLX se parece a la de GGUF (mapeo por bloques), pero está optimizada de raíz para aprovechar la memoria unificada y el Neural Engine de los chips M-series. Si tienes Mac, MLX rinde notablemente mejor que GGUF.

Recomendación práctica:

  • Empezando con IA local en PC: GGUF (vía Ollama).
  • GPU con VRAM holgada y máxima velocidad: EXL2.
  • Servidor de producción: AWQ + vLLM.
  • Apple Silicon: MLX.

K-quants y el sweet spot Q4_K_M

Dentro de GGUF aparece una nomenclatura que despista: Q2_K, Q3_K_S, Q4_0, Q4_K_M, Q5_K_M, Q6_K, Q8_0… El número indica los bits promedio por peso. La «K» significa que es una cuantización k-quants, que aplica distintas precisiones a distintas partes de la red según su importancia. Las letras finales (S, M, L) indican el grado de mezcla dentro de ese nivel.

Q4_K_M es el sweet spot para casi cualquier modelo y casi cualquier caso. Ofrece la mejor relación calidad/tamaño y es la elección por defecto recomendada por la comunidad. Si tienes VRAM extra, sube a Q5_K_M. Si te falta, baja a Q4_K_S o Q3_K_M asumiendo cierta pérdida.

Por debajo de Q3, solo si no hay alternativa. Por encima de Q6, el incremento ya no compensa.

Cómo calcular tu VRAM y entender el offloading

La fórmula práctica:

VRAM aproximada (GB) ≈ (parámetros en miles de millones × bits por peso) ÷ 8 + overhead

El overhead (caché KV, buffers, contexto) suele estar entre 1 y 4 GB para contextos modestos.

Ejemplos concretos con Q4_K_M:

ModeloPesos en Q4+ overheadTotal estimado
Llama 3.1 8B~4,5 GB~1,5 GB~6 GB
Llama 3.1 14B~8 GB~2 GB~10 GB
Llama 3.1 32B~18 GB~3 GB~21 GB
Llama 3.1 70B~39 GB~4 GB~43 GB

El offloading consiste en cargar las primeras capas del modelo en la GPU y las últimas en la RAM del sistema, usando la CPU para procesarlas. Permite ejecutar modelos que no caben enteros en VRAM, a cambio de velocidad. Una RTX 4090 (24 GB) con 64 GB de RAM puede correr un 70B, aunque sólo a 2-5 tokens por segundo.

La realidad del hardware: rutas honestas para correr Llama 70B

Hay que ser claros: un 70B en Q4 no entra en una sola GPU de consumo actual. La RTX 5090, la tope de gama doméstica, tiene 32 GB. La 4090, 24 GB. Las rutas reales para correr Llama 70B en local son:

  1. Doble RTX 3090 (24 + 24 = 48 GB). Es el setup clásico de la comunidad. Las 3090 de segunda mano son la mejor relación VRAM/precio para IA local hoy.
  2. RTX 5090 + algo de offloading, o bajando a Q3 para que entre en 32 GB.
  3. Mac con memoria unificada (M-series con 64 GB o más). Gracias a la arquitectura compartida, corre el 70B en MLX sin drama.
  4. GPU de 24 GB + RAM con offloading GGUF. Funciona, más lento.

Si solo tienes una GPU modesta, el sweet spot para velocidad fluida es un modelo de 8B-32B cuantizado en una sola tarjeta. Para la mayoría de casos de uso prácticos —incluidos agentes locales— un 14B-32B bien elegido rinde de sobra.

Cuantización y agentes locales: la conexión clave

Toda la teoría de la cuantización tiene un objetivo aplicado: permitir que cualquier desarrollador pueda construir agentes de IA totalmente locales. Cuatro razones por las que esto importa:

  • Privacidad real. Datos internos, código propietario, documentos confidenciales: nada sale de tu infraestructura.
  • Coste cero recurrente. Pagas el hardware una vez. Después, inferencias infinitas a coste marginal cero.
  • Latencia y disponibilidad controladas. Sin dependencia de internet ni de APIs ajenas.
  • Soberanía arquitectónica. Tú eliges modelo, cuantización, contexto, herramientas, políticas.

Sin cuantización, los modelos open source competentes seguirían fuera del alcance del 99% de los desarrolladores. Con ella, el ecosistema IA local es viable hoy.

Herramientas recomendadas

  • Ollama — Servidor de modelos con API HTTP. La forma más rápida de empezar.
  • LM Studio — Interfaz gráfica para probar cuantizaciones y modelos. Soporta MLX nativo.
  • llama.cpp — El motor que está debajo de casi todo. Control total.
  • ExLlamaV2 — Para EXL2 y máxima velocidad en GPU NVIDIA.
  • Hugging Face — Donde encontrar modelos ya cuantizados (organizaciones bartowski, mlx-community, lmstudio-community).

Preguntas frecuentes sobre cuantización

¿Qué es la cuantización en IA en una sola frase? Es el proceso de reducir la precisión numérica de los pesos de un modelo (por ejemplo, de 16 a 4 bits) para que ocupe mucho menos espacio y se pueda ejecutar en hardware modesto sin apenas pérdida de calidad.

¿La cuantización reduce la calidad del modelo? Sí, pero muy poco si se hace bien. Con cuantización a 4 bits usando métodos modernos como Q4_K_M, la pérdida de perplejidad suele ser inferior al 1%.

¿Qué cuantización debería elegir para empezar? Q4_K_M en formato GGUF. Es el sweet spot calidad-tamaño y funciona con Ollama, LM Studio y prácticamente cualquier herramienta de IA local.

¿Puedo correr Llama 70B en mi PC? Depende del hardware. Necesitas alrededor de 40-45 GB entre VRAM y RAM. Las rutas viables son: doble RTX 3090, RTX 5090, Mac con 64+ GB de memoria unificada, o una GPU de 24 GB con offloading a RAM (más lento).

¿Qué diferencia hay entre GGUF y MLX? GGUF es el formato general del ecosistema llama.cpp y funciona en cualquier hardware. MLX está optimizado específicamente para Apple Silicon y rinde notablemente mejor en Macs gracias a la memoria unificada y el Neural Engine.

¿La cuantización solo sirve para inferencia o también para entrenamiento? Principalmente para inferencia. Existen técnicas de entrenamiento cuantizado (QLoRA, por ejemplo), pero el grueso del beneficio práctico está en ejecutar modelos ya entrenados.


🔗 Recursos relacionados


Sobre el autor

Joaquín Ruiz (Jokioki) es divulgador y experto en inteligencia artificial afincado en Zaragoza, autor de tres libros sobre IA y redes neuronales publicados en Amazon —entre ellos «El Motor de la IA»— y creador del canal de YouTube IA para desarrolladores, donde explica desde fundamentos matemáticos hasta arquitecturas de agentes locales para una audiencia técnica hispanohablante.

Su trabajo se centra en hacer accesibles los conceptos profundos del machine learning sin renunciar al rigor, con especial foco en IA local, agentes autónomos y herramientas open source para desarrolladores.


Si te ha sido útil este artículo, compártelo con otro desarrollador que esté empezando con IA local. Y si quieres profundizar, el vídeo lo cubre con ejemplos prácticos.

Que la IA te acompañe!

5 1 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x