2025-05-11 · Actualizado 2026-07-15

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

Variantes de peso abierto LLM, cuantización y formatos: Instruct, MoE, GGUF, GPTQ y AWQ

Nombres como Model-32B-A3B-Instruct-AWQ Parece complejo porque combina varias decisiones independientes: familia y tamaño, arquitectura, rol de entrenamiento y cuantización. Un repositorio puede empaquetar dichos pesos como Safetensors fragmentados, mientras que una conversión comunitaria del mismo checkpoint se presenta como Q4_K_M.gguf.

Esos etiquetas no pertenecen a la misma categoría: GPTQ y AWQ son métodos de cuantización, GGUF es un contenedor y runtime un ecosistema, mientras que MoE corresponde a una arquitectura. Al analizar las capas por separado, resulta mucho más sencillo decidir qué descargar.

Resumen. Se debe elegir un checkpoint en función de la calidad de la tarea, la licencia, el idioma, el contexto y el comportamiento de la interfaz. A continuación, se selecciona un runtime que sea compatible con su arquitectura. Solo después se eligen una representación de pesos y una forma de cuantización adecuadas a las limitaciones de memoria y latencia medidas. GPTQ y AWQ son métodos de cuantización; Safetensors y GGUF son contenedores, mientras que MoE se refiere a una arquitectura, no a una garantía de que todos los pesos cabrán en la memoria destinada a los “parámetros activos”.

Leer un artefacto de modelo en seis capas

Estas capas no son mutuamente excluyentes. Un checkpoint puede ser destilado, ajustado mediante instrucciones, ajustado para el razonamiento y MoE al mismo tiempo.

“Código abierto” también requiere atención especial. Muchos modelos descargables son de peso abierto según licencias que no cumplen con la definición de código abierto o que imponen restricciones en su uso. Es necesario leer la ficha del modelo y la licencia antes de diseñar la arquitectura o realizar comparaciones benchmark.

Las etiquetas de rol de entrenamiento describen el comportamiento, no garantizan capacidades específicas

Base

Una base checkpoint se entrena principalmente para la predicción del siguiente token. Resulta útil para realizar preentrenamiento continuo, investigaciones controladas o procesos de adaptación en los que se desea tener el control total sobre el comportamiento ante las instrucciones. Puede completar un prompt en lugar de responder a él.

No asuma que cada proceso de ajuste fino debe iniciarse a partir de la versión base. Un modelo ya entrenado checkpoint puede resultar ser una inicialización más adecuada si su comportamiento actual coincide con los requisitos del objetivo, y si su evaluación confirma que no entra en conflicto con el nuevo propósito.

Instruir o chatear

Estos checkpoints reciben entrenamiento posterior cuyo objetivo es mejorar la capacidad de seguimiento de instrucciones y la interacción en conversación. La receta exacta puede incluir fine-tuning supervisado, optimización de preferencias, aprendizaje por refuerzo, destilación, o combinaciones de estos métodos; no necesariamente se trata de un enfoque clásico basado en SFT junto con RLHF.

Utilice una instrucción checkpoint como punto de partida básico para el primer asistente. Confirme su plantilla de chat, el formato permitido para las llamadas a herramientas, el comportamiento de los mensajes del sistema y las características de rechazo. El mero uso de la palabra “Instruct” no garantiza un JSON ni un tool use fiables.

Ajustado para razonamiento

Los modelos orientados al razonamiento checkpoints están optimizados para tareas o trayectorias que premian la resolución de problemas en múltiples pasos. Algunos exponen el texto del razonamiento, otros lo separan mediante un analizador serving, y otros solo presentan una respuesta. Una generación más extensa no garantiza un razonamiento fidedigno ni una menor cantidad de alucinaciones.

Se debe adoptar una cuando mejora las partes críticas que son relevantes tras tener en cuenta los tokens de salida, la latencia y la verificación. La extracción o clasificación rutinaria puede volverse más lenta sin que su calidad aumente.

Destilado

La destilación permite transferir el comportamiento de un modelo maestro o de datos generados por este a otro modelo. El modelo estudiante puede ser más pequeño, del mismo tamaño o tener una estructura distinta. No existe una regla fija que establezca que “se mantenga un 70–80 % de la calidad con la mitad del tamaño”; la calidad conservada depende del modelo maestro, de los datos, de los objetivos, de la capacidad del modelo estudiante y de los métodos de evaluación utilizados.

Tratar Distill Como información de origen relativa al entrenamiento, entonces benchmark se trata como cualquier otro checkpoint.

Las etiquetas de arquitectura describen la ejecución

Modelos densos

