DeepSeek V4.1 Flash: A Brand-New Base Model Wearing a Point-Release Number

DeepSeek V4.1 Flash is six days old, and the three questions its launch left open have now closed — two of them in the company's favour and one sharply against. The model itself is unchanged from September 10: a 552-billion-parameter mixture-of-experts with open MIT weights, a one-million-token context, and a new Causal Encoder-Decoder architecture that the vendor's own model card files under what the company calls its "new architecture family." What moved is everything around it. An independent evaluator published a score where launch morning had none. The company withdrew the DeepSeek V4 Pro retirement it had announced in its own changelog. And the day-zero serving work that did not exist that morning now runs on several mainstream inference runtimes — with the two hardest parts of it, the Engram memory tables and the prefill/decode split that production deployments depend on, still being actively reworked in public.

The naming mismatch is still why this piece exists. Reading "V4 Flash to V4.1 Flash" as a patch step is the natural thing to do and the wrong thing to do: the version number sits one decimal away from a retune while the architecture underneath founds a family. Six days of evidence have not softened that. If anything the independent numbers have hardened it, because a model that outscores its own vendor's 1.6-trillion-parameter flagship is not a point release — it is a generation that declined to name itself.

What actually shipped on September 10

This was not a leak and not a beta. The two-day API test that began September 8 under the model ID deepseek-v4.1-flash-expires-on-0910 ended the way its suffix said it would, and the release landed across DeepSeek's web app, mobile app and first-party API, with weights and a technical report published on Hugging Face under deepseek-ai/DeepSeek-V4.1-Flash.

The practical details have not moved in six days:

• Model name — call deepseek-flash. The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but they no longer resolve to the models they used to: both are retired, and requests naming them are served by DeepSeek V4.1 Flash and billed at the Flash rate.

• What's in the box — a 1M-token context window, 384K maximum output, JSON output, function calling, native image input, and a thinking mode that is on by default with low, high and max effort settings.

• Licence — MIT, weights included, with an inference folder and a separate encoding module in the repository. DeepSeek explicitly invited the open-source community to build inference support on day one, and the community took that up faster than the invitation implied.

The .1 that isn't a point release

The claim that started this piece came from teortaxesTex, a pseudonymous but closely followed DeepSeek watcher, in a September 10 post: that this is "the first time DeepSeek labels a completely new base model with a .1 release version," that V4.1 is "more different from V4 than, say, LLaMA 3 from LLaMA 1," and that DeepSeek "don't feel this is worth V5 yet" — without the poster being able to say why not.

Treat the causal part as inference and the structural part as checkable. The inference — why DeepSeek picked .1 over V5 — is one observer's read and nothing more; no one outside the company has explained the decision, and DeepSeek's own materials never address it. The checkable part is the architecture, and it does not read like a point release. DeepSeek's changelog describes V4.1 Flash as "the smallest model in our new architecture family," which is a strange sentence to write about a version bump: a version bump extends a family, it does not found one.

There is a real cost to the ambiguity, and it lands on buyers rather than on DeepSeek. Version numbers are the cheapest signal a developer has for "is this a new generation or a retune, and how much of my evaluation budget does it deserve?" DeepSeek has now made that signal unreliable in one direction — a model that founds an architecture family sits one decimal place away from one that changed its post-training recipe. The company gets to keep its V5 marker in reserve. Everyone doing a migration assessment pays for the confusion.

What "new architecture" means in the weights

The model card is unusually specific, which makes the generational claim testable without a single benchmark. Five things stand out — the fifth being the one the launch coverage mostly skipped, and the one that turns out to matter most to anyone trying to serve this model.

• Asymmetric activation — the Causal Encoder-Decoder split is a 40-layer transformer organized as a 20-layer causal encoder followed by a 20-layer decoder, where the decoder's global KV cache is projected from the encoder's final hidden states rather than derived from each decoder layer's own. The point of that design is that the model activates only 8B parameters per token during prefill and 16B during decode. Input-heavy agent workloads — long documents, long tool traces — get the cheap half of the model; generation gets the expensive half.

• KV cache compression, measured per token — DeepSeek-V4.1-Flash runs FP4 main KV caching at 890 bytes per token, which the card puts at roughly a quarter of DeepSeek V4 Flash. Chinese coverage went further and framed the compression against the first-generation V4 model as a 437× reduction; that larger figure is vendor-sourced arithmetic on a different baseline, so treat it as a claim rather than a measurement.

