Ternary weights do not survive, and per-column scaling does not rescue them
Ternary weights are attractive because they make a 12B model smaller than a 3B at int8 — 2.73 GB against 2.82 GB. Measured against real weights, they lose 46% of the output on a single matrix, and a 48-layer model has no slack for that.
| format | y rel err | y cosine | size (12B) |
|---|---|---|---|
| int8 per-column | 0.0108 | 0.99995 | 10.90 GB |
| int4 per-column | 0.1912 | 0.98126 | 5.45 GB |
| ternary per-column | 0.4566 | 0.87707 | 2.73 GB |
| ternary global | 0.4858 | 0.87309 | 2.73 GB |
Why per-column scaling does not save it
Per-column scaling genuinely rescues int2 relative to a global scale — cosine 0.50 against 0.036, a large effect. At ternary the same change moves cosine from 0.873 to 0.877, which is nothing.
The reason is that a scale can only carry the exponent. Once the scale is per-column, what remains for the weight to encode is sign and mantissa, and ternary has 1.58 bits — enough for the sign, nothing for the magnitude.
A correction worth recording
An earlier round of this work concluded ternary failed because the bundled artifact had discarded per-column magnitudes. That evidence was confounded: it was measured while the inference engine used a phase-only encoding that could not compute the target function with perfect weights either. Two broken variables, no attribution possible.
The result above was measured engine-free, on both model families, and reaches the same conclusion for a reason that survives scrutiny.
← Back to the library