GLM-5.2 test cuts BF16 memory by nearly 25%

A new lossless BF16 compression experiment on GLM-5.2 753B reports two separate results: a 30.168% reduction from K15 charged-format accounting, and a fully validated 24.967% reduction from a byte-split representation that was decoded bit-for-bit across all 59,509 BF16 tensors.

The raw accounting numbers are large. The project says GLM-5.2 753B would shrink from 1,403.19 GiB to 979.87 GiB under the K15 format, a savings of 423 GiB.

How the compression works

The method targets the structure of BF16 weights, which store 16 bits per value: 1 sign bit, 8 exponent bits, and 7 mantissa bits. According to the write-up, trained models reuse a small set of sign-and-exponent combinations very heavily.

In the K15 estimate, the original 9-bit sign-and-exponent symbol is replaced by a 4-bit code pointing to a 15-entry table. Rare 9-bit symbols are sent to an exact escape stream, while the 7-bit mantissa is kept raw. With all overhead included, the full scan prices that layout at 11.173 bits per weight.

Recommended reading

AI Won’t Replace Coders, but It Will Reshape the Job

The separately validated byte-split path reconstructs the high byte from a codebook, indices, and escape stream, while keeping the low byte unchanged. The validator then compared the reconstructed tensors against the original checkpoint and found that all 59,509 tensors matched bit-for-bit. That representation came out to 12.005 bits per weight, or 24.967% less than BF16.

What remains unproven

The article is careful to separate what was measured from what is still open work. The 30.168% K15 result is an accounting estimate and was not independently decoded at GLM scale.

There is also an early runtime result: a separate dense 12-bit prototype reconstructed codes in registers and measured 0.733 times BF16 GEMV time on an A40. But sparse escape correction was validated separately and was not fused into or included in that timing.

The author says several pieces still need to be demonstrated:

• an exact lossless speedup
• a physical GLM-scale K15 container
• end-to-end serving integration

The write-up also places the work alongside earlier efforts. It credits ZipNN and DFloat11 with establishing lossless BF16 exponent compression in this size range, and calls ZipServ the closest prior runtime design because it already showed fixed-length coding with direct register reconstruction.

For reproduction, the project points to a single command using uv run verify.py zai-org/GLM-5.2, with no GPU required. The script streams the roughly 1.4 TB BF16 checkpoint shard by shard from Hugging Face, deletes data as it goes, verifies the exact byte-split reconstruction, and separately computes the fully charged K15 accounting. The source labels the result as Verifiedblind gate, 2026-07-12.