Three Local Flagships, One Idea: Qwen3.8-Flash-Next vs DeepSeek-V4-Flash vs Qwen3.8-27B

Read the config files of the three most interesting open-weight models you can run at home in August 2026 and something odd happens. They stop looking like rivals and start looking like drafts of the same idea.

All three ship their own speculative decoder inside the checkpoint. Two of the three ship a sparse-attention indexer that decides which parts of a long context to actually look at. Two of the three are hybrids that use linear attention for three layers out of every four. And the newest of them spends roughly a third of its download on a lookup table that is not a neural network at all.

This is a comparison of what those three models are — read from their configuration files, which is the one source that cannot market at you — and of what all three do, on hardware sitting in one room.

What is measured here and what is not

This distinction runs through the whole article, so it goes first.

Qwen3.8-27B and DeepSeek-V4-Flash have been run on our own hardware, at length, and every performance number attributed to them below is something observed rather than published — a single RTX 5090 for the Qwen, a pair of DGX Spark (GB10) boxes at TP=2 for the DeepSeek.

Qwen3.8-Flash-Next has been run here too, which took stopping the DeepSeek deployment for a day and handing the pair over: NVFP4, TP=2 across the same two GB10 boxes, at two speculative depths. So every performance figure below was observed rather than published, and the article can compare designs three ways and behaviour three ways.

The vendor's own benchmark scores stay in their own section and out of our tables. They are not opaque — the model card documents its harnesses, sampling parameters and pass@k settings — but they were produced by the people selling the model, on harnesses nobody here has re-run. Putting them in the same column as a number from this room would look like a comparison and be a category error.

And one thing is worth saying before any of the numbers, because it happened repeatedly: almost everything we got wrong on the first attempt was configuration rather than capability. Twice, a confident conclusion about a model turned out to be a conclusion about a flag — which is a hazard of home benchmarking that no benchmark suite warns you about.

The three, at a glance

The two Qwen models share a vocabulary size exactly, share a vision tower depth exactly, and share a native context length exactly. Flash-Next is not a different product line. It is the same design taken to a place a 27B dense model cannot go.

Where the speculator lives

This is the convergence that matters most, because it changes what deploying a model involves rather than merely how fast it runs.

The classical arrangement is a separate draft model: a small network you download alongside the real one, version-match against it, load into memory beside it, and keep in sync forever after. It proposes tokens, the big model verifies them in a batch, and you keep whatever the big model would have produced anyway. That is how Muse Glimmer 30B runs DFlash, and it works — but every one of those steps is a step you can get wrong.

All three of these models reject that arrangement.

Qwen3.8-27B declares mtp_num_hidden_layers: 1 — a multi-token-prediction head trained into the checkpoint and quantised along with it. On a 5090 it takes decode from a measured 66 tokens per second to between 147 and 159, with nothing downloaded. That is the flag we spent weeks not testing.

Qwen3.8-Flash-Next declares the same field, with more detail than the 27B exposes:

"mtp": { "hybrid": true, "layer_types": ["full_attention"],
         "num_hidden_layers": 1, "rope_theta": 10000000 }

The vendor accounts for it as 4 B of the 180 B total. It accelerates a great deal: measured here, the head is the whole difference between 71 tok/s and 93 tok/s on structured output, accepting 9.75 of a possible 10 tokens per forward pass at depth 9. What the config could not say is that its depth is quantised — the ring buffer behind the sparse-attention indexer has to divide the attention block size, so depths 5 through 8 cannot be set at all.

DeepSeek-V4-Flash uses DSpark — a different mechanism with the same siting: in the checkpoint, dspark_block_size: 5, three draft layers, markov_rank: 256. On the GB10 pair it measures 77.2% draft acceptance, 4.86 accepted tokens for every six proposed.

Three checkpoints, two vendors, two entirely different speculative mechanisms, one shared conclusion about where the drafter should live. The operational difference is not subtle: there is no second artefact to source, no version skew to manage, and no separate set of weights competing for memory.

It is worth adding that this convergence is easy to miss. The 27B's own documentation asserted for weeks that its MTP head was unimplemented in llama.cpp and unusable outside vLLM. That claim was inferred from a loader message, never tested, and wrong — the head had been sitting in the file the whole time, reachable by a single flag.

