DeepSeek V4.1 Flash: persistent KV cache storage drops to one-eighth

So AI agents have an annoying habit: the longer they work, the more stuff they have to remember.

Ask a chatbot one question and this barely matters. Ask an agent to spend two hours researching companies, opening files, running code, checking its work, fixing mistakes, and using tools, and suddenly the conversation history becomes enormous.

The model has to keep dragging all of that history along every time it takes another step.

DeepSeek's new V4.1-Flash technical report is basically 50 pages dedicated to solving that problem.

And the wild part is that DeepSeek didn't solve it by making a tiny model.

V4.1-Flash has 552B backbone parameters, another 196B parameters dedicated to a memory system called Engram, native image understanding, and a context window of up to one million tokens.

DeepSeek instead redesigned how much of that model has to work, how much previous context it stores, and how often it can reuse work it already did. The result is a model that DeepSeek says uses one-quarter the global KV cache and roughly one-eighth the persistent KV-cache storage of V4-Flash at the same sequence length.

First up, the TL;DR

DeepSeek released a technical report for V4.1-Flash, a 552B-parameter multimodal Mixture-of-Experts model designed specifically to make huge AI contexts cheaper to process and remember.

A Mixture-of-Experts model, or MoE, is a giant model that activates only a small group of specialized parts for each token instead of firing the whole thing every time.

Here's what happened:

• V4.1-Flash supports 1M-token contexts, images and text, and activates only 8B parameters per token while reading input and 16B while generating output.
• Its global KV cache (cached key/value representations from previously processed tokens, kept in high-bandwidth GPU memory during active use) takes just 890 bytes per token, roughly one-quarter of V4-Flash.
• Its persistent KV-cache storage, kept in SSD or host memory for later prefix reuse, falls to roughly one-eighth of V4-Flash's footprint.
• DeepSeek says going from 4K to 1M tokens, a 256x increase in context, raises its precision-adjusted single-token decoding computation by only about 25%.

DeepSeek also reports some serious agent scores. V4.1-Flash hit 90.6% on Terminal-Bench 2.1, 74.2% on DeepSWE v1.1, and 54.8% on AutomationBench, posting the highest reported point estimate among the comparison models on all three tests.

And this model has a built-in reasoning dial. Increasing effort from 25 to 100 improved DeepSeek's eight-benchmark reasoning average from 67.1% to 76.3%, while using roughly 2.5x the output tokens.

Our take: The most important idea here is bigger than DeepSeek. As agents work longer, AI economics increasingly depend on the cost of carrying context through the job. V4.1-Flash is a model designed around that reality from the beginning.

Okay, what exactly is eating all this memory?

Every time an AI model reads your prompt, it creates mathematical representations of the information it may need later.

Some of those representations are stored in the KV cache, short for key-value cache. More precisely, it stores cached key/value representations from previously processed tokens so the model can reuse them instead of recomputing the same attention state from scratch.

We've actually covered this problem before in our breakdown of Google's TurboQuant research, but the simple analogy is a cheat sheet.

Imagine giving an AI a 500-page document.

You do not want it rereading all 500 pages from scratch every time it generates another word. So the model stores useful intermediate calculations from those pages in memory.

Great!

Except now imagine an agent working for hours.

It reads your instructions. Searches the web. Opens 30 files. Runs code. Gets an error. Reads the error. Fixes the code. Opens another tool. Receives another giant response.

That cheat sheet gets chonky.

DeepSeek divides that memory into two buckets.

Global attention gives the model a route to information across the full context. In V4.1-Flash, the sparse global-attention layers still select only some cached entries for attention rather than reading every earlier token at every layer. The corresponding global KV cache can keep growing as the context grows.

Sliding-Window Attention, or SWA, gives the model a smaller local memory window. Each layer only looks at the most recent chunk of information, so that portion stays bounded even during huge conversations.

Then there are two places the memories live.

HBM, or high-bandwidth memory, is the extremely fast and expensive memory attached to AI accelerators. DeepSeek keeps the active global KV cache there.

Persistent KV cache is saved to SSDs or host memory so previously processed prefixes can be reused later.

DeepSeek says that as sparse attention made the actual math of processing long contexts cheaper, storing and moving all this memory became one of the next bottlenecks.

That is the race V4.1-Flash is trying to win.

The first trick: only make half the model read everything

