Introduction#

DeepSeek released DeepSeek V4.1 Flash on September 10, 2026, describing it as a 552B-parameter Mixture-of-Experts model designed for faster inference, higher throughput, and long-context workloads.

At first, that sounds contradictory.

552 billion parameters is enormous.

Yet during inference, DeepSeek says V4.1 Flash activates only:

8B parameters while processing the input

and

16B parameters while generating output.

It also supports a context window of up to 1 million tokens.

So the interesting question isn't:

How did DeepSeek make a 552B model fast?

The better question is:

How did DeepSeek design a 552B model so that it rarely needs to use all 552B parameters — or remember everything in the expensive way traditional Transformers do?

That is where the architecture becomes interesting.

---

First: Where Does LLM Inference Actually Spend Time?

Before looking at DeepSeek, there are three major things worth separating.

When you send a prompt to an LLM, it broadly has to:

1. Process your existing input

2. Remember information from that input

3. Generate new tokens

These are related, but they create different computational problems.

Consider this prompt:

Read this 100,000-token codebase and fix the authentication bug.

Before generating a single answer token, the model first needs to process those 100,000 tokens.

This phase is commonly called prefill.

Then generation begins:

The issue appears to be...

Now the model produces tokens one after another.

This is the decode phase.

And while generating each new token, the model needs access to information about the previous tokens.

That's where the KV cache enters the picture.

For long-context agents, coding assistants, document analysis and similar workloads, all three can become expensive.

DeepSeek V4.1 Flash attacks each one differently.

---

So What Did DeepSeek Change?

There isn't one magic trick.

The speed comes from several ideas working together:

1. Mixture-of-Experts — don't activate the whole model
2. Causal Encoder-Decoder — don't process input and output the same way
3. Compressed Sparse Attention 2 — don't attend to everything
4. KV cache compression — don't store everything at full size
5. Cross-layer reuse — don't repeatedly calculate the same type of information
6. DSpark — try to generate multiple tokens ahead

Let's break them down.

---

1. If the Model Has 552B Parameters, Why Does It Use Only 8B or 16B?

Because DeepSeek V4.1 Flash is a Mixture-of-Experts model.

Instead of having one giant dense network where every parameter participates in every token, the model contains many smaller expert networks.

DeepSeek's published configuration contains 384 routed experts plus one shared expert per MoE layer, while only 6 routed experts are selected for each token.

Think of it like having a company with 384 specialists.

A programming question does not require all 384 employees to work simultaneously.

A router looks at the incoming token and effectively decides:

Which specialists are useful for this token?

Only a small group gets activated.

That means:

Total model capacity ≠ computation required for every token.

This distinction is extremely important.

DeepSeek V4.1 Flash may have a 552B-parameter backbone, but its published active-parameter figures are approximately:

Prefill → 8B

Decode → 16B

So already, the GPU isn't performing computation over 552B parameters for every token.

But MoE alone isn't the most interesting part.

DeepSeek has been using MoE for generations.

The bigger architectural change in V4.1 Flash is what happens next.

---

2. Why Treat Reading and Writing Differently?

Traditional decoder-only LLMs essentially use the same Transformer stack for two rather different jobs:

understanding the existing prompt

and

generating the next token.

DeepSeek V4.1 Flash changes this with something called:

Causal Encoder-Decoder — CED#

The model still contains 40 Transformer layers, but they are organized as:

20-layer causal encoder

↓

20-layer decoder

This creates an asymmetric architecture.

And this is probably the easiest way to understand it:

Traditional approach#

Imagine reading a 500-page book while taking detailed notes separately on every floor of a 40-floor building.

Every floor processes the book and stores its own information.

That becomes expensive.

DeepSeek V4.1 approach#

The first 20 layers act more like the reading stage.

They process the input and build a useful representation of it.

The decoder can then derive its global KV information from the encoder's final hidden states instead of reconstructing a completely independent global KV representation from every decoder layer.

In simpler language:

Read the context, compress what was learned, and let generation work from that representation.

This is one reason DeepSeek can report only 8B active parameters during prefill, compared with 16B during decoding.

And this matters particularly for agents.

A coding agent might repeatedly receive:

• system instructions
• repository files
• previous conversation
• tool outputs
• terminal logs
• patches
• documentation

The input can easily be dramatically larger than the output.

Making the input side cheaper can therefore matter almost as much as making token generation faster.

---

3. But Doesn't a 1-Million-Token Context Make Attention Extremely Expensive?

Normally, yes.

Suppose our model has already seen:

1,000,000 tokens

