DeepSeek-V4.1-Flash Explained: The Causal Encoder-Decoder Architecture That Cuts KV Cache by 8x

DeepSeek shipped something on September 10, 2026 that is easy to misread as just another point release. The version number, V4.1, reads like a minor bump. The architecture underneath it is not. DeepSeek-V4.1-Flash is built on what the company calls a Causal Encoder-Decoder, or CED, a genuinely new architecture family for DeepSeek's model line, not a fine-tune, not a distillation, and not the kind of quiet efficiency patch that usually hides behind a ".1" [1] [4].

The headline number is the KV cache footprint: roughly a quarter of the high-bandwidth memory and an eighth of the SSD storage that the prior generation, DeepSeek-V4-Flash, needed to keep a session's attention state alive [1]. That is not a benchmark score. It is a structural claim about how the model is built, and it is the kind of claim worth actually verifying against the mechanism rather than repeating as a marketing line. This post does that: what CED actually is, why splitting a transformer into a causal encoder and a separate decoder produces that specific 8x reduction, what DeepSeek's own benchmark numbers say, exactly what it costs to call, and how the migration away from DeepSeek-V4-Pro is already underway whether you opted in or not.

If you already read our breakdown of DeepSeek-V4-Flash-Vision-Exp, the experimental multimodal branch DeepSeek shipped back on August 21, 2026, V4.1-Flash is the real answer to that experiment. Native vision and multimodal understanding, which Vision-Exp bolted on as a separate branch, now ships built into the main V4.1-Flash line directly [1]. And if you read our piece on DeepSeek-V4-Pro-0813's hybrid attention architecture, the 1.6 trillion parameter, 49 billion active flagship that had been the top of DeepSeek's lineup since August, V4.1-Flash is now what DeepSeek is explicitly benchmarking it against, and, as of this week, what DeepSeek is quietly routing V4-Pro's own API traffic through.

What Actually Shipped on September 10

Strip away the architecture story for a moment and look at the plain facts DeepSeek published alongside the release. DeepSeek-V4.1-Flash is a Mixture-of-Experts model with 552 billion total parameters, callable through the DeepSeek API under the model id deepseek-flash, with open MIT-licensed weights published on Hugging Face the same day [1] [5]. That is a meaningfully larger total parameter count than the V4-Flash generation it replaces, but the headline is not the size of the model, it is how little of it any single token actually touches.

DeepSeek's own official changelog reports three benchmark figures worth sitting with before anything else: a GPQA Diamond score of 90.9, a Codeforces rating of 3471, and a Terminal-Bench 2.1 score of 90.6 [2]. DeepSeek describes these results as ahead of its own flagship models, V4-Pro included, across performance, cost, speed, and total runtime [2]. We will come back to exactly what that claim does and does not mean in the benchmarks section below, because a company's own reported numbers are worth reading carefully rather than either dismissing or repeating at face value.

The pricing is where V4.1-Flash gets genuinely aggressive, and it is worth quoting precisely rather than rounding, since the exact ratios between tiers turn out to matter for how you should actually build against this model. Cached input tokens cost $0.003 per million off-peak and $0.006 per million at peak. Cache-miss input tokens cost $0.15 per million off-peak and $0.30 per million at peak. Output tokens cost $0.60 per million off-peak and $1.20 per million at peak [3]. Peak hours are defined precisely too: 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday. Every other hour, including all of Saturday and Sunday, is off-peak, and off-peak pricing is exactly half of peak pricing in every single tier [3]. We will do the full worked math on what that means for a real workload later in this post, but the short version is that DeepSeek's pricing structure and CED's architecture were clearly designed by people talking to each other, not two teams working in isolation.

Finally, the migration mechanics. DeepSeek is not making anyone rewrite their integration to get the new model. Requests to the old model names deepseek-v4-flash and deepseek-v4-flash-vision-exp are temporarily routed straight through to V4.1-Flash for backward compatibility, and starting September 14, 2026 at 04:00 UTC, that same routing was extended to deepseek-v4-pro itself, with those requests now billed at V4.1-Flash's (much lower) rates, a state of affairs DeepSeek says will continue until a V4.1-Pro ships [2]. If your production code still says model="deepseek-v4-pro", it has already been talking to V4.1-Flash for a day by the time most readers see this post. That is a bigger practical story than most model launches get, and it deserves its own section further down.

The Workload CED Was Actually Built For

Before getting into the mechanism itself, it helps to understand the specific shape of problem DeepSeek built CED to solve, because the architecture only makes sense once you see the workload it is optimized against.

