Boole-1.7B stores a derivative of Qwen3-1.7B in 247MB of weights, compared with roughly 3.44GB for the BF16 original. It is an unusually compact download for developers experimenting with local LLM inference, though that figure does not establish that the model runs in 247MB of RAM.
Precision Numerics announced the model on October 11, 2026, alongside downloadable weights, demo code and a detailed publisher-run evaluation. Its Boole-1.7B announcement reports a ten-task average of 50.55, against 58.83 for the BF16 base: a 13.9-fold reduction in stored-weight size while retaining 85.9% of that particular benchmark average.
Developers can download the release and test that tradeoff themselves. Before treating it as a small-device breakthrough, though, two qualifications deserve attention: the easiest CPU inference path uses a larger file than the headline figure, and the evaluation does not measure runtime memory, latency or throughput.
The 247MB Figure Depends on the Runtime Format
The Boole-1.7B model repository provides the weights. The accompanying demo supports two inference routes, with different formats and hardware requirements.
According to the demo repository, the options are:
| Inference route | Model file | Reported stored size | Documented hardware |
|---|---|---|---|
| llama.cpp | Boole-1.7B-Q1_0.gguf | 292.1MB | CPU or CUDA GPU |
| vLLM + Humming | Locally exported Boole-1.7B.safetensors | 247.1MB | Single CUDA GPU, using BF16 dtype |
Precision Numerics explains the size difference: the GGUF stores the embedding and output matrices separately, while the safetensors representation shares their sign bits and retains separate scales.
For a developer starting with CPU inference, 292.1MB is the relevant model-file figure. It remains compact, but storage budgets and format comparisons need to account for the difference from 247MB.
The repository’s exporter downloads the packed checkpoint and creates a vLLM model directory. Its plugin handles the 1-bit embedding and output head. The documented vLLM route targets version 0.31.0 and humming-kernels 0.1.16, with both pinned by the installation extra.
These details give developers more to work with than a compression chart. The supplied vLLM command also explicitly requests bfloat16, so “1-bit model” should not be read as a claim that every part of inference uses one-bit arithmetic.
The runtime code and model weights are licensed under Apache License 2.0, according to the demo documentation.
Binary Weights Discard Magnitude Information
BF16 stores each weight using a 16-bit floating-point representation. In the binary-weight scheme described by Precision Numerics, a weight keeps a sign, positive or negative, with its magnitude supplied by a scale shared across a group.
A 4-bit format can represent sixteen levels, allowing weights in the same group to retain different magnitudes. A binary group represents each weight as either positive or negative the shared scale. This is an aggressive simplification: weights that originally had substantially different magnitudes can end up with the same magnitude after binarization. Compression removes information as well as storage.
Scales also occupy space. The announcement explains that a 16-bit scale shared by 32 one-bit weights adds half a bit per weight. Reducing group size can preserve more local information, but increases the scale overhead.
That overhead helps explain why a nominally one-bit model does not reach the ideal one-bit file size. Precision Numerics lists an ideal packed-weight size of 215.1MB for Qwen3-1.7B before quantization scales and other overhead, versus Boole’s reported 247MB.
The publisher includes an idealized calculation illustrating how much information a shared scale cannot recover, with an explicit caution that it does not predict accuracy loss. The model’s evaluation provides the practical evidence of that loss.
Boole is intended for English-language inference in non-thinking mode. Its benchmark results should not be treated as validation of multilingual performance or the base model’s thinking behavior.
Boole Loses 8.28 Points Against Its BF16 Base
The reported ten-task average falls from 58.83 for Qwen3-1.7B BF16 to 50.55 for Boole, an 8.28-point decline. This is the clearest capability cost attached to the headline compression result.
Precision Numerics gives each of the ten tasks equal weight in the average. Its “85.9% retained” figure is the ratio between those two averages. It does not mean Boole preserves 85.9% of every capability, answers 85.9% of arbitrary questions correctly, or behaves like the original model in all applications.
The publisher’s comparison places the storage tradeoff in context:
| Evaluated model or format | Stored weights | Publisher-reported ten-task average |
|---|---|---|
| Qwen3-1.7B BF16 | 3,441.1MB | 58.83 |
| Boole-1.7B | 247.0MB | 50.55 |
| Binary Bonsai-1.7B | 242.4MB | 44.97 |
| Ternary Bonsai-1.7B | 457.3MB | 51.57 |
| Qwen3-1.7B Q3_K_M | 933.6MB | 53.66 |
These are publisher-reported results, not an independently reproduced comparison.
At nearly the same storage size, Boole averages 5.58 points above binary Bonsai. Ternary Bonsai scores 1.02 points higher than Boole while using about 1.9 times its stored-weight space. The evaluated Q3_K_M version of Qwen3-1.7B scores 3.11 points higher, at about 3.8 times Boole’s storage.
There is no universal winner here. A strict sub-300MB storage budget favors a different compromise than a system that can accommodate approximately a gigabyte of weights.
Performance also varies by task. Precision Numerics says Boole improves over binary Bonsai in seven of ten tasks, with its largest gains in math and code. It scores lower on MuSR, IFEval and BFCLv3 function calling.
Those deficits are against binary Bonsai, not against the BF16 base. The math and coding gains over Bonsai likewise do not establish parity with the original Qwen model. The overall BF16 comparison demonstrates a meaningful capability loss, but its average cannot identify how that loss is distributed across individual workloads.
For applications that depend on following exact instructions or producing valid tool calls, task-specific results deserve more attention than the aggregate retention percentage. An attractive average per megabyte may still leave a model unsuitable for the behavior an application requires.
Sources
- Boole-1.7B announcementprecisionnumerics.ai
- Boole-1.7B model repositoryhuggingface.co
- demo repositorygithub.com