• SWA Bounded Replay — sliding-window attention normally forces you to persist KV state to SSD to reconstruct context. This rebuilds missing SWA KV states by replaying only the most recent window of tokens instead, cutting the persistent KV footprint to about an eighth of DeepSeek V4 Flash's.

• Compressed Sparse Attention 2 — each attention layer runs in one of three static modes (Full, Reindex, or Reuse), sharing KV and indexer state across layers, with a hierarchical sparse indexer bounding the cost of deeper layers independently of context length.

• Engram — a conditional-memory module that keeps memory separate from computation, implemented as n-gram hash lookups gated into the model's residual stream rather than as attention or as extra experts. The two fp8 tables hold 189 GiB of weights, per SGLang's own write-up of the architecture, and runtime vendors that ported the checkpoint put the tables at roughly 196B parameters on top of the 552B backbone — which is why the card's headline parameter count is a description of the backbone and not of the whole download. Engram is trained at two layers, uses orders of two, three and four n-grams across eight hash heads per order, and collapses tokens that normalize alike so that casing variants hash to the same bucket. The design detail worth carrying away is the cost it imposes: every decode step reads those tables, so where you put them decides how much KV cache you have left.

Read those five together and the strategic picture is legible: this is a sparsity, cache-efficiency and memory-offload architecture first, sized so the same structure can be scaled up later. The mention of a "new architecture family" is doing real work — it is a statement that there is more coming.

The independent score finally landed — and it backs the vendor

Four days ago this section would have read very differently. At launch, Artificial Analysis had published nothing on DeepSeek V4.1 Flash, Hugging Face's model page still carried the note that the model "isn't deployed by any Inference Provider," and the load-bearing claim of the whole release — that a Flash-tier model comprehensively beats a 1.6T-parameter flagship on performance, cost, speed and total task time — was a vendor assertion with no external audit. All three of those gaps have since closed.

Artificial Analysis has now measured the model on its Intelligence Index, and the short version is that DeepSeek's claim survives contact with a third party:

• Intelligence Index — DeepSeek V4.1 Flash scores 40 at max reasoning effort, ranked sixth of 113 models in its comparison class and well above the median of 18 for comparable open-weights models. DeepSeek V4 Pro 0813, the flagship it was accused of displacing, scores 36 on the same index.

• Cost per task — $0.27 per Intelligence Index task for V4.1 Flash against $0.67 for V4 Pro 0813. That is the capability-per-dollar claim, independently reproduced: the cheaper model is the more capable one on this measure, at roughly 40% of the cost per completed task.

• Speed — 212.1 output tokens per second against a median of 73.1 t/s across comparable models, with time to first token at 1.31s against a median of 2.37s. On the same harness, V4 Pro 0813 measures 94.4 t/s and a 1.72s TTFT.

• Price — Artificial Analysis records $0.30 per million input tokens and $1.20 per million output tokens with a 98% cache discount, which is DeepSeek's peak rate card as published, not a premium third-party markup.

Label that correctly, because the label has changed. These are independent measurements, not vendor figures — but they are independent measurements on a single third-party harness, and one index is not a verdict on a model. What it does settle is narrower and more useful than a leaderboard position: the specific claim DeepSeek made to justify its own product line, that Flash would beat Pro on capability and cost simultaneously, now has outside corroboration rather than a changelog behind it.

There is an honest caveat on the other side too, and it comes from the same vendor reporting as before. DeepSeek's own numbers have V4.1 Flash winning 13 of 16 comparisons against Kimi K3 and 11 of 13 against GLM-5.3, while still trailing GPT-5.6 Sol and Claude Opus 5 on the newer Terminal-Bench 3.0 and 4.0 tasks and on ProgramBench. That is a coherent shape — strongest at the coding, terminal and agent-automation work this architecture is optimized for, weaker at frontier-reasoning tasks — and it is the shape a real generational step would have. The independent index agrees with the outline without settling every cell.

The Pro retirement DeepSeek announced — and then called off

Here is the part that changed against DeepSeek's own stated plan, and it is the part most likely to affect a live integration.

