Los formatos de 16 bits reducen a la mitad la memoria de los pesos del modelo sin cambiar la arquitectura

En un mismo modelo de 7.000 millones de parámetros, los pesos pueden ocupar aproximadamente 28 GB en FP32, 14 GB en FP16 o BF16 y 7 GB con ocho bits. La arquitectura no cambia; lo que cambia es la forma de almacenar los números. La ventaja parece evidente: se necesita menos memoria y hay que mover menos datos entre la memoria y las unidades de cálculo, por lo que el modelo debería responder más rápido.

Pero es precisamente aquí donde suele comenzar la confusión. Usar menos bits no garantiza una aceleración. Si el procesador o la GPU no pueden ejecutar eficazmente operaciones en el formato elegido, el entorno puede añadir conversiones, cambiar a un kernel más lento o incluso finalizar el cálculo con un error. Además, un rango de valores demasiado estrecho puede convertir una activación grande en infinito o borrar pequeñas diferencias entre números.

FP16 y BF16 resuelven problemas diferentes

Un número de coma flotante almacena un signo, un exponente y una mantisa. El exponente determina el rango de magnitudes, mientras que la mantisa determina la capacidad de distinguir valores cercanos. Al reducir el número de bits, hay que decidir qué sacrificar.

FP16 dedica más espacio a la mantisa, por lo que distingue con mayor precisión números contiguos. Sin embargo, su rango es relativamente estrecho: los valores grandes de las activaciones pueden provocar desbordamiento. BF16 almacena tantos bits de exponente como FP32, por lo que admite magnitudes mucho mayores y menores. El precio es una menor precisión para valores cercanos.

Imagine una capa que recibe los valores 1,001 y 1,002 y que más adelante se encuentra con una activación de 100.000. FP16 conservará mejor la diferencia entre los dos primeros números, pero corre el riesgo de no poder manejar el valor grande. BF16 tolerará el valor atípico con mayor facilidad, aunque puede redondear de la misma forma los números cercanos. La mejor opción la determinan el modelo, los datos y el hardware, no el nombre del formato.

Hay otro detalle: el tipo usado para almacenar los pesos no muestra toda la situación. Una multiplicación de matrices puede leer datos en FP16, acumular la suma en FP32 y volver a escribir el resultado en FP16. Por eso, los informes de rendimiento deben indicar la precisión de las entradas, la acumulación y las salidas.

La precisión mixta protege las operaciones sensibles

No es necesario convertir todo el modelo a un único formato. Las multiplicaciones de matrices pueden ejecutarse en FP16 o BF16, mientras que la normalización, softmax, las reducciones y determinadas capas permanecen en FP32. Este modo mantiene la aceleración en las operaciones más pesadas y reduce el riesgo de errores numéricos.

Sin embargo, cambiar los tipos manualmente tampoco es gratis. Las conversiones innecesarias consumen tiempo, y una incompatibilidad entre los tipos de las entradas y los pesos puede interrumpir la ejecución. Para un modelo preentrenado, lo más razonable es empezar con el modo de precisión mixta compatible con su biblioteca, revisar después el perfilador y solo entonces modificar capas concretas.

Es preferible cargar un checkpoint grande directamente en el formato de destino. Si primero se coloca en memoria la versión FP32 y después se convierte a FP16, durante un breve periodo se necesitará memoria para ambas copias. En un modelo grande, esto basta para provocar un error por falta de memoria antes incluso de la primera solicitud.

Que medir antes del lanzamiento

Los formatos deben compararse en tres dimensiones. La primera es la memoria: tamaño de los pesos, consumo máximo, caché KV y búferes temporales. La segunda es la velocidad: por separado, la latencia de procesamiento del contexto de entrada, la generación de tokens y el rendimiento total con tamaños de lote realistas. La tercera es la calidad: perplejidad, métricas de aplicación y respuestas a solicitudes representativas.

No basta con obtener un único texto coincidente. Con una selección voraz de tokens, las respuestas pueden parecer idénticas aunque las distribuciones de probabilidad ya se hayan separado de forma notable. Para detectar problemas, conviene comparar los logits, especialmente cerca de decisiones en las que dos tokens reciben puntuaciones casi iguales.

La conclusión práctica es sencilla: empiece con FP32 como referencia numérica, pruebe FP16 y BF16 en el hardware de destino, caliente el modelo y sincronice el dispositivo antes de medir. Después, elija el formato más compacto que conserve la calidad requerida y que realmente se ejecute más rápido en su hardware. La precisión óptima no consiste en usar el menor número posible de bits, sino en alcanzar un equilibrio medido entre memoria, velocidad y fiabilidad.