Plane decomposition
PTWM's bread-and-butter transform is a two-step decomposition:
1. Bit reorder
IEEE 754 places the sign bit between the exponent and mantissa, straddling a byte boundary. The bit reorder shifts the exponent to the most-significant position with the sign tucked below it.
For float32 and bfloat16 (8-bit exponent), the exponent occupies a
full byte after reorder:
IEEE 754 fp32: [S EEEEEEEE MMMMMMMMMMMMMMMMMMMMMMM]
After reorder: [EEEEEEEE S MMMMMMMMMMMMMMMMMMMMMMM]
For float8_e4m3fn and float8_e5m2 (4–5 bit exponent), the reorder
moves the exponent into the high nibble of each byte:
FP8-E4M3FN: [S EEEE MMM]
After reorder: [EEEE SMMM ] ← exponent in high nibble
2. Byte / nibble split
The byte (or nibble) split deinterleaves the reordered data into separate planes. The compressor then encodes each plane independently with whichever codec compresses it smallest.
| Dtype | Strategy | Planes |
|---|---|---|
float32 | bit reorder + 4-plane byte split | plane 3 = exponent |
bfloat16 | bit reorder + 2-plane byte split | plane 1 = exponent |
float16 | 2-plane byte split (no reorder) | sign + exp in MSB already |
float8_e4m3fn / float8_e5m2 | bit reorder + 2-plane nibble split | plane 0 = exponent nibbles |
float4_e2m1fn_x2 (MXFP4 / NVFP4) | PPG chain over nibble pairs | best chain selected per tensor |
int8 / uint8 / bool | single stream | no reorder |
int16 | 2-plane byte split | |
int32 | 4-plane byte split | |
int64 | 8-plane byte split |
Why this works
The exponent plane on a trained float weight typically holds about 20 unique values out of 256 (≈ 2.6 bits/byte entropy). The mantissa planes are near-random. Coding the planes independently lets the entropy coder spend its bits where they buy compression and treat the near-random planes cheaply.
The two-step decomposition is a standard byte-shuffle preprocessing step, plus a bit-reorder step that cleanly separates the exponent from the sign. Without it, the sign contaminates the exponent byte.
Where the savings come from
For float weights (bfloat16, float16, float32), nearly all the
compression savings come from the exponent plane.
For microscaling formats, the FP4 nibbles are near-uniform and the plane decomposition does little. The savings come from the scale codec applied to the paired E8M0 or FP8-E4M3 scale tensor.