I Ran 1-bit DeepSeek V4 Flash and Qwen 3.8 Flash Next on CPU (No GPU Needed)

DeepSeek released V4 in two sizes. The Pro is 1.6T parameters and ships only in 4-bit and 8-bit builds of roughly 800 GB, so it is out of reach for a desktop. The Flash is 284B total with 13B active per token, and Unsloth ships a 1-bit build of it at 76.87 GB. That one fits in a machine with 96 GB of RAM.

In this blog, we will run it and measure what we get. Its opponent is Qwen 3.8 Flash Next, a 180B model with about 6B active per token, also at its smallest 1-bit build, on 19 problems hard enough that 30B models mostly fail them. Everything runs on one desktop with an RTX 5090 and 95.3 GB of system memory.

The short version: DeepSeek answered more problems, but it is not the better reasoner. It is the model that finishes.

What We Tested

Every number in this table is explained below.

One fairness note before any number. Both builds carry the same IQ1_S label, but the dynamic quantizer resolves that target differently per architecture: about 3.28 bits per parameter for Flash Next, about 2.33 for DeepSeek. So this is not an equal-compression comparison. It pairs each model at the smallest build its vendor ships, which is the build anyone with this much RAM would actually run.

Almost all of DeepSeek-V4-Flash lives in its experts. The model has 43 layers, and each layer holds 256 routed experts.

Two widths define an expert. The hidden size, 4096, is the width of the vector that carries each token through the model. The intermediate size, 2048, is the narrower width inside the expert.

An expert is a small feed-forward network built from these two widths. It projects the 4096-wide token vector down to 2048, applies a gate, and projects back up to 4096. That takes three 4096 x 2048 matrices (gate, up, and down), so one expert holds 3 x 4096 x 2048 = 25.2M parameters.

Here is the dataflow through one expert:

The token splits into the gate and up matrices in parallel: both read the same 4096 incoming values, and their two 2048-wide results multiply element by element before the down matrix restores the token's shape.

Now multiply it out: 25.2M x 256 experts x 43 layers = 277B. That is 97% of the model. The shared expert, attention, and embeddings add about 7B more, which matches the 284B on the model card.

  DeepSeek-V4-Flash, where the 284B sits
  ----------------------------------------------------
  one expert   3 x 4096 x 2048                 25.2M
  x 256 routed experts per layer                6.4B   one layer
  x 43 layers                                   277B   97% of the model
  shared expert, attention, embeddings            7B   3%
  ----------------------------------------------------
  model card total                              284B

That shared expert deserves a closer look. Each layer holds one shared expert next to its 256 routed ones. The router picks which 6 routed experts see a token, but the shared expert sees every token, with no routing decision at all. This is a division of labour: knowledge that every token needs stays in the shared expert, so the routed experts are free to specialize. Flash Next uses the same trick, with one shared expert in every one of its 48 blocks.

Attention is the other part of every DeepSeek layer, and all 43 layers use MLA (multi-head latent attention). Instead of storing separate keys and values for every attention head, MLA compresses them into a single 512-wide latent per token. That is why its key-value cache stays small even at long context.

DeepSeek's config also records expert_dtype fp4: the routed experts are natively 4-bit, so a 1-bit build pushes them below their native precision. That cost is something to measure, not assume.

Qwen3.8-Flash-Next reaches its count differently. The model has 48 blocks, and each block holds 512 routed experts. Its widths are smaller: the hidden size is 2,560, and each expert is only 640 wide inside. So one expert holds 3 x 640 x 2,560 = 4.9M parameters. Multiply it out: 4.9M x 512 experts x 48 blocks = 121B.

The rest of Qwen3.8-Flash-Next sits in two unusual pieces. It stores 20 million n-grams at 2,560 dimensions each, which is another 51B of embeddings. A 4B draft head for speculative decoding comes on top. Together with attention and the other small parts, the stored weights add up to about 177B, which Qwen reports as 180B on the model card.

  Qwen3.8-Flash-Next, where the 180B sits
  ----------------------------------------------------
  one expert   3 x 640 x 2560                   4.9M
  x 512 routed experts per block                2.5B   one block
  x 48 blocks                                   121B   68% of the model
  n-gram table   20M x 2560                      51B   29%
  draft head for speculative decoding             4B
  attention and the rest                          1B
  ----------------------------------------------------
  stored weights                                177B   model card says 180B