The hybrid, and what it buys

Both Qwen models set full_attention_interval: 4. Their layer_types arrays are literally three linear-attention layers followed by one full-attention layer, repeating:

linear, linear, linear, full,   × 16   (27B, 64 layers)
linear, linear, linear, full,   × 12   (Flash-Next, 48 layers)

The linear layers are Gated DeltaNet, which holds a fixed-size recurrent state instead of a growing key-value cache. Only the full-attention layers pay per-token KV cost. That single fact is what makes a quarter-million-token context arithmetically plausible on hardware that could not otherwise hold it — and if the per-token figure is not a number you think in, the KV cache explainer is the one to read first.

Working it through for each model — the same arithmetic that was validated against measured VRAM on the 27B to within 1.6%:

Flash-Next halves the KV heads relative to the 27B and drops four full-attention layers, and the result is a cache roughly 2.7× cheaper per token on a model 6.7× larger. That is the trade being made: enormous parameter count, tiny working memory per token of context. What that buys, at the context lengths these models advertise, is the difference between a 262K window you can afford and one you cannot.

DeepSeek gets to a similar place by an entirely different route. Multi-head Latent Attention compresses the KV representation itself rather than eliminating layers that hold one, and it lands slightly cheaper still — 18.28 KiB per token, measured across all 43 layers.

Sparse attention: two indexers, one job

Long context is not only a memory problem. Attending densely over a million tokens is hopeless regardless of what it costs to store them, so both of the newer models ship a mechanism that decides what to read.

DeepSeek's is the Lightning Indexer: 64 index heads, index_topk: 512, a 128-token sliding window. It selects the top 512 keys and the model attends to those.

Flash-Next's is Qwen Sparse Attention, and the config is more modest — indexer_n_heads: 4, indexer_head_dim: 128, indexer_compress_ratio: 4, indexer_budget: 2048. Four index heads against DeepSeek's sixty-four, a budget of 2,048 tokens or 512 blocks.

Both are the same architectural admission: past a certain context length, a model that reads everything is not a better model, it is a slower one. Neither is measured here, and the two sets of numbers are not comparable to each other in any case — different mechanisms, different units, different vendors' definitions of a "budget".

The strangest thing in the file

Flash-Next spends 51 B of its 180 B parameters on something that is not a transformer:

"ngram_size": 3,
"ngram_vocab_size_base": 20000000,
"ple_layer_ids": [2],
"heads_per_ngram": 8,
"ple_embed_dim": 2560

That is a twenty-million-entry embedding table over bigrams and trigrams, injected into the residual stream at layer 2. Nearly a third of the download, and the thing it does is look up character sequences it has seen before.

Two observations, both worth being explicit about the confidence level of. The first is factual: this is a lookup, so unlike the MoE experts it does not contribute to the dense read per token — you touch the rows your input hits and nothing else. The second is an inference and nothing more: a large n-gram memory placed very early looks like a way to hand the transformer layers cheap surface-level statistics so they can spend their capacity elsewhere. That is a plausible story about a config field, not a finding, and it should be read as exactly that until somebody ablates it.

Neither Qwen3.8-27B nor DeepSeek-V4-Flash has anything comparable. This one is not convergence — it is the place where Flash-Next is genuinely doing something the others are not.

Sparsity, and what you pay for it

The three models occupy three different points on the same trade-off.

A dense model reads every parameter it has, every token. That is why the 27B decodes at 60.8 to 66 tokens per second on a 5090 — measured, and consistent with an achieved memory bandwidth of about 1,088 GB/s, or 61% of the card's theoretical 1,792 GB/s. It is the same bandwidth ceiling that decided its race against Muse Glimmer.

A sparse model inverts the constraint. DeepSeek-V4-Flash holds 304 B of parameters and touches roughly 13 B of them per token, which is why a model that size decodes at a measured 71.8 tokens per second mean and 88.3 peak on two desktop-class boxes. You pay for the parameters in memory and capital cost; you pay for the active ones in time.