Picture a coding agent pointed at a real repository. It ingests 400,000 tokens of source files, configuration, tests, and commit history to understand the codebase well enough to make a change, then produces a 1,500-token patch. Or picture a research agent that reads hundreds of pages of documents, papers, filings, transcripts, and distills all of it into three paragraphs of synthesis for a human to act on [4]. Both of these are real, common agentic workloads in 2026, and both share the same lopsided shape: the input is enormous, the output is tiny. The coding agent example above has an input-to-output ratio of roughly 267 to 1. That is not an edge case anymore, it is close to the median shape of a serious coding-agent or document-research task.

A standard decoder-only transformer, the architecture behind essentially every large language model shipped before this generation, was not built with that ratio in mind. As general background on how these models work, not a DeepSeek-specific claim: a decoder-only transformer processes every token, whether it came from the prompt or from the model's own output, through the exact same stack of layers, and at every one of those layers it builds and updates its own key-value (KV) state for that token. During the initial pass over the prompt, called prefill, the model runs every prompt token through every layer once to build up that KV cache. During generation, called decode, each new output token also runs through every layer, and at every layer the model reads the accumulated KV cache built from all prior tokens, prompt and generated alike, to compute attention. The architecture treats prefill and decode as the same operation run at different points in a growing sequence, because structurally, in a decoder-only model, they are the same operation.

That symmetry is elegant, and it is also wasteful for a workload where 99.6 percent of the tokens are input and 0.4 percent are output. The model pays the full per-layer, per-token cost of building and updating KV state for all 400,000 input tokens, using the exact same machinery it will use to generate the 1,500 output tokens that were actually the point of the request. CED's entire premise is that this symmetry does not need to hold. The expensive, representation-building work of understanding a huge prompt can happen once, in a dedicated pass, and the cheaper, generative work of producing a short output can read from that already-built representation instead of rebuilding it from scratch at every layer as it streams tokens out [4].

This is also, not coincidentally, close to the same lopsided pattern behind a lot of the AI-assisted content production tools people use every day. A tool like AI Clipping in Miraflow ingests an entire long-form video upload, transcribes and analyzes the whole thing, then produces a handful of short, ranked clips, a similarly input-heavy, output-light shape at the product level even though it is not running V4.1-Flash under the hood. The general principle, that efficient handling of a large, information-dense input paired with a comparatively small output is worth architecting for specifically, is exactly what makes fast, responsive AI tooling in the browser, the kind Miraflow's Text2Shorts pipeline depends on, practical to run at real product scale rather than as a slow, expensive demo.

Inside the Causal Encoder-Decoder Architecture

A 40-Layer Transformer, Split in Half

CED is a 40-layer transformer, and the defining structural choice is where those 40 layers go: the first 20 form a causal encoder, and the remaining 20 form a decoder [4]. That split itself is not radical on paper, classic sequence-to-sequence transformers going back to the original "Attention Is All You Need" architecture and later models like T5 also used a separate encoder and decoder. What makes CED a genuinely new design is what the encoder half is allowed to see, and what the decoder half is allowed to read from it.

The Encoder Is Causal, Not Bidirectional

Here is the detail that is easy to skim past and shouldn't be. In a classic encoder-decoder transformer, the encoder is bidirectional, meaning every prompt token can attend to every other prompt token, both earlier and later in the sequence, the way BERT's encoder works. That full bidirectional view is normally treated as an advantage: it lets the encoder build the richest possible representation of the input, since nothing is hidden from any position.

CED's encoder deliberately gives that up. Each position in CED's causal encoder can only attend to earlier positions in the prompt, never later ones, the same left-to-right causal masking a decoder-only model uses [4]. On the surface that looks like a step backward, trading away information for no obvious benefit. The actual reason is architectural consistency and cache reuse: a causal encoder produces hidden states that are valid prefixes of each other, meaning the representation built after processing the first 1,000 tokens of a prompt does not have to be thrown away and recomputed if you feed the model the same 1,000 tokens as a prefix of a longer, 5,000-token prompt later. A bidirectional encoder cannot offer that property, because every token's representation there depends on the full sequence, including tokens that have not arrived yet, so adding new input invalidates everything computed before it. For an agentic workload where a huge prompt often gets extended incrementally, more retrieved documents, more tool outputs, more conversation turns, that prefix-reuse property is exactly what makes the KV caching story in the next section work at all.

Where the Decoder's KV Cache Actually Comes From

This is the mechanism that does the real work. In a standard decoder-only transformer, every one of its layers independently builds its own key-value cache from its own hidden states as tokens stream through. A 40-layer decoder-only model is maintaining 40 separate KV caches, one per layer, each one computed from that specific layer's own view of the sequence.