La mayoría de los parámetros intervienen en el paso forward de cada token. El número de parámetros sirve como indicador aproximado del espacio de almacenamiento necesario para las ponderaciones, pero la memoria runtime también incluye KV cache, las activaciones o el espacio de trabajo, la sobrecarga del gestor de asignación, y en ocasiones estados duplicados o fragmentados.

Mezcla de expertos

Una capa MoE dirige cada token hacia un subconjunto de redes feedforward especializadas. Nombres como A3B Por lo general, esto implica que hay aproximadamente tres mil millones de parámetros activos por token, aunque las convenciones de nomenclatura varían según la familia del modelo. Consulte la ficha técnica del modelo para conocer el número total de parámetros, los parámetros activos, el conteo de expertos y el diseño de enrutamiento.

Los parámetros activos describen principalmente los recursos de cómputo necesarios. A menos que runtime transfiera la ejecución a los expertos especializados, todos los pesos de dichos expertos siguen requiriendo almacenamiento, generalmente en la memoria del dispositivo distribuida a lo largo de la topología de serving. Un modelo con un total de 30 mil millones de parámetros y 3 mil millones activos no se adapta automáticamente como lo haría un modelo denso de 3 mil millones de parámetros.

La compatibilidad con Runtime también depende específicamente de la arquitectura. Antes de descargarlo, es necesario verificar la implementación del modelo, así como si ofrece soporte para procesamiento en paralelo por expertos o por tensores, los kernels de cuantización y el tamaño máximo de contexto permitido.

Los contenedores y la cuantización son capas distintas

Safetensors

Safetensors es un formato de serialización de tensores seguro que se utiliza habitualmente en los repositorios Hugging Face. Un modelo puede contener múltiples .safetensors los fragmentos, junto con los archivos de configuración, tokenizador y generación. Dichos tensores pueden ser BF16/FP16 o pre-cuantizados mediante un método como GPTQ o AWQ.

La extensión por sí sola no indica la precisión ni la compatibilidad con runtime. Es necesario inspeccionarla. config.json, configuración de cuantización, ficha del modelo, tipo de dato del tensor y documentación de runtime.

GGUF

GGUF Empaqueta tensores y metadatos para el ecosistema ggml/llama.cpp. llama.cpp Requiere GGUF y admite servidores backend como Metal, CUDA, HIP, Vulkan y rutas de tipo CPU. La arquitectura del modelo y la calidad de la conversión siguen siendo los factores determinantes para la compatibilidad.

GGUF es un contenedor. Puede albergar tensores de alta precisión o cuantizados. Los modelos multimodales también pueden requerir un archivo de proyección o codificador separado; la afirmación de que “un solo archivo GGUF contiene todo” no es una regla universal.

GPTQ y AWQ

GPTQ y AWQ son métodos de cuantización de pesos posteriores al entrenamiento, y no extensiones de archivo. Sus artefactos suelen emplear Safetensors junto con una configuración específica del método. Los motores de Serving requieren núcleos compatibles con el método, el ancho de bits, el tamaño del grupo, la arquitectura del modelo y el hardware.

Ninguno de estos métodos constituye una solución universal para garantizar la mejor calidad. Los datos de calibración, la implementación, la ruta del kernel y la tarea son factores determinantes. Los Transformadores de Corriente, TGI, y vLLM admiten varios backends de cuantización, pero sus matrices varían; por lo tanto, es necesario verificar los valores fijos de runtime en lugar de confiar en tablas estáticas publicadas en blogs.

La matemática de la cuantización representa un límite inferior, no una herramienta para la planificación de capacidad

Para los parámetros de peso (P) con (b) bits, el almacenamiento bruto de los pesos es aproximadamente:

[ \text{bytes de peso} \approx \frac{P \times b}{8} ]

Un modelo de 13 mil millones de parámetros con pesos nominales de cuatro bits comienza, por lo tanto, con un tamaño cercano a los 6,5 GB. No necesariamente funcionará ocupando únicamente esos 6,5 GB. Los escalones, los puntos cero, los tensores de mayor precisión, embeddings, los metadatos, los buffers runtime, KV cache, y la fragmentación añaden memoria adicional.

El contexto y la concurrencia pueden marcar la diferencia entre los conceptos de “cargas” y “servicios”. Es necesario medir el consumo máximo de memoria teniendo en cuenta la secuencia real de operaciones, la política de procesamiento por lotes, el tipo de datos del caché y el nivel de paralelismo.

La cuantización puede reducir el consumo de memoria y, en ocasiones, mejorar la velocidad, pero los núcleos de pocos bits también pueden ser más lentos en hardware no compatible. Es necesario comparar la calidad de la tarea y el rendimiento de punta a punta, y no solo el tamaño del archivo.

Decodifique con cuidado los nombres de cuantización de GGUF

In Q4_K_M:

• Q4 Indica una familia de cuantización de cuatro bits, aunque no todos los tensores requieren exactamente cuatro bits. K Identifica el esquema K-quant. M Identifica una receta mixta que emplea diferentes tipos de tensores para los pesos seleccionados. Esto no se refiere al “tamaño de bloque medio”.

El actual llama.cpp

Evite hacer afirmaciones universales que Q4_K_M no es distinguible de BF16, ni existe la certeza de que un modelo Q3 de mayor tamaño siempre supere a uno Q8 de menor tamaño. Para el cálculo preciso de checkpoint, se debe emplear una escalera de valores más reducida:

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

Ejecuta los mismos controles de prompts de salida estructurada, casos de contexto largo y pruebas de latencia en los tres sistemas.

Un flujo de trabajo de selección capaz de adaptarse a nuevos formatos

1. Corregir el contrato de tarea

Define el lenguaje, la modalidad, la longitud de contexto, la interfaz de herramientas o esquemas, las restricciones de seguridad, los requisitos de licencia y las porciones de evaluación. Compara checkpoints en una representación lo suficientemente precisa como para evitar que la cuantización influya en la decisión de la primera ronda.

2. Seleccione el checkpoint

Elija el checkpoint más pequeño que cumpla con los requisitos ineludibles en cuanto a calidad y comportamiento. Anote el repositorio y la revisión exactos, así como el tokenizador, la plantilla de chat y cualquier analizador de razonamiento necesario.

3. Seleccione el runtime

Verifique el soporte de la arquitectura, el hardware backend, el paralelismo, los kernels de cuantización, structured output, los adaptadores y la interfaz operativa. En el caso de la inferencia local GGUF, llama.cpp La referencia es runtime. En el caso de GPU serving, se debe comparar el vLLM actual, TGI, los modelos Transformers o los motores especializados con el artefacto real.

4. Definir un presupuesto de memoria controlado

Incluir los pesos, el espacio de trabajo KV cache y runtime, la concurrencia esperada, así como el margen disponible para el sistema operativo o los procesos ubicados en el mismo hardware. Es necesario que un archivo que quepa en la RAM o en VRAM esté presente, pero eso no es suficiente por sí solo.

5. Elegir y validar una representación

Se prefieren los artefactos proporcionados por el fabricante, que incluyan documentación sobre su calibración y procedencia verificables. Si se utiliza una conversión de la comunidad, es necesario registrar la versión del código fuente, la versión del convertidor, las reglas de cuantización, los datos de calibración o importancia, así como los hashes correspondientes.

6. Benchmark la unidad de lanzamiento

Medir la calidad de la tarea, la corrección del esquema y de las llamadas a herramientas, el tiempo hasta obtener el primer token, el rendimiento de salida, el consumo máximo de memoria, así como los fallos en el contexto y nivel de concurrencia objetivo. Volver a ejecutar la medición después de modificar cualquier checkpoint, runtime, el núcleo del sistema o la configuración de cuantización.

Nombre funcional

Supongamos que un repositorio se denomina:

Acme-32B-A3B-Instruct-AWQ

Lee esto como un conjunto de preguntas:

• Acme: ¿Qué familia, licencia y revisión? 32B: ¿pesos totales o alguna convención distinta de la editorial? A3B: ¿Cómo define esta familia los parámetros activos? Instruct: ¿Qué receta de posentrenamiento y plantilla de chat? AWQ: ¿Qué ancho de bits, tamaño de grupo, calibración y kernels compatibles?
• Archivos del repositorio: fragmentos Safetensors, configuraciones, tokenizador y código personalizado.
• Target runtime: ¿La versión fijada es compatible con esta arquitectura y nivel de cuantización específicos?

El nombre sirve como índice en la documentación, y no constituye una especificación completa de despliegue.

Conclusión

La selección de modelos deja de ser confusa en cuanto las etiquetas dejan de pertenecer al mismo grupo. El rol de entrenamiento indica qué comportamiento se ha optimizado. La arquitectura explica cómo está organizada la computación. La cuantización muestra cómo se han aproximado algunos tensores. Los contenedores indican cómo se almacenan los artefactos. Los entornos de ejecución determinan qué se ejecuta de forma eficiente en tu hardware.

Elige en ese orden, preservando la procedencia exacta, y permite que una evaluación de tareas compare los artefactos de la versión publicada. Un sufijo conocido no constituye evidencia de que el modelo sea adecuado, funcione rápidamente ni mantenga el comportamiento que necesitas.

Referencias

• especificación GGUF y llama.cpp guía de cuantización
• Hugging Face Conceptos de cuantización en Transformers
• el artículo académico sobre GPTQ
• AWQ papel
• Documentación sobre cuantización de vLLM