Prueba de GLM-5.2 reduce la memoria BF16 en casi un 25%

Un nuevo experimento de compresión BF16 sin pérdida en GLM-5.2 753B informa dos resultados separados: una reducción del 30.168% según la estimación contable en formato K15, y una reducción totalmente validada del 24.967% a partir de una representación dividida por bytes que se decodificó bit por bit en los 59,509 tensores BF16.

Las cifras contables sin procesar son grandes. El proyecto indica que GLM-5.2 753B se reduciría de 1,403.19 GiB a 979.87 GiB bajo el formato K15, un ahorro de 423 GiB.

Cómo funciona la compresión

El método apunta a la estructura de los pesos BF16, que almacenan 16 bits por valor: 1 bit de signo, 8 bits de exponente y 7 bits de mantisa. Según la explicación, los modelos entrenados reutilizan de forma muy intensa un pequeño conjunto de combinaciones de signo y exponente.

En la estimación K15, el símbolo original de 9 bits (signo y exponente) se reemplaza por un código de 4 bits que apunta a una tabla de 15 entradas. Los símbolos raros de 9 bits se envían a un flujo de escape exacto, mientras que la mantisa de 7 bits se mantiene sin comprimir. Con toda la sobrecarga incluida, el escaneo completo sitúa ese esquema en 11.173 bits por peso.

Recomendado

La IA no reemplazará a los programadores, pero sí remodelará el trabajo

La vía separadamente validada por división de bytes reconstruye el byte alto a partir de un diccionario de códigos, índices y un flujo de escape, mientras deja el byte bajo sin cambios. El validador comparó entonces los tensores reconstruidos con el checkpoint original y encontró que los 59,509 tensores coincidían bit por bit. Esa representación resultó en 12.005 bits por peso, o un 24.967% menos que BF16.

Qué queda por demostrar

El artículo se ocupa de separar lo que se midió de lo que aún es trabajo pendiente. El resultado del 30.168% con K15 es una estimación contable y no se descodificó de forma independiente a escala GLM.

También hay un resultado preliminar de tiempo de ejecución: un prototipo denso de 12 bits reconstruyó códigos en registros y midió 0.733 veces el tiempo GEMV de BF16 en una A40. Pero la corrección de escape escasa se validó por separado y no se fusionó ni se incluyó en esa medición.

El autor dice que aún deben demostrarse varias piezas:

• una aceleración sin pérdida exacta
• un contenedor físico K15 a escala GLM
• integración de extremo a extremo en el servicio

La explicación sitúa además el trabajo junto a esfuerzos anteriores. Atribuye a ZipNN y DFloat11 el haber establecido la compresión sin pérdida del exponente BF16 en este rango de tamaño, y considera a ZipServ como el diseño de tiempo de ejecución previo más cercano porque ya mostró codificación de longitud fija con reconstrucción directa en registros.

Para la reproducción, el proyecto apunta a un único comando usando uv run verify.py zai-org/GLM-5.2, sin necesidad de GPU. El script transmite los aproximadamente 1.4 TB del checkpoint BF16 fragmento por fragmento desde Hugging Face, elimina los datos a medida que avanza, verifica la reconstrucción exacta por división de bytes y calcula por separado la contabilidad K15 totalmente cargada. La fuente etiqueta el resultado como Verifiedblind gate, 2026-07-12.