Qwen3.8-Flash-Next also spends much less on attention. Only every fourth block uses full attention with a growing key-value cache, 12 of the 48. The other 36 blocks use linear attention, which keeps a fixed-size state no matter how long the context gets. This mix is Qwen's answer to the same problem MLA solves for DeepSeek: keeping long context cheap.

So the two designs make opposite bets, and the active counts follow the same math. DeepSeek wakes 6 of its 256 experts in every layer. That is 6 x 25.2M x 43 layers = 6.5B of expert weight per token, and the shared expert, attention, and embeddings bring the card's active figure to 13B.

Flash Next wakes 10 routed experts plus the shared one in every block. That is 11 x 4.9M x 48 blocks = 2.6B per token, about 6B once everything else is counted. Running 6B instead of 13B per token is why Flash Next generates faster.

  What actually wakes up for one token
  ----------------------------------------------------
  DeepSeek   6 of 256 experts x 25.2M           151M   per layer
  x 43 layers                                   6.5B   expert weight
  shared expert, attention, embeddings          6.5B
  ----------------------------------------------------
  DeepSeek active per token                      13B

  ----------------------------------------------------
  Flash Next   10 routed + 1 shared              54M   per block
  x 48 blocks                                   2.6B   expert weight
  attention, embeddings, draft head             3.4B
  ----------------------------------------------------
  Flash Next active per token                     6B

Our Test Setup

Everything ran on one machine with the same settings for both models:

• CPU: Intel Core Ultra 9 285K, 8 performance cores and 16 efficiency cores
• GPU: RTX 5090 with 32,607 MB of VRAM, driver 610.88, Windows 11 Pro
• Weights: Unsloth UD-IQ1_S for both, verified byte-exact against the Hugging Face manifest
• Tasks: 19 per model at one seed. 12 are ported byte-identical from our earlier four-model 30B run, 6 are harder problems built for this test, and 1 is a three.js game task

Who Delivers More Answers?

DeepSeek delivered an answer on 16 of 19 problems. Flash Next delivered on 13. If we stopped at the score, DeepSeek wins by three, and that is what most benchmarks would report.

We did not stop there, because every completion is stored verbatim next to its grade. We read the reasoning of every failed cell, and that reading changed the story: on two of its failures, Flash Next had computed the correct answer and simply never said it. Counting derived answers rather than delivered ones, the score is 16 to 15.

So the three-problem gap is almost entirely about finishing. Let's look at the two cells that prove it.

Why Is the Gap About Finishing, Not Reasoning?

The hardest problem in the set is a counting question: how many 5-element subsets of 1 to 20 contain no two consecutive integers and have a sum divisible by 3. A brute force program says the answer is 1456, so the answer key is not our opinion.

Flash Next's stored reasoning contains this line: Total =156+525+600+150+25=1456. Same. Good. The word "Same" matters. It had computed 1456 by two independent methods and cross-checked them against each other. Then it kept thinking until it hit the token ceiling and returned nothing.

DeepSeek also failed that problem, and it failed it differently. The number 1456 appears in its reasoning too, but only as a guess: Total 4368, sum residues maybe around 1456 each. It had worked out that there are 4,368 such subsets in total and was estimating an even three-way split. Its actual dynamic program was producing 4,604, it knew the program was broken, and it ran out of budget hunting the bug.

So on the single hardest problem, the smaller model solved it and the larger one did not. The scoreboard records both as failures. This is why we read the raw output instead of trusting the score.

What Does Each Model's Failure Look Like?

DeepSeek fails by being wrong. Asked what a short Python program prints, it answered [1] [1, 2] where the correct middle line is [1, 2] [1, 2]. It missed that print(f(1), f(2)) evaluates both calls before converting either to a string, so both show the same mutated list. That is a real error, and the grader is right to mark it. It also failed a formatting task asking for exactly five sentences beginning with A through E, each exactly eight words. All four 30B models in our earlier run passed that one.

Flash Next produced zero wrong answers across all 19 problems. Every one of its six failures is the same event: it hit the token ceiling while still thinking. On the arithmetic expression parser task, it produced 104,081 characters of reasoning and zero characters of answer. It wrote def calc eleven times without committing to any of them, and it spent tokens deciding how to tokenize 5e-3, which the problem never asked about.

