DeepSeek-V4.1-Flash vs V4-Pro vs V4-Flash: Benchmarks, Cost, and Speed Compared

DeepSeek published the model card for DeepSeek-V4.1-Flash on September 10, 2026, and the numbers are awkward for V4-Pro customers. The smaller, cheaper model scores higher than the flagship on every coding and agent benchmark DeepSeek lists, costs 70 to 77% less per token at peak, and on September 14 it absorbs V4-Pro entirely: every deepseek-v4-pro request gets routed to V4.1-Flash and billed at Flash rates.

This isn’t the usual small-versus-large trade-off. It’s a comparison with a deadline. If you run V4-Pro in production, you have four days to learn what changes when the reroute lands. If you run V4-Flash, the change already happened: the deepseek-v4-flash name is served by V4.1-Flash today.

Below: all three models on architecture, DeepSeek’s reported benchmarks, USD pricing, and throughput, then a workflow for running one prompt set through both deepseek-v4-pro and deepseek-flash in Apidog before the cutover to diff outputs, latency, and usage counts. For the architecture deep dive, read what DeepSeek-V4.1-Flash is first; for the migration checklist, see the V4-Pro retirement guide.

TL;DR

• V4.1-Flash wins on DeepSeek’s own benchmarks. DeepSWE v1.1 is the headline: 74.2 against 62.7 for V4-Pro and 54.4 for V4-Flash.
• It’s the cheapest of the three. Peak cache-miss input is $0.30 per 1M tokens against $1.32 for V4-Pro and $0.44 for the old V4-Flash.
• It’s built for throughput. 8B active parameters on prefill, a KV cache at 890 bytes per token, and a 2,500 concurrency limit.
• After September 14 there’s one choice. V4-Pro traffic reroutes to V4.1-Flash. The question is what you gain and lose, not which to pick.

Specs side by side

The V4.1 generation is a new architecture, not a re-post-train. DeepSeek calls it a Causal Encoder-Decoder (CED): 40 layers split 20 encoder and 20 decoder, with 384 routed experts plus one shared expert per layer. The model card puts the backbone at 552B parameters (763B with the vision encoder).

The split active-parameter count is the detail to notice: V4-Flash used 13B for every token, while V4.1-Flash spends 8B on input and 16B on output, where the quality lives.

Benchmarks: where the 11.5 points come from

Every number below is DeepSeek-reported from the model card. No independent runs have been published, and the retirement notice’s “tests by multiple parties” phrase doesn’t name them. Treat them as vendor claims and verify on your own prompts.

DeepSWE v1.1 (+11.5 over Pro, +19.8 over V4-Flash). The headline, and the only gap large enough to change decisions. DeepSWE measures multi-file software engineering tasks, the workload coding agents run all day. If it holds on your repos, V4.1-Flash out-codes the model that cost four times more.

Terminal-Bench 2.1 (+2.7). Shell-driven agent tasks. V4-Flash-0731 already beat V4-Pro-Preview here in July; V4.1 extends the lead by under three points. Real, not decisive.

HumanEval (+2.6) and GSM8K (+0.4). Both are near saturation: every model clears 90 on GSM8K, and HumanEval says little about production code. Don’t weight these rows.

MiniMax M3 vs DeepSeek V4 vs Qwen 3.7 has the V4-generation numbers against other open models; none include V4.1 yet.

Cost: three models, six price tiers

Peak is Monday to Friday, 01:00 to 04:00 and 06:00 to 10:00 UTC; everything else is off-peak at half price. Rates are per 1M tokens from the pricing page, effective September 10. V4-Flash rows use its August 21, 2026 USD rates as the “before” column.

Against V4-Flash, V4.1 cuts cache-hit input by about 57%, cache-miss input by about 32%, and output by about 9%. Against V4-Pro, the cuts are 77% on cache-miss input and 70% on output at peak.

A worked month. A coding agent processes 2B input tokens a month at a 70% cache-hit rate (system prompt and repo context reused across turns) and emits 300M output tokens, all at peak.

That’s 73% less than V4-Pro, and moving batch jobs off-peak halves it again. Output tokens dominate every column, so the 70% output cut matters more than the cache-hit headline. The V4.1-Flash pricing breakdown covers the cache-hit math.

Speed and throughput

DeepSeek publishes no tokens-per-second figure, so the throughput story rests on three architectural facts and one anecdote.

