News · 2026-08-04

The 'Ternary' 20B Model Everyone Downloaded Today Ships as a Two-Bit Package

DeepGrove's Maple-Preview is a 20-billion-parameter mixture-of-experts model with roughly 1 billion active parameters per token, and its native BF16 repository is about 40.4 gigabytes. The 5.3-gigabyte figure being shared as proof that a 20B ternary model fits on a laptop belongs to a separate two-bit MLX package - a deployment artifact whose configuration specifies affine two-bit group quantisation with four-bit embeddings and output head. DeepGrove has published no ternary training recipe, so whether the model was trained ternary from scratch or converted afterwards is currently undocumented.

Key facts

• 20B total parameters, ~1B active per token, sparse expert routing, a mix of sliding-window and global attention.
• Native BF16 repository: about 40.4GB. Separate two-bit MLX package: about 5.3GB.
• The MLX loader packs ternary values into two-bit codes and uses scaled quantised matrix multiplication.
• DeepGrove's own card admits minimal agentic post-training and warns the model may underperform on agentic benchmarks.

What ternary actually promises

A conventional weight is a number with many possible values. A ternary weight has three operative states: a negative scale, zero, and a positive scale. The zero is the interesting one - it lets the network say "ignore this connection entirely," which no ordinary rounding scheme can express as cleanly.

The mechanical payoff is that multiplying by -1, 0 or +1 is not really multiplication. It is a sign flip, a skip, or a copy. In a genuinely ternary-trained network, large stretches of matrix multiplication collapse into signed accumulation, which is far cheaper in silicon than multiply-accumulate. The original BitNet b1.58 paper laid out the case and, critically, distinguished a training recipe built around ternary weights from the outset from ordinary post-training compression.

That distinction is the whole story here. BitNet is a definition, not evidence for Maple.

What Maple actually ships

Read the release files rather than the headline and a different picture appears. The small package is not one bit per weight - it is a two-bit encoding with four-bit embeddings and output head, group-quantised with affine scales. The loader unpacks ternary values out of two-bit codes, then performs scaled quantised matrix multiplication.

So the shipped runtime does not demonstrate a multiplication-free model. It demonstrates a compact, ternary-encoded deployment build. Those are different claims, and only one of them is on the box.

The analogy: a book compressed into a zip file is smaller than the book. That tells you about the encoding, not about how the book was written. To know whether Maple was authored in ternary - trained with the constraint active, so the weights learned to live inside three values - you would need a technical report. DeepGrove has not published one.

This is not an accusation. Post-training quantisation, quantisation-aware fine-tuning and native ternary training are three legitimate approaches with three very different quality profiles, and DeepGrove has simply not said which it used. The accurate line is: it ships a ternary-encoded two-bit deployment artifact; native ternary training is unverified.

Why the sparsity number is also slippery

Maple is a mixture of experts: 20B total, about 1B active per token. Sparse routing genuinely reduces per-token computation. It does not reduce resident weight storage - every expert has to be somewhere the router can reach.

Today offers a clean contrast in the same shape. inclusionAI's Ling-3.0-flash, also out this week, is 124B total with about 5.1B activated per token. Its BF16 repository is roughly 255 gigabytes, and the official serving path calls for custom SGLang or vLLM forks with tensor parallelism across four GPUs. "5.1B active" is not "a 5.1B local model," and this site has covered the same confusion in a 284B model with a 3-gigabyte working set that turned out to be 768GB of server RAM.

Why it matters

Three different meanings of "small" landed in a single day, and they are not interchangeable. LFM2.5 is small in architecture - it genuinely does less work per token. Maple is small as a deployment package - the same weights, encoded tighter. Ling is small per token - sparse activation over a large resident artifact.

Only the first one makes the model cheaper to think with. The second makes it cheaper to store and load. The third makes it cheaper to serve at scale on hardware you probably do not own. Every "tiny model" headline should prompt the same question: what disappeared from the bill - global attention, numerical precision, resident experts, or test disclosure?

The honest caveat

The r/LocalLLaMA thread got to the right questions fast: independent tests, degradation data against equally quantised baselines, and non-MLX low-bit builds. The strongest version of the skeptical case is not that Maple is bad - nobody has measured it - but that a size-normalised score is meaningless without a same-bit-width comparison, and that knowledge and coding failures are where aggressive quantisation usually shows up first. Maple's topology, licence, package sizes and MLX encoding are all confirmed from primary sources. Its speed and quality claims are the vendor's, and its training method is a blank.

Primary source, verified: read the paper →

Ground Truth. (2026, August 4). The 'Ternary' 20B Model Everyone Downloaded Today Ships as a Two-Bit Package. Ground Truth. https://groundtruth.day/news/the-ternary-20b-model-ships-as-a-two-bit-package-not-a-one-bit-one.html

@misc{groundtruth:the-ternary-20b-model-ships-as-a-two-bit-package-not-a-one-bit-one,
  title  = {The 'Ternary' 20B Model Everyone Downloaded Today Ships as a Two-Bit Package},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/the-ternary-20b-model-ships-as-a-two-bit-package-not-a-one-bit-one.html}
}

Topics: quantization · ternary · moe · local-llm · mlx · open-weights · bitnet