Breaking the 1.58-bit Barrier for Ternary LLMs
matt_d
177 points
24 comments
September 16, 2026
Related Discussions
Found 5 related stories in 68.7ms across 6,833 title embeddings via pgvector HNSW
- The efficient frontier of LLM inference philipkiely · 83 pts · September 01, 2026 · 56% similar
- Show HN: A tiny LLM running at 21,000 tok/s on a $250 FPGA (Live Demo) mikeayles · 12 pts · August 10, 2026 · 55% similar
- GRP-Obliteration: Unaligning LLMs with a Single Unlabeled Prompt vital101 · 19 pts · September 15, 2026 · 54% similar
- LLMs as a Cognitive Virus canjobear · 239 pts · September 05, 2026 · 54% similar
- Speculative Decoding in vLLM on AMD GPUs ankitg12 · 136 pts · September 07, 2026 · 53% similar
Discussion Highlights (12 comments)
Kevcmk
Woah. Good science.
NooneAtAll3
This is the only time "1.58 bit" phrase makes more sense than "1 trit" Who knew that if you actually look at information entropy you can pack stuff better!
plqbfbv
Very interesting, I was just exploring this to hopefully fit one of the latest quantized models in 16GB of VRAM.
om8
Ternary quantization does not make any sense. Vector quantization and trellis based methods are better in this region for PTQ.
infogulch
So they get down from 1.58 to 1.48 bits per weight by exploiting the fact that actual weights in practice are 0 51% of the time. Neat. If ternary llms work out and are baked into hardware as custom silicon I bet they'll be shockingly efficient.
wgd
Only a presence bitmap? If we're contemplating packing schemes I'm tempted to write a paper that uses arithmetic coding to squeeze out a few more centi-bits.
yalok
sounds like a perfect fit for ASIC-optimized models (where matrix ops could be supported directly in BITCOS format, potentially) & achieving record power efficiency for on-device inference. And it looks like per [0], a model needs only ~30% more weights to be at comparable quality, if quantization-aware training is done... 0. https://arxiv.org/pdf/2402.17764 - The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits
Marchant_hq
Pushing past log2(3) for real. This could drastically shrink LLMs for embedded systems, making them truly portable.
kittikitti
Thank you for sharing this. I like to test out running LLM's on edge computing with limited RAM and GPU/CPU so this research will have practical implications on my activities. I also appreciated how the authors formulated 1.58 (it's log_2(3)) because that was embarrassingly confusing for me when I was first introduced to ternary LLM's.
explainit2me
So this compression is only pertinent to the LLM file format? In memory it'd have to be expanded into the 1.58-bit form - 5 trits per byte.
c7b
> We measure the actual symbol distribution of 29 ternary LLM models and find that zeros account for up to 51.5% of all weights. Motivated by this finding, we introduce BITCOS, a simple distribution-adaptive layout I honestly assumed that's how they already work. I have to admit that I even explained it like that to a friend. Why on earth wouldn't you design it like that from the start (talking about the adaptive, not the measure part; just sacrifice a few bits to clarify your encoding and save a ton of bits)?
ant6n
ternary is totally losslessly compressed anyway. Why not just use an 8-bit LUT to encode the 256 most common ternary vectors with 6 components. That means of the possible 729 possible such vectors, you can only represent 256 different ones. You have to do more aggressive rounding, but at least the scheme is very simple to decompress and stream.