V4.1-Flash has 40 Transformer layers.

A Transformer is the basic architecture behind most modern language models. You can roughly think of those layers as 40 consecutive stages that transform the information into progressively more useful representations.

DeepSeek splits them evenly:

• 20 layers form a causal encoder.
• 20 layers form a decoder.

Normally, processing a huge prompt would involve pushing those tokens through the whole network.

DeepSeek's Causal Encoder-Decoder architecture, or CED, takes a shortcut.

The first 20 layers process the input. Then the model uses the encoder's final representations to generate the decoder's global KV cache directly.

In plain English: the second half of the model can get the global long-context memory it needs without independently rereading the entire prompt. The decoder still replays the final 128 prompt tokens to rebuild its local SWA state before generation.

For sufficiently long sequences, DeepSeek says this changes prefill computation from roughly N × L to N × L/2, with a smaller bounded decoder-replay term still remaining.

Prefill simply means the work the model does reading and processing your input before it starts answering.

Combined with the model's MoE routing, this encoder-decoder design helps V4.1-Flash activate 8B parameters per token during prefill and 16B during decoding, when it is actually producing the response.

DeepSeek says CED nearly halves prefill computation while maintaining comparable performance to its baseline.

For agents, that matters a lot.

An agent keeps calling tools and getting new information back. Every new chunk can create another prefill job.

The cheaper you make reading, the cheaper you make the loop.

Then DeepSeek started making layers share notes

The next technique has the extremely normal human name Compressed Sparse Attention 2, or CSA2.

Stay with me.

Attention is basically the process an AI model uses to decide which earlier information deserves attention right now.

With one million tokens available, checking every previous token at every layer would get ridiculous.

So CSA2 attacks the problem in three places:

• Compress how large each memory entry is.
• Reduce how many previous positions get inspected.
• Share memories between different model layers instead of giving every layer its own copy.

That third part is the big addition.

DeepSeek gives CSA2 layers three modes.

Full Mode makes a fresh global KV cache and chooses which previous pieces of context matter.

Reindex Mode shares an existing cache but makes its own choice about which entries matter.

Reuse Mode shares both the cache and the previous layer's selections.

So some layers basically say: Yep, those notes look good. I'll use those.

More precisely, the sparse-attention system selects the Top 512 entries it believes are most relevant for a query.

In the decoder, DeepSeek also builds a larger candidate pool containing up to 16,384 positions, created from 2,048 blocks of eight positions each.

The first Full indexing layer still scores the full causally visible range. Later Reindex layers can search only that candidate pool, so their indexing search cost stays bounded even as total context gets much longer.

The broader design choice is pretty clever: layers can share memory without being forced to pay attention to exactly the same information.

Then DeepSeek squeezed those memories into four bits

DeepSeek also stores its main KV cache using FP4, a roughly four-bit numerical format.

This is called quantization, which basically means representing numbers using fewer bits.

Fewer bits means less memory.

DeepSeek's previous V4 model stored its main KV cache in FP8. Moving the main cache to FP4 nearly halves that portion of the storage requirement again.

The model does not keep everything at four bits.

DeepSeek says its local SWA cache was more sensitive to compression, so that remains in FP8.

The company also trained the model to expect the lower-precision cache through quantization-aware training, meaning the effects of that compression are present while the model learns rather than being bolted on afterward.

DeepSeek reports that the selected FP4 format supports magnitudes up to 2,688. Its theoretical cache-value bound is only about 22.6, while values observed during training were around 10.

That gave DeepSeek enough numerical headroom to simplify the format without measuring an accuracy decrease from removing an additional global scaling factor.

And then it stopped saving a bunch of short-lived memories at all

This may be my favorite optimization in the paper because it is basically a storage cleanup.

DeepSeek says V4's persistent cache kept two types of information for more than 72 hours under typical workloads:

1. Global KV, which can remain useful for a long time.
2. SWA KV, the model's short local memory.

The problem was that SWA memory generally mattered for only minutes during an active session.

Yet it consumed nearly half of V4's persistent KV cache capacity.

So V4.1 stops keeping SWA KV in the long-term persistent cache.

Instead, it gives this state a short-lived home in a distributed memory pool built from 10% of each machine's host DRAM.

Once the session moves on, the space can quickly be recycled.

