RunPod analiza 4 métodos de cuantización: de FP16 a INT4, la memoria se reduce a una cuarta parte

RunPod, proveedor de GPU en la nube, ha publicado una guía sobre cuatro formas de comprimir modelos antes de desplegarlos: cuantización post-training (PTQ), quantization-aware training (QAT), precisión mixta y cuantización dinámica. El material no incluye benchmarks propios: es una comparación de referencia sobre los compromisos de cada método. Sin embargo, el tema influye directamente en la factura de inferencia. Los pesos de un modelo de 70 mil millones de parámetros ocupan unos 140 GB en FP16, unos 70 GB en INT8 y unos 35 GB en INT4. La diferencia entre «hacen falta dos aceleradores de 80 GB» y «basta con uno» sale de estas cifras.

Cuatro formas de perder un poco de precisión

PTQ toma un modelo ya entrenado, le pasa un pequeño conjunto de datos de calibración y convierte los pesos, y a veces también las activaciones, a INT8 o INT4. No requiere reentrenamiento y el proceso lleva minutos u horas. Así funcionan los populares GPTQ y AWQ. El precio es una caída de calidad, sobre todo con 4 bits y en modelos pequeños.

QAT va por otro camino. La cuantización se emula durante el entrenamiento o el ajuste fino, y el modelo aprende a funcionar con pesos "toscos". El resultado suele acercarse más a la precisión original, pero hacen falta datos, tiempo y horas de GPU, un gasto considerable en el caso de un modelo grande.

La precisión mixta mantiene la mayoría de las operaciones en FP16 o BF16 y deja en una resolución más alta los puntos sensibles, como los acumuladores, la normalización y softmax. La cuantización dinámica almacena los pesos en enteros y calcula los rangos de las activaciones sobre la marcha, durante la ejecución. Es la que más fácilmente se aplica a un modelo ya entrenado y encaja bien con la inferencia en CPU, aunque la sobrecarga de calcular los rangos se come parte de la ganancia.

Referencias por nivel de precisión

La velocidad y la memoria mejoran a medida que baja la resolución en bits, pero no de manera uniforme. Para hacer estimaciones sirven unas cuantas magnitudes de referencia:

• FP16/BF16: 2 bytes por parámetro, precisión de base; un modelo de 70B requiere unos 140 GB solo para los pesos.
• INT8: 1 byte por parámetro, la mitad de memoria; las pérdidas de calidad en la mayoría de las tareas suelen ser pequeñas.
• INT4: 0,5 bytes por parámetro, unos 35 GB para 70B; riesgo notable de degradación en razonamiento y código.
• Sobrecarga: el KV-cache y las activaciones no están incluidos en estas cifras y crecen con la longitud del contexto y el número de solicitudes paralelas.
• Soporte de hardware: solo se acelera lo que los tensor cores saben calcular de forma nativa. En la H100 son FP8 e INT8, y para INT4 a menudo hacen falta kernels especiales.

Dónde está la trampa

La principal trampa es que comprimir los pesos no equivale a acelerar. La inferencia de modelos grandes suele estar limitada por el ancho de banda de memoria, así que unos pesos más pequeños sí aceleran la generación de tokens. Pero si el runtime descuantiza de forma constante sin kernels optimizados, la ganancia desaparece. El segundo problema es que las métricas medias, como la perplexity, ocultan fallos en tareas concretas: aritmética, contexto largo, idiomas poco frecuentes y generación de código.

De ahí se deduce un orden práctico de actuación. Para un primer intento, use PTQ en INT8 o en el formato de 8 bits que admita su hardware, y compare con FP16 usando sus propios datos, no pruebas públicas. Si la calidad se mantiene, pruebe INT4 y fíjese en los peores casos, no en la media.

Si la caída es crítica y hay presupuesto para ajuste fino, pase a QAT. La cuantización dinámica sirve cuando no hay GPU o cuando se necesita comprobar una hipótesis con rapidez. Calcule aparte el KV-cache: un modelo INT8 de 70 GB en una tarjeta de 80 GB deja solo unos 10 GB para el contexto y las solicitudes paralelas, y en ese punto INT4 aventaja a INT8 por la memoria libre que deja, no por la velocidad.