CED does not do that. The decoder's global KV cache is projected from the encoder's final hidden states, a single, already-computed representation, rather than every decoder layer independently building its own separate global KV state from its own hidden states the way a standard decoder-only transformer's layers do [1] [4]. Concretely: the causal encoder runs once over the input and produces a final set of hidden states at its last layer. Those hidden states get projected into the KV representation that the decoder's layers read from for global context. The decoder is not independently recomputing "what does this prompt mean" at 20 separate depths, it is reading one answer to that question, produced once by the encoder, and spending its own 20 layers on the actual job of generating the next token well, rather than re-deriving context it already has access to.

This is the structural reason CED's active parameter counts land where they do. DeepSeek reports 8 billion active parameters per token during prefill, when the causal encoder is doing its one-time pass over the input, and 16 billion active during decode, when the decoder is generating output tokens and reading the encoder's projected KV cache, out of 552 billion total parameters in the full Mixture-of-Experts model [1]. Compare that to a standard decoder-only MoE model of similar scale, where a token running through the full 40-layer stack activates roughly the same set of experts whether it is a prompt token being ingested during prefill or a generated token being produced during decode, because structurally, those are the same operation in that architecture. CED breaks that symmetry deliberately: prefill only ever runs through the 20 encoder layers, and decode's 16 billion active parameters reflect a smaller decoder stack doing generation work against an already-built KV projection, not a full second pass rebuilding context from scratch at every layer.

Put another way: DeepSeek-V4-Pro, the prior flagship built on a standard decoder-through architecture and covered in our DeepSeek-V4-Pro architecture breakdown, activates roughly 49 billion parameters per token whether that token is being consumed during prefill or produced during decode, because a conventional decoder-only model has no structural reason for those two phases to cost differently. CED's split means prefill costs less than half that per token, and even decode, the phase every architecture treats as expensive because it happens token by token in a loop, costs roughly a third of V4-Pro's flat rate. For a workload shaped like the coding-agent example above, 400,000 prefill tokens and 1,500 decode tokens, that 8B-versus-49B gap on the overwhelming majority of tokens is where the real compute savings live.

SWA Bounded Replay: Reconstructing Instead of Storing

The encoder-projected KV cache handles global context efficiently, but modern long-context models also lean heavily on sliding window attention (SWA), where certain layers only attend to a fixed recent window of tokens rather than the full sequence, as a way to keep local, nearby-token attention cheap. The catch with SWA in a long-running session is what to do with its KV state once the window has moved past a given token. The conventional answer is to persist it, writing sliding-window KV states out to SSD so they can be reloaded if the session needs them again later.

DeepSeek's answer with CED is different. Instead of persisting sliding-window-attention KV state to SSD, "SWA Bounded Replay" reconstructs any missing SWA KV state by replaying just the most recent n_win tokens, the size of the attention window itself, rather than keeping a full persisted history on disk [1]. In practice this means if the model needs sliding-window context that has fallen out of the live cache, it recomputes it fresh from a small, bounded number of recent tokens rather than fetching a much larger stored history back off SSD. That is a genuine recompute-versus-storage tradeoff, and it is the specific mechanism DeepSeek credits for shrinking the persistent KV cache footprint to roughly one-eighth of DeepSeek-V4-Flash's [1].

It is worth being precise about what "roughly one-eighth" actually measures, because DeepSeek reports two separate figures that are easy to conflate. The official numbers are that KV cache needs one-quarter the HBM (the fast memory directly on the GPU) and one-eighth the SSD storage of the prior generation [1]. Those are different resources with different cost profiles. HBM is scarce, expensive, and directly limits how many concurrent sessions a single GPU can serve, so a 4x reduction there means meaningfully higher concurrency per accelerator. SSD is comparatively cheap and abundant, but it is what makes very long, paused-and-resumed agentic sessions affordable to keep alive over hours or days without re-processing the entire prompt from scratch every time a session resumes, so an 8x reduction there is specifically a win for exactly the kind of long-running coding-agent and research-agent sessions this whole architecture targets.

Why the HBM and SSD Numbers Land Where They Do

It's worth walking through why a quarter and an eighth are the two specific ratios that show up here rather than treating them as arbitrary marketing figures. The HBM reduction traces directly back to the encoder-projection mechanism from the previous section: a standard decoder-only model with 40 layers keeps 40 separate per-layer KV caches resident in fast memory during a session. CED's decoder reads from one projected KV representation rather than building 20 independent ones of its own, so the fast-memory footprint for the decoder's global context shrinks by roughly the same proportion that independent per-layer caches shrink down to a shared one, landing at the reported quarter of V4-Flash's HBM usage once you also account for the encoder's own smaller, prefill-only cache needs.

