What Is DeepSeek-V4.1-Flash?

DeepSeek retired its flagship with its smallest model. On September 10, 2026, DeepSeek-V4.1-Flash went GA on the API, and the release note carries a line most labs would bury: starting September 14, every request to deepseek-v4-pro gets routed to V4.1-Flash and billed at Flash prices. The 552B-parameter Flash model, with 8B parameters active on input, now answers for the whole V4 family.

That is the story behind the “deepseek v4.1 flash” searches this week, and it matters for two reasons. First, the architecture is new. A Causal Encoder-Decoder split, FP4 KV caching at 890 bytes per token, and native vision from the first pretraining step are not incremental changes to DeepSeek V4. Second, the price sheet moved with it. If you were paying V4-Pro rates, your bill drops by 70% or more on the 14th whether you change anything or not.

This guide covers what shipped, how the architecture works in developer terms, what the vendor benchmarks say, and the pricing math. It closes with a workflow for testing the model against your own prompts in Apidog, because a benchmark table is a starting point, not a verdict.

TL;DR

• DeepSeek-V4.1-Flash is GA as of September 10, 2026. Model id: deepseek-flash. Base URL unchanged at https://api.deepseek.com.
• 552B MoE (763B with the vision encoder), 8B active for prefill, 16B active for decode. 1M context, 384K max output.
• On DeepSeek’s own numbers it beats V4-Pro on HumanEval, GSM8K, DeepSWE, and Terminal-Bench.
• Peak pricing: $0.30 per 1M cache-miss input, $1.20 per 1M output. Off-peak is half that.
• V4-Pro requests reroute to V4.1-Flash on September 14 at 04:00 UTC.

What shipped on September 10

DeepSeek ran a two-day internal beta from September 8 under the model name deepseek-v4.1-flash-expires-on-0910, capped at 20 concurrent requests per account and priced the same as deepseek-v4-flash. TechNode reported on that beta. Two days later the model went GA, with a changelog entry dated 2026-09-10 and an announcement on X.

Three naming changes matter for your code:

• The new model id is deepseek-flash. Use it for new integrations.
• The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp still resolve, but they are served by V4.1-Flash. V4-Flash and V4-Flash-Vision-Exp are retired as separate models.
• deepseek-v4-pro keeps working until September 14, then routes to V4.1-Flash.

Base URLs did not move: https://api.deepseek.com for the OpenAI format, https://api.deepseek.com/anthropic for the Anthropic format. The Responses API was already supported on the Flash line, so Codex-style integrations carry over. For parameter details, including image input and reasoning effort, see how to use the DeepSeek-V4.1-Flash API.

The Causal Encoder-Decoder architecture for developers

The model card describes a design DeepSeek calls Causal Encoder-Decoder, or CED. Here is what each number means when you are the one paying for tokens.

552B parameters, 763B with vision. The language backbone is a 552B-parameter mixture-of-experts model. Add the DeepSeek-ViT encoder, trained from scratch for this release, and the full model reaches 763B. Those are stored parameters, not the cost of a request.

8B active for prefill, 16B active for decode. This is the headline change. The 40 layers split into 20 encoder and 20 decoder layers. Reading your prompt (prefill) activates about 8B parameters per token. Writing the answer (decode) activates about 16B. Earlier DeepSeek MoE models used one active-parameter budget for both phases.

Why does that split matter? Prefill is compute-bound: you push a 200K-token document through the model in one pass. Decode is memory-bound: you generate one token at a time, and the cost is reading weights and KV cache from HBM. Fewer parameters on prefill cuts time-to-first-token on long inputs. More on decode buys answer quality where extra compute is cheap relative to memory traffic. A 1M-context agent trace that produces a 2K-token reply takes the cheap path for 99.8% of its tokens.

384 routed experts plus 1 shared expert per layer. The router picks a few of the 384 experts per token, and the shared expert runs every time. That is how 552B stored parameters become 8B or 16B active.

CSA2 and the FP4 KV cache. Compressed Sparse Attention 2 ships with three static attention modes. Paired with FP4 storage for the main KV cache, the global cache footprint is 890 bytes per token, about one quarter of DeepSeek-V4-Flash. The release note puts it as 1/4 the HBM and 1/8 the SSD storage of the previous generation. At 890 bytes per token, a full 1M-token context needs about 0.9 GB of KV cache. That is part of why the concurrency limit sits at 2,500 for Flash versus 500 for Pro.

1M context, 384K output. Sparse attention was trained at 64K and extended to 1M at the 34T-token mark of a 45T-token multimodal corpus. Reasoning effort is described as continuously controllable on a 1 to 100 scale; the exact API parameter shape for that scale is [VERIFY] against the docs.

Benchmarks: what DeepSeek reports

Every number in this section is DeepSeek-reported from the model card. No independent evaluation had been published as of September 10. Read them as the vendor’s claim, then run your own.

The pattern is consistent: V4.1-Flash lands above V4-Pro on every row, with the widest gap on agentic coding. DeepSWE jumps 11.5 points over Pro and nearly 20 over the old Flash. GSM8K is saturated, so the 0.4-point edge tells you little.

Vision scores, again vendor-reported: MMMU-Pro 56.5, CVBench 77.9, DocVQA 95.6, RefCOCO 86.0. DocVQA is the number to watch, since document parsing is where most production vision traffic goes.

DeepSeek’s framing for the V4-Pro reroute is that V4.1-Flash “has comprehensively surpassed V4 Pro in performance, cost, speed, and total time”, citing tests by multiple parties. The parties are not named. Treat that sentence as a claim you can check.

Pricing and the V4-Pro reroute

Rates below are from the pricing page, effective September 10 at 04:00 UTC, in USD per 1M tokens.

Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays; off-peak is 50% of peak. Context caching is automatic, and a cache hit costs 50x less than a miss at either tier.

Against V4-Flash’s August rates, V4.1-Flash cuts cache-hit input by about 57%, cache-miss input by about 32%, and output by about 9%.

The V4-Pro column is the one to watch. After September 14, a request sent to deepseek-v4-pro pays the Flash column. At peak, that is $0.30 instead of $1.32 per 1M cache-miss input (77% less) and $1.20 instead of $3.96 per 1M output (70% less). You get the cut without touching code, though you should update the model id anyway instead of depending on a retired alias. The migration guide walks through the checklist, and the pricing deep dive covers the cache-hit math for long agent sessions.

Evaluate V4.1-Flash against your own prompts in Apidog

The vendor table says the model is good at DeepSWE. It does not say whether it handles your extraction schema, your tool-call format, or your 300K-token support transcripts. Here is a workflow in Apidog that answers those questions in an afternoon and keeps answering them after every silent model update.

1. Store the key as an environment variable. Create an Apidog environment and add DEEPSEEK_API_KEY from the DeepSeek platform. Reference it in the Authorization header as Bearer {{DEEPSEEK_API_KEY}}.
2. Add the endpoint. Create POST https://api.deepseek.com/chat/completions, or import an OpenAPI spec.
3. Save one request per real prompt. Take five to ten prompts from production logs and save each as its own request with "model": "deepseek-flash". Keep a copy pointed at deepseek-v4-pro until the 14th so you can diff outputs side by side.
4. Stream and watch the events. Set "stream": true. Apidog renders SSE responses event by event, so reasoning deltas and answer deltas show up separately instead of as a wall of data: lines. It is the fastest way to see time-to-first-token on a long prefill.
5. Add assertions and build a test scenario. Assert on status code, on a tool_calls field where you expect one, and on JSON validity of the output. Chain the saved requests into a test scenario.
6. Rerun on every model update. When DeepSeek pushes the next change behind deepseek-flash, run the scenario. Wire it into CI with apidog-cli so it runs on every deploy.

Here is the body for one of those saved prompts, using the OpenAI SDK:

import os
from openai import OpenAI

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": "Extract the order ID, SKU list, and refund amount as JSON."},
        {"role": "user", "content": "Ticket #48213: customer wants a refund of $42.90 for SKUs KB-220 and MS-114 from order ORD-99117."},
    ],
    stream=True,
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

Download Apidog and paste that body into a saved request. Apidog tests the API layer, not a model host, so what you see is the response your users will get.

FAQ

Is DeepSeek-V4.1-Flash a replacement for V4-Pro? Yes, by DeepSeek’s decision. From September 14 at 04:00 UTC, deepseek-v4-pro requests are served by V4.1-Flash at Flash prices. There is no larger model left in the V4 API lineup.

Do I need to change my model id? Not immediately. deepseek-v4-flash, deepseek-v4-flash-vision-exp, and (after the 14th) deepseek-v4-pro all resolve to V4.1-Flash. Switch to deepseek-flash when you next touch the integration. The API guide has the full parameter reference.

What does 8B prefill / 16B decode mean for latency? Fewer active parameters on input means faster time-to-first-token on long prompts. More on output means compute goes where generation quality is decided. The 890-byte-per-token KV cache keeps long sessions cheap to hold in memory.

Can I run it locally? The weights are MIT-licensed on Hugging Face. The backbone alone is about 552 GB at 8-bit or 280 GB at 4-bit, so this is a multi-GPU or SSD-streaming project, not a laptop one. Day-zero inference-engine support is [VERIFY].

Are the benchmarks independent? No. Every score above comes from DeepSeek’s model card. The tech report has the methodology.

Where this leaves the V4 line

DeepSeek collapsed a two-model API into one. The bet is that a 552B model with a 16B decode budget, a quarter-size KV cache, and 2,500 concurrent sessions per account serves agent workloads better than a bigger model at three to four times the price. The vendor numbers support the bet; your workload decides whether it holds.

Point your SDK at deepseek-flash, run your own prompts through it before the 14th, and keep the test scenario. If you built on the original V4-Flash API, your integration already works. What changed is the model behind it, and that is the part worth measuring.