DeepSeek V4 Flash vs Qwen 3.8 Flash Next at 1-Bit

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, 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

	DeepSeek-V4-Flash-0731	Qwen3.8-Flash-Next
build	UD-IQ1_S	UD-IQ1_S
size on disk	76.87 GB	67.56 GB
total parameters	about 284B	176,943,899,520
architecture	deepseek4	qwen4exp

One fairness note before any number. Both models carry the same IQ1_S label, but that label is a target the dynamic quantizer resolves differently per architecture. Flash Next lands at about 3.28 bits per parameter and DeepSeek at about 2.33. So this is not an equal-compression comparison. It compares each model at the smallest build its vendor ships, which is the build anyone with this much RAM would actually run. No claim about which architecture is better can rest on this pairing.

Where does the 284B figure come from? We did not take it on faith. DeepSeek's config.json says 43 layers, hidden size 4096, 256 routed experts of intermediate size 2048, one shared expert, and 6 experts active per token. Multiplying that out, the routed experts alone hold 277.0B parameters, which is 97% of the model, and the shared expert and embeddings add 2.1B more. That arithmetic corroborates the 284B on the model card. Flash Next is the easier case: its GGUF metadata stores the exact count, so the 176,943,899,520 in the table is read straight from the file.

The same file shows two things worth knowing. It uses MLA attention, so its key-value cache stays small even at long context. And its expert_dtype is fp4, meaning the routed experts are natively 4-bit. A 1-bit build is quantizing them below their native precision, which is a thing to measure rather than assume is free.

Setup: One Desktop, Two Binaries

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
• Runtime: llama.cpp at commit 6c5afc86, which supports both architectures
• Weights: Unsloth UD-IQ1_S for both, verified byte-exact against the Hugging Face manifest
• Sampling: identical on both sides, temperature 1.0, top_p 0.95, top_k 20, min_p 0
• Flags: --parallel 1, --jinja, 24 unpinned threads; GPU runs used -ngl 99 with --n-cpu-moe 30 for DeepSeek and 20 for Flash Next
• 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
• Grading: exact answers and real test runs in a subprocess, no judge model anywhere

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.

	DeepSeek-V4-Flash 284B	Qwen3.8-Flash-Next 177B
delivered an answer	16/19	13/19
derived correctly	16/19	15/19
median generation (GPU)	24.7 t/s	47.4 t/s
total wall clock	45.8 min	58.4 min
three.js game	working	never emitted

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.

Is that a quantization glitch, a model stuck in a loop? We checked. 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:

task	first cap	second cap
expression parser	fail at 8,192	fail at 24,576
three.js game	fail at 16,384	fail at 32,768

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.

model	build	tokens	result
DeepSeek-V4-Flash 284B	UD-IQ1_S	9,368	working game, first attempt
Qwen3.8-Flash-Next 177B	UD-IQ1_S	32,989	working game, but only after being told not to plan
Qwen3.8-27B	UD-Q4_K_M	16,384	nothing emitted, hit the ceiling still thinking
Qwen3.8-27B	UD-IQ1_S	4,048	finished quickly, but did not produce a game

DeepSeek is the only model that produced a working game from the unmodified prompt. Its file is 9,488 bytes, loads three.js 0.160.0 through an importmap, creates a live WebGL context, and logs no console errors.

Flash Next needed help. At its original caps it never emitted a file at all. At a 40,960-token cap it spent about 30,000 tokens deliberating, then wrote 322 lines of real code before running out. So the model is not incapable. It needs roughly four times DeepSeek's budget because it plans for that long before it starts.

Could we shorten the planning? Qwen's documented /no_think toggle did nothing: reasoning went from 122,013 characters to 121,045, a change of under 1%, and the run still truncated. A plain English instruction not to plan or worry about visual style worked, cutting the reasoning to 87,114 characters and letting the model finish. That file is 22,303 bytes over 608 lines, and it is the larger and more elaborate of the two working games. But note what happened: DeepSeek was asked for a game and produced one. Flash Next was asked for a game, told how to approach it, and then produced one. Those are different conditions, so this result sits outside the scoreboard.

The two 27B runs are the control, and both failed in ways worth reading. 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, because a 4-bit model a quarter the size does the same thing on the same prompt.

At 1-bit, the 27B failed differently and more completely. It finished fast, in 4,048 tokens, and emitted 12,962 bytes of HTML that cannot run. The file looks like code: it opens a module script and writes 312 references to THREE. But it never imports the library, so the script throws a ReferenceError on its first line. And 293 of those 312 references are the same statement, new THREE.Object3D(), assigned to everything the game needs, including plain numbers such as speed and score. There is no renderer, no camera, no animation loop, and no <body> element at all. The model produced something with the shape of a three.js program and none of its substance.

Here, we can see the pattern that matters for buying decisions. 1-bit quantization visibly destroys the 27B on this task, while the 177B and 284B models still write real code at the same bit width. If we have the memory, a 1-bit giant is a far better bet than a 1-bit small model, 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:

model	weights	prompt t/s	generation t/s	stddev
Qwen3.8-Flash-Next	67.56 GB	62.94	11.19	0.03
DeepSeek-V4-Flash	76.87 GB	25.21	7.10	0.02

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	prompt t/s	generation t/s
30	45.16	27.95
27	19.70	6.16
24	17.32	4.98
21	18.70	4.47

--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. Why? 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 177B 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.