The 1-bit 763B DeepSeek Coder still weighs 182.72 GB
A 763B DeepSeek build advertises 1 bit per parameter. We check the arithmetic: 72.1GB of weights, 110.6GB of lookup tables, 94.8% of the base SWE-bench score.
Vlad Makarovreviewed and published
ISTA-DASLab's new Coder build of DeepSeek-V4.1-Flash-1017 is described, on its own model card, as "A 763B-parameter mixture-of-experts model at 1 bit per parameter". Both halves of that sentence are true and neither means what a reader will assume. The repository weighs 182.72 GB. The 1.05 bits is computed against a model that no longer has half its experts, so the deleted ones count as zero. It is a bookkeeping rate, and the fair storage claim is narrower: 72.1 GB of transformer weights against 138.2 GB for the unpruned build it was carved from.
Where the 1.05 comes from
The card does the arithmetic out loud, which most compression releases skip. Its 72.12 GB of transformer weights divided by the original model's 551.9B transformer parameters gives 1.05 bits per parameter, rounded to 1. The base model holds 763.2B parameters; 551.9B sit in the transformer, the rest in two Engram lookup tables.
The denominator is the move. "The count is against the original model, so every removed expert counts as zero bits," the card says, and calls the result "an effective rate" that "amortises the removed experts over the original parameter count". Nothing in the surviving weights is 1-bit. The 280.1B parameters the Coder keeps average 2.06 bits, because they retain the per-tensor types of the IQ2_XXS build and the dense tensors, held at higher precision, are a larger share of a smaller model. A 2.06-bit file with half its transformer parameters deleted averages 1.05 bits once the deleted ones stay in the divisor.
Pruning is not quantization, and the format took a cut too
The card draws the distinction cleanly: pruning "removes parameters from the model outright, reducing both file size and resident memory, and restricts the router to a smaller candidate pool", where quantization keeps every parameter and spends precision. Half of the 384 routed experts per layer are gone, 192 remain, and the base model activates 6 of 384 per token. The card never restates the Coder's active count, so the per-token saving is not quantified on the page that advertises it.
Selection used RCO, minimising KL divergence between pruned and unpruned outputs on calibration data rather than ranking experts by a heuristic score. The search ran on the already-quantized IQ2_XXS build, so it keeps the experts whose removal changes that build's outputs least. The card's reason is the sharpest line in it: expert importance "is not an intrinsic property of an expert but is defined relative to a distribution of inputs", and the calibration data "consequently determines which capabilities survive compression".
The container forced a second compromise: GGUF stores "a single expert count for the entire model", so every layer keeps exactly 192. A global budget would have stripped insensitive layers harder and sensitive ones less, which the card says "generally yields a better model", but the format cannot represent those counts "without padding that forfeits the memory saved".
The 182.72 GB the headline leaves out
Transformer shards total 72.12 GB. The Engram file is 110.60 GB: two lookup tables, 196.6B parameters at a fixed 4.50 bpw, neither pruned nor searched, the same file as in the unpruned release. With the 0.97 GB vision projector the repository comes to 182.72 GB against 248.84 GB for the unpruned build, a 26.6% smaller download. Over the whole model including those tables the rate is 1.92 bits per parameter.
The tables are read one row per token and may stay memory-mapped on disk, which is how a 182.72 GB artifact gets discussed as a 72.1 GB one by anyone counting resident bytes. The mixture-of-experts rule applies here: weight memory scales with total parameters, compute per token with the active ones. Pruning cuts the download and the resident set both, and the card is right that quantization alone could not have done that. But the model is not smaller in the sense that changes what it is. It is the same 763B model with fewer experts and a router with fewer places to look.
The benchmark bill
Two rows, vendor-measured, all numbers at reasoning effort 50.
| SWE-bench Verified | LiveCodeBench v6 | |
|---|---|---|
| Base model (FP8 / FP4) | 81.20 | 89.71 |
| GSQ-RCO Coder (72.1 GB) | 77.00 | 88.57 |
LiveCodeBench v6 keeps 98.7% of the base score; SWE-bench Verified keeps 94.8%. The card reads the gap as error accumulating across turns, since sustained multi-step tasks "tolerate capacity reduction less well than single-problem code generation". That second number is the more useful of the two, because SWE-bench is closer to what this release is for. A model sold for agentic workflows should be judged on the agentic benchmark, and there it loses one point in twenty.
What the card concedes
"Removing half of a model's experts necessarily reduces its capabilities." That sentence sits in the Overview, not in a limitations appendix, and the paragraph around it says the reduction is directed at "code, agentic tool use, long context and vision", with degradation outside that set "an accepted cost of the method". Anyone wanting a general-purpose model is pointed at the unpruned GSQ-RCO releases. The card also labels this "an experimental release" and asks for feedback "particularly on capabilities that were not represented in the calibration data" — an admission, inside the request for help, that the calibration set decided what survived and that nobody has mapped the edges.
Two days of reception
The r/LocalLLaMA release thread, posted 2 November at 14:33 UTC, drew roughly 352 points and 98 comments. The comparison that stuck was LiveCodeBench v6, where the Coder's 88.57 sits below commenter-reported figures of 90.3 for Qwen3.8-27B and 91.9 for Qwen3.8-Flash-Next. Those are commenter figures against a vendor number taken at one reasoning effort, and a separate thread benchmarked Unsloth's dynamic quants against these GGUFs. None of it settles the question it raises: what a 763B model at an effective 1 bit buys over a 27B at 4 bits for the work someone actually has.
The card reports 28,666 downloads last month, an MIT licence inherited from the base model, and a llama.cpp build requirement of b11870 or newer. Nothing on it argues anyone should prefer the 1-bit framing to the build it derives from. The reason to choose this artifact is 72.1 GB of resident transformer weights and an expert set tuned for code; the price is 5.2% of SWE-bench Verified and everything the calibration data did not cover. That may be an excellent trade for an agent harness on a fixed memory budget. It is still a trade, and "1 bit per parameter" is the shape it takes on a poster. The earlier coverage of the base model is the reference point for what was given up, and the Betelgeuse streaming work shows the other route to fitting a large MoE into small memory: keep every expert, move them off the card.