Flash-Next pushes that further than either — 6 B active out of 180 B on disk. On paper it is the sparsest of the three by a wide margin.

Vision: the same tower, twice

Both Qwen models carry a vision encoder whose every dimension is identical — 27 layers, hidden size 1,152, 16 heads, intermediate 4,304, patch size 16, 2,304 position embeddings, spatial and temporal merge 2. Not similar: the same. Both config.json files were read directly for this, rather than one of them being taken from a prior write-up.

Two fields differ, and neither is a capability. One is model_type, an architecture-family tag — qwen3_5 against qwen4_exp. The other is the one most likely to be misread. out_hidden_size is 5,120 on the 27B and 2,560 on Flash-Next — but that is the width of the projection out of the vision tower and into the language model, and it necessarily equals whatever the text model's hidden_size is. The 27B is 5,120 wide; Flash-Next is 2,560 wide and buys its capacity from 512 experts instead. The number tracks the shape of the LLM, not the quality of the eye.

So nothing in these two configs says one model sees better than the other. If Flash-Next does read images better — and it may well — the reason will be its training and the far larger language model doing the reasoning behind an identical encoder, neither of which is visible in a config file. Multimodal ability is not mostly a property of the ViT. Its vendor does publish both models on one multimodal harness — 64.4 against 57.4 on ClawEval-MM at pass@3 — but that is the vendor's harness rather than ours, so it is reported further down with the rest of the published figures rather than treated as a finding here.

Both also ship deepstack_visual_indexes: []. DeepStack — fusing intermediate ViT layers into the language model at multiple depths, which Qwen3-VL headlines as a feature and populates with [8, 16, 24] — is switched off in both. Only the final ViT layer's output reaches the language model.

On the 27B that was predicted to hurt exactly the work DeepStack exists for: small-text OCR, dense document layout, grounding. Tested against Qwen3-VL-32B on real scanned documents, it did not. Whether the same holds for Flash-Next is unknown, but the prediction has a poor track record on this architecture family.

Same encoder is not the same behaviour

One warning against over-reading all of that, because it is the trap this section sets.

Matching config fields describe the tower. They say nothing about what reaches it. The 27B's vision is served by llama.cpp from a separate mmproj file, and needs an explicit floor of 1,024 image tokens — a flag that exists because without it the engine's own image tokenisation dominates the result rather than the model's ability. Flash-Next's encoder ships inside the checkpoint and would be served by an entirely different stack.

Identical weights reached through different preprocessing, different tokenisation, and different serving code do not produce identical behaviour, and nothing here licenses moving a measured result from one row to the other. The 27B's OCR reputation was earned on its own stack.

Flash-Next has read documents here, and the warning above turned out to be the load-bearing sentence in this section. Given the same number of image tokens it reads at least as well as the 27B — it recovered an author's name the 27B misread. Given the tokens each serving stack hands it by default, it reads far worse, because llama.cpp pads small pictures to a floor and vLLM does not. Same tower, same weights, a 5.4× difference in what reaches them. The behaviour that differs is the preprocessing, exactly as this section warned, and it took two wrong conclusions to notice.

DeepSeek-V4-Flash has no vision tower at all. For a document-reading workload the comparison ends there, whatever the throughput numbers say.

What we actually measured

Fenced off deliberately. Everything in this section was observed on hardware in this room.

Qwen3.8-27B, single RTX 5090, Q4_K_XL, 65,536-token context with vision loaded:

DeepSeek-V4-Flash-0731, two GB10 boxes at TP=2, NVFP4 experts and FP8 elsewhere:

Qwen3.8-Flash-Next, the same two GB10 boxes at TP=2, NVFP4 experts with an FP8 n-gram table, with reasoning disabled so that it is being asked the same question DeepSeek is:

Put the three side by side and the first thing you notice is that the smallest one is still winning. The 27B with its speculator running is faster per token than either 100-billion-plus model on twice the hardware. Sparsity, on this evidence, buys capability rather than latency — it lets a model know more things, not answer sooner. That was true before Flash-Next arrived and it survived Flash-Next arriving.

The second is that all three get roughly a doubling out of a speculator that came in the box, which is the previous section's argument restated as a measurement, three times over.

