IA cuantizada: qué ahorra y qué puede perder

Dos archivos del mismo modelo pueden ocupar tamaños muy distintos aunque compartan el número de parámetros. Una versión cuantizada guarda muchos pesos con menos bits; a cambio, puede aproximar con menor precisión los valores originales. El tamaño menor es una propiedad del almacenamiento, no una garantía de que responderá igual, consumirá la mitad de memoria en total o generará más deprisa.

La decisión útil no es «¿cuál tiene menos bits?», sino «¿qué versión cabe en mi equipo y mantiene un resultado aceptable en las tareas que sí voy a usar?». Aquí veremos cómo leer las etiquetas, estimar el tamaño de los pesos y comparar las opciones sin confundir una ficha técnica con una prueba de calidad.

Qué significa cuantizar un modelo

Los pesos de una red se guardan como números. En una representación de mayor precisión, cada valor puede distinguir más niveles; al cuantizar, el sistema representa esos valores con una cantidad menor de bits y conserva información auxiliar —por ejemplo, escalas por grupos— para reconstruir aproximaciones durante el cálculo. Hugging Face describe la cuantización como una reducción de precisión que busca ahorrar memoria manteniendo tanta exactitud como sea posible; los métodos y sus requisitos varían.

«4-bit» o «8-bit» suele referirse al formato de ciertos pesos, no necesariamente a cada tensor, a las activaciones ni a toda la sesión. Algunos métodos cuantizan pesos y dejan capas o componentes en otra precisión. Por eso dos archivos etiquetados como Q4 pueden tener tamaños, compatibilidad y comportamiento diferentes.

La idea se relaciona con otros conceptos, pero no es intercambiable con ellos. Reducir los bits no reduce el número de parámetros; tampoco convierte por sí solo un modelo cerrado en abierto ni cambia los permisos de su licencia. Para comparar esos aspectos consulta nuestra guía sobre modelos de IA abiertos y sus licencias.

Cómo estimar el tamaño de los pesos

Una aproximación inicial se obtiene con una cuenta sencilla:

tamaño teórico en bytes ≈ número de parámetros × bits por parámetro ÷ 8

Para un modelo de 7.000 millones de parámetros, el cálculo da aproximadamente 14 GB si cada parámetro ocupa 16 bits, 7 GB a 8 bits y 3,5 GB a 4 bits. Son GB decimales y cifras de los pesos ideales, no tamaños prometidos de descarga ni requisitos recomendados de VRAM.

La estimación sirve para descartar opciones que claramente no caben; no basta para elegir una configuración ejecutable. El archivo puede guardar escalas, ceros, alineación y metadatos, y no todos los tensores tienen por qué usar cuatro bits. Como referencia concreta, el repositorio de llama.cpp describe varios tipos GGUF con bits efectivos por peso distintos del entero redondo indicado en su nombre: los bloques y datos auxiliares también ocupan espacio.

Por qué el archivo no predice la memoria total

Durante la generación el programa necesita algo más que cargar los pesos: espacio para caché, activaciones temporales y el propio backend. En un asistente de texto, la caché KV guarda información de los tokens procesados para seguir generando; su consumo depende, entre otros factores, de la longitud del contexto, el número de secuencias y la arquitectura. La documentación sobre caché KV muestra por separado si una combinación cabe incluyendo esa caché, una distinción importante frente a mirar únicamente el tamaño del archivo.

Una conversación corta puede caber y una solicitud larga provocar que se agote la memoria. También influye dónde se ejecuta cada capa: CPU, GPU o memoria compartida. Si necesitas calcular un equipo, empieza por la guía para dimensionar un PC para IA local, que trata RAM, VRAM y otros componentes; aquí nos centramos en cómo comparar versiones cuantizadas de los pesos.

Qué puede perderse al usar menos bits

La cuantización reemplaza valores originales por aproximaciones. Si la aproximación altera información relevante para una tarea, puede empeorar el resultado; cuánto y dónde depende del modelo, el método, el formato, el hardware y la prueba. No existe una regla fiable del tipo «cada reducción de bits resta tantos puntos» que sirva para todos.

Los trabajos sobre GPTQ y AWQ describen métodos distintos para reducir el error: GPTQ ajusta pesos después del entrenamiento usando información de calibración; AWQ utiliza estadísticas de activación para proteger canales o pesos más sensibles. LLM.int8() combina cálculo de 8 bits con tratamiento de mayor precisión para valores atípicos. Estos artículos explican diseños y resultados en sus experimentos; no prueban que una variante descargada concreta sea mejor para tus documentos, idioma o flujo.

En la práctica conviene vigilar fallos que importan a tu uso: instrucciones que deja de seguir, cifras o nombres que altera, código que ya no compila, omisiones al resumir, cambios en formato o respuestas inconsistentes al repetir una pregunta. Una diferencia en una métrica general puede pasar por alto el error que más te preocupa. Tampoco debe confundirse «el modelo responde» con «el resultado es suficientemente fiable».