The SSD reduction is a separate, additive win layered on top, and it comes specifically from SWA Bounded Replay. A model that persists full sliding-window KV history to disk pays a storage cost that scales with how long a session runs and how far back its window has drifted. A model that instead replays only the last n_win tokens on demand pays a small, bounded storage cost regardless of how long the session has been running, since it never needs to keep old window states around at all, only whatever recent slice is needed to reconstruct context on the fly. Combine a KV representation that is already smaller in fast memory with a sliding-window component that stores almost nothing persistently, and an eighth of the prior generation's SSD footprint is a believable, mechanism-backed outcome rather than an unexplained multiplier.

A Quick Illustrative Look at the Numbers

None of DeepSeek's own published figures need re-deriving to trust them, they are the company's stated numbers from the announcement itself. But it helps to see the ratios laid out programmatically rather than only in prose, both to build intuition for the scale of the gap and as a template for estimating your own workload's cost profile before you commit real infrastructure planning to it.

python
/code
# Illustrative comparison of active-parameter cost between CED's split
# (8B active during prefill, 16B during decode, out of 552B total [1])
# and a standard decoder-only model that activates a flat rate per token
# regardless of phase (49B, the disclosed V4-Pro active-parameter count).
# This is a simplified relative-cost illustration, not a real latency or
# FLOPs benchmark.
def relative_compute(active_params_b: float, num_tokens: int) -> float:
    return active_params_b * num_tokens

prefill_tokens = 400_000   # a real repository ingested as context [4]
decode_tokens = 1_500      # the resulting patch [4]

ced_prefill_cost = relative_compute(8, prefill_tokens)
ced_decode_cost = relative_compute(16, decode_tokens)
flat_prefill_cost = relative_compute(49, prefill_tokens)
flat_decode_cost = relative_compute(49, decode_tokens)

print(f"CED prefill relative cost:  {ced_prefill_cost:,.0f} (param-billions x tokens)")
print(f"Flat-rate prefill cost:     {flat_prefill_cost:,.0f}")
print(f"Prefill savings:            {(1 - ced_prefill_cost / flat_prefill_cost):.1%}")
print()
print(f"CED decode relative cost:   {ced_decode_cost:,.0f}")
print(f"Flat-rate decode cost:      {flat_decode_cost:,.0f}")
print(f"Decode savings:             {(1 - ced_decode_cost / flat_decode_cost):.1%}")

Running that script makes the asymmetry concrete: on a 400,000-token prefill pass, CED's 8 billion active parameters per token is doing the heavy lifting at a fraction of what a flat 49-billion-parameter decoder-only model would spend on the exact same input, and even the 1,500-token decode pass, generating the actual answer, runs at roughly a third of that flat rate. Multiply either of those per-token savings across a production workload running thousands of requests a day, and the gap compounds into a genuinely different cost and latency profile, not just a smaller number on a spec sheet.

Benchmarks in Context: GPQA Diamond, Codeforces, and Terminal-Bench 2.1

DeepSeek's official changelog for the September 10 release reports three headline benchmark numbers for V4.1-Flash: 90.9 on GPQA Diamond, a graduate-level, multiple-choice science reasoning benchmark built specifically to resist simple lookup or memorization; a Codeforces rating of 3471, evaluated against real competitive programming problems and expressed on the same rating scale competitive programmers use for themselves; and a Terminal-Bench 2.1 score of 90.6, a benchmark built around real terminal and command-line agentic tasks rather than isolated code snippets [2]. Terminal-Bench 2.1's focus on real agentic tool use also reflects a broader 2026 training trend across labs, one covered in more depth in our explainer on environment scaling for RL training, where models are trained against increasingly realistic simulated environments rather than static datasets alone, which is a big part of why agentic benchmarks like this one have improved so fast across the industry this year.

DeepSeek states plainly that these results put V4.1-Flash ahead of its own flagship models, including DeepSeek-V4-Pro, across performance, cost, speed, and total runtime [2]. That is a genuinely strong claim, and it is worth taking seriously precisely because it is specific and falsifiable rather than vague. It is also, plainly, a self-reported benchmark. DeepSeek chose the tasks, ran the evaluation, and published the number without an independent third party replicating the run on neutral infrastructure. That does not make the number wrong, DeepSeek has a real track record of benchmark claims that independent evaluators later corroborated, but it does mean these three figures should be read as DeepSeek's own reported results rather than a peer-reviewed, independently audited score, at least until an outside lab publishes its own comparison. This post is not going to manufacture additional benchmark numbers to fill that gap, since inventing figures to make a comparison feel more complete would be worse than leaving the honest caveat in place.

