Ternary / 1.58-bit quantization (general)

Ternary weights -1/0/+1 average 1.58 bits per weight (log2(3)), which is where the name comes from, and the int8-packed representation is why the practical bit width with scale metadata is sometimes quoted higher. The framing that matters: ternary LLM quantization is a TRAINING-TIME recipe, not a post-training one. There is no such thing as PTQ-ing an existing fp16 LLM to 1.58 bits and keeping its quality - you quantize during training with the weights constrained to the ternary set. quality_delta is null here deliberately because the headline 'matches fp16 perplexity' claims are all from-from-scratch training runs at matched size and token budget (see bitnet-b158), not from converting a trained model; GPTQ does report a ternary 'extreme quantization' result but on OPT-175B where it degrades substantially, and no comparable number was transcribed. Hardware: no accelerator has a ternary matrix-multiply path; INT8 tensor cores will not run it, and the whole point is the energy win from accumulating in low precision on custom silicon, which is what the BitNet paper explicitly calls an open design target ('opens the door for designing specific hardware'). NATIVE_SUPPORT CLASSIFIED 2026-10-04: this field is still [] and that is CORRECT, but the empty list used to be ambiguous between three different states and now is not. Reason class on this record: WEIGHT-ONLY, SO STRUCTURALLY ABSENT. The bits field keeps activations in FP16, so execution is dequantize-to-FP16 then an FP16 tensor-core GEMM; there is no INT4-x-INT4 (or sub-8-bit x sub-8-bit) silicon instruction for it to target. This is a statement about the arithmetic, not an absence of investigation. Consequence for a reader: nothing further to verify - no silicon path is possible for this format as defined. The full statement of the three-way distinction, and the worked list of all 72 empty records by class, is in gotcha quant-native-support-empty-means-three-different-things. Rule of thumb for this field everywhere in the repo: if the bits field carries an 'a16', or the scheme is KV-cache-only or a llama.cpp integer storage type, an empty native_support is a DEFINITION and needs no verification; only a W4A4/W8A8/sub-8-bit format with research kernels can have an empty list that is a real finding.