This is not a quantization glitch or a model stuck in a loop. Repeated 12-word sequences make up only 2.3% of that text, and those are re-quotes of the prompt. The reasoning is coherent from start to end. It just does not stop. Doubling the budget did not save it:

Can a 1-Bit Model Build a Playable 3D Game?

The game task separated these models more sharply than anything else, so we widened it to four models. Each one received the byte-identical prompt: a playable endless lane runner in one self-contained HTML file using three.js, loaded from a CDN through an importmap.

DeepSeek is the only model that produced a working game from the unmodified prompt: 9,488 bytes, a live WebGL context, no console errors.

Flash Next needed help. At its original caps it planned so long it never emitted a file, and Qwen's documented /no_think toggle cut the reasoning by under 1%. A plain English instruction not to plan or worry about visual style did work: reasoning fell from 122,013 to 87,114 characters, and the model finished the larger and more elaborate of the two working games. But note what happened. DeepSeek was asked for a game. Flash Next was asked for a game and told how to approach it. Those are different conditions, so this result sits outside the scoreboard.

The two 27B runs are the control. At 4-bit, the 27B behaved exactly like Flash Next: 51,749 characters of reasoning, zero characters of answer. So this style of non-termination is not caused by 1-bit quantization. At 1-bit, the 27B finished fast but emitted code that cannot run: 312 references to THREE with no import of the library, and 293 of them the same new THREE.Object3D() assigned to everything the game needs, including plain numbers such as speed.

Here, we can see the pattern that matters for buying decisions. 1-bit quantization visibly destroys the 27B, while the 180B and 284B models still write real code at the same bit width. If we have the memory, a 1-bit giant is the better bet, and on this task it beat the 4-bit small model too.

How Fast Do They Run?

First, the number that makes this whole experiment worth doing. On the CPU alone, with no GPU involved:

A 284B model generates at 7.1 tokens a second on a desktop with no GPU at all. The stddev column matters as much as the mean. A model that is paging to disk produces wildly variable timings, and 0.02 is not wild. So 76.87 GB of weights genuinely fits inside 95.3 GB of RAM alongside the OS, which was the riskiest assumption in this plan.

With expert offload to the 5090, the median served rate is 24.7 tokens a second for DeepSeek and 47.4 for Flash Next.

Flash Next generates roughly twice as fast per token, and it still took 58.4 minutes for the suite where DeepSeek took 45.8. Speed per token is not speed to an answer. On the one hard code problem both models solved, Flash Next spent 10,600 tokens where DeepSeek spent 1,149 for the same passing result.

Both models also passed a two-hop retrieval test over a long document, where the two facts needed sit about 37,000 tokens apart. The prompt tokenizes to 38,873 tokens for DeepSeek and 45,485 for Flash Next, and they answered in 256 and 119 seconds.

Which Server Settings Matter More Than the Model?

The largest performance differences we measured had nothing to do with either model. They came from two llama-server settings, and both fail silently.

--n-cpu-moe 30 keeps 30 of DeepSeek's 43 expert layers on the CPU, and it is the operating point on a 32 GB card. At that setting the card sits at 31,160 of 32,607 MB used. Lower the number, which moves more layers onto the GPU, and generation collapses by 4.5 times. The reason is that past that point the weights no longer fit in VRAM, and on Windows CUDA does not refuse. It quietly spills over PCIe, and the spilled layers run slower than if they had stayed on the CPU. Nothing errors, the server starts, everything loads. The decode rate is the only signal.

The second setting is easier to miss. llama-server defaults to four parallel slots and allocates key-value cache for all four. On a GPU configuration, that memory comes straight out of the weight budget and pushes layers into the same spill. Adding --parallel 1 took DeepSeek from 14.6 to 23.5 tokens a second with no other change.

Which Model Should We Run?

Our honest answer is neither, not as a daily driver. A 1-bit build is the most extreme compression a vendor ships, and this run showed what that extremity costs: the 27B control collapsed into code-shaped output with nothing inside, and DeepSeek's natively 4-bit experts are stored below their design precision here. The giants survived because of their scale, not because 1-bit is safe. For everyday work, we recommend a smaller model at 4-bit precision or higher, like the 30B class at Q4_K_M, over any heavily quantized build.

