Open Weights
5 min read

Llama-modchip Runs DeepSeek on 64 GB: Reactions

llama-modchip says it runs the 284B DeepSeek-V4-Flash on 64 GB of RAM with no GPU. Hacker News questioned its 1.71-bit compression and slow prefill.

Olivetti-style cover reading Llama-modchip 284B on 64 GB, What People Are Saying, with blocks for 0 GPUs, 1.71 bits per weight and a 56.56 GiB model file
Olivetti-style cover reading Llama-modchip 284B on 64 GB, What People Are Saying, with blocks for 0 GPUs, 1.71 bits per weight and a 56.56 GiB model file

The open-source project llama-modchip claims to run DeepSeek-V4-Flash, a 284-billion-parameter open model, in 64 GB of RAM with no GPU. A Hacker News post by joshcsimmons on November 8 at about 2:22 AM PT put it on the front page. By 1:23 AM PT on November 9 it had 418 points and 188 comments, and posts about it were spreading on X in English, Chinese, Japanese, Korean, Arabic and Persian. This roundup covers what people on Hacker News and X said. Reddit cannot be read from our tools, so it is not included.

What the project claims

llama-modchip adds its own patches and tools to llama.cpp, under the Apache 2.0 license. The GitHub repository was created on October 29, and the README describes version 2.4.0. All numbers below are the author's own, from the README:

  • DeepSeek-V4-Flash has 284.33B total parameters, with 13.17B active per token. As a mixture-of-experts model, it uses only part of its weights for each token.
  • A standard UD-IQ1_S build from Unsloth is 76.87 GiB, which the README says is more than the roughly 62.5 GiB usable on a 64 GB Linux machine.
  • llama-modchip shrinks that file to 56.56 GiB, an average of 1.71 bits per weight. Most routed experts drop to IQ1_S at 1.5625 bits per weight, while embeddings, shared experts and some attention weights stay at higher precision.
  • On a 16-core Zen 5 CPU, the README reports prefill (reading the prompt) at about 44.4 tokens per second and generation at 9.1 to 14.7 tokens per second, with peak memory of 57.61 GiB at a 256K context.
  • A smaller Nemotron-3.5-30B-A3B build is said to run at 25.0 to 60.4 tokens per second in 16 to 32 GB of RAM.

The compressed files use a custom tensor format, so the README says stock llama.cpp, Ollama and LM Studio cannot load them. If you are new to running models at home, our guide to how much memory you need to run an AI model locally explains why bits per weight matter so much here.

How llama-modchip fits DeepSeek-V4-Flash in 64 GB: 76.87 GiB UD-IQ1_S file, cut to 56.56 GiB at 1.71 bits per weight, 57.61 GiB peak RAM, per the project README

Hacker News: what quantization is this

The first question on the thread was about compression. "At which quantization? That's the only thing I want to know," wrote akie. madduci replied that "Everything lower than 4/5 is really bad." throw10920 put it in one line: "'2-bit quant' is the 'in mice' of 'look at how big a model I can fit on this hardware'."

Others were less gloomy. pu_pe wrote that "some models keep surprisingly good performance at aggressive levels of quantization," and liuliu noted that DeepSeek-V4-Flash is "a native 4-bit model," so "you would think a 2-bit roughly equivalent to 4-bit of a native bf16 model." Both were replying to armcat, who had cited research that the best size-to-performance ratio usually sits at 4 bits. Youden told armcat that the paper itself puts quantization-aware training out of scope.

adrian17 flagged confusing size figures in the README, asking which model and quantization the 76.87 GiB number referred to.

The README itself

Other comments were about the README, not the code. intoXbox called it "quite an obnoxious Readme.md with AI slop." superkickstart asked people to "clean up the ai spammed emoji," and epihelix wrote that "The LLM vibes are dialed up to 11." zahlman asked for an overview "that doesn't require me to understand Claude-speak nor the jargon of domain experts."

People who tried it

Hands-on reports were mixed. sparse-Matrix wrote that it "works pretty good" on a Ryzen 7 5700U with 64 GB of DDR4, at a "Steady 12 to 14 TPS" and 15 watts. The comment does not say which model was running.

aappleby tested the Nemotron build on a 16-core Ryzen 7945HX with 96 GB of DDR5 and wrote that it "runs just about the same as plain old llama.cpp on the cpu (except prefill seems much faster)." They did not test DeepSeek, because the setup tool offered no option for it.

ar-nelson tried DeepSeek on a 24-core Intel Xeon server with 96 GB of DDR4, which the readiness script rated "Tier A." Loading their quant failed with a "wrong shape" tensor error, and the bundled binary failed with "Illegal instruction (core dumped)." "So I have no idea how to run this," they wrote.

Is it fast enough for coding agents

antirez linked his own X post about running DeepSeek 4.1 Flash with his separate project, DwarfStar, in SSD streaming mode. On Hacker News he wrote that with 128 GB of unified RAM "it can run even fast," and called it "coding-agent acceptably fast." embedding-shape replied that the video seemed to show about 4 seconds to process 43 input tokens. kgeist counted 116 seconds for that small request and wrote: "It's like... 1 coding task per night?"

Aurornis, who has a 128 GB M5, wrote that "The happy spot for these is for long running closed loop tasks where I'm stepping away for the evening." Roark66 added that at 1.75 bits per weight (the README says 1.71) the model is "barely usable" for them, and that they would rather run Qwen3.8-flash-next at 4 bits.

Speeds reported for llama-modchip: README says 44.4 tok/s prefill and 9.1 to 14.7 tok/s generation for DeepSeek; one HN user reported 12 to 14 TPS; another could not load the DeepSeek build

X: hype posts and two deeper checks

The most viewed X post we found came from RoundtableSpace, which opened with "You don't need a GPU to run a frontier-size AI model anymore." It had 37 likes and about 42,900 views at 1:25 AM PT on November 9.

Two posts checked the numbers. In an X post and a linked X article, Joshua_WD wrote that "The memory math holds up," but noted that the README's "lossless" label compares the patched runtime with the unpatched one on the same 56.56 GiB file. By the article's math, the repo's 22,237-token Claude Code prefix (measured on its Nemotron setup) would take about 8 minutes to process cold at 44 tokens per second. The article calls the project's trick of saving that processed prefix to a RAM disk, then restoring it in milliseconds, the most useful idea in the repo.

X user superdoccimo parsed the headers of the files on Hugging Face. In a long post written in Japanese, they reported that the custom tensors use ID 42, upstream llama.cpp's Q2_0 number, with a different block layout, not the ID 40 the README names. Upstream llama.cpp failed with an offset error rather than the error in the README, they wrote. They also said they did not run the 284B model itself, for lack of memory and disk.

Why it matters

The thread split along a familiar line. Fitting a 284B model into 64 GB of RAM is a real engineering result, and both X posts that checked the files said the sizes match the README. But nobody in these threads had published a quality comparison of the llama-modchip build against the full model, and the one detailed DeepSeek install report on Hacker News ended in errors. For a broader view of the model family, see our explainer on what DeepSeek is, and our comparison of Ollama vs LM Studio for simpler ways to run models at home.

Sources

Open WeightsDeepSeekInferenceReactions