TurboQuant: cuantizar modelos grandes para que quepan en local

#¿Por qué TurboQuant?

Los K-quants GGUF (Q4_K_M, Q5_K_M…) son la referencia desde 2023: son compatibles con llama.cpp, Ollama y LM Studio de forma universal y fáciles de producir. Pero alcanzan su límite en los modelos muy grandes. Un modelo denso de 70B en Q4_K_M requiere aproximadamente 40 GB de VRAM, fuera del alcance de una RTX 4090 de 24 GB. Bajar a Q3 o Q2 hace que la calidad se desplome.

La cuantización TurboQuant aborda específicamente esta carencia. Es una familia de técnicas que combinan la calibración con un conjunto de datos, la asignación no uniforme de bits por capa y la compresión por bloques con un diccionario compartido. El resultado: de 2,5 a 3 bits efectivos por peso con una pérdida de calidad inferior a la de un Q3_K_M GGUF.

#Cómo funciona la compresión

Tres mecanismos se acumulan. Ninguno es revolucionario por sí solo; es su combinación la que hace la diferencia.

Calibración con datos

Se pasan unos cientos de prompts representativos por el modelo para medir qué pesos influyen realmente en las salidas. Los demás se pueden cuantizar de forma agresiva.

Asignación de bits por capa

En lugar de un presupuesto fijo (4 bits en todas partes), TurboQuant asigna 5-6 bits a las capas de atención críticas y baja a 2 bits en MLP redundantes. El promedio total baja a 2,7-3,2 bpw.

Compresión por bloques

Los pesos se agrupan en bloques de 32 o 64 valores que comparten un factor de escala y un desplazamiento, con un libro de códigos comprimido por grupo. Esto evita el sobrecoste por parámetro de los K-quants.

#TurboQuant vs GGUF clásico

Para un modelo denso de 70B, este es el orden de magnitud típico:

GGUF Q4_K_M (~4.5 bpw)

~40 GB, calidad cercana a FP16, compatible en todas partes. La referencia.

GGUF Q3_K_M (~3.4 bpw)

~32 GB, pérdida notable de capacidad en razonamientos largos; aparecen alucinaciones.

GGUF Q2_K (~2.6 bpw)

~26 GB, modelo claramente degradado, evitar para un uso serio.

TurboQuant ~3.0 bpw

~28 GB, calidad similar a la de Q4_K_M. Cabe en 1×RTX 3090 o 1×4090 con un contexto corto.

TurboQuant ~2.5 bpw

~23 GB, ligeramente por debajo del Q4 pero bien por encima del Q3. Permite el 70B en 24 GB de VRAM.

#Ahorro de VRAM medido por tamaño del modelo

Las cifras siguientes son órdenes de magnitud para modelos densos recientes (Qwen 3.5, Granite 4.2), con un contexto de 4k, sin Flash Attention. Añade un margen del 10-20 % para la caché KV y la sobrecarga del entorno de ejecución.

7B — Q4_K_M: 4.4 GB

TurboQuant 3.0 bpw: ~2.9 GB. Interés limitado: el 7B ya cabe en cualquier equipo.

13B — Q4_K_M : 7.8 GB

TurboQuant 3.0 bpw: ~5.1 GB. Permite 16k+ de contexto en 8 GB de VRAM.

32B — Q4_K_M : 19 GB

TurboQuant 3.0 bpw: ~13 GB. Cabe holgadamente en una RTX 4080 de 16 GB con un contexto de 8k.

70B — Q4_K_M : 40 GB

TurboQuant 2.5 bpw: ~23 GB. Permite el 70B en 1×RTX 4090 de 24 GB o 1×3090 de 24 GB.

120B MoE — Q4_K_M : ~70 GB

TurboQuant 2.7 bpw: ~42 GB. Viable con 2×3090 o un Mac Studio de 64 GB.

#Impacto en la calidad

En los benchmarks habituales (MMLU, HellaSwag, HumanEval), un modelo de 70B cuantizado con TurboQuant a 3.0 bpw queda a 0.5-1.5 puntos del FP16. En el razonamiento multietapa y en código largo, empezamos a ver diferencias más claras. La prueba que distingue más claramente los métodos: un fragmento largo de código Python con dependencias cruzadas.

Conocimientos generales

Casi imperceptible. Si haces preguntas de cultura general, no verás la diferencia.

Razonamiento corto

Pérdida leve. Las cadenas de pensamiento permanecen coherentes en 5-10 pasos.

Razonamiento largo (matemáticas/demostraciones)

Pérdida visible. El modelo puede saltarse un paso o perderse después de más de 20 turnos de razonamiento. Prioriza 3,5 bpw o más si ese es tu uso.

Código

Sensible a las cuantizaciones agresivas. Por debajo de 3.0 bpw, espera más errores sutiles (índices incorrectos, condiciones invertidas). Usa Q4_K_M o TurboQuant ≥3.5 bpw para Aider/Continue.

Idiomas poco comunes

El francés funciona bien hasta 2,5 bpw. Los idiomas poco representados en el corpus de calibración sufren más.

#Requisitos de hardware y software

Cuantizar un modelo por tu cuenta sigue siendo una tarea compleja. Descargarlo ya cuantizado desde Hugging Face es casi siempre más sencillo. Si aun así quieres producir tu propia versión:

GPU para la calibración

Se debe poder cargar el modelo en FP16 o en BF16 durante el análisis. Para un 70B, se necesitan 2×A100 de 80 GB o un Mac Studio M2 Ultra de 192 GB. Para un 32B, una RTX 4090 de 24 GB basta con offload parcial.

Modelo base

Los pesos no cuantizados (safetensors) descargados desde el repositorio original de Hugging Face. Calcula 140 GB para un 70B FP16.

Dataset de calibración

256 a 1024 muestras representativas de tu uso. Wikipedia FR, código, tus propios prompts. Evita conjuntos de datos genéricos si tienes un dominio específico.

Entorno de ejecución de destino

Decide de antemano: ExLlamaV3 (el más rápido en Nvidia), llama.cpp con backend turbo o un fork específico. El formato de archivo varía entre runtimes.

Python 3.10+ y CUDA 12+

Cadena de herramientas estándar. Del lado de AMD, ROCm 6.x funciona con llama.cpp pero no (aún) con todos los forks turbo.

#Flujo de trabajo para cuantizar por tu cuenta

El flujo típico, desde un modelo Hugging Face FP16 hasta un archivo ejecutable en Ollama o llama.cpp.

1. 01
   Recuperar los pesos originales

   Clonar el repositorio de Hugging Face del modelo no cuantizado. Calcular al menos una hora para un 70B con una buena conexión. Usa huggingface-cli download para poder reanudar la descarga tras una interrupción.
2. 02
   Preparar el conjunto de datos de calibración

   Crear un archivo JSONL con 256-1024 prompts. La diversidad es más importante que la cantidad: código, prosa francesa, diálogos, preguntas técnicas. Un archivo de 5-20 MB es más que suficiente.
3. 03
   Iniciar la calibración

   La herramienta (por ejemplo, el script quantize proporcionado por el proyecto TurboQuant elegido) carga el modelo, realiza una pasada hacia delante con cada prompt y recopila estadísticas de activación capa por capa. Calcula entre 1 y 4 horas para un 70B, según la GPU.
4. 04
   Cuantizar y exportar

   La asignación de bits se calcula a partir de las estadísticas y luego se codifica cada tensor. Salida: un archivo .safetensors o .gguf según el entorno de ejecución. Calcula entre 30 minutos y 2 horas adicionales.
5. 05
   Convertir al formato de ejecución

   Para Ollama: crear un Modelfile que apunte al archivo cuantizado, luego ejecutar ollama create monmodele -f Modelfile. Para llama.cpp: el binario main acepta directamente el archivo .gguf.
6. 06
   Validar la calidad

   Ejecutar una pequeña batería de pruebas: 20-30 prompts que cubran tus usos. Comparar ambos resultados lado a lado con la versión GGUF Q4_K_M de referencia. Si la degradación es demasiado grande, repetir con más bits o un mejor conjunto de datos.

# Une fois le .gguf TurboQuant produit
cat > Modelfile <<EOF
FROM ./glm-4.7-turboquant-3.0bpw.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create glm-4.7-turbo -f Modelfile
ollama run glm-4.7-turbo "Explique le théorème de Bayes en 3 phrases."

#Errores comunes y solución de problemas

El entorno de ejecución no reconoce el archivo

TurboQuant no es un formato estándar único. Asegúrate de cargar el archivo con el entorno de ejecución correspondiente al método utilizado (ExLlamaV3 para EXL3, una versión reciente de llama.cpp para los GGUF turbo).

Se supera la capacidad de la VRAM durante la inferencia aunque el archivo cabía en ella

Olvidas la caché KV. En un contexto de 32k, el KV puede ocupar 4-8 GB adicionales. Reduce num_ctx o activa Flash Attention mediante OLLAMA_FLASH_ATTENTION=1.

Calidad catastrófica en tu caso de uso

El conjunto de datos de calibración no cubre tu dominio. Vuelve a hacerlo añadiendo 100-200 prompts representativos. Es, con diferencia, la medida más eficaz.

El modelo cuantizado es más lento que el Q4_K_M

Es normal en ciertas arquitecturas: la descompresión turbo añade una sobrecarga. En tarjetas antiguas (RTX 20xx), el ahorro de VRAM puede lograrse a costa de una reducción de los tokens/segundo. Mide antes de adoptarlo.

Diferencias entre ejecuciones

La calibración introduce no determinismo. Dos cuantizaciones del mismo modelo con el mismo conjunto de datos pueden divergir ligeramente en calidad. Haz varias ejecuciones y conserva la mejor.

#Para ir más allá

TurboQuant es una herramienta entre otras para ampliar el límite de lo que cabe localmente. Algunas opciones complementarias:

Elegir tu cuantización (Q4, Q5, Q8, FP16)

Para ubicar bien TurboQuant frente a los K-quants GGUF clásicos y elegir caso por caso.

Fine-tuning de LLM en local: LoRA y QLoRA

Si quieres ir más allá de la cuantización y adaptar un modelo a tu dominio —a menudo un mejor enfoque que una cuantización más agresiva.

Elegir tu GPU para IA local

Para decidir qué tarjeta elegir, sabiendo que la VRAM sigue siendo la principal limitación, incluso con TurboQuant.