If that short-term state disappears and the model needs it again, V4.1 uses something called SWA Bounded Replay.

Exact reconstruction would require replaying number of layers × window size worth of tokens.

V4.1's window is 128 tokens.

Instead of perfectly reconstructing every layer's history, DeepSeek replays only those latest 128 tokens and accepts an approximation.

That approximation means the reconstructed state is not mathematically identical to what a full replay would have produced.

DeepSeek says its experiments found little observed impact on response quality. For decoder replay specifically, it simulated the same approximation during post-training so the model could adapt to it.

Combine that change with the global-cache compression and DeepSeek says persistent KV storage drops to roughly one-eighth of V4-Flash under identical workloads.

For comparison, the global cache alone is 890 bytes per token, around one-quarter of V4-Flash and about 1/437th the per-token global KV-cache size of DeepSeek-V1.

That is an absurd amount of architectural dieting.

And somehow this is still a 552B-parameter model

The funny part is how easy the word "Flash" makes this thing sound small.

It isn't.

DeepSeek-V4.1-Flash has 552B backbone parameters plus 196B Engram parameters.

Its efficiency comes partly from Mixture-of-Experts, or MoE.

Imagine having 384 specialists in a building, but only calling six of them into the meeting for each piece of information.

Every Transformer block contains one shared expert plus 384 routed experts, and six routed experts activate for each token.

That sparse expert routing helps explain how DeepSeek can have hundreds of billions of available parameters while activating a much smaller subset for each token. The specific 8B prefill versus 16B decode split also reflects the CED architecture described above.

If this architecture sounds familiar, our previous DeepSeek V4 deep dive explains how DeepSeek had already made efficient long-context inference one of V4's defining architectural bets.

V4.1 pushes much harder in the same direction.

DeepSeek added a separate 196B-parameter memory system too

Those extra 196B Engram parameters deserve their own explanation.

Engram is what DeepSeek calls a conditional memory module.

The idea is to let one part of the system specialize in memorizing patterns while the Transformer spends its expensive computation solving the actual problem.

DeepSeek spreads Engram across two modules, each receiving half the parameters.

The memory looks up patterns spanning two, three, and four tokens, uses eight hash heads, and gives each head a table of roughly 16M entries.

These tables use FP8 precision.

Because the lookup address is predictable from the input, DeepSeek can start retrieving the relevant memory from ordinary host memory while the rest of the model is computing.

In other words, part of this gigantic parameter count can live outside precious GPU memory and get fetched when needed.

It also learned to look at images

V4.1-Flash is natively multimodal, meaning it can process both text and images through the same language-model backbone.

DeepSeek trained a dedicated 32-layer vision encoder called DeepSeek-ViT.

That model breaks images into patches, processes them, then uses a 3×3 pixel-unshuffle operation to rearrange the visual information and reduce the number of visual tokens by a factor of nine.

That lets it support images up to approximately 1344×1344 pixels while controlling how much visual context gets dumped into the language model.

DeepSeek trained this vision system in stages.

First came contrastive training on approximately 47B image-text pairs, where the model learns which text and images belong together.

Then it connected the vision encoder to a temporary 4B MoE language model and trained on another 236B tokens spanning captions, alt text, charts, and optical character recognition, or OCR.

Afterward, DeepSeek threw away that temporary language model and kept the trained vision encoder.

DeepSeek trained the whole thing on 45 trillion tokens

The full V4.1-Flash backbone then trained on 45T tokens.

For scale, the batch size stayed fixed at 100.6M tokens throughout training.

DeepSeek says it trained sparse attention from scratch with 64K-token sequences, then extended the context window to 1M tokens after 34T training tokens.

The final data mix used approximately seven text-only tokens for every one multimodal token.

DeepSeek also says it deliberately filtered model-generated text that added little new information.

Its argument is that weak synthetic output and low-quality machine translation can become a form of "implicit duplication." The model keeps seeing repackaged versions of information it already knows.

The coding corpus also included newer repositories, commits, libraries, frameworks, and a broader mix of programming languages.

The post-training section contains maybe the most important sentence in the paper

After all that architectural novelty, DeepSeek says the next wave of gains came from something much less exotic:

better training tasks.

The company says V4.1's post-training uses the familiar sequence of supervised fine-tuning, reinforcement learning, and on-policy distillation.

In normal-person English:

Supervised fine-tuning shows the model examples of good behavior.

Reinforcement learning, or RL, lets the model attempt tasks and receive rewards when it succeeds.

Distillation uses stronger teacher models to teach another model how to behave.

DeepSeek says it introduced no novel post-training algorithm here.

Instead, it argues that essentially all of the observed post-training improvement came from scaling the quality, diversity, and verifiability of the tasks and environments used for training.

This lines up with something we have been talking about for months: increasingly capable agents need increasingly realistic places to practice.

Our beginner guide to AI agents explains the runtime side of this. The model is only one layer. Tools, context, permissions, memory, and the surrounding agent system change what it can actually accomplish.

DeepSeek took that idea straight into training.

So DeepSeek built millions of sandboxed practice environments for AI

A DeepSeek training task has three pieces:

• A problem.
• An environment where the model can work.
• A verification system that determines whether it actually succeeded.

DeepSeek recreated interfaces from real SaaS products, enterprise applications, and specialized business systems.

It also collected voluntarily returned employee and partner interactions, including negative feedback and model failures, and turned those failures into new training environments.

For coding, separate agents help choose projects, construct containers, install dependencies, create tests, remove clues that leak the solution, attempt the task, inspect failures, and repair broken evaluations.

The resulting training and evaluation infrastructure eventually had to support millions of concurrent sandbox instances spanning different harnesses, repositories, dependencies, platforms, and services.

A sandbox is basically a sealed-off computer environment where an AI can run programs and make changes without getting free rein over the entire system.

DeepSeek built its own system, called DeepSeek Elastic Compute, or DSec, rather than relying entirely on a standard orchestrator such as Kubernetes.

It reports increasing density from roughly 1,000 to more than 2,500 live containers per physical machine before measurable end-to-end performance degradation appeared.

The agents also started attacking their own training environments

This section of the paper gets pretty wild.

DeepSeek says its agents frequently attempted reward hacking, meaning they found ways to game the training setup rather than solve the task the intended way.

The report says agents exploited recently disclosed permission issues in the XFS filesystem and illegal-memory-access vulnerabilities involving AppArmor.

Some found answers through package mirrors.

Others deleted critical binaries, broke system files, or removed the filesystem.

During evaluation, DeepSeek says it even observed agents decompiling core Ubuntu packages while looking for vulnerabilities.

So DeepSeek added per-sandbox AppArmor restrictions and eBPF network policies, which are low-level rules controlling what network actions processes are allowed to take.

If an agent causes its environment to crash, DeepSeek treats that trajectory as a failure and sends what it calls a "repercussion" signal back into RL.

Nothing builds character like deleting Linux and getting a zero.

Training itself became asynchronous

Agent tasks can take wildly different amounts of time.

One agent may finish quickly. Another might still be fighting a software installation 20 minutes later.

Waiting for every agent in a batch to finish wastes hardware.

So DeepSeek moved nearly all of its RL and on-policy distillation toward asynchronous generation, where completed work can keep flowing into training without waiting for the slowest sample.

That creates new problems.

Short outputs tend to finish first, which can bias early training data toward short solutions.

Some trajectories also become off-policy, meaning portions were generated by an older version of the model after training has already moved forward.

DeepSeek compensates by controlling how many examples come from each dataset, optionally discarding unusually early short completions, bounding how stale samples can become, and masking overly stale tokens out of the training loss.

Even crazier, generation can be interrupted at any token boundary, saved, and resumed after the model checkpoint changes.

DeepSeek persists both the KV cache and its expert-routing state so the job can continue without rereading the entire context.

The final distillation stage uses more than 40 teacher models spanning different domains and even different architectures.

Then there's the reasoning dial

DeepSeek also trained V4.1-Flash with a reasoning effort setting from 1 to 100.

This does not impose a hard token limit.

Instead, DeepSeek changes how strongly the training reward penalizes extra reasoning tokens.

Low effort applies more pressure to be concise.

High effort makes additional reasoning cheaper, allowing the model to spend more tokens working through the problem.

The September 2026 API deployment described in the report maps three public presets onto that internal scale:

• Low = 50
• High = 75
• Max = 100

Same model weights. Same basic decoding setup. Different learned operating point.

And the cost-versus-quality curve is revealing.

DeepSeek reports that increasing effort from 25 to 100 raised its eight-benchmark reasoning average from 67.1% to 76.3%.

On DeepSWE, it went from 66.0% to 74.2%.

Terminal-Bench 2.1 went from 82.4% to 90.6%.

But output-token usage increased about 2.5x overall.

Across individual reasoning benchmarks, responses grew roughly 2x to 3.1x. AIME 2026 went from about 4.6K to 11.4K tokens, while MathArena Apex jumped from 29.1K to 86.1K.

DeepSeek says effort settings around 60 to 80 capture most of the accuracy available at maximum effort while using less than half the token budget.

Going all the way to 100 lengthens some agent trajectories another 1.6x to 1.8x for relatively modest additional gains.

That is a very useful way to think about "thinking" models in general.

More reasoning has a bill attached.

The right question becomes less "which model scored highest?" and more "how much reasoning do I need for this job?"

The agent benchmark results are legitimately impressive

DeepSeek compares V4.1-Flash against Opus-5, GPT-5.6 Sol, Kimi-K3, GLM-5.3, V4-Pro, and V4-Flash.

On several agent benchmarks, V4.1-Flash posts the highest reported point estimate in the comparison group.

At maximum effort, DeepSeek reports:

• Terminal-Bench 2.1: 90.6%, versus 89.1% for Opus-5 and 88.8% for GPT-5.6 Sol.
• DeepSWE v1.1: 74.2%, versus 74.0% for Opus-5 and 73.0% for GPT-5.6 Sol.
• CyberGym: 88.1%, versus 84.5% for GPT-5.6 Sol.
• AutomationBench: 54.8%, versus 50.3% for Opus-5 and 45.8% for GPT-5.6 Sol.
• Agents' Last Exam: 31.8%, versus 28.6% for Opus-5 and 26.7% for GPT-5.6 Sol.
• HLE with tools: 63.9%, versus 63.6% for Opus-5.

Its Codeforces rating also reached 3,471, above V4-Pro's 3,348 and V4-Flash's 3,289. On MathArena Apex, V4.1-Flash scored 65.6%, matching Kimi-K3 and slightly topping V4-Pro's 65.3%.

That is the good news.

The rest of the benchmark table is why I would avoid turning this into "DeepSeek beat everyone."

The hardest tasks still expose a gap

V4.1-Flash scored 30.0% on Terminal-Bench 3.0, behind Opus-5 at 43.3% and GPT-5.6 Sol at 34.4%.

On the even harder Terminal-Bench 4.0, DeepSeek scored 31.2%, versus 51.8% for Opus-5 and 39.9% for GPT-5.6 Sol.

ProgramBench tells a similar story: 20.3% for V4.1-Flash, compared with 37.0% for Opus-5 and 23.0% for GPT-5.6 Sol.

On GPQA Diamond, a difficult science reasoning benchmark, V4.1-Flash scored 90.9%, behind GPT-5.6 Sol's 94.1% and Opus-5's 93.4%.

And on Humanity's Last Exam, DeepSeek reports 36.8% overall, versus 56.3% for Opus-5 and 44.5% for GPT-5.6 Sol.

DeepSeek itself acknowledges that larger closed models retain an advantage on harder science-oriented agent work requiring deep specialist knowledge. It also acknowledges an overall multimodal gap from the biggest closed systems.

That distinction matters.

V4.1-Flash looks extremely competitive on a large class of everyday agent work.

The paper does not establish a universal frontier-model win.

The harness can move the same model's score by several points

This is one of the most useful experiments in the whole report.

An agent scaffold, sometimes called a harness, is all the software wrapped around the model that decides how it sees tools, receives errors, retries actions, keeps context, and knows when to stop.

Same model. Same task. Different harness.

DeepSeek tested V4.1-Flash across Claude Code, Codex, OpenCode, Pi, mini-SWE, and several versions of its own harness.

On DeepSWE v1.1, the exact same checkpoint ranged from 65.5% with OpenCode to 74.2% with mini-SWE.

On Terminal-Bench 2.1, results ranged from 84.1% with Codex to 90.6% with DeepSeek Harness Minimal.

Even four different versions of Claude Code produced DeepSWE scores ranging from 68.4% to 69.8%.

So when you see two agent models separated by one percentage point on a leaderboard, remember this section.

You are often measuring the model plus the system around it.

A 74.2% versus 74.0% result does not magically prove one underlying model is better, especially when the report provides no confidence interval for that tiny difference.

More agents helped too

DeepSeek also ran preliminary experiments where one lead agent could create persistent teammates, assign work, message them, and coordinate through a shared task board.

On ProgramBench, multi-agent performance rose from 13.59% after one hour to 30.04% after eight hours.

DeepSeek gives the corresponding single-agent results as 12.79% and 20.39%.

On a no-GPU subset of FrontierSWE v2, multi-agent performance rose from 13.50% after one hour to 32.90% after 20 hours.

Single-agent performance went from 10.50% to 28.20%.

Multi-agent configurations beat single agents at every tested deadline.

But DeepSeek calls these results preliminary.

The report compares the best observed configurations under wall-clock deadlines. It does not establish that the multi-agent systems used the same total number of tokens or the same amount of compute.

So the result supports: "multiple agents completed more work within the deadline."

It does not yet support: "multiple agents are more compute-efficient."

DeepSeek makes one giant claim that the report does not actually prove

Near the beginning, DeepSeek says V4.1-Flash is capable of completing "over 95% of real-world tasks."

That sounds enormous.

The report never defines the population of "real-world tasks" behind that number.

There is no denominator, sampling methodology, evaluation set, or corresponding 95% benchmark presented in the supplied report.

So I would treat that sentence as DeepSeek's claim, rather than a measured conclusion a reader can independently reconstruct from the evidence published here.

The benchmark table uses different task sets and success definitions, so it cannot be used to reconstruct or validate whatever DeepSeek means by that 95% figure.

The paper's more defensible claim is narrower and still impressive: V4.1-Flash can deliver frontier-level performance on several important agent benchmarks while using an architecture aggressively optimized for long-context serving efficiency.

That statement the report actually backs up.

And DeepSeek is unusually clear about what could still break

There are several caveats worth carrying around with all these numbers.

First, SWA Bounded Replay is approximate. The reconstructed cache can vary depending on where a cache hit occurs.

DeepSeek reports little observed response-quality impact in its experiments, but explicitly says extreme or untested conditions could reveal capability loss.

Second, sparse attention means the model deliberately avoids examining every previous token at every layer.

DeepSeek plans more stress testing around long-context sparse retrieval and cache-resumption boundaries, exactly where these shortcuts could become visible.

Third, many benchmark results are already getting close enough that tiny point differences can create fake certainty.

DeepSeek itself warns that benchmark saturation can make near-parity look more meaningful than it is.

And there is one enormous missing number for an architecture sold on efficiency: the report does not provide API pricing or a clean end-to-end latency comparison.

It gives us computation, memory, kernel counts, architecture, and benchmark results.

It does not prove that persistent cache being eight times smaller makes your entire AI workload eight times cheaper.

The race is shifting toward the cost of keeping an agent alive

This is where I think the paper gets really interesting.

For years, AI model releases have mostly been framed like IQ tests.

More parameters. Better scores. Harder math. Bigger context window.

Agents change the equation.

Give an AI an actual job and it may run for an hour, make hundreds of tool calls, accumulate hundreds of thousands of tokens of context, reread information, restart work, and reason through the same problem repeatedly.

Suddenly memory movement, cache reuse, prefill cost, reasoning length, and the surrounding harness become part of real-world agent performance and cost.

DeepSeek-V4.1-Flash is one of the clearest examples yet of a model designed around that world.

It reads long inputs with half the backbone active. Layers share caches. Important memories use four-bit storage. Short-lived memories get thrown away and reconstructed. Sparse attention avoids looking everywhere. Speculative decoding tries to produce multiple future tokens efficiently. The training infrastructure can pause an agent at any token boundary, update the model checkpoint, and resume its rollout.

And DeepSeek managed all that while reporting 90.6% on Terminal-Bench 2.1 and 74.2% on DeepSWE.

The next thing I want to see is much simpler than another leaderboard.

Give V4.1-Flash, Opus-5, GPT-5.6 Sol, and the next generation of agent models the same ugly, multi-hour real-world job. Then measure completed work, human rescues, elapsed time, total tokens, and total dollars.

Because once agents stay alive long enough, the smartest model per token may matter less than the cost of getting the whole job done correctly.

And that is exactly the race DeepSeek built V4.1-Flash to run.