and now needs to generate another token.

The naive approach would effectively ask:

Which of these previous million tokens matter right now?

Doing expensive attention over everything becomes increasingly costly as context grows.

DeepSeek's solution is called:

Compressed Sparse Attention 2 — CSA2#

The key word here is:

Sparse.

The model does not need to perform full expensive attention over every previous position at every layer.

DeepSeek V4.1 Flash's published configuration uses a 128-token sliding window and an indexer that can select 512 relevant compressed positions for sparse attention.

Conceptually, instead of saying:

Read all one million previous tokens carefully.

it can behave more like:

Read the recent context carefully, then retrieve a smaller set of older locations that appear relevant.

This is similar to searching a book.

If I ask:

What did the author say about CUDA memory optimization?

You probably don't need to reread all 1,000 pages.

You need:

the page you're currently reading

plus

the older sections related to CUDA and memory.

That is much closer to what sparse attention is trying to accomplish.

---

4. But How Does DeepSeek Know Which Old Tokens Matter?

This introduces another component:

The indexer#

You don't want the full expensive attention system to search one million positions just to determine which positions deserve attention.

That defeats the point.

So a smaller indexing mechanism first searches for promising locations.

The published model configuration shows:

32 index heads

128-dimensional index heads

Top-K = 512

Those selected positions are then used by the more expensive attention operation.

So conceptually:

1,000,000 previous positions

↓

cheap relevance search

↓

select useful positions

↓

expensive attention only where necessary

That is already useful.

But DeepSeek goes further.

---

5. Why Search Again in Every Layer?

Imagine Layer 20 just spent time determining:

These parts of the context seem important.

Then Layer 21 performs another search.

Layer 22 performs another search.

Layer 23 performs another search.

We are duplicating work.

CSA2 therefore introduces different layer behaviours:

1. Full
2. Reindex
3. Reuse

A Full layer can construct the relevant global cache/index information.

A Reindex layer can perform another selection when necessary.

A Reuse layer can reuse previously calculated sparse-attention information.

The official configuration makes this structure visible.

Among the 40 Transformer layers, only particular layers act as KV or index sources. The configuration lists KV-source layers 2, 8, 14 and 20, while additional index-source layers include 24, 28, 32 and 36.

The idea is simple:

If another layer has already done useful retrieval work, don't automatically repeat it from scratch.

This is one of those optimizations that sounds obvious after seeing it.

But traditional Transformer designs often let every layer maintain its own attention state.

DeepSeek is increasingly treating information retrieval across layers as something that can be shared.

---

6. Why Does the KV Cache Matter So Much?

Now we reach one of the biggest themes of the V4.1 technical report.

KV cache.#

During autoregressive generation, attention creates Keys and Values for previous tokens.

Without caching them, whenever the model generated another token it would have to recompute huge amounts of information about the entire previous sequence.

So inference engines save them.

That saved memory is the KV cache.

For a short conversation, this isn't necessarily a huge problem.

For:

1,000,000 tokens × many layers × many concurrent users

it becomes a very big problem.

Memory bandwidth matters.

GPU HBM matters.

Storage matters.

Cache movement matters.

And the number of simultaneous requests a server can handle matters.

---

7. What Did V4.1 Flash Do to the KV Cache?

DeepSeek combines several techniques:

• cross-layer KV reuse
• compressed sparse attention
• FP4 KV storage

The result reported in the technical documentation is a global KV cache footprint of:

890 bytes per token

That is approximately one quarter of the global KV-cache footprint of DeepSeek V4 Flash.

At one million tokens:

890 × 1,000,000 ≈ 890 MB

for that global KV-cache component.

To be clear, that does not mean the whole model needs only 890 MB.

The model weights themselves are enormous.

It means the part of the KV cache being discussed has been compressed dramatically.

And this matters because inference isn't only a computation problem.

It is increasingly a memory problem.

If each request consumes less HBM, the server can potentially accommodate more concurrent contexts.

More concurrency means:

higher throughput

and potentially:

lower serving cost per request.

---

8. Then What Is SWA Bounded Replay?

DeepSeek also uses sliding-window attention.

The model's local attention window is 128 tokens.

One option would be to persist all the sliding-window KV information to slower memory or SSD so it can later be restored.

Instead, DeepSeek describes an optimization called:

SWA Bounded Replay#

Rather than permanently storing all of that sliding-window state, the system can reconstruct the required state by replaying only a bounded recent section of the sequence.

According to DeepSeek, this reduces the persistent KV-cache footprint to roughly one eighth of DeepSeek V4 Flash.