NF4, GPTQ, AWQ y GGUF no son cuatro niveles equivalentes

El número de bits y el nombre del método contestan preguntas diferentes. La documentación de Transformers ofrece implementaciones y rutas de carga distintas; confirma compatibilidad de la combinación concreta antes de descargar o convertir nada.

• Bitsandbytes de 8 bits: LLM.int8() busca reducir la huella con una ruta de precisión mixta para valores atípicos. Es una opción de carga que depende de las bibliotecas, acelerador y modelo admitidos.
• NF4 / QLoRA: NF4 es un tipo de datos de cuatro bits propuesto para pesos con distribución aproximadamente normal en el trabajo QLoRA. QLoRA combina una base congelada cuantizada con adaptadores LoRA entrenables; no es simplemente otro nombre para cualquier archivo de inferencia INT4. La configuración de QLoRA también explica la doble cuantización de constantes para reducir memoria adicional.
• GPTQ: método de cuantización posterior al entrenamiento. La guía actual de Transformers distingue el proyecto que soporta de herramientas antiguas y explica que determinadas rutas usan pesos int4 y los reconstruyen al vuelo. Que aparezca «GPTQ» en el nombre no confirma que el backend instalado pueda abrir ese archivo.
• AWQ: método que utiliza activaciones para identificar qué partes conviene preservar al cuantizar pesos. La publicación original y la guía de carga describen el método y las implementaciones compatibles; no todas las aplicaciones admiten las mismas variantes.
• GGUF y etiquetas Q4: GGUF es un formato usado por llama.cpp, con familias como Q4_K_M. Esas etiquetas identifican una receta de almacenamiento concreta, no un estándar universal que pueda equipararse sin más a NF4, GPTQ o bitsandbytes.

Estas diferencias son una razón para copiar el identificador exacto del repositorio y el archivo, no anotar solo «modelo de 4 bits». Comprueba también licencia, versión del modelo base, fecha, método, contexto admitido, arquitectura y backend. Para situar la cuantización dentro de la decisión de capacidad, puedes leer nuestra comparación entre modelos más capaces y opciones eficientes.

Cómo comparar versiones sin atribuirles resultados inventados

No hemos ejecutado una prueba propia de modelos cuantizados para esta guía. Este procedimiento permite preparar una comparación reproducible sin convertir los resultados de un artículo científico o de un benchmark ajeno en una experiencia de Gaia:

1. Fija la tarea. Escribe qué tiene que hacer el modelo y qué cuenta como error. «Que responda bien» es demasiado amplio; «extraer fechas y nombres sin inventarlos de un párrafo» es verificable.
2. Registra los artefactos. Apunta modelo base, revisión, archivo exacto, cuantización, runtime, versión y hardware. No compares un checkpoint cambiado con otro y atribuyas toda diferencia a los bits.
3. Usa entradas representativas. Prepara ejemplos reales o sintéticos permitidos para tu evaluación, incluidos casos difíciles y una respuesta esperada o criterio de revisión. Excluye información confidencial si no tienes autorización para procesarla.
4. Mantén iguales las condiciones. Repite los mismos prompts, contexto, parámetros de generación y backend. Si cambias más de una cosa, registra cada cambio.
5. Evalúa errores, no solo fluidez. Revisa exactitud, omisiones, obediencia al formato y consistencia según el trabajo. Para decisiones sensibles, una revisión humana competente sigue siendo necesaria.
6. Mide recursos por separado. Registra si carga, memoria máxima observada, latencia y velocidad de generación en el mismo equipo. El menor archivo puede necesitar más tiempo o no aprovechar una GPU concreta.
7. Guarda una alternativa. Si la cuantización más agresiva causa errores inaceptables, prueba una precisión superior o un método distinto. Vuelve a revisar tras actualizar el modelo o el programa.

Una decisión rápida según tu prioridad

La mejor cuantización es la que supera tu prueba

Cuantizar suele ser una forma práctica de reducir el almacenamiento de pesos y puede abrir opciones que antes no cabían. Pero el tamaño teórico, la memoria durante una conversación, el rendimiento y la calidad son medidas diferentes. Empieza por estimar los pesos, verifica el presupuesto total con el contexto previsto y compara versiones del mismo modelo en tareas propias. Si no puedes medir la calidad, trata la cuantización como una hipótesis útil, no como una garantía.

Fuentes y agradecimientos

Para esta explicación consultamos la visión general y selección de métodos de cuantización de Transformers, junto con su guía de caché KV y sus guías de bitsandbytes, GPTQ y AWQ; la documentación de cuantización de llama.cpp; y los trabajos originales LLM.int8(), QLoRA, GPTQ y AWQ.

Agradecemos a los autores de esos estudios, a sus instituciones y a los equipos que mantienen la documentación y el software por publicar los métodos, limitaciones y ejemplos que permiten contrastar estas diferencias. Las ilustraciones y el cálculo de 7B son elaboración propia; no representan un benchmark ni una prueba de hardware.