[ FIG. 01 ]
Most weights share a few sign-exponent symbols
Every BF16 weight is 16 bits: a sign, 8 exponent bits, 7 mantissa bits. In a trained model the exponents are wildly repetitive; a handful of values cover nearly every weight.
The K15 accounting replaces the 9-bit sign-and-exponent symbol with a 4-bit code into a 15-entry table. Rare 9-bit symbols go to an exact escape stream; the 7-bit mantissa stays raw. With all side costs charged, the full scan prices this layout at 11.173 bits per weight.
The byte-split path round-trips
The streamed validator reconstructed the high byte from its codebook, indices, and escape stream, kept the low byte verbatim, and compared every BF16 tensor with the source.
All 59,509 tensors matched bit-for-bit. That decoded representation costs 12.005 bits per weight, or 24.967% less than BF16. The 30.168% K15 layout is separately charged accounting and was not independently decoded at GLM scale.
A dense prototype, not a serving result
A separate dense 12-bit prototype reconstructed codes in registers and measured 0.733 times BF16 GEMV time on an A40. Sparse escape correction was validated separately but was not fused into or included in that timing.
An exact lossless speedup, a physical GLM-scale K15 container, and end-to-end serving integration therefore remain open.
The exponent insight and fused concept are prior art
ZipNN and DFloat11 established lossless BF16 exponent compression in this size range. DFloat11 uses variable-length Huffman codes and restores BF16 weights before matrix multiplication. ZipServ is the closest prior runtime design: it already demonstrated fixed-length coding with direct register reconstruction. This experiment uses a different representation, per-tensor 4-bit codes over 15 joint sign-and-exponent symbols with sparse exact escapes, and does not claim the shared exponent redundancy, roughly 11-bit range, or fused concept as new.