The trade-off is interesting.

Instead of saying:

Store absolutely everything because recomputation is bad.

DeepSeek sometimes says:

This information is cheap enough to reconstruct. Don't waste expensive storage keeping it forever.

That reflects a broader idea in efficient AI systems:

sometimes recomputing a small amount of information is cheaper than storing and moving a large amount of information.

---

9. Are We Done?

Not quite.

Everything so far helps with:

processing context

and

accessing previous information efficiently.

But LLM generation still has one annoying property.

It is autoregressive.

The model normally generates:

Token 1

↓

Token 2

↓

Token 3

↓

Token 4

Each token depends on what came before it.

That sequential dependency is difficult to parallelize.

DeepSeek has another trick for that.

---

10. What Is DSpark?

V4.1 Flash includes DSpark speculative decoding.

The released configuration contains three next-token prediction layers and uses a draft block size of 5.

Instead of always asking the full model to generate exactly one token before moving to the next one, a smaller drafting mechanism can propose several likely future tokens.

Imagine the model has generated:

The capital of France is

The drafter might predict:

Paris.

Rather than forcing the expensive model through completely independent generation cycles for every likely token, speculative decoding allows candidate tokens to be proposed and then verified.

V4.1 Flash uses semi-autoregressive drafting together with confidence-based verification.

The important word is speculative.

The model isn't blindly accepting five tokens.

It proposes likely continuations.

The main model verifies them.

If several are valid, multiple tokens can effectively move through the generation pipeline together.

If they aren't, they can be rejected and normal generation continues.

So instead of:

generate → generate → generate → generate → generate

the system tries to move toward:

draft several → verify → accept useful candidates

This attacks one of the hardest bottlenecks in LLM inference: sequential decoding.

---

11. What About Engram?

V4.1 Flash also introduces something called Engram conditional memory.

The model contains approximately 196B parameters of Engram memory, accessed sparsely through token-based lookup.

This is important, but I wouldn't put it in the same category as KV compression or speculative decoding.

Engram is better understood as another attempt to separate:

how much information the model can contain

from

how much expensive neural computation must happen for every token.

Instead of forcing every piece of knowledge through large dense matrix operations, some information can be retrieved through conditional memory.

In other words:

Bigger memory does not necessarily have to mean proportionally more computation.

That principle seems to be appearing repeatedly throughout V4.1.

---

There Seems to Be a Pattern Here

Once you ignore all the architecture names, something interesting appears.

DeepSeek keeps asking the same question:

Does this computation really need to happen?

For experts:

Do all 384 experts need to run?

No. Activate 6.

For input processing:

Does input need the same amount of active computation as output?

No. Use 8B during prefill and 16B during decode.

For long-context attention:

Does every token need to attend to the entire history?

No. Keep recent tokens and retrieve relevant older positions.

For layers:

Does every layer need to independently rediscover the same relevant context?

No. Reuse attention information across layers.

For KV cache:

Does everything need to be stored at high precision?

No. Compress it, including FP4 storage.

For sliding-window states:

Does everything need to remain persisted?

No. Reconstruct bounded recent state when needed.

For generation:

Does the full model always need to advance exactly one token at a time?

Not necessarily. Draft several candidates and verify them.

And that, to me, is the most interesting part of DeepSeek V4.1 Flash.

---

So Why Is DeepSeek V4.1 Flash Fast?

Not because 552B suddenly became cheap.

It didn't.

And not because of one magical algorithm.

Instead, DeepSeek has designed the architecture around avoiding unnecessary work.

The model has a huge total capacity, but only a small portion is active for each token.

It processes input more cheaply than output.

It avoids full attention over enormous contexts.

It shares KV information between layers.

It stores the remaining cache much more compactly.

And it can use speculative decoding to reduce the sequential generation bottleneck.

You can almost summarize the architecture as:

• Don't compute what you can route.

• Don't search what you can index.

• Don't recompute what you can reuse.

• Don't store what you can reconstruct.

• Don't generate sequentially when you can safely speculate.

That seems to be where much of the speed is coming from.

And I think that's more interesting than simply saying:

“DeepSeek made another faster model.”

Because the larger trend may be that future LLM progress won't only come from building bigger models.

It may increasingly come from figuring out:

How little of a very large model do we actually need to use at any given moment?

---

Note: This article is an architecture walkthrough based primarily on DeepSeek's V4.1 Flash technical report, released model configuration and official documentation. I haven't independently benchmarked the model yet, so performance figures mentioned here should be read as published results rather than my own measurements.