Skip to main content
MACaQ: Huawei libera su cuantizador y lo pone a hablar GGUF

This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.

3 min read

MACaQ: Huawei libera su cuantizador y lo pone a hablar GGUF

Sesenta y cuatro minutos y 32,5 GB de memoria para cuantizar un modelo de 122.000 millones de parámetros. Esa es la cifra con la que Huawei presenta MACaQ, la herramienta de cuantización que su Computing Systems Lab acaba de publicar en GitHub con licencia Apache 2.0.

Lo primero que hice fue buscar en qué GPU. El README no lo dice. Así que tomo el dato como lo que es: una cifra del propio autor, sin contexto de hardware, que habrá que ver reproducida por alguien más.

Qué es exactamente

MACaQ es un cuantizador "agnóstico al modelo": la idea es que no dependa de la arquitectura concreta y que sirva igual para un modelo de texto que para uno de imagen, vídeo o audio. El repositorio lo organiza por backends, cada uno con su entorno de Python 3.12 por separado:

  • llama.cpp, para sacar modelos de texto en GGUF de 2, 3 y 4 bits, con un runtime incluido que también tira de CPU.
  • vLLM, para servir en W4A4 (pesos y activaciones a 4 bits) o solo pesos.
  • Diffusers, para generación de imagen, vídeo y audio en W4A4.
  • PyTorch, para síntesis de voz con modelos como Qwen3-TTS.

Hay además soporte para los aceleradores Ascend de la propia Huawei, vía dos pull requests en CANN. No es casualidad: a Huawei le interesa que la cuantización a 4 bits funcione bien en su hardware.

En cuanto a calidad, el proyecto afirma mejor perplejidad que MR-GPTQ y DuQuant++, o igualar su mejor resultado en Llama-3-8B tardando once veces menos. En su tabla con Qwen3.8-27B sobre vLLM, la perplejidad pasa de 2,8463 en BF16 a 2,8994 en W4A4, con el prefill 2,33 veces más rápido y la decodificación 2,58 veces. Son números autodeclarados; el paper está en arXiv (2611.10649) y todavía no he visto comparativas independientes.

La parte que me ha hecho pararme: MACaQ-R

De todo el anuncio, lo que me parece más práctico es MACaQ-R. En lugar de cuantizar desde cero, coge un GGUF que ya existe y refina los códigos de los pesos manteniendo el formato nativo y las escalas por bloque. El resultado sigue abriéndose con un llama.cpp normal, sin parches.

Su ejemplo es Qwen3.6-35B-A3B: con el mismo tamaño de 22,36 GB, la divergencia KL frente a FP16 baja de 0,015731 en el Q4_K_XL de Unsloth a 0,013367 en su versión refinada. Es una mejora modesta en números absolutos. Pero gratis en tamaño, y eso cuenta.

El comando que enseñan es de este estilo:

bash
.venv-llamacpp/bin/python llamacpp/macaq.py refine \
  --model models/model-q4.gguf --hf models/original \
  --teacher models/original-f16.gguf --calibration data/calibration.txt \
  --output models/model-macaq-r.gguf --work-dir work/refinement

Fíjate en el detalle: necesitas el modelo original y una versión FP16 que haga de "profesor". O sea, el refinado lo haces en una máquina con memoria de sobra, y el fichero final lo llevas a donde vayas a ejecutarlo.

Mi lectura

Desde sistemas, la cuantización es lo que decide si un modelo pasa de "interesante" a "lo puedo desplegar". Y hasta ahora el flujo habitual era descargar el GGUF que alguien de la comunidad hubiera subido y fiarte de su receta. Que aparezca una herramienta abierta, con licencia permisiva y respaldada por un laboratorio grande, abre la puerta a algo distinto: generar tus propias cuantizaciones con tus propios datos de calibración.

Ahí tengo una duda que me apunto para la UNED. La calibración se hace con un texto de ejemplo, y es razonable pensar que un modelo calibrado con documentación técnica en español se comporte distinto que uno calibrado con texto genérico en inglés. ¿Cuánto? No lo sé, y no lo he probado todavía.

También me guardo algo de cautela. Son 230 estrellas, muy pocos días de vida y benchmarks propios. Antes de cambiar nada de lo que uso, quiero ver a alguien de fuera comparando un MACaQ-R contra los GGUF de siempre en tareas reales, no solo en perplejidad.

Si cuantizar deja de ser cosa de unos pocos que publican sus ficheros y pasa a ser un paso más del despliegue, ¿empezaremos a ver equipos que calibran sus modelos con sus propios tickets y manuales internos?

Fuentes

David González Lombraña

Apuntes, laboratorio y proyectos de IA, Linux y redes.