What is genuinely useful here, even accepting the self-reported caveat, is the shape of the claim: DeepSeek is not just saying V4.1-Flash scores well in isolation, it is saying a 552-billion-parameter model with 8 to 16 billion active parameters per token outperforms a 1.6-trillion-parameter, 49-billion-active flagship on real reasoning, coding, and agentic terminal-use tasks, while costing meaningfully less to run. If that claim holds up under independent scrutiny in the weeks after launch, it is a genuinely significant result for how the field thinks about the tradeoff between total capacity and active compute, not just a routine leaderboard shuffle.

Pricing and the V4-Pro Migration

The Four Pricing Tiers, Exactly

DeepSeek's pricing for deepseek-flash is published with enough precision that it is worth quoting the raw table rather than paraphrasing it, since the exact ratios between tiers matter for how you should structure requests against this model.

Two ratios inside that table are worth calling out specifically because they are easy to skim past. First, a cache hit on input tokens costs exactly one-fiftieth of a cache miss, in both the off-peak and peak windows: $0.003 versus $0.15 off-peak, $0.006 versus $0.30 at peak [3]. That is an enormous incentive to structure your prompts so that repeated, unchanging context, a large system prompt, a stable codebase snapshot, a long document being referenced across multiple turns, lands as a cache hit on every call after the first. Second, output tokens are consistently the most expensive tier by a wide margin, four times the cache-miss input rate and two hundred times the cache-hit rate in both windows. That pricing structure is not incidental. It rewards exactly the workload shape CED was architecturally built for: pushing as much of a request's real cost as possible into cheap, cacheable input processing, and keeping the generated output short.

Peak Hours, Precisely

Peak pricing applies during two UTC windows on weekdays only: 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday [3]. Every other hour of the week, all of the remaining weekday hours plus the entirety of Saturday and Sunday, bills at the off-peak rate, which is precisely half the peak rate in every single tier. For a team in the Americas, those two UTC windows correspond roughly to late night through early morning and mid-morning hours in US time zones, meaning a large share of US business-hours traffic actually falls in the cheaper off-peak window by default, while teams operating primarily out of East Asia or parts of Europe are more likely to have real production traffic land inside at least one of the two peak windows and should plan batch or non-latency-sensitive work accordingly.

A Worked Cost Example

Numbers land differently once they are run against an actual workload rather than read as a rate card. Here is a simple calculator that prices out a representative agentic workload, a large, mostly-cached repository context plus a modest amount of fresh input and a short generated patch, across both pricing windows.

python
/code
# Worked monthly cost example for a coding-agent workload using
# DeepSeek-V4.1-Flash's published pricing tiers [3]. Token volumes below
# are illustrative assumptions for one representative request pattern,
# not DeepSeek-published figures.
PRICING = {
    "off_peak": {"cache_hit": 0.003, "cache_miss": 0.15, "output": 0.60},
    "peak":     {"cache_hit": 0.006, "cache_miss": 0.30, "output": 1.20},
}

# One illustrative request: a mostly-cached 400K token repo context,
# a small amount of fresh (cache-miss) diff context, and a short patch.
cached_input_m = 0.395     # 395,000 tokens, cached repo context
fresh_input_m = 0.005      # 5,000 tokens, new diff context
output_m = 0.0015          # 1,500 tokens, the generated patch
requests_per_month = 20_000

for window, rates in PRICING.items():
    per_request = (
        cached_input_m * rates["cache_hit"]
        + fresh_input_m * rates["cache_miss"]
        + output_m * rates["output"]
    )
    monthly = per_request * requests_per_month
    print(f"{window:>9}: ${per_request:.5f} per request -> ${monthly:,.2f} per month")

The exact figures in that example are illustrative, not a DeepSeek-published number, but the mechanism they demonstrate is real and directly traceable to the published rate card: scheduling a batch of similar, cache-friendly requests to land inside the off-peak window, or simply avoiding the two narrow weekday peak windows entirely, is close to free relative to the alternative of paying peak rates by accident because a scheduled job happens to kick off at 07:00 UTC on a Tuesday.

The September 14 V4-Pro Cutover

Here is the detail that changes how you should think about any code still pointed at the old model name. Starting September 14, 2026 at 04:00 UTC, four days after V4.1-Flash itself shipped, all deepseek-v4-pro requests began routing to V4.1-Flash instead, billed at V4.1-Flash's rates, and DeepSeek says this will continue until a V4.1-Pro model ships [2]. The same backward-compatible routing already covers the older model names deepseek-v4-flash and deepseek-v4-flash-vision-exp [2]. If your production system still specifies any of those three model strings, it is not actually calling the model those names describe anymore, it is calling V4.1-Flash under a legacy alias, likely at a noticeably lower price than you were budgeting for, and with a materially different latency and cost profile than the model you originally integrated against and load-tested.