At launch, DeepSeek said DeepSeek V4 Pro would be retired from its API. From 12:00 Beijing time on September 14, requests naming deepseek-v4-pro would be routed to V4.1 Flash and billed at Flash pricing — a roughly 70% cut to output cost for anyone with the Pro model name hard-coded — and would stay routed that way until a future V4.1 Pro shipped. On the launch-day rate card that meant Pro's $3.96 per million output tokens collapsing to Flash's $1.20 at peak, with no code change and no notice beyond a changelog entry.

That did not happen. On September 11, DeepSeek published a notice on its own open platform saying that in response to user demand it would continue providing DeepSeek V4 Pro API service after September 14, with billing unchanged — the notice remained displayed on the platform on September 14 itself, after the cutover moment had passed, so this is a live first-party statement rather than a rumour about one. The reported reason is the least surprising thing in this story: developers objected to a vendor silently swapping the weights behind a model name in a production integration, and DeepSeek's own multi-party testing had found V4 Pro retaining a quality edge on some teams' real workloads even where V4.1 Flash wins the public evals.

The practical read is a straight reversal of what launch-day coverage advised. If you put September 14 in your calendar to re-test a Pro-pinned integration, the deadline is void: DeepSeek V4 Pro is still DeepSeek V4 Pro, and still priced as before, while V4.1 Pro remains unannounced with no card, no parameter count, no date and no weights. What has not changed is the direction of travel — DeepSeek clearly intends to converge its line on the new architecture, and the only thing it has confirmed about the old one is that it will not force the move on a fixed date.

Serving it: 189 GiB of n-gram tables, and the work still open

The launch-day framing of availability was "runs on the vendor's API and nowhere else." That is no longer true, and where it stopped being true is instructive about this architecture.

SGLang and Miles shipped day-zero support for DeepSeek V4.1 on September 10, in the same window as the model itself — so the "no third-party serving" note that sat on the Hugging Face page at launch was stale within hours. The interesting part is not that it runs; it is what running it costs. Because every decode step reads the Engram tables, SGLang's approach is to let you place them in GPU memory or in host memory, with host offload clearing roughly 46 GiB per GPU for KV cache at the price of about 200 GB of host RAM on the node. On a four-GPU GB300 configuration, host offload raised KV cache capacity by 36% with comparable decode throughput and time to first token, and all 28 greedy probe completions matched the all-on-GPU baseline. It is opt-in, behind a single environment variable, not the default. vLLM has parallel work going the other direction — memory-mapping shards of the tables off disk rather than holding them in host RAM — which tells you the same thing from two angles: the Engram tables, not the weights, are the constraint on how cheaply you can serve this model.

The most recent changes in the whole story sit here, and they are small ones that deserve to be labelled as small. On September 15, an SGLang contributor opened pull request #39666, adding an Engram module and a shared request-history adapter to the project's DeepSeek V4.1 branch — 7 files, +1205/−11, with the adapter exposing optional n-gram history fields on the scheduler and forward batches and reconstructing that history across prefix hits, retractions and slot reuse. It is open and unmerged, its CI runs were failing, and it was awaiting review from nine code owners; the author's own summary is blunt about the limits, noting that lookup checks do not prove request-lifecycle correctness. It was one of a batch of DeepSeek V4.1 pull requests opened on that branch on September 15, most of them from the same contributor, spanning model construction, the vision tower, chat encoding and the kernel layer.

Then on September 16 the plan for the harder half of serving arrived in public. A roadmap issue, #39700, sets out prefill/decode disaggregation for DeepSeek V4.1 on the B200 platform as a staged list: prefill-side context parallelism first, then that prefill work combined with MegaMoE, BCG and multi-stream, then the decode-side items, DP attention and CUDA-graph memory among them. Stage one landed as pull request #39748, titled "[DSV4.1-PD-1/8] Support prefill node use cp parallel strategy" and opened the same day by the same author. It lets the prefill node in a disaggregated deployment run a context-parallel strategy, with a reference configuration of eight B200s at TP4/EP4 running the flashinfer_mxfp4 MoE runner and DSPARK speculative decoding. The prefill node takes --enable-prefill-cp --cp-strategy interleave alongside --disaggregation-mode prefill over the Mooncake transfer backend; the decode node runs with no CP flags at all. Validation is gsm8k scoring plus unit tests on the text and image paths. Like the Engram pull request, it is open, unmerged, and currently blocked in CI on a missing run-ci label.

