LLM quantization: qué formato elegir y cuánta memoria reservar

Elige la mayor precisión que se ajuste a tu carga de trabajo y supere tus propias pruebas de calidad. Una descarga más pequeña solo ayuda si el modelo sigue respondiendo correctamente y deja memoria suficiente para la conversación.

La documentación y las afirmaciones sobre compatibilidad se verificaron en las páginas oficiales de los proyectos el 20 de octubre de 2026. Las cifras de memoria se calculan a partir del número de parámetros documentado de Qwen2.5-7B-Instruct; no son mediciones de uso de GPU ni resultados de pruebas de rendimiento.

LLM quantization: menos precisión, la misma estructura del modelo

La cuantización almacena los valores que aprende el modelo con menos bits. Un modelo de lenguaje de gran tamaño, o LLM, genera texto a partir de parámetros numéricos aprendidos, llamados pesos. Reducir su precisión abarata su almacenamiento y transferencia, a cambio de introducir errores de aproximación. La introducción a la cuantización de Hugging Face explica este equilibrio entre memoria y exactitud.

Piensa en un plano arquitectónico cuyas medidas se han anotado con gran precisión. Redondearlas permite registrarlas de forma más compacta, pero algunas dimensiones cambian ligeramente. El edificio sigue teniendo las mismas habitaciones. De forma parecida, la cuantización habitual de los pesos no convierte un modelo grande en otro con menos capas o menos parámetros aprendidos: cambia la precisión con la que se representan sus pesos.

La analogía tiene un límite: cuantizar requiere más criterio que simplemente borrar decimales. Los valores pueden agruparse, recibir un factor de escala y asignarse a un conjunto más pequeño de valores representables. Ese factor permite al entorno de ejecución recuperar una aproximación cuando necesita hacer cálculos. Las partes importantes pueden conservar una precisión mayor. La explicación de IBM sobre cuantización describe estas correspondencias y el error que producen.

Antes de elegir qué descargar, distingue estos tres componentes:

• Pesos: los valores aprendidos que se almacenan con el modelo.
• Activaciones: los valores intermedios que se generan al procesar la entrada.
• Caché KV: los datos de atención que se guardan del contexto ya procesado y que ocupan más memoria a medida que crece la conversación.

Un esquema que cuantiza solo los pesos reduce el primer componente. No reduce automáticamente los otros dos. Por eso un modelo puede cargarse sin problemas y quedarse sin memoria al recibir una solicitud larga. La documentación de Ollama sobre memoria y caché aborda por separado la capacidad de contexto y la precisión de la caché.

Cuantización después del entrenamiento o entrenamiento consciente de la cuantización

Si vas a descargar un modelo para desarrollar una aplicación, lo habitual es empezar por la cuantización posterior al entrenamiento. Este enfoque, conocido como PTQ, convierte un checkpoint ya entrenado. Algunos métodos utilizan datos de calibración: entradas representativas que ayudan a decidir cómo aproximar los pesos. El entrenamiento consciente de la cuantización, o QAT, incorpora los efectos de la baja precisión durante el entrenamiento o el ajuste fino. IBM explica ambos enfoques.

No necesitas entrenar un modelo para usar un checkpoint cuantizado que ya esté publicado. Sí necesitas saber de qué modelo original procede, qué procedimiento se utilizó para cuantizarlo y qué entorno de ejecución puede cargarlo. El nombre del archivo, por sí solo, no sustituye esa información.

GGUF, AWQ, GPTQ y FP8: ¿cuál admite cada entorno de ejecución?

Estos nombres describen capas distintas del sistema; no son alternativas intercambiables. GGUF es un contenedor. AWQ y GPTQ son métodos de cuantización. FP8 es un formato numérico. Un checkpoint es el archivo o conjunto de archivos del modelo guardado, que reúne los pesos y la información necesaria para cargarlos.

Hugging Face, la plataforma de alojamiento de modelos que desarrolla Transformers, documenta tanto los formatos de archivo como los métodos de carga. La tabla combina esa documentación con las indicaciones de los propios entornos de ejecución. Sirve para orientar la elección, sin dar por hecho que todas las arquitecturas de modelos funcionen en todas las opciones enumeradas.

