Variantes, formatos y cuantización de LLMs con pesos abiertos

Viacheslav Dubrov

2025-05-11 · Actualizado 2026-08-16 · 12 min · Ingeniería de modelos

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Los nombres como Model-32B-A3B-Instruct-AWQ parecen densos porque combinan varias decisiones independientes: familia y tamaño, arquitectura, rol de entrenamiento y cuantización. Un repositorio puede empaquetar esos pesos como shards de Safetensors, mientras que una conversión comunitaria del mismo checkpoint puede aparecer como Q4_K_M.gguf.

Esas etiquetas no pertenecen a una única categoría: GPTQ y AWQ son métodos de cuantización, GGUF es un contenedor y un ecosistema de runtime, y MoE es una arquitectura. Leer cada capa por separado facilita la elección de la descarga.

Al elegir entre una descarga Q4_K_M.gguf para inferencia local y un repositorio de Safetensors AWQ para servir en GPU, empieza por el comportamiento del checkpoint y la arquitectura que necesita tu tarea. Después confirma que su representación numérica, la estructura del paquete y el runtime de destino encajan con el hardware, la memoria y las restricciones de serving disponibles.

TL;DR. Selecciona un checkpoint según la calidad en la tarea, la licencia, el idioma, el contexto y el comportamiento de la interfaz. Después selecciona un runtime compatible con su arquitectura. Solo entonces elige una representación de pesos y una cuantización que encajen con la memoria y la latencia medidas. GPTQ y AWQ son métodos de cuantización, Safetensors y GGUF son contenedores, y MoE es una arquitectura. Una etiqueta MoE no garantiza que todos los pesos quepan en la memoria correspondiente a los «parámetros activos».

Para una elección compacta de deployment, consulta Formatos de cuantización de LLM.

Lee un artefacto de modelo en seis capas

La procedencia del entrenamiento anota estas capas en lugar de añadir otra capa de artefacto. Por ejemplo, distilled describe cómo se ha transferido el comportamiento, no el rol del checkpoint. Un checkpoint puede ser distilled, instruction-tuned, reasoning-tuned y MoE al mismo tiempo.

La etiqueta «open-source» requiere una comprobación propia. Si un modelo solo publica pesos descargables, no des por hecho que su licencia cumple una definición de open source o permite tu caso de uso. Lee la model card y la licencia antes de comparar arquitecturas o benchmarks.

Las etiquetas del rol de entrenamiento describen el comportamiento, no garantizan capacidades

Base

Un checkpoint base se entrena principalmente para predecir el siguiente token. Resulta útil para continued pretraining, investigación controlada o adaptación cuando quieres controlar el comportamiento de instrucciones. Puede completar un prompt en lugar de responderlo.

No des por hecho que todo fine-tuning deba empezar desde un modelo base. Un checkpoint instruct puede ser una mejor inicialización si su comportamiento actual se alinea con el objetivo. Confirma mediante evaluación que el comportamiento existente no entra en conflicto con el nuevo objetivo.

Instruct o chat

Estos checkpoints reciben post-training orientado a mejorar el seguimiento de instrucciones y la conversación. La receta exacta puede incluir supervised fine-tuning, optimización de preferencias, reinforcement learning, distillation o una combinación de varias técnicas. No tiene por qué ser supervised fine-tuning seguido de RLHF.

Usa un checkpoint instruct como baseline inicial del asistente. Confirma su chat template, el formato de tool call compatible, el comportamiento ante mensajes de sistema y sus características de rechazo. «Instruct» por sí solo no garantiza JSON fiable ni tool use.

Reasoning-tuned

Los checkpoints orientados al reasoning se optimizan con tareas o trayectorias que premian la resolución de problemas en varios pasos. Algunos exponen texto de reasoning, otros lo separan mediante un parser del serving y otros solo muestran la respuesta. Una generación más larga no garantiza un reasoning fiel ni menos alucinaciones.

Adopta uno cuando mejore los slices difíciles de la evaluación después de tener en cuenta los tokens de salida, la latencia y la verificación. Las tareas rutinarias de extracción o clasificación pueden volverse más lentas sin mejorar.

Distilled

La distillation transfiere el comportamiento de un teacher o de datos generados por un teacher a otro modelo. El student puede ser más pequeño, tener el mismo tamaño o presentar una estructura diferente. No existe una regla estable del tipo «70–80 % de calidad con la mitad de tamaño»: la calidad conservada depende del teacher, los datos, el objetivo, la capacidad del student y la evaluación.

Trata Distill como información de procedencia del entrenamiento y hazle benchmark como a cualquier otro checkpoint.

¿Qué etiqueta debe influir en cada paso de selección? Este mapa mantiene separados el rol de entrenamiento, la procedencia del entrenamiento y la arquitectura. No establece una clasificación de tipos de modelo.

La documentación de chat templates de Transformers explica por qué importa el formato exacto de mensajes de un modelo instruction-tuned. En el artículo original sobre knowledge distillation, Hinton, Vinyals y Dean transfieren comportamiento a un student sin afirmar una proporción fija de calidad. El artículo sobre Switch Transformer presenta un diseño de routing disperso de experts. Una familia MoE concreta puede enrutar los tokens de forma diferente, por lo que su model card sigue siendo la fuente de referencia.