The third takes a moment longer to see, because it only appears once you stop reading tokens per second as a single number.

Throughput is forward passes multiplied by how many tokens each pass yields, and those two quantities move against each other. DeepSeek manages 14.9 forward passes a second and accepts 5.94 of a possible 6 tokens on each. Flash-Next at k=4 manages 14.2 and accepts 4.99 of 5 — the same machine rate, produced from 6 billion active parameters against DeepSeek's much larger set. Push the speculator deeper, to k=9, and the trade becomes explicit: the machine slows to 9.6 passes a second but each one now carries up to ten tokens, and it accepts 9.75 of them. That is an excellent bargain when the next words are guessable and a bad one when they are not, which is exactly why the structured rows climb by nearly a third while prose gets slower.

The fourth is a non-event, and worth recording precisely because everyone expects otherwise. The 200-gigabit fabric joining the two boxes is barely used: tensor-parallel traffic sits at 1.3% of the link during decode and 7.4% during prefill, around 3.3 MB of all-reduce per generated token. A far slower cable would produce these same numbers. The bottleneck is arithmetic, not distance — something the GB10 community had already concluded, and which this run reproduced without setting out to.

Which one to run, and when

None of that resolves into a winner, which is the honest result. It resolves into a split:

Neither fits on one box. Both sit at roughly 119 GB of the 121 GB each node reports, which is its own quiet finding: two models three years and two vendors apart, arriving independently at the same answer for how much of a machine a flagship should occupy.

What it took to run it here

Four obstacles looked likely before the attempt. Three of them were real, the one billed as decisive was the easiest, and the one that actually cost the afternoon was not on the list.

The 5090 was never in contention. The smallest published quantisation is 72.5 GB against a 32.6 GB card, and no amount of context trimming closes a gap of that size. Which card you need for which model stops being a preference at this size and starts being arithmetic.

The pair had the memory and was occupied, so it was emptied. DeepSeek came down for a day. There was no way around it: at 126 GiB resident against 121 GB a node, the checkpoint does not fit one Spark either, so TP=2 is a requirement rather than a tuning choice — and the two models can never be measured on the same day, let alone the same hour.

Engine support, billed as the real blocker, took twenty minutes. vLLM ships a dedicated image for the architecture and it loads qwen4_exp without complaint. It needed one 14-line patch to the n-gram embedding layer, because this checkpoint keeps that table in FP8 while the outer quantisation is NVFP4 — a combination the stock path mishandles by serving 44 GiB of lookup table with no scale applied. It does not raise an error. It just returns wrong numbers, which is the more expensive failure.

What actually cost the afternoon was configuration. Five launches failed before one worked, and not one of them failed in a way that named its own cause:

That last one is architectural rather than accidental, and it is the most interesting: the QSA ring must hold every row a speculative step writes before acceptance is known, rounded to whole groups, and the result has to divide the attention block size. So k=5 — the depth DeepSeek runs at — cannot be set on this model at all.

The part where looking is not like reading

Everything above is about generating text. Ask these models to look at something and the ordering inverts.

The same twelve video frames take 0.52 seconds each on the 27B's single 5090 and 1.26 seconds each on Flash-Next spread across the pair — the desktop card winning by a factor of two and a half against hardware four times its size. The reason is that a vision request is almost all prefill: six images is some 6,600 tokens to encode and then barely anything to generate, so it is bound by raw arithmetic, and one 5090 has more of that than two GB10s. Decode is the opposite regime, which is where speculation pays and the pair takes the lead. Two speeds, two different bottlenecks — and the hardware ordering flips between them.

For an actual job that matters less than it sounds. Describing a ten-minute video goes from about 105 seconds to about 250, and it is a button you press before doing something else. The reason to move vision onto the pair was never speed — it was to stop it competing with the image generator for the desktop's card.

There is a stranger finding underneath. Speculative depth, which costs nothing in text quality, visibly degrades what the model sees. Same clip, same keyframes, same weights: at k=9 the descriptions called a cloth stocking "dough" four to six times across a track; at k=4, not once. Run the same window three times, and k=4 gives the right reading every time where k=9 flips between them. The 27B's own launch script had already recorded the hazard in almost these words — "baseline vision is 100% reproducible across a restart, MTP vision is not" — and it transfers to the newer model intact. Since there is only one speculative setting per server, a machine tuned to write JSON quickly is a machine whose descriptions of pictures are a sample rather than a reading.