La extensión .safetensors tampoco resuelve la cuestión de la precisión. Identifica un formato de almacenamiento de tensores. Lee la configuración de cuantización y la ficha del modelo del checkpoint para saber cómo se representan esos tensores y qué cargador debes utilizar. La documentación de GGUF de Hugging Face distingue los metadatos del contenedor de los datos de los tensores, mientras que su guía de AWQ muestra los campos correspondientes de quantization_config.

¿Qué significa Q4_K_M?

Q4_K_M es una configuración predefinida de precisión mixta, no una garantía de que cada parámetro ocupe exactamente cuatro bits. Q4 identifica la familia nominal de cuatro bits; K, el esquema de bloques K-quant; y M, la configuración intermedia. Determinados tensores pueden usar una precisión mayor según la arquitectura del modelo y las reglas del cuantizador. La implementación de cuantización de llama.cpp detalla esas decisiones.

Incluso un bloque Q4_K básico incluye información auxiliar: la tabla de codificación de tensores del proyecto indica 4.5 bits por peso al contar la información de escala y mínimo. Es una cifra por bloque, no el promedio de todos los modelos Q4_K_M.

En un equipo local con recursos limitados, Q4_K_M es una opción razonable para evaluar. Si una variante de mayor precisión cabe en memoria con el contexto que necesitas, compárala también. No sacrifiques la calidad de las respuestas solo porque exista un archivo más pequeño.

Cómo estimar la memoria: el ejemplo de Qwen2.5-7B-Instruct

Calcula primero el espacio para todos los parámetros y después suma la memoria necesaria para ejecutar el modelo. Qwen2.5-7B-Instruct, el modelo de Qwen ajustado para seguir instrucciones que usamos como ejemplo, tiene 7.61 mil millones de parámetros en total. Su ficha indica por separado 6.53 mil millones de parámetros sin contar los embeddings; usar esa cifra menor dejaría fuera parte del modelo almacenado. Ficha del modelo Qwen.

El cálculo idealizado es:

Bytes de los pesos ≈ número de parámetros × bits por parámetro ÷ 8

A 16 bits, el cálculo es 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes. Si lo repetimos con las otras precisiones:

Son cálculos propios basados en el número redondeado de parámetros que figura en la ficha del modelo, suponiendo que todos usan la cantidad de bits indicada. Para obtener GB decimales, se dividen los bytes entre 1,000,000,000; para obtener GiB, entre 1,073,741,824. Cambiar la unidad modifica la cifra que se muestra, no la cantidad de memoria.

La tabla excluye deliberadamente los factores de escala de cuantización, los tensores de mayor precisión, los metadatos del archivo, la caché, las activaciones, los búferes temporales de trabajo y las reservas del entorno de ejecución. Una descarga Q4_K_M no ocupará lo que indica la fila ideal de cuatro bits. Esa fila tampoco demuestra que el modelo pueda ejecutarse en una hipotética GPU de 4 GB.

Por tanto, una conversación breve no basta para comprobar la capacidad de un asistente de programación local. Una prueba útil incluye los archivos de código, las instrucciones y la longitud de respuesta que esperas usar. En un servidor, añade solicitudes simultáneas. Ollama documenta expresamente el efecto de las solicitudes en paralelo y la asignación de contexto sobre la memoria.

Consulta la guía de caché KV para calcular por separado la memoria del contexto. Cuantizar los pesos y cuantizar la caché son ajustes distintos; vLLM también documenta la cuantización de la caché KV como una función independiente.

Elige el formato según el entorno de ejecución

Primero decide cómo vas a ejecutar el modelo; después, con qué precisión. La compatibilidad es un requisito imprescindible. Una vez resuelta, elige según la memoria disponible, la calidad de las respuestas y la latencia medida con tu carga de trabajo.

llama.cpp: empieza por un GGUF compatible

llama.cpp, un motor de inferencia local, ofrece una vía directa para usar GGUF cuando quieres controlar los archivos del modelo y su distribución entre dispositivos. Su documentación incluye ejecución en CPU, compatibilidad con Apple silicon y ejecución mixta en CPU/GPU. Esto resulta útil cuando los pesos no caben por completo en una GPU dedicada. Documentación del proyecto llama.cpp.

