Medir LLM cuantizados: qué se pierde al comprimir un modelo abierto

Cuarta entrega de Radiografía del clúster. Es el mejor ejemplo de lo que decía la entrada de resumen : el clúster hoy es sobre todo un laboratorio de medida. Aquí no se entrena un parámetro.

La pregunta #

Los modelos abiertos se distribuyen cuantizados: los mismos pesos comprimidos a 8, 6, 5, 4, 3 o 2 bits para que quepan en una tarjeta pequeña o en un portátil. La comunidad publica cientos de variantes, pero rara vez con una medida comparable de lo que se pierde. La línea pregunta cuánto rinde de verdad cada nivel de cuantización de cada familia en tareas que importan para usar el modelo como herramienta, y a qué velocidad y coste energético lo hace en cada tarjeta.

Cómo se aborda #

Casi 300 ficheros GGUF distintos de familias como Qwen (2.5 a 3.8), Gemma 3 y 4, GLM, DeepSeek, Mixtral, Llama 3, Mistral, gpt-oss, Nemotron, Granite, SmolLM o Phi-3, además de modelos ternarios experimentales, y la escalera completa: BF16, Q8_0, Q6_K, Q5_K_M, Q4_K_M (la más común), Q3, Q2, la serie UD de Unsloth con sus IQ1 a IQ4, MXFP4 y NVFP4. Para varias familias se generan curvas de siete u ocho niveles del mismo modelo.

Tres exámenes, elegidos porque miden al modelo como herramienta y no como conversador:

BFCL, llamada a funciones: si el modelo produce la llamada correcta con los argumentos correctos.
BigCodeBench, 148 problemas de programación con bibliotecas reales.
RULER, recuperación en contextos de 4K a 128K tokens.

A eso se suman tokens por segundo por tarjeta, la memoria real que ocupa cada fichero, la perplejidad sobre wikitext-2 en los barridos de cuantización, y la energía: se mide el consumo en reposo de cada nodo y se resta al consumo durante la generación.

El método tiene dos reglas que lo hacen comparable. Cada punto lleva un manifiesto con el fichero, la cuantización, la caché KV, el contexto, el binario con su suma de verificación y la tarjeta. Y antes de medir nada, se reproduce la nota publicada de un modelo ancla: si la desviación pasa de cinco puntos, el fallo es del arnés, no del modelo.

Qué se aprende #

Varios hallazgos quedaron escritos en los propios scripts, con fecha:

Cuantizar la caché KV no es gratis ni forma parte del protocolo. Con Gemma 4 rompe: bucles degenerados en 101 de 148 problemas, frente a un resultado limpio con la caché en f16.
Cambiar de tarjeta cambia la salida. Solo 21 de 148 respuestas fueron idénticas entre una L4 y una H200 con la misma configuración. Las comparaciones se hacen siempre en la misma tarjeta.
Se mide al modelo, no al andamiaje. BFCL se ataca por la API de compleción cruda: «por la vía nativa mediríamos al modelo más el andamiaje».
Un ancla que no se puede descargar no es un ancla: cuando Llama 3.1 8B quedó tras un muro de aceptación, el ancla de contexto largo pasó a Phi-3 mini.

Y una regla de seguridad que forma parte del método: el clúster genera texto, nunca ejecuta el código que escribe el modelo. La corrección de BigCodeBench, que sí ejecuta ese código, ocurre en un contenedor aislado en una máquina aparte. La fase multi-turno de BFCL, que ejecuta llamadas durante la generación, va dentro de un sandbox sin red y con las respuestas correctas ocultas. Un comentario que se corrige a sí mismo deja constancia de que leer mal el código del arnés «habría puesto el aislamiento en el sitio equivocado».

En el clúster #

Cifras de la línea. Dos personas comparten el mismo arnés; la segunda lanzó 1.184 trabajos en seis días de septiembre.

Trabajos cortos de una GPU, cuatro núcleos y prioridad rebajada, la mitad en la modesta L4 de 24 GB. Los primeros 593 fracasaron por un túnel SSH entre el portátil y el nodo; desde entonces cliente y servidor corren en el mismo nodo. Cinco trabajos de septiembre quedaron colgados unas 18 horas más allá de su límite hasta que Slurm los cerró a la vez; en las cifras de la serie se cuentan solo hasta el límite pedido.

Trabajos por tipo: los tres exámenes, velocidad y energía, y la preparación de ficheros.

En la quinta entrega cambiamos completamente de tema: plegar proteínas.

Cifras de la contabilidad de Slurm (capacidad reservada, no uso medido) y de los sbatch archivados. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables. Las citas son de los comentarios de los scripts.