Las etiquetas de arquitectura describen la ejecución

Modelos dense

La mayoría de los parámetros participa en el forward pass de cada token. El número de parámetros es un indicador aproximado del almacenamiento de pesos. La memoria del runtime también incluye KV cache, activaciones o workspace, overhead del allocator y, en ocasiones, estado duplicado o shardeado.

Mixture of Experts

Una capa MoE enruta cada token a un subconjunto de redes feed-forward expert. Nombres como A3B suelen indicar que aproximadamente tres mil millones de parámetros están activos por token, pero las convenciones de nomenclatura son específicas de cada familia. Consulta la model card para conocer los parámetros totales, los parámetros activos, el número de experts y el diseño de routing.

El número de parámetros activos describe el compute enrutado, no la ubicación de los pesos. Por ejemplo, el expert parallelism de vLLM distribuye las capas de experts entre ranks de expert parallelism y calcula la asignación de experts de cada rank a partir del número total de experts. Otros runtimes pueden ubicar u offloadear los pesos de otra forma. Por tanto, un modelo de 30B totales y 3B activos no encaja automáticamente como un modelo dense de 3B.

La compatibilidad del runtime también depende de la arquitectura. Confirma la implementación del modelo, el soporte de expert parallel o tensor parallel, los kernels de cuantización y el contexto máximo antes de descargarlo.

Los contenedores y la cuantización son capas diferentes

Safetensors

Safetensors es un formato seguro de serialización de tensores utilizado habitualmente en repositorios de Hugging Face. Un modelo puede tener varios shards .safetensors, además de archivos de configuración, tokenizer y generación. Esos tensores pueden estar en BF16/FP16 o prequantizados con un método como GPTQ o AWQ.

La extensión por sí sola no indica la precisión ni la compatibilidad con el runtime. Inspecciona config.json, la configuración de cuantización, la model card, el dtype de los tensores y la documentación del runtime.

GGUF

GGUF empaqueta tensores y metadatos para el ecosistema ggml/llama.cpp. llama.cpp carga GGUF y admite backends como Metal, CUDA, HIP, Vulkan y rutas para CPU. La arquitectura del modelo y la calidad de la conversión siguen determinando la compatibilidad.

GGUF es un contenedor. Puede contener tensores de alta precisión o cuantizados. Los modelos multimodales también pueden necesitar un archivo independiente de projector o encoder. «Un único archivo GGUF contiene todo» no es una regla universal.

GPTQ y AWQ

GPTQ y AWQ son métodos de cuantización de pesos post-training, no extensiones de archivo. Sus artefactos suelen utilizar Safetensors junto con una configuración específica del método. Los motores de serving necesitan kernels compatibles con el método, el número de bits, el group size, la arquitectura del modelo y el hardware.

Ninguno de los dos métodos es superior en calidad de forma universal. Importan los datos de calibración, la implementación, la ruta de kernels y la tarea. El soporte del runtime cambia, así que verifica el artefacto exacto con la versión que hayas fijado. Consulta las páginas oficiales de cuantización de Transformers y cuantización de vLLM junto con esa decisión.

El hardware por sí solo no puede determinar el contenedor. Primero elige un runtime compatible con la arquitectura y la interfaz de serving. Después utiliza la estructura del artefacto y la ruta de cuantización documentadas por ese runtime.

Por ejemplo, el proyecto llama.cpp requiere GGUF y documenta varios backends de hardware. La especificación de GGUF define un contenedor para tensores y metadatos. Transformers, en cambio, carga los métodos de cuantización mediante configuración específica del backend, tal como describe su flujo de trabajo de cuantización. Ninguna de estas fuentes promete que una extensión compatible funcione con todas las arquitecturas o rinda bien en cualquier dispositivo.

Las matemáticas de la cuantización son un límite inferior, no una planificación de capacidad

Para $P$ parámetros de pesos a $b$ bits, el almacenamiento bruto de los pesos es aproximadamente:

Un modelo de 13B con pesos nominales de cuatro bits parte, por tanto, de unos 6,5 GB. No necesariamente funcionará en 6,5 GB. Las escalas, los zero points, los tensores de mayor precisión, los embeddings, los metadatos, los buffers del runtime, la KV cache y la fragmentación añaden memoria.

El contexto y la concurrencia pueden dominar la diferencia entre «carga» y «sirve». Mide la memoria máxima con la secuencia máxima real, la política de batch, el dtype de la cache y el paralelismo que vayas a utilizar.

La cuantización puede reducir la memoria y, en ocasiones, mejorar la velocidad, pero los kernels de pocos bits también pueden ser más lentos en hardware no compatible. Compara la calidad en la tarea y el throughput de extremo a extremo, no solo el tamaño del archivo. Consulta la guía de cuantización de llama.cpp para ver recetas específicas del runtime.

Interpreta con cuidado los nombres de cuantización de GGUF