Be clear about what all of that is and is not. It is infrastructure plumbing inside a runtime that already serves the model — it changes nothing about what DeepSeek V4.1 Flash does, what it costs, or whether you should use it. It is worth these lines only because it marks where the remaining sharp edges are. On the Engram side, n-gram history surviving retraction and prefix-cache reuse is exactly the kind of correctness detail that separates a demo from a production endpoint. On the disaggregation side, the target is operators who split prefill and decode across separate pools so each half can be parallelized for its own bottleneck — a deployment whose reference configuration starts at eight B200s, which is a capital decision rather than a line in a config file. And the series is labelled 1/8 while the roadmap issue enumerates its stages in six parts, with the entire decode half still unwritten: even the numbering is provisional. If you are not making that capital decision, none of this is visible from where you sit — DeepSeek V4.1 Flash is live on OrcaRouter at the pass-through rate below, and the plumbing stays on the operator's side of the endpoint.

Calling DeepSeek V4.1 Flash today

The availability line has changed on our side too, and it changed in the direction readers of the launch-day version of this piece were told to expect it would not. OrcaRouter did not carry DeepSeek V4.1 Flash on September 10 — the model page returned "model not found" and this article said so plainly rather than implying otherwise. It carries it now: deepseek/deepseek-v4.1-flash is live in the catalogue at $0.15 per million input tokens and $0.60 per million output tokens, DeepSeek's own provider rate passed through with 0% markup added, which is also the number to check the next time DeepSeek changes a price. Since it landed it has moved 54,982.2M tokens through the platform at a p50 time to first token of 811 ms and a p95 of 3.03 seconds.

What that buys you beyond the same rate card is the ability to treat a six-day-old architecture as an experiment rather than a commitment. Failover means a V4.1 Flash call that starts erroring under load can be re-pointed at another model without a deploy; the routing DSL means you can put the new model on part of your traffic and a known one on the rest and compare them on your own inputs rather than on a leaderboard; and every other model in the catalogue sits behind the same key, including the rest of the DeepSeek line — DeepSeek V4 Flash and DeepSeek V4 Pro — so a switch back is a string change, not a second contract.

That matters more than usual here, for two reasons that six days of news have made concrete. The first is that the price advantage is real but conditional on the provider keeping the rate, and a pass-through arrangement is the only kind that stays honest when it does not. The second is that the one caution from launch week has survived: both the capability edge and the cost advantage are now independently measured, but they are measured on one harness, on a model whose naming says "minor update" and whose architecture says otherwise. Route it like a new generation, because that is what it is, and keep it behind a tier you can move.

What's still open

Three things, in ascending order of how much they would tell you.

DeepSeek V4.1 Pro would test the family claim. DeepSeek V4.1 Flash calls itself the smallest model in a new architecture family, and the sibling that would prove the family exists still has no card, no parameter count, no date, no weights and no price. It is also the model the whole Pro-routing manoeuvre was structured around, now that the manoeuvre has been called off.

A second independent evaluation would test the score. An Intelligence Index of 40 with a 36 for the model it replaced is a clear result on one harness and a single data point on the question of whether this architecture is a generation ahead or a well-optimized sideways step. Watch for a second evaluator, and for whether the Engram-offload serving path holds up under real traffic rather than on greedy probes, and whether the prefill/decode split now being staged in pull requests ever turns into a packaging story that a normal team can deploy.

And the useful if unglamorous one: whether DeepSeek does this again. A second .1 label on another new base model would turn an anomaly into a convention, and convention is something a developer can plan around. One model is a curiosity. The naming only becomes misleading in a useful way once there is a pattern.

For now, the practical read separates cleanly by who you are. If you are on DeepSeek V4 Pro, the model behind that name is not changing on September 14 or any announced date — DeepSeek reversed that, and you can leave your integration alone. If you are on DeepSeek V4 Flash, you are already being moved, at the same price, onto an architecture DeepSeek built to scale. And if you were waiting for V5, the honest answer is that DeepSeek appears to have shipped the generation, declined to name it, and then found out that the number on the box is load-bearing after all.