Su límite es que cargar un modelo correctamente no garantiza una velocidad útil. Repartirlo entre CPU y GPU cambia las condiciones de ejecución: sigue siendo necesario medir el rendimiento con tus entradas y respuestas reales. Elige primero la arquitectura del modelo, después un GGUF compatible y, por último, una configuración de cuantización.

La guía de los mejores LLM locales del sitio te ayuda a elegir el modelo base. La cuantización no hará que un modelo inadecuado entienda una tarea que ya resuelve mal con mayor precisión.

Ollama: importa la versión cuantizada que quieras ejecutar

Ollama, una herramienta para ejecutar modelos localmente, puede importar un GGUF preparado, pero importarlo no lo cuantiza. Su guía de importación actual indica que primero hay que preparar el archivo cuantizado. Conviene tenerlo claro si esperas que el comando de importación convierta automáticamente un modelo de mayor precisión a Q4_K_M. Documentación de importación de Ollama.

Con Ollama instalado y un archivo compatible, ya cuantizado, guardado como model.gguf en el directorio actual, el procedimiento documentado queda así:

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

Ejecuta ollama ps en otra terminal para comprobar cómo se distribuye el modelo cargado entre CPU y GPU. Esto permite verificar qué se ha cargado; no es una prueba de calidad. Preguntas frecuentes de Ollama.

El límite de Ollama sigue siendo la memoria que exige la carga de trabajo. La comodidad de un comando no elimina la necesidad de reservar memoria para el contexto y la concurrencia. La comparación entre Ollama y llama.cpp explica qué nivel de control sobre los archivos del modelo y su ejecución conviene elegir.

vLLM: comprueba que el checkpoint, el kernel y la GPU sean compatibles

vLLM, un motor para inferencia y despliegue de modelos como servicio, necesita un checkpoint cuantizado compatible con alguna de las modalidades de ejecución que admite. Empieza por una versión en AWQ, GPTQ o FP8 que el editor del modelo indique como compatible. Después, consulta tu GPU en la matriz de compatibilidad de hardware de vLLM. Un kernel es la implementación de cálculo de bajo nivel que permite ejecutar un formato de manera eficiente en ese hardware.

Para nuevos trabajos de cuantización con AWQ, la documentación actual recomienda LLM Compressor. AutoAWQ está obsoleto; AWQ sigue existiendo como método y como familia de checkpoints. Para GPTQ en Transformers, el backend que recibe mantenimiento es GPTQModel, y la compatibilidad puede depender de la configuración del checkpoint. Guía de AWQ de vLLM, guía de GPTQ de Hugging Face.

Con FP8 hay que hacer otra distinción. W8A8 significa pesos y activaciones de ocho bits; W8A16, pesos de ocho bits con activaciones de dieciséis bits. vLLM documenta FP8 W8A8 nativo para NVIDIA Ada, Hopper y Blackwell, mientras que Turing y Ampere pueden usar una modalidad W8A16 que cuantiza solo los pesos mediante Marlin. Por eso, leer «compatible con FP8» no basta para saber qué modalidad de cálculo se utilizará. Documentación de FP8 de vLLM.

Que GGUF haya funcionado localmente no basta para convertirlo en tu formato predeterminado de despliegue en vLLM. La documentación actual lo admite a través de vllm-gguf-plugin y sigue describiéndolo como experimental y poco optimizado, con posibles incompatibilidades entre funciones. Es una restricción que debes considerar al migrar, no una prueba de que GGUF sea inferior. Documentación de GGUF de vLLM.

API alojada: elige entre las opciones que exponga el endpoint

Si una API alojada no ofrece un ajuste de precisión, no tienes ninguna decisión de cuantización local que tomar. Lee la especificación del endpoint. Si ofrece variantes de precisión identificadas, evalúa la que elijas. Si no las ofrece, evalúa sus respuestas y su latencia sin suponer cómo representa el modelo internamente.

Que dos proveedores usen el mismo nombre de modelo no permite deducir que empleen la misma cuantización, el mismo entorno de ejecución o que produzcan los mismos resultados. Pide un checkpoint documentado o una garantía de precisión solo cuando tu aplicación lo requiera. Subir tus propios pesos y servirlos es una decisión de despliegue distinta, que vuelve a plantear la compatibilidad entre entorno de ejecución y hardware.

