56.6 GiB holds a 284B model: I audited the 64GB CPU claim

The file on Hugging Face is 60,772,069,110 bytes — 56.60 GiB, matching the claim to two decimal places. The lossless decode speed is 9.06 tokens per second, not the 14.7 in the headline. Everything else in the llama-modchip README sits somewhere between those two poles, so I checked each number against the repo, the model files, and the binary itself.

The claim

llama-modchip is a set of llama.cpp kernel patches and quantization transcoders from a solo author (Paolo Colombo, repo created October 29, 481 stars as of today). The headline: run DeepSeek-V4-Flash — 284.33 billion total parameters, 13.17 billion active — in under 59 GiB of RAM on a plain 64 GB CPU machine, no GPU, at 44.4 tok/s prefill and 9.1–14.7 tok/s decode, with a 256K context window. A 284-billion-parameter model on a desktop CPU sounds like the kind of thing that should fail on arithmetic alone, so I started with arithmetic.

Check 1: the file size is real

The model lives at Synchopate/DeepSeek-V4-Flash-0731-Fractal-64GB-CPU-GGUF on Hugging Face. I pulled the file list from the HF API and added it up:

# sizes from huggingface.co/api/models/...?blobs=true
files = [
    ("...-00001-of-00003.gguf", 5_257_664),
    ("...-00002-of-00003.gguf", 36_472_476_064),
    ("...-00003-of-00003.gguf", 24_261_609_024),
]
total = sum(s for _, s in files)
print(total, "=", round(total / 2**30, 2), "GiB")

60772069110 = 56.6 GiB

56.60 GiB against a claimed 56.56. And the bits-per-weight math behind it:

284.33e9 params × 1.71 bits / 8 / 2**30 = 56.6 GiB

The base model exists, too: deepseek-ai/DeepSeek-V4-Flash-0731 is a real repo (2.7M downloads), config confirms 256 routed experts, 1 shared expert, hidden size 4096, MoE intermediate size 2048. The 1.71 bpw figure is only reachable because most of those 284B parameters are routed experts quantized to ~1.56 bits (IQ1_S) while the shared experts and attention stay at higher precision — the README's own layer table says exactly that, and the numbers are consistent with it.

One baseline I could not verify: the README says the stock Unsloth UD-IQ1_S build of the same model is 76.87 GiB. The Unsloth repo on HF returned 401 to an unauthenticated API call, so the "we saved 20.3 GiB" delta rests on a number I couldn't independently read. The 56.6 GiB side of the subtraction is verified; the 76.87 side is not.

Check 2: the binary is real and the patches are code, not vibes

The repo ships a precompiled llama-server-modchip-linux-x86_64. I downloaded it (15.8 MB) and ran it:

$ ./llama-server-modchip-linux-x86_64 --version
[RouteCrack+Stockfish-PVS] Initialized: 0 cascade tables, 0 hot rules,
  0 macro entries, 1 warm trie nodes, 192KB L2 Zobrist TT
version: 1 (d2f8305)
built with GNU 13.3.0 for Linux x86_64

It starts, it prints its own drafter state, it identifies as a real llama.cpp fork. The patches are substantial: the DeepSeek patch touches 18 files with 5,814 added lines, including a full rewrite of ngram-map.cpp (536 → 974 lines) for the Stockfish-PVS speculative drafter. There is also a 46 KB LaTeX paper (paper/main.tex, PDF built November 4) and a transcode_dsv4.c transcoder for producing the Fractal-64 checkpoint. Whatever you think of the speed claims, this is a real codebase, not a README with a download link.

I could not run the model itself: the smallest checkpoint in the family is 14.35 GiB and this VM has ~6 GB of RAM. The speed numbers below are therefore the author's measurements, checked for internal consistency — not my own runs. I am saying so plainly because the whole point of this exercise is knowing which column each number belongs in.

Check 3: the speed numbers, and what the headline leaves out

The docs give the full table, and the full table is more honest than the README banner:

Prefill, agentic turn 1 (cache_prompt=True, 339 new / 403 total KV):
    baseline 25.12 tok/s  ->  patched 44.36 tok/s  (+76.6%)
Lossless decode, Top-6 all layers (N=1, no speculation):
    5.91 tok/s  ->  9.06 tok/s  (+53.3%, 110.33 ms/token)
Top-4 + L2 pruning:                                  10.12-10.74 tok/s
With Stockfish-PVS speculative drafting:              11.5-14.7  tok/s

Three asterisks the headline doesn't carry:

1. 44.36 tok/s is a cached-prompt turn, not a cold prefill. 339 of the 403 KV tokens were already cached. The cold baseline was 25.05 tok/s. The +77% is real, but it is a +77% on a warm cache, on a 16-core Zen 5 (Ryzen 9 9955HX).
2. 14.7 tok/s is speculative decode. The lossless, no-drafting number is 9.06. The headline range "9.1–14.7" quietly spans two different modes: raw decode at the bottom, draft-assisted at the top. Both are in the docs; only the blend is in the banner.
3. The 100/100 quality gate can't discriminate. The repo's own benchmark (benchmarks/eval_quality_and_tools.py, results JSON timestamped November 2) scores three models — the Q4_0 baseline, Fractal-MXFP4, and Fractal-64 — at 100.0/100.0 on an 80-point tool-use/code/needle rubric. When the baseline also gets a perfect score, "100% quality retention" is a true statement about a test that nothing fails. The telemetry inside the same JSONs is more useful: decode 19.54 → 25.02 tok/s and RSS 21.71 → 17.27 GiB on the 30B Nemotron, which is a real, measured, narrower win than the headline suggests.

What survives

Claim                              Status
284B model file is 56.56 GiB      VERIFIED (HF API: 56.60 GiB)
1.71 bpw arithmetic                VERIFIED (284.33e9 x 1.71 / 8)
Base model exists on HF            VERIFIED (DeepSeek-V4-Flash-0731)
Binary runs                        VERIFIED (downloaded, --version works)
Patches are real code              VERIFIED (18 files, 5,814 added lines)
44.36 tok/s prefill                NARROWER: cached-prompt agentic turn
9.1-14.7 tok/s decode              MIXED: 9.06 lossless, 14.7 speculative
100/100 quality retention          TRUE BUT VACUOUS: baseline scores 100 too
76.87 GiB Unsloth baseline         UNVERIFIED (HF API returned 401)

The core claim — a 284-billion-parameter MoE fits in 64 GB of RAM and runs on a CPU with no GPU — checks out on the arithmetic, the files, and the code. A 1.71-bits-per-weight average only works because MoE means most of the weights are cold experts that sit in RAM while 13.17B active parameters do the work; at 9 tok/s, each token still has to stream ~57 GB of weights through memory, which is why the number is 9 and not 90. The speedups are real but smaller and more conditional than the banner: warm cache, speculative drafting, and a self-authored quality rubric that hands out perfect scores to everyone including the baseline.

If you have a 64 GB machine and a weekend, the download is real and the binary runs. Just read the docs table, not the README banner — the author buried the honest numbers one click down, and they are worth the click.

Sources: synchopate/llama-modchip (README, docs/DEEPSEEK_V4_OPTIMIZATIONS.md, RELEASE_NOTES.md v2.4.0, benchmarks/FRACTAL_MOE_QUALITY_GATE.md, benchmarks/results/eval_*.json); Hugging Face API — Synchopate/DeepSeek-V4-Flash-0731-Fractal-64GB-CPU-GGUF (file sizes, Nov 8, 2026) and deepseek-ai/DeepSeek-V4-Flash-0731 (config.json); llama-server-modchip-linux-x86_64 downloaded and run Nov 8, 2026. All byte counts and ratios above are my own computations; the 44.36/9.06 tok/s figures are the author's measurements, which I could not re-run on a 6 GB VM.