The trap that produced two wrong answers

This one deserves telling properly, because it is the sort of mistake that survives peer review: it produces a result that is coherent, repeatable, and about the wrong thing.

The 27B is launched with --image-min-tokens 1024, so llama.cpp pads a small picture up to a floor. vLLM has no such flag set and tokenises the actual pixels. The same 331×468 page therefore reached one model as 1,128 image tokens and the other as 209 — and the model given a fifth of the picture read the small print wrong, which looks exactly like a model that hallucinates. It does not. Given equal tokens it read an author's name correctly that the 27B got wrong.

A pixel floor is not a token floor either: a 720×1280 video keyframe clears 1024 pixels on its long side and still arrived as 631 tokens against 1,087. Two vision models are comparable only if they receive the same number of image tokens, and nothing in an inference call makes that visible.

What the vendor publishes, in its own section

Everything above was measured here. Everything in this section was not — it is Qwen's own evaluation, reproduced because leaving it out would hide something material.

The material thing is this: the model card benchmarks all three of the models this article compares, on one harness. A three-way quality comparison does exist. It simply is not ours, and no number in it has been re-run here.

Claude-Opus-4.6 — which the card runs at a setting it labels only as "Max" — is kept below as Opus-4.6, because it is the reference point every reader of a local-model comparison reaches for. It is Qwen's measurement of somebody else's model, and it is the least trustworthy thing on this page — see the note under the tables before drawing anything from it. The card's Qwen3.7-Plus column is dropped as out of scope; the full table is on the model card.

The card bolds its own leaders. That emphasis is removed here, because dropping a column changes which figure leads a row and carrying the bold across would assert a ranking we had altered by omission.

DeepSeek-V4-Flash is not a column in the card's vision table, which is the correct decision — it has no vision tower. That leaves the two Qwens, and the same unverified Claude column:

Four things in those tables are worth saying out loud, with the caveat that all of them are observations about someone else's numbers.

The 27B is closer than the parameter counts suggest, and that is the vendor saying so. SWE-bench Pro 61.7 against 62.5. GPQA Diamond 89.2 against 91.7. LiveCodeBench v6 90.3 against 91.9. On the vision side, OSWorld 2.0 binary is a dead tie and MathVision is within a point. A 27 B dense model is trading single-digit points to a 180 B model with seven times the parameters — on the larger model's own evaluation. That is the article's argument arriving from the opposite direction: the throughput finding said sparsity buys capability rather than latency, and the vendor's table suggests the capability it buys is real but modest.

DeepSeek takes two rows, and both are about long or open-ended work. NL2Repo-Bench, 54.2 against 48.1 — repository-scale code generation, the longest-context task in the set, on the model that serves 1,048,576 tokens against 262,144. And Agents' Last Exam at pass@1, 25.2 against 24.3, which is close enough to be noise but is the one agent row it takes. Note that the card scores that benchmark two ways and DeepSeek appears in only one of them, so the pair of Agents' Last Exam rows is not a like-for-like three-way comparison the way the rest of the table is.

One apparent contradiction is not one. The card has Flash-Next beating DeepSeek on CoWorkBench 73.9 to 45.1, while our own measurements put DeepSeek ahead on agent loops by 30–100%. Both can hold: the card is scoring whether the agent completes the task, and we measured how fast tokens come out. A model can be better at the work and slower at emitting it. Reading either number as the other is the mistake this section exists to prevent.

And the Claude column should be read very differently from the other three. Flash-Next beats Opus 4.6 on every row but HLE, sometimes enormously — IFBench 81.3 to 62.5, JobBench 55.7 to 36.6, ERQA 72.3 to 40.8, MathVision 90.6 to 65.5. Those are not the margins of a capability gap between two frontier-class models, and the reason to be careful is structural rather than a suspicion of bad faith:

A vendor's number for its own model is a claim about that model. A vendor's number for a competitor is a claim about a configuration you cannot see. Qwen chose the harness, the prompts, the tool definitions, the sampling parameters and the mode Claude ran in. Nobody tunes a rival's setup as hard as their own.

Four things that produce this pattern without anyone lying. Mode — the card writes "Opus-4.6 (Max)" without saying what that sets, and our own DeepSeek measurement moved from 54.3% to 96.7% on LiveCodeBench on a single reasoning flag, so a 19-point gap is well inside the range one setting can explain. Scaffold — SWE-bench-family scores move ten to twenty points on the agent harness alone. Answer extraction — large, uniform vision gaps are the signature of a parser that does not match the other model's output format, scoring correct answers as zero. Image preprocessing — the failure this article devotes a whole section to, where the same page reached two stacks as 1,128 image tokens and 209, and the starved one looked like it was hallucinating.

Two points in Qwen's favour: they published HLE, which they lose, and their own smaller 27B is left looking competitive throughout — neither is what a massaged table looks like. Some of these results are probably real; open weights have genuinely closed much of the gap on well-specified coding and agentic work. The problem is that from inside the table there is no way to tell which rows are which, and not one number in that column has been checked here.

What this article does not tell you

The Flash-Next numbers are one day old and one configuration deep. They were taken on a single NVFP4 conversion, at two speculative depths, on one prompt set. The DeepSeek column beside them has months of use behind it. A model that has been run once is not a model that is known.

And the speculative comparison is asymmetric. DeepSeek has only ever been run at k=5, the depth its recipe shipped, and was never swept. Flash-Next was swept and gained 31% from moving. So the tables show one model tuned against another at its default, which flatters the newcomer by an unknown amount.

The quality benchmarks above are the vendor's, and none were re-run here. They are reported because a three-way comparison exists and hiding it would be worse, not because they have been checked. Our own quality measurement covers one model: DeepSeek scores 54.3% on LiveCodeBench without reasoning and 96.7% with it, through an endpoint that had to be hand-built because the checkpoint ships no chat template. Note that this is not the 90.6 in the card's table — different version, different settings, not the same measurement, and a good illustration of why the two sets of numbers stay apart. Flash-Next reasons natively and its equivalent in-house number does not exist yet. That is still the most interesting missing measurement in this article.

The two indexers are not comparable to each other, and nothing here should be read as saying four index heads is worse than sixty-four. They are different mechanisms measured by their vendors in different units.

The n-gram interpretation is a guess. The field values are facts; what the table is for is a plausible reading of a config file.

Nothing here addresses cost. A 304 B model on two GB10s and a 27 B model on one 5090 are not the same purchase, and the article compares what they do rather than what they cost to do it.

The thing the config files were right about

The three checkpoints turned out to agree with each other more than they disagree. Each ships its own speculative decoder. Two of three use linear attention for most of their layers and spend real attention only where it earns its keep. Two of three carry a sparse indexer whose job is to decide what not to look at. Set the marketing aside and they read as three attempts at one design, arrived at independently, converging.

What separates them in practice is smaller and more specific than the architecture suggests, and it is rarely the thing the model card leads with. A million tokens of context against 262 thousand. A speculative depth that cannot be set to 5 because a ring buffer has to divide 1616. An image reaching one model at five times the resolution of the other because of a flag nobody would think to compare. The interesting differences between local flagships in 2026 are not architectural any more — they are operational, and most of them are invisible until you run the thing yourself.

Which is the argument for running it yourself. A vendor's benchmark table would not have caught a single item in that list.

Related reading

• Qwen3.8-27B Is 2.3× Faster With One Flag — Do You Need DFlash2? — the in-checkpoint speculator on the smallest of the three, measured in full
• DeepSeek-V4-Flash on Two GB10s: 304B Params, 1M Context, 83 Watts — the months of use behind this article's DeepSeek column
• AI Workstation Comparison: RTX 5090 vs GB10 (HP ZGX) — the two machines every number here was taken on
• Mixture of Experts (MoE), Explained — why 180B on disk can read like 6B
• What a 256K (or 1M) Context Window Actually Costs You — the arithmetic behind the KV-per-token table