Qué cambia al cuantizar: memoria, velocidad y calidad

Una representación más compacta reduce el espacio de almacenamiento; la velocidad y la calidad deben evaluarse por separado. Mantener menos datos en memoria puede reducir el trabajo necesario para transferir los pesos. Sin embargo, el entorno de ejecución también puede tener que desempaquetar o convertir esos valores antes de operar con ellos. La documentación de GPTQ de Hugging Face explica cómo un kernel fusionado puede recuperar los pesos de pocos bits para el cálculo sin expandir el modelo completo en la memoria global de la GPU.

Ahí están tanto la oportunidad como el límite. Un kernel compatible permite aprovechar los pesos compactos. Una modalidad de ejecución inadecuada puede anular la ventaja. Mide el tiempo hasta el primer token, la velocidad de generación y el rendimiento total con el nivel de concurrencia previsto, en vez de usar el tamaño del archivo como prueba de velocidad.

La calidad también depende del uso concreto. Para un asistente de programación, comprueba si el cambio propuesto supera las pruebas pertinentes. Para extraer datos de documentos, compara los campos requeridos y la validez de la salida estructurada. Para un asistente multilingüe, incluye los idiomas que vayas a ofrecer. Que una respuesta suene fluida no demuestra por sí solo que la cuantización haya conservado el comportamiento del modelo en tu tarea.

La comparación útil parte del mismo checkpoint original: una versión de mayor precisión y la variante cuantizada, ambas con los mismos prompts, plantilla de chat y ajustes de generación. Si al mismo tiempo comparas modelos que no están relacionados, no podrás aislar qué cambios se deben a la cuantización.

Cuándo conviene conservar la precisión y qué promesas se exageran

Conserva la mayor precisión si ya cabe en memoria y la versión cuantizada no aporta ninguna ventaja operativa medida. Comprimir más implica generar otra versión del modelo y validar de nuevo su comportamiento. Debe resolver un problema real de tu aplicación.

No adoptes una variante de menor precisión si falla en pruebas importantes de la tarea, si su modalidad de ejecución cuenta con poco soporte o si la carga de trabajo con contextos largos sigue superando la memoria disponible. En este último caso, revisa el contexto y la concurrencia antes de seguir reduciendo los pesos.

Tampoco des por hecho que una versión cuantizada para inferencia sirve como checkpoint de entrenamiento universal. Bitsandbytes documenta la compatibilidad con entrenamiento de pocos bits para parámetros adicionales, como los pesos de adaptadores. Se trata de un flujo específico de ajuste fino; no significa que cualquier modelo cuantizado que descargues permita el entrenamiento convencional de todos sus pesos. Documentación de bitsandbytes de Hugging Face.

Estas son las afirmaciones que suelen exagerarse:

• «Cuatro bits significa que toda la aplicación usa una cuarta parte de la memoria». Esa proporción compara el tamaño ideal de los pesos con una representación de dieciséis bits. La memoria de ejecución incluye otros componentes.
• «Ocho bits es un único formato». FP8, INT8 y Q8_0 son representaciones y modalidades de ejecución distintas.
• «Con menos bits siempre se ejecuta más rápido». El checkpoint, el kernel, el hardware y la carga de trabajo determinan si la reducción de memoria mejora la latencia o el rendimiento total.
• «Un modelo grande cuantizado siempre supera a uno pequeño de mayor precisión». El número de parámetros y la cantidad de bits no bastan para determinar la calidad en una tarea. Evalúa ambas opciones si las dos caben en memoria.

Para elegir modelos orientados a programación, consulta la guía de los mejores modelos de IA locales para programar. Después compara las variantes cuantizadas del checkpoint elegido con el trabajo que esperas que resuelva.

Cómo empezar a trabajar con modelos cuantizados

Empieza con una versión compatible y una evaluación pequeña que puedas repetir. Mantén fijo el modelo original hasta comprender el efecto de la precisión.

Preguntas frecuentes

Para recibir guías prácticas sobre cómo ejecutar y poner en producción sistemas de IA, suscríbete al boletín.