BitNet b1.58 (ternary LLM)

GROUP SIZE LEFT NULL 2026-10-04: BitNet b1.58 weights are trained to be ternary {-1,0,+1} at 1.58 bits average. There is no scale and no group - the clipping threshold is absorbed into training. The '32' in the sibling ternary record is a real quantization block for that method, and must not be copied here. Every parameter is ternary {-1, 0, 1}. The framing that matters: this 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 constrain the weights to the ternary set during training. Read the quality claim correctly: 'matches fp16' means 'a ternary model trained from scratch on the same token budget matches an fp16 model trained from scratch on the same token budget', which is a statement about the expressiveness of the ternary set at fixed compute, not about quantization loss on a pretrained checkpoint. The paper explicitly frames 1-bit hardware as an open design target ('opens the door for designing specific hardware optimized for 1-bit LLMs'), so no accelerator here has a native ternary path. Confidence kept moderate because the authors label the paper 'Work in progress' and the match-claim is their own headline; no third-party perplexity comparison was located. UPGRADE (2026-10-03) - b1.58 vs b1.0, which the parent asked to be pinned down: the repo holds the B1.58 recipe only (2402.17764, quant-bitnet-paper). The B1 paper is a DIFFERENT and earlier architecture: arXiv 2310.11453, 'BitNet: Scaling 1-bit Transformers for Large Language Models' (qlab-bitnet-b1-paper), which introduces BitLinear as a drop-in nn.Linear replacement and reports competitive performance with substantially reduced memory and energy versus both an 8-bit quantized baseline and an FP16 baseline, plus evidence that BitNet follows a scaling law analogous to full-precision transformers. The substantive differences, sourced from the two abstracts: b1 is '1-BIT' with weights constrained to a binary set and BitLinear performing the binary accumulation, whereas b1.58 is '1.58-BIT' with every weight TERNARY {-1,0,+1} - the third state exists specifically because pure binary weights lose too much, and b1.58's activations stay in 8-bit. So '1.58' is not a marketing average of 1 bit; it is a specific ternary weight set with 8-bit activations, and it is a different architecture from the b1 paper. The b1 abstract also stresses 'scalable and STABLE' 1-bit training, and its scaling-law claim is what the later b1.58 work builds on. Recommend the parent add a separate bitnet-b1 record; I did not create one because the repo already has b1.58 and two adjacent bitnet records with the same scheme enum would need the schema widened. 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.