The 1-bit giants are for one situation: we have the RAM, we want the largest models, and no smaller build of them exists. Inside that experiment, the head-to-head reads like this.

If we want a model that reliably returns something, DeepSeek-V4-Flash is the one, and it is the only model here that produced a working game from the plain prompt.

If we want a reasoner and are willing to manage it, Flash Next matched DeepSeek on derived answers and beat it on the hardest problem in the set. It needs a large token ceiling and sometimes an instruction that makes it commit.

If we have 96 GB of RAM and no GPU, both run. 7.1 and 11.2 tokens a second are slow but usable.

Limits of This Test

• One seed per problem. A one-problem difference is noise. The six-to-two split in truncated failures is not.
• 19 problems is a small suite. The 12 reused ones saturate, since a 30B model scored 12 of 12 on them. The 6 harder problems exist because of that, and they are where the models separated.
• The 12 reused problems are not a controlled comparison with the 30B article. Tasks and graders are byte-identical, but that run used Ollama at temperature 0.2 and this one used llama.cpp at temperature 1.0. Treat any cross-article comparison as indicative only.
• This is not an equal-compression comparison, as explained above.
• We did not test multiple seeds, quantizations above IQ1_S, DeepSeek's DSpark speculative decoding, context beyond 64K, or any non-English task.
• We cannot conclude that DeepSeek reasons better than Flash Next. On derived answers they are one problem apart. What we measured is that DeepSeek finishes and Flash Next often does not.
• The game section is not a controlled comparison, because Flash Next's working file needed an added instruction and a larger cap.
• The games were not play-tested frame by frame. We confirmed DeepSeek's file loads three.js, creates a live WebGL context, and logs no console errors.

What We Got Wrong

• Our longest-palindrome test was broken when we wrote it. It timed the function on a random string, where the longest palindrome is only about 35 characters, so a slow quadratic solution finished in 0.5 seconds and passed. We caught it by running a deliberately naive solution against every test before any model saw them, and fixed it to an adversarial "ab" repeated 100,000 times. Both models were scored only against the fixed version.
• Our first token cap was too low and produced the false AIME failure described above. Every truncated cell was re-run at a larger cap.
• Our substring audit produces false positives. It flags any failed cell whose text contains the expected answer. That correctly caught Flash Next's two derived-but-unsaid answers, and it also flagged DeepSeek's 1456, which turned out to be a coincidence. Substring presence is a reason to read the context, not a verdict.
• We reported a meaningless speed number at first. Our per-cell rate divides completion tokens by total request time, so the long-document task reported 0.34 tokens a second for a 38,873-token prompt answered in 86 tokens. That is a prefill measurement wearing a generation label, and it is excluded from the median rates above.

Conclusion

We put a 284B model on a desktop and it worked. The interesting part was never the score. It was reading the failures, where one model turned out to be wrong and the other turned out to be endless.

Key takeaways:

• A 284B model runs on a plain desktop: 76.87 GB of 1-bit weights inside 95.3 GB of RAM, at 7.1 tokens a second on the CPU and 24.7 with the RTX 5090 helping.
• Both models missed 3 of 19, but differently. DeepSeek gives wrong answers, Flash Next never finishes. On derived answers they sit one problem apart.
• The biggest speed losses were settings, not models: too many GPU layers cost 4.5x to silent PCIe spill, and the default four server slots cost DeepSeek 9 tokens a second.
• 1-bit broke the 27B on the game task while the 180B and 284B kept writing real code. Scale absorbs quantization damage that small models cannot, but our daily pick stays a smaller model at 4-bit or higher.

Next steps:

• Qwen 3.8 Flash Next on CPU only covers the thread sweep and offload ladder this run builds on.
• Qwen 3.8 Flash Next vs Qwen 3.8 27B tears down the Flash Next architecture this article benchmarks.
• The local LLMs technical reference guide matches a model and context size to our own GPU.

This is how two 1-bit giants behave on one desktop. We started by checking that 76.87 GB of weights really fit in RAM. We read every failed answer instead of trusting the scoreboard. And we finished knowing the real difference: DeepSeek finishes, Flash Next thinks past the ceiling, and the server settings matter more than the gap between them.