DeepSeek V4.1 Flash, explained: an open model that does less work reading your prompt, and what it costs

On 10 September 2026 DeepSeek posted "DeepSeek-V4.1-Flash: Smarter, Faster, More Efficient" in its API news. The same day the model went live on its API under the name deepseek-flash, and the weights went up on Hugging Face, the main website for sharing models. Hugging Face's own record says the repository was created at 02:17 UTC (Coordinated Universal Time, the world reference clock) that day.

DeepSeek calls it "the smallest model in our new architecture family". In other words, more models built the same way are coming. The news post says the bigger V4.1-Pro is still to launch. It also says that from 14 September, requests to the older name deepseek-v4-pro are answered by V4.1 Flash at the Flash price, until V4.1-Pro arrives. But DeepSeek's pricing page on 7 October still showed deepseek-v4-pro on its own line, so the two pages disagree. Check before you rely on either name.

The older names deepseek-v4-flash and deepseek-v4-flash-vision-exp are retired. DeepSeek still accepts them for now, but the answers come from V4.1 Flash and are billed at its price. If your code uses an old name, you are already using the new model.

V4.1 Flash reads images as well as text, built in from the start of training, and it writes text. Before it, DeepSeek offered image input only through an experimental separate model, V4-Flash-Vision-Exp, from 21 August 2026. DeepSeek trained it from scratch on 45 trillion tokens of text and images, according to the model card.

Two design choices explain the two numbers. First, a model is a stack of layers: your text passes through layer 1, then layer 2, and so on, and each layer changes it a little. The first choice is mixture of experts, often shortened to MoE. A normal (dense) model uses every parameter for every token. In an MoE model, each layer holds many small blocks called experts, and a router (a tiny part of the layer that scores the experts) picks a few of them for each token. V4.1 Flash has 384 experts in each MoE layer, and the router picks 6 of them for every token. One more shared expert always runs, so 7 expert blocks work on each token. Most of the model sits idle for any one token.

The second choice is new in this version. DeepSeek calls it a Causal Encoder-Decoder. Its 40 layers are split in two: the first 20 (the encoder) work out what the prompt says, and the last 20 (the decoder) produce the answer. To write, the decoder needs a stored memory of the prompt, called the KV cache (the next section is about it). In this model that memory is built straight from the encoder's 20th layer, so when the model reads your prompt (DeepSeek calls this prefill), most prompt tokens never go through the decoder at all. When the model writes the answer (decode), each new token goes through all 40 layers.

That is why DeepSeek gives two numbers: 8 billion active parameters per token when reading and 16 billion when writing. The technical report says this "nearly halves" the work of reading a prompt. It matters for agent work, where the model calls tools (functions your code lets it run, such as looking up an order) in a loop. Agents take in a lot of new input: every tool result and file has to be read once, and the answers are short. Earlier messages that DeepSeek has cached are almost entirely skipped, apart from the last 128 tokens (the next section explains caching), so the saving is on the new input. On DeepSeek's API you do not see it as a separate discount; it is part of why the price is low.

The cost of mixture of experts is memory. Any expert can be picked for the next token, so all of them have to sit on the GPUs all the time. So the work per token depends on the 8 or 16 billion that run, and the GPU memory you need depends on all of it. DeepSeek's report also describes a separate lookup table of 196 billion numbers called Engram, which the model only dips into and which is not counted in the 552 billion. The report says Engram can be fetched from the server's ordinary memory instead of the GPUs, which matters for the hardware later.

While a model works through a conversation, it keeps a record of what it has already computed for every earlier token, so it does not redo that work. This record is called the KV cache (key-value cache). It grows with every token, it lives in GPU memory, and for long conversations it can take more room than you expect. This model keeps two kinds: a global cache for the whole conversation, and a small sliding-window cache for only the last few tokens. The numbers below are the global one, the part that grows.

DeepSeek's headline for this release is that the KV cache got smaller. The chart on the model card gives 3,514 bytes per token for V4-Flash, released in April 2026, and 890 bytes for V4.1 Flash, about 4 times less. For one conversation that fills the full 1M context (1,048,576 tokens), that is 3.68 GB against 0.93 GB, by my arithmetic. DeepSeek also says V4.1 Flash needs about 1/8 of the disk space (SSD) the old model needed to save prompts for reuse.

Why should a user care? DeepSeek saves these caches to disk. If your next request starts with exactly the same text as an earlier one, it reloads the saved cache instead of reading that text again. That is a cache hit, and DeepSeek charges far less for it: $0.006 per million tokens at peak against $0.30 for new input. Agents resend the same long history on every step, so most of their input can be cache hits. OpenAI and Alibaba also charge less for cached input, so this is not unique to DeepSeek. DeepSeek's news post says cache-hit charges often account for a large share of agent costs, and that compressing the cache cuts those costs.

The open weights are the reason a company would pick this model over a closed one: you can run it on your own servers, keep your data there, and change it. Ivo, a contract-review company, used the open weights of the previous version this way. On 7 October 2026 Artificial Lawyer reported that Ivo released Sage, a contract model built on DeepSeek V4 Flash, that lawyers can fine-tune (train a little further) on their own data.

The 510 GB download has two parts. About 307 GB is the 552B backbone: the files store each number in fewer bits than usual, the experts in FP4 (about half a byte per number) and most other parts in FP8 (one byte). The other 203 GB is Engram, the 196B lookup table, in FP8. DeepSeek's report says Engram rows can be fetched ahead of time from the server's ordinary CPU memory, so they do not have to sit on the GPUs.

DeepSeek's reference code is an example split across 8 GPUs, not a stated minimum, and it does not name a GPU. Counting only the backbone, a server with eight NVIDIA H100 cards (80 GB each, 640 GB in all) has about 333 GB left, and eight H200 cards (141 GB each) about 821 GB. With Engram on the GPUs too, those drop to about 130 GB and 618 GB. One more check: H100 and H200 cards have no native FP4 maths (NVIDIA added that in its newer Blackwell cards), so make sure your serving software supports these FP4 files on your cards. If it has to widen the experts to FP8, by my rough estimate the backbone nearly doubles, to about 600 GB, which leaves almost nothing on eight H100s.

Here the smaller KV cache helps. On paper, the 821 GB left on eight H200s holds the global KV cache of about 879 conversations that fill the full 1M context with V4.1 Flash, against 222 with V4-Flash. Real numbers will be much lower, but the ratio holds: the same GPUs can keep about 4 times as many long conversations in memory.

If you do not want to run it yourself, other companies host it. Hugging Face listed five inference providers (companies that run models on their servers and charge per token) for V4.1 Flash on 7 October 2026: Novita, Fireworks AI, Featherless AI, Baseten and DeepInfra. Each one sets its own prices and limits, so check them yourself.

The facts about the model come from DeepSeek's API news post, its pricing page and change log, its Hugging Face model card, config file, licence and technical report, and Hugging Face's own records, all read on 7 October 2026 and linked below. The comparison prices come from each company's own pricing page the same day.

I did not send a prompt to V4.1 Flash. The API needs a DeepSeek key, which this project does not have; Ollama's copy is cloud only and needs an account; and the weights need a server with several large GPUs. So I cannot tell you how good its answers are, only what DeepSeek reports.

What I did run is real: the API and Ollama checks, DeepSeek's 50 encoding tests, the prompt format and its token counts with DeepSeek's tokenizer, and the cost and memory arithmetic. The hardware numbers are for the files and the global KV cache only, not a measured deployment. I will update this page if I run the model itself.