That is worth treating as an action item, not a footnote. Anyone with model="deepseek-v4-pro" hardcoded into a production system should update to model="deepseek-flash" explicitly, both because relying on an undocumented-duration compatibility routing is fragile engineering practice, and because any cost projections, rate limit assumptions, or latency budgets built around V4-Pro's old pricing and behavior are now measuring the wrong model entirely. For anyone doing capacity planning around this kind of routing behavior more generally, our explainer on how AI request routing works across NVIDIA NeMo Switchyard and Runway's model router covers the broader pattern of providers quietly redirecting a model name to newer infrastructure behind the scenes, which is exactly what is happening here.

How to Actually Call DeepSeek-V4.1-Flash

The API is OpenAI-compatible, which means if you already have code calling any DeepSeek model, or really any OpenAI-compatible provider, switching to V4.1-Flash is a matter of changing the base URL and model string, not rewriting your integration.

python
/code
# Calling DeepSeek-V4.1-Flash through the OpenAI-compatible API.
# Model id is "deepseek-flash" [2]. Old names (deepseek-v4-flash,
# deepseek-v4-flash-vision-exp, and now deepseek-v4-pro) are temporarily
# routed to this same model for backward compatibility [2].
from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "system", "content": "You are a precise coding agent working inside an existing repository."},
        {"role": "user", "content": "Here is a 400,000-token repository context (truncated for this example). Produce a patch that fixes the failing test in payment_utils.py."},
    ],
    temperature=0.2,
    max_tokens=1500,
)

msg = response.choices[0].message.content
usage = response.usage
print(msg)
print(f"prompt_tokens={usage.prompt_tokens} completion_tokens={usage.completion_tokens}")

A few details worth setting up correctly from the start. The model id to call is exactly deepseek-flash, not deepseek-v4.1-flash or any variant with the version number spelled out [2]. Because pricing is genuinely time-sensitive, logging the wall-clock UTC time alongside token usage on every request is worth doing from day one, both to reconcile actual spend against the published rate card and to catch a scheduled batch job that is unintentionally landing inside a peak window. And because cache-hit pricing is fifty times cheaper than cache-miss pricing on input tokens, structuring your prompt so that stable, repeated content, system instructions, a large reference document, an unchanging codebase snapshot, appears first and consistently in the same form across calls gives the caching layer the best chance to recognize it as a hit rather than treating slightly-reordered or reformatted context as new content every time.

For teams that need to self-host rather than call the hosted API, the weights are open under an MIT license on Hugging Face, which is a meaningfully permissive license for a model at this parameter count and puts real commercial self-hosting on the table for teams with the infrastructure to support a 552-billion-parameter Mixture-of-Experts model [5]. CED's split between prefill and decode is one lever for making inference cheaper. It is worth knowing it is not the only one in active use across the industry this year; our explainer on speculative decoding covers a different, decode-time technique that speeds up token generation itself using a smaller draft model, a complementary approach rather than a competing one, and the two techniques are not mutually exclusive in a real serving stack.

bash
/code
# DeepSeek-V4.1-Flash weights are open under MIT license on Hugging Face [5].
# 552B total parameters still requires real multi-GPU capacity to self-host.
pip install "huggingface_hub[cli]"
huggingface-cli login

huggingface-cli download deepseek-ai/DeepSeek-V4.1-Flash \
  --local-dir ./deepseek-v4.1-flash \
  --local-dir-use-symlinks False

vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code \
  --port 8000

If you want to see the mechanism itself rendered as motion rather than static diagrams, here is a generation prompt built around the same encoder-to-decoder handoff described throughout this post, written in the same pastel technical blueprint style as the images above.

A soft-gradient pastel technical blueprint animation on a faint grid background with a ruler tick-mark border, drawn like laboratory pipeline equipment with thin colored outlines rather than flat fills. A stream of small glowing tokens flows in from the left into a row of twenty connected glass-and-tubing modules captioned CAUSAL ENCODER, lighting up one module at a time strictly left to right, never skipping backward, as the tokens pass through. At the twentieth module, the accumulated light compresses into a single glowing capsule labeled KV PROJECTION that travels down a thin conduit into a second, visibly shorter row of twenty modules captioned DECODER. That shorter row lights up in the same left-to-right sequence, producing a small trickle of glowing output tokens at the far right labeled OUTPUT. Camera holds a steady wide static shot, gentle pastel blue and lavender gradient lighting shifting subtly as each stage activates, smooth continuous motion throughout, no people, no logos, no garbled text, captions short and legible.