• KV cache at 890 bytes per token. FP4 main KV caching puts the global cache at roughly a quarter of V4-Flash’s footprint. The release note states it as 1/4 the HBM and 1/8 the SSD storage of the previous generation. A full 1M-token context needs about 0.9 GB of cache.
• 8B active parameters on prefill. Less compute per input token than V4-Flash’s 13B, so time-to-first-token on large contexts should drop.
• Concurrency 2,500 vs 500. Rerouted V4-Pro traffic inherits the Flash limit, a 5x gain for agent fleets.
• One user’s report: “almost 400 t/s”. One X user posted it from video tests during the beta; it’s an anecdote, not a benchmark. The HN beta thread is mostly the same enthusiasm.

Measure your own p50 and p95 before you trust any of it.

What you lose and gain after September 14

There’s no “which model should I pick” after the cutover. deepseek-v4-pro becomes an alias, so the honest framing is a ledger.

You gain: higher scores on every listed benchmark, 70 to 77% lower peak prices, 5x concurrency, native image input without a separate vision model id, and a reasoning-effort dial that DeepSeek describes as continuously controllable on a 1 to 100 scale.

You lose: the ability to pin a V4-generation checkpoint. Prompts tuned for V4-Pro’s style, verbosity, or tool-call formatting can drift. Output length and reasoning-token counts can change, which changes your bill in ways the rate table doesn’t show. And the reroute happens on DeepSeek’s schedule, not yours.

That second list is why you should diff before the 14th, not after.

Diff V4-Pro against V4.1-Flash in Apidog before the cutover

Apidog tests the API layer, so it’s the right place to run one prompt set through both model ids and compare what comes back.

1. Add the endpoint. Create a project and add POST https://api.deepseek.com/chat/completions, or import an OpenAPI spec.
2. Put the key and the model id in environments. Store DEEPSEEK_API_KEY and a MODEL variable. Create two environments, v4-pro with MODEL=deepseek-v4-pro and v41-flash with MODEL=deepseek-flash, and reference them as Bearer {{DEEPSEEK_API_KEY}} in the header and "model": "{{MODEL}}" in the body.
3. Save your real prompts as requests. Pick 20 to 30 prompts that represent production: your system prompt, a tool-call turn, a long-context summarization, a multi-file code edit. Save each with stream: false so the usage object lands in the response body.
4. Assert on the fields that change your bill. Build a test scenario from the saved requests and add assertions on usage.prompt_tokens, usage.completion_tokens, and usage.prompt_cache_hit_tokens. Record response time per step, and add a pre-request script that stamps the environment name into a header so the runs are labeled.
5. Run once per environment, then diff. Run the scenario under v4-pro, then under v41-flash. Compare completion-token counts (the reroute changes your output bill), latency per step, and the content itself for formatting drift.
6. Rerun in CI on the 14th. Run the same scenario with apidog-cli in your pipeline at the cutover. Anything the reroute broke shows up as a failed assertion instead of a support ticket.

The same comparison as a script:

import os, time
from openai import OpenAI

client = OpenAI(api_key=os.environ["DEEPSEEK_API_KEY"],
                base_url="https://api.deepseek.com")

prompt = "Make payment retries in the checkout service idempotent. Return a unified diff."

for model in ("deepseek-v4-pro", "deepseek-flash"):
    start = time.perf_counter()
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    print(model, f"{time.perf_counter() - start:.2f}s",
          r.usage.prompt_tokens, r.usage.completion_tokens)

Run it at peak and off-peak and keep the outputs. Download Apidog to keep the diff, assertions, and run history in one place.

FAQ

Is V4.1-Flash better than V4-Pro at coding? On DeepSeek’s reported numbers, yes: 74.2 vs 62.7 on DeepSWE v1.1 and 90.6 vs 87.9 on Terminal-Bench 2.1. For how the V4 generation compared with Claude on coding, see DeepSeek V4 vs Claude Opus for coding.

What happens to my V4-Pro integration on September 14? From 04:00 UTC, every deepseek-v4-pro request is served by V4.1-Flash and billed at Flash rates. Your code keeps working; the model behind it changes. The migration guide has the full checklist.

Do I need to rename deepseek-v4-flash to deepseek-flash? Not today. deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted and served by V4.1-Flash. DeepSeek hasn’t given a removal date, so switch to deepseek-flash the next time you touch the config.

Is V4.1-Flash faster than V4-Pro? DeepSeek says so and publishes no figures. The architecture supports the claim: 8B active parameters on prefill and a KV cache a quarter the size of V4-Flash’s. Measure your own.

Can I still run V4-Pro somewhere? Not on DeepSeek’s API after the 14th. The V4 generation’s background is in What Is DeepSeek V4; V4.1-Flash weights are on Hugging Face under MIT.

The short version

V4.1-Flash is smaller, cheaper, and higher-scoring at once, at least on the vendor’s table, and that table can’t tell you whether it’s better for your prompts. Run both model ids through the same prompt set in Apidog this week, keep the diffs, and you’ll know what changes on September 14 before your users do.