Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
savoji 
posted an update 1 day ago
Post
981
A 284B-parameter DeepSeek-V4-Flash now runs on a 64 GB desktop with 0 GPUs: llama-modchip shrinks the checkpoint to 56.56 GiB (1.71 bpw) and decodes at 9.1 to 14.7 tok/s.

The standard UD-IQ1_S build is 76.87 GiB, above the ~62.5 GiB usable on a 64 GB Linux box. The repo mixes precisions (routed experts mostly IQ1_S, MLA projections in a custom Fractal-64 type) and patches the CPU kernels. The model plus a 256K KV cache then sits at 57.61 to 58.9 GiB RSS with zero swap. The repo was created on 2026-10-29 and already has 744 stars and 470 points on Hacker News.

📊 The numbers
• Size: 56.56 GiB, 20.31 GiB smaller than UD-IQ1_S
• Prefill: 25.0 to 44.36 tok/s (+77%) on a 16-core Ryzen 9 9955HX
• Decode: 5.91 tok/s unpatched, 9.06 to 9.95 tok/s at Top-6, 11.5 to 14.7 tok/s with the n-gram drafter

⚠️ Caveats
• "Lossless" means bit-exact against the same re-quantized checkpoint. Versus UD-IQ1_S the author reports 0.9964 top-logit cosine similarity
• The 98.5/100 quality score comes from the author's own gate, and the headline speeds come from one machine
• The custom tensor type 40 is rejected by stock llama.cpp, Ollama and LM Studio

🛠️ Try it
• Run scripts/check_cpu_readiness.py from the repo: it needs no model download
• Run ./modchip bench for speed, then ./modchip eval to check the quality claims yourself

Repo:
https://github.com/synchopate/llama-modchip

HN thread:
https://news.ycombinator.com/item?id=50411961

Would you accept a custom runtime for 9 to 15 tok/s from a 284B model on a 64 GB box?

📚 Read it elsewhere
• The deep dive on Medium: https://medium.com/p/e47ab3581f58
• The long read on Substack: https://sajjadpakdamansavoji.substack.com/p/llama-modchip-runs-a-284b-deepseek
• The thread on X: https://x.com/saavoji/status/2119858773280141526
• Every version on sajjadpsavoji.github.io: https://sajjadpsavoji.github.io/blog#llama-modchip

Heavy Quantization down to 1-2 bits has really gone a long ways.

As to answering the question 'would i accept a runtime for 9-15t/s'?, I'm hesitant to say as you are still moving the same work from a GPU to a CPU.

I have 8 cores plus 8 efficiency cores, meaning i can't use all 16 rather i can only use 8 (As i understand it the memory bandwidth space is shared, so using more just slows it down, so I'd get at best half that speed unless the CPU's intelligently divide the work). CPU's are also aligned for 32bit or 64bit block accesses, taking a block and then separating them out before working is far less efficient especially if you aren't using all of them, than if it's natively supported by the GPU. Also GPU's don't have nearly the permissions overhead to work so they can work far faster since it's mostly math and memory but only on their own memory blocks thus the speed boosts on top of fast memory.

Ultimately if i have a very important task that needs it and it can provide the work, of course even if it's slow, but a lot of prototyping often is getting test results and then iterating on the orders rather than giving it a task and coming back 4+ hours later only to see it started down the wrong path of how to approach the problem or it obviously is getting some part of your request wrong, and wasting the energy and time.

But getting it to work at all on consumer machines is still nice.