En llama.cpp, Q4_K_M da nombre a una receta de cuantización a nivel de archivo, no a un único tipo de tensor aplicado en todas partes. Las opciones de llama-quantize exponen Q4_K_M como tipo seleccionable y describen --pure como la desactivación de las mezclas de K-quant. La implementación del cuantizador utiliza Q4_K como valor predeterminado para esta receta y aplica otros tipos a algunas categorías de tensores. Trata el sufijo como un nombre de receta llama.cpp, no como una especificación de número de bits portable.

La documentación actual de cuantización de llama.cpp también muestra que las recetas pueden variar según la arquitectura y la categoría de tensor. Una matriz de importancia puede guiar qué pesos conservan una mayor precisión.

Evita afirmaciones universales como que Q4_K_M es indistinguible de BF16 o que un modelo Q3 más grande siempre supera a un modelo Q8 más pequeño. Utiliza una pequeña escalera para el checkpoint exacto:

1. artefacto de alta precisión o de referencia fiable
2. un candidato cercano al límite de memoria
3. un candidato más pequeño con mayor margen

Ejecuta los mismos prompts, comprobaciones de structured output, casos de contexto largo y pruebas de latencia en los tres.

Un flujo de selección que resiste la aparición de nuevos formatos

1. Fija el contrato de la tarea

Define el idioma, la modalidad, la longitud de contexto, la interfaz de tool o schema, las restricciones de seguridad, los requisitos de licencia y los slices de evaluación. Compara los checkpoints con una representación suficientemente precisa para que la cuantización no decida la primera ronda.

2. Selecciona el checkpoint

Elige el checkpoint más pequeño que supere los gates no negociables de calidad y comportamiento. Registra el repositorio y la revisión exactos, el tokenizer, el chat template y cualquier parser de reasoning necesario.

3. Selecciona el runtime

Comprueba el soporte de arquitectura, el backend de hardware, el paralelismo, los kernels de cuantización, el structured output, los adapters y la interfaz operativa. Para inferencia local con GGUF, llama.cpp es el runtime de referencia. Para serving en GPU, compara vLLM, TGI, Transformers o motores especializados actuales con el artefacto real.

4. Establece un presupuesto de memoria medido

Incluye los pesos, la KV cache, el workspace del runtime, la concurrencia prevista y margen para el sistema operativo o procesos que compartan la máquina. Que un archivo quepa en RAM o VRAM es necesario, pero no suficiente.

5. Elige y valida una representación

Prioriza los artefactos proporcionados por el publisher con calibración y procedencia documentadas. Si utilizas una conversión comunitaria, registra la revisión de origen, la revisión del conversor, la receta de cuantización, los datos de calibración o importancia y los hashes.

6. Haz benchmark de la unidad de release

Mide la calidad en la tarea, la corrección del schema y de los tool calls, el tiempo hasta el primer token, el throughput de salida, la memoria máxima y los fallos con el contexto y la concurrencia objetivo. Repite las pruebas después de cambiar cualquier checkpoint, runtime, kernel o ajuste de cuantización.

Ejemplo de nombre

Supón que un repositorio se llama:

Acme-32B-A3B-Instruct-AWQ

Interprétalo como un conjunto de preguntas:

• Acme: ¿qué familia, licencia y revisión?
• 32B: ¿pesos totales u otra convención del publisher?
• A3B: ¿cómo define esta familia los parámetros activos?
• Instruct: ¿qué receta de post-training y qué chat template?
• AWQ: ¿qué número de bits, group size, calibración y kernels compatibles?
• archivos del repositorio: ¿shards de Safetensors, configuraciones, tokenizer y código personalizado?
• runtime objetivo: ¿la versión fijada admite exactamente esta arquitectura y esta cuantización?

El nombre es un índice hacia la documentación, no una especificación completa de deployment.

Conclusión

La selección de modelos resulta menos confusa cuando las etiquetas dejan de tratarse como si pertenecieran a una misma categoría. El rol de entrenamiento indica qué comportamiento se ha optimizado. La arquitectura indica cómo se organiza el cómputo. La cuantización indica cómo se han aproximado algunos tensores; los contenedores, cómo se almacenan los artefactos; y los runtimes, qué se ejecuta de forma eficiente en tu hardware.

Elige en ese orden, conserva la procedencia exacta y utiliza una única evaluación de la tarea para comparar los artefactos de release. Un sufijo conocido no demuestra que el modelo quepa, funcione rápido o conserve el comportamiento que necesitas.

Referencias

• Chat templates de Transformers - Formato de mensajes para modelos de lenguaje causales base y instruction-tuned.
• Distilling the Knowledge in a Neural Network - Artículo original sobre distillation de Hinton, Vinyals y Dean.
• Switch Transformers - Arquitectura de routing disperso de experts de Fedus, Zoph y Shazeer.
• Especificación de GGUF y guía de cuantización de llama.cpp
• Conceptos de cuantización de Hugging Face Transformers
• Artículo sobre GPTQ
• Artículo sobre AWQ
• Documentación de cuantización de vLLM