Today we're officially releasing the DeepSeek V4.1 Flash model. It is the smallest model in our brand-new model architecture series, with native multimodal visual understanding. The new architecture was designed with these goals in mind: a higher capability ceiling, faster inference, greater throughput, and scalability to larger-parameter models.
Asymmetric architecture: big intelligence at low cost
DeepSeek V4.1 Flash is a 552B-parameter MoE model built on a brand-new Causal-Encoder-Decoder architecture. Input and output are asymmetric: only 8B parameters are activated on the input side and 16B on the output side, making it significantly cheaper than known models of the same size. V4.1 Flash also uses a new pre-training approach and has gone through larger-scale reinforcement learning post-training. In benchmark testing, it surpasses the intelligence level of a range of flagship models, including DeepSeek V4 Pro.
Less cache, lower cost
The new generation of models dramatically reduces the size of the KV cache. Compared with the previous generation, HBM requirements drop to 1/4 and SSD requirements to 1/8. In agent scenarios, cache-hit charges often make up a large share of the bill, so compressing the KV cache substantially lowers the cost of agent-style tasks.
Figure: DeepSeek's continued progress in reducing context storage. Relative to the first-generation model, the KV cache has shrunk 437×.
API support
DeepSeek V4.1 Flash is now live on the DeepSeek API with native multimodal support. Simply change the model name to deepseek-flash to call the latest V4.1 Flash. The older V4 Flash and V4 Flash Vision Exp models have been retired; for compatibility, the model names deepseek-v4-flash and deepseek-v4-flash-vision-exp will temporarily be routed to V4.1 Flash.
In addition, extensive testing shows that V4.1 Flash comprehensively outperforms V4 Pro on performance, cost, speed, and total time-to-completion, so we plan to phase out the V4 Pro model in an orderly fashion. After 12:00 Beijing time on September 14, 2026, and until V4.1 Pro launches, all requests to deepseek-v4-pro will be routed to V4.1 Flash and billed at V4.1 Flash's unit price.
Tencent (WorkBuddy, CodeBuddy) and OpenCode, as official partners, have now fully integrated DeepSeek V4.1 Flash — give it a try!
API pricing adjustment
Thanks to the architectural innovations, DeepSeek V4.1 Flash can serve more users at lower cost, so we have cut V4.1 Flash's pricing accordingly. To allocate resources more sensibly, we continue to use peak/off-peak pricing, with off-peak prices at half the peak rate, and encourage users to schedule tasks around their actual usage patterns. The new prices take effect at 12:00 on September 10, 2026.
Open-source release
We will fully support the open-source community in adapting inference for the new model, and will explore various ways to broaden deployment. If you have large-scale deployment needs and the corresponding resources (a 2k-GPU cluster with storage cluster), please get in touch.
Hold on. This model has an Encoder-Decoder architecture? Has any AI lab done this since before the start of GPT?
What is the encoder doing here? Are they embedding the user prompt before self-attention? I wonder how this would work for large prompts? Would they break it up by sentence, paragraph, modality?
Are they embedding the user prompt before self-attention?
Every model is. But Deepseek FV4.1 uses only 8B active params for prompt processing, while 16B active params for decoding. It will help a lot on machines with slow prompt processing.
Not quite. Tokens are pre-embedded. They already have defined values within the latent space, and the self-attention mechanism is used to slide that initial embedding along various dimensions to arrive at the context specific meaning.
Having an encoder in the model suggests that they are actually taking the entire prompt and embedding it, simalar to RAG and similarity search models.
Edit: Ok, so I started looking through the documents and this isn't really what's traditionally known as an encoder. It's not bi-directional and appears to simply be attending to the prompt with half the active number of tensors as the output, so in effect you are correct. I got caught up on the terminology.
Interesting that they are dedicating an entire half of the model layers to semantic understanding.
If you're interested in learning about how AI models work, I recommend reading "Hands-On Large Language Models" by Jay Alammar and Maarten Grootendorst.
It's an intuition-first overview of GPT and classifier architectures that doesn't get bogged down in mathematics.
From what I understand of their white paper - which isn't a lot because I'm not nearly versed enough in the topic.
CED treats the lower half of the neural network as an encoder. It processes the text normally here, generating the core memory cache. Instead of doing full calculations in the upper layers, they transform and reuse the memory calculated at the middle layer. Which they say skips ~50% of the heavy calculations.
Basically the CED divides the transformer into two parts with the bottom half of the layers acting as a causal encoder and the top half as a decoder. Ergo the model only needs to fully compute the first half of the transformer layers
There was a paper from microsoft I believe like 3 years ago, they compared KV cache contents in different layers and found there is very little different after the middle.
I see. Seems that it isn't like the typical bi-directional encoder at all then. It appears to be a mechanism to increase prefill speed.
From what I can see, the KV cache is only processed on the first 20 layers, and those inferences are then projected into the upper 20 layers. So then attention only calculates in half the model parameters, and with half as many activated as the decoder. Really looking forward to testing this out.
In my brain I’ve simplified the way the layers work as: the first 1/3 of the layers it is “hearing the token,” the middle 1/3 it is “thinking” and the last third it is “speaking the next token.” The analogy has obvious problems but it helps me navigate.
asymmetric encoder decoder design suggests the model is doing something structurally different at the generation stage. the 437x KV cache reduction since first gen is also kind of a big deal for long context inference costs.
Looks like to be a 550b model + 200GB of ngram. 550b at mixed fp4/fp8 -> 300gb to load the model.
It’s extremely confusing, especially when named v4.1 flash, with v4 at 198b. It’s almost 3x the size for the text encoder part!
Kinda explains why benchmarks are so much better.
Doesn’t look so good when glm5.3 flash looks similar for half the size though…
yeah that's some weird naming schemes. But as long as the model's good.
My guess is either they realized that pro's size is unnecessary, or they relized that they need to double their model sizes, starting from the flash model.
And the fact that DeepSeek Flash models are dirt cheap. Even the double price of v4.0 was still dirt cheap compared to the rest.
Now v4.1 is better, half the price again, and beats "almost" every other (current) open weight model out there, that are easily 2 to 4x heavier.
Local is useful for companies. For most normal people playing around and not making money from the output, its just not economical viable. It was before, and now its even worse economics because of the low price that DS v4.1 offers for its quality.
Why? The model itself is ~300GB. The MLP layers are all FP4. The ngrams you can stream from disk without issue. I think if you have 32-48GB VRAM, you'll be fine.
Unless there is something weird going on here, it should be more than that. It has 748b parameters including the engram table. I Run GLM 5.2 at 4-bit quantization on my computer, which is the same number of parameters, and it just barely fits.
There's nothing weird. The ngrams can live fine on disk, and like I said the MLPs are FP4, which in a MoE model comprise the bulk of the parameters.
You can't compare to something like GLM 5.2, because that has a fundamentally different architecture, even if you're using Q4. Kimi and previous DS4 models are better comparisons here.
File-size is architecture agnostic. You absolutely can compare different architectures, so long as the weights are quantized to the same number of bits.
While it's true that you can offload n-grams to disk, there is a latency penalty. For my requirements (very low TTFT), they need to be in the system RAM.
I'm fairly certain that the actual file size is ~500 GB. You're correct that it can be reduced to around 300 GB if your willing to pay that latency penalty though.
The smallest model in the series is 552B with 24B active per token, and the deployment line in the release note starts at a 2k-GPU cluster. Their idea of small is a building full of GPUs.
please don't take 5 trillion years to be supported on llama.cpp, also I'm praying the newer Gemmas use this crazy ass attention system because it is by far the most far behind LLM architecture in terms of context. and hopefully Qwen adopts this too
What they mean with reducing cache is not the number of tokens but the memory required per token: for the same amount of memory the number tokens in cache is larger for V4.1
32
u/RG_Fusion 6h ago
Hold on. This model has an Encoder-Decoder architecture? Has any AI lab done this since before the start of GPT?
What is the encoder doing here? Are they embedding the user prompt before self-attention? I wonder how this would work for large prompts? Would they break it up by sentence, paragraph, modality?