Choosing CED vs a Dense Decoder-Only Model: Production Notes

Not every workload should switch to V4.1-Flash, or to a CED-style architecture in general, and it is worth being direct about where the tradeoff actually cuts rather than treating this as a universal upgrade.

You are a strong fit if your requests are genuinely input-heavy. Coding agents operating over real repositories, research and document-synthesis agents, retrieval-augmented generation systems feeding large chunks of retrieved context, and long multi-turn agent sessions that accumulate substantial conversation history are exactly the workload shape CED's active-parameter split was built to optimize. If your typical request looks like tens or hundreds of thousands of input tokens producing a few hundred to a few thousand output tokens, the 8-billion-active prefill cost and the shrunk KV footprint translate directly into lower real spend and higher achievable concurrency per GPU if you are self-hosting, or lower and more predictable API cost if you are calling the hosted endpoint.

You get comparatively less benefit if your workload is output-heavy or roughly balanced. A creative-writing assistant generating long-form output from a short prompt, a chatbot with brief per-turn context, or a code-generation tool producing large files from a short spec does not spend most of its compute in the phase CED optimizes. The decoder's 16-billion active parameters during generation are still meaningfully lower than a flat 49-billion-parameter decoder-only model, so there is still a real benefit, but the architecture's headline advantage is specifically concentrated in the prefill-heavy case, and a workload that inverts that ratio will see a smaller relative gain.

Evaluate the self-reported benchmarks against your own task distribution before committing production traffic. DeepSeek's GPQA Diamond, Codeforces, and Terminal-Bench 2.1 numbers are real, specific, and worth taking seriously, but they are DeepSeek's own evaluation. Running your own held-out evaluation set through both V4.1-Flash and whatever model you are currently using, on tasks that actually resemble your production traffic, is worth the relatively small effort before a full migration, especially for anything customer-facing where a benchmark-chart win does not automatically translate into a better experience on your specific task distribution.

If you were already planning to migrate off V4-Pro, the timing argument is strong. Given that deepseek-v4-pro traffic is already being routed to V4.1-Flash as of September 14, 2026, and DeepSeek states this continues until a V4.1-Pro ships, there is limited value in resisting the migration for its own sake. The practical move is updating your model string explicitly, validating behavior against your own test suite, and treating the transition as already underway rather than optional.

For teams building consumer-facing AI content tools, the efficiency story matters even if you never call DeepSeek directly. The broader trend CED represents, architectures that spend compute proportionally to what a request actually needs rather than uniformly across every token, is the same underlying pressure that makes fast, responsive AI generation inside a browser, the kind behind tools like Miraflow's AI Image Generator, its Cinematic AI Video Generator, its YouTube Thumbnail Maker, and its AI Music Generator, practical to serve at real consumer scale rather than remaining a slow, expensive research demo. None of those tools run on DeepSeek specifically, but the underlying engineering pressure, getting a large model to respond in seconds instead of minutes, is exactly what a whole browser-based platform like Miraflow AI depends on across every one of its generation pipelines.

Common Mistakes to Avoid

Treating "552 billion parameters" as the number that determines cost. The total parameter count describes the model's learned capacity, not what any single request actually pays for. The active-parameter figures, 8 billion during prefill and 16 billion during decode, are the numbers that actually predict compute cost and latency, and conflating total and active parameters is an easy way to badly overestimate how expensive this model is to run.

Assuming the causal encoder works like a bidirectional one. CED's encoder is causal, each position can only see earlier positions, not the full BERT-style bidirectional view a classic encoder-decoder transformer's encoder uses. If you are reasoning about what the model can and cannot "see" while building a prompt, remember that this still behaves like left-to-right processing on the input side, not full-context bidirectional attention.

Citing the GPQA Diamond, Codeforces, and Terminal-Bench numbers as independently verified. They are DeepSeek's own published, self-reported results from its own official changelog. Real and specific, but not the same evidentiary standard as an independent third-party evaluation, and worth flagging as such if you are citing them in your own writing or decision-making.

Leaving deepseek-v4-pro hardcoded in production code and assuming nothing changed. As of September 14, 2026, those requests are silently being served by V4.1-Flash at V4.1-Flash's pricing. That is convenient in the short term, but relying on an undocumented-duration compatibility redirect instead of updating to the explicit deepseek-flash model id is fragile, and any performance or cost assumptions baked into your system from the V4-Pro era no longer describe the model actually answering your requests.

Ignoring the fifty-times price gap between cache hits and cache misses on input tokens. Structuring prompts so that stable, repeated content does not land as a cache hit, because it gets reordered, reformatted, or regenerated slightly differently on every call, is one of the most common and easily avoidable ways teams overpay for this model relative to what the rate card actually allows.

Frequently Asked Questions

What does CED, or Causal Encoder-Decoder, actually mean? It is a 40-layer transformer split into a 20-layer causal encoder that processes the input with left-to-right (not bidirectional) attention, followed by a 20-layer decoder that generates output by reading a KV cache projected from the encoder's final hidden states, rather than building its own separate KV state at every layer the way a standard decoder-only model does [1] [4].

Is DeepSeek-V4.1-Flash the same thing as DeepSeek-V4-Flash-Vision-Exp? No. Vision-Exp was an experimental, separate multimodal branch DeepSeek shipped on August 21, 2026, on top of the earlier V4-Flash architecture [1]. V4.1-Flash is the full, non-experimental release that supersedes it, built on the new CED architecture, with native multimodal and vision understanding built directly into the main model rather than a separate branch. Read more in our earlier DeepSeek-V4-Flash-Vision-Exp explainer.

Why does the model use fewer active parameters during prefill than during decode? Prefill only runs tokens through the 20-layer causal encoder, which is where DeepSeek's reported 8-billion active-parameter figure comes from. Decode runs through the 20-layer decoder while reading the encoder's already-projected KV cache, landing at 16 billion active parameters, still well under half of what a comparable standard decoder-only model activates in either phase [1].

Are DeepSeek's benchmark numbers independently verified? Not as of this post. The GPQA Diamond (90.9), Codeforces (3471), and Terminal-Bench 2.1 (90.6) figures come from DeepSeek's own official API changelog, run and reported by DeepSeek itself [2]. They are specific and credible given DeepSeek's track record, but they have not yet been replicated by an independent third-party evaluation at the time of writing.

What happens to my existing DeepSeek-V4-Pro integration? As of September 14, 2026 at 04:00 UTC, all deepseek-v4-pro requests are routed to V4.1-Flash and billed at V4.1-Flash's rates, a state DeepSeek says continues until a V4.1-Pro model ships [2]. Updating your code to explicitly call deepseek-flash is the recommended move rather than relying on the compatibility redirect indefinitely.

Can I self-host DeepSeek-V4.1-Flash? Yes. The weights are published under an MIT license on Hugging Face [5]. At 552 billion total parameters, self-hosting still requires real multi-GPU infrastructure, though the smaller active-parameter counts during both prefill and decode make it more forgiving to serve than a similarly-sized dense or standard MoE model at comparable total parameter count.

How much cheaper is off-peak pricing? Exactly half of peak pricing, in every tier, every time. Peak hours are 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday only; every other hour of the week is off-peak [3].

Conclusion

DeepSeek-V4.1-Flash is a genuinely new architecture wearing a minor-version-looking name. The Causal Encoder-Decoder design does something structurally different from every decoder-only model that came before it in DeepSeek's own lineup: it stops treating prompt-processing and output-generation as the same operation happening at different points in a sequence, and instead lets a dedicated causal encoder build the input's representation once, while a smaller decoder reads a projection of that representation to generate output cheaply. The result, 8 billion active parameters during prefill and 16 billion during decode out of 552 billion total, plus a KV cache footprint that DeepSeek reports at a quarter the HBM and an eighth the SSD of the prior generation, is not an incremental efficiency tweak. It is a direct, mechanism-level answer to the specific, lopsided shape of real 2026 agentic workloads, a 400,000-token repository in, a 1,500-token patch out.

The benchmark numbers, GPQA Diamond at 90.9, a 3471 Codeforces rating, and 90.6 on Terminal-Bench 2.1, are worth taking seriously precisely because DeepSeek reported them specifically rather than vaguely, even while remembering they are self-reported until an independent evaluation confirms them. The pricing, down to $0.003 per million cached input tokens off-peak, rewards exactly the workload shape CED is built for. And the fact that DeepSeek is already routing deepseek-v4-pro traffic through this new model as of September 14 means the migration is not a future decision for most teams, it is a present one, whether their code has been updated to reflect it yet or not.

References and Sources

[1] DeepSeek. "DeepSeek-V4.1-Flash."

[2] DeepSeek API Docs. "DeepSeek API Changelog, September 10, 2026."

[3] DeepSeek API Docs. "Pricing."

[4] Helix.ml. "DeepSeek V4.1 Flash Explained."

[5] Hugging Face. "deepseek-ai/DeepSeek-V4.1-Flash model card."