llama-modchip Claims DeepSeek V4 Flash 284B Runs on 64GB RAM Without a GPU

The project is called llama-modchip. Its GitHub README, now at v2.4.0, bills itself as a way to run DeepSeek-V4-Flash in under 59 GiB of RAM at 256K context on a pure CPU, with no GPUs. Every figure below is the developer's own. The project's evidence brief found no independent reproduction of this exact 284B-on-64GB result.

What the project actually claims​

The project describes DeepSeek-V4-Flash as having 284.33 billion total parameters across 43 layers, with 256 routed experts plus one shared expert per layer. Only 13.17 billion parameters are active per token. That mixture-of-experts design is why a CPU can attempt this at all. Per token, the machine only has to touch a small slice of the weights.

The memory story is the headline:

• Baseline: the IQ2_XXS version of the source checkpoint is 76.87 GiB, which already exceeds a 64 GiB machine before any KV cache or compute buffers are allocated.
• Compressed model: the project's version is 56.56 GiB, a saving of 20.31 GiB. The README reports 57.61 GiB of resident memory at 256K context. Other passages in the README give a range up to 58.9 GiB.
• Test machine: an AMD Ryzen 9 9955HX (Zen 5) with 64GB of DDR5 and no GPU.

The memory margin is thin​

Check the units. A machine sold as 64GB has roughly 59.6 GiB of addressable capacity. A peak of 57.61 to 58.9 GiB leaves between about 0.7 and 2 GiB for Windows or Linux, background services, a browser and everything else.

The model file size (56.56 GiB) is also a different measurement from total runtime memory. On a machine that is doing anything else, this is not a comfortable fit. Treat it as a demonstration of the limit, not a recommended configuration.

Prefill is not chat speed​

The speed figures cover different stages of inference, and they are easy to mix up.

The README's own summary quotes 44.4 tok/s for prefill and 9.1 to 14.7 tok/s for generation. Prefill is the rate at which the model digests your prompt. Generation is the rate at which it writes its answer. For a chat or coding session, the 10 to 15 tokens per second range is the number that matters. That is usable for patient reading, but it is not snappy.

The project also reports a 77.1% prefill improvement over its own earlier prefill baseline of 24.70 to 25.05 tokens/s. (The 5.91 tokens/s figure was the pure-decode baseline, which improved by 53.3% to 9.06 tokens/s.) That is a comparison against the project's earlier build, not an independently verified result. A higher "Turbo" profile reportedly reaches 16.0 tokens/s with speculation. Don't confuse it with the headline 11.5 to 14.7 range.

How it gets there​

Two pieces do most of the work, according to the project:

• Compression. The README credits "SwiGLU-H2" analytical compression and a "Fractal-64" format at 3.75 bits per weight. The project also publishes quality tables with cosine similarity, KL divergence and top-1/top-3 match rates. The default "lossless" row reportedly shows perfect similarity. These are the author's measurements, so test on your own workload before trusting them.
• CPU kernels. The v2.4.0 release notes describe a four-level tiling design across AVX-512BW registers, L1, L2 and L3 caches. They credit it with +77.1% prefill and +53.3% to +81.7% pure decode. The project's published hardware requirement is AVX-512BW support. That favors recent AMD Zen 4/5 chips and some Intel parts, and it rules out many older desktops.

Speculative decoding also plays a part. A small draft component proposes tokens and the big model verifies them. The project pairs this with a 1.64 MB component called RouteCrack. Gains depend on how often the main model accepts the drafts, so speeds will vary by prompt and workload.

The compatibility catch​

This is not a file you can drop into your favorite app. The Fractal-64 files use a custom tensor type (ID 40). The README warns that unpatched llama.cpp, Ollama and LM Studio will fail with an "unknown tensor type 40" error. You need the project's patched runtime and kernels.

The project ships a setup script, command-line tools and precompiled Linux binaries. The v2.4.0 release notes also mention a Windows 10/11 hybrid GPU+CPU pack. The repository has a dedicated windows folder. The evidence available here does not show how the 284B-on-64GB result performs on Windows, so check that folder's instructions before assuming parity with the Linux numbers.

The README's example server command uses a 32K context (-c 32768). It is not itself a demonstration of the 256K claim.

Smaller models, bigger numbers​

The repository also lists NVIDIA Nemotron-3.5-30B-A3B results:

• 14.35 GiB of memory and 25.0 to 60.4 tok/s on the 16-core Zen 5 machine.
• A Threadripper result of 111.62 tok/s, plus 80.8 tok/s on an AMD Vulkan hybrid setup.

These are different models on different hardware. They do not validate the 284B result. They do suggest that mid-size mixture-of-experts models are the more practical target for ordinary desktops and laptops.

How the claim is circulating​

The project is getting attention. A popular X post describes it as "developer-reported numbers" and repeats the 76.87 to 56.56 GiB reduction. Coverage so far largely repeats the README. Its own tagline calls the result "world's first", which is a marketing claim. Treat that as promotion until others reproduce it.

What Windows and PC users should take away​

• Check your RAM and your CPU. You need a true 64GB, AVX-512BW support and spare memory headroom. A busy Windows desktop will struggle with under 2 GiB free.
• Expect modest generation speed. Think roughly 9 to 15 tokens per second at best, not instant answers.
• Plan for the custom stack. You can't use stock Ollama or LM Studio with these files. Match the project's model, runtime and hardware instructions.
• Verify quality yourself. The similarity numbers come from the author. Run your own prompts before relying on the model.
• Consider a smaller model first. If you only have 16 to 32GB, the 30B-class results are the realistic option.

Bottom line​

llama-modchip is an interesting engineering demonstration. It shows how aggressive quantization, cache-aware kernels and speculative decoding can push a very large mixture-of-experts model into commodity memory. It isn't proof that any 64GB PC can comfortably run a 284B model. The memory margin is tight and the runtime is custom. Every benchmark is the developer's own until someone reproduces them.

Correction (November 8, 2026): An earlier version of this article said the project's 77.1% prefill improvement was over an earlier baseline of 5.91 tokens/s. That figure was the pure-decode baseline; the prefill baseline was 24.70 to 25.05 tokens/s. The text has been corrected.