Back to articles

DeepSeek V4: why this open-weights model can really shake up closed models

10 min read
aideepseekopen-sourcellmagentsbenchmarksinferencedeveloper-tools

DeepSeek just released V4, and for once I find it hard to dismiss as "yet another model."

Not because the announced scores are close to the best closed models. We've seen that before. The real subject is the combination: open weights under the MIT license, 1M context by default, an MoE architecture designed to make that context actually usable, explicit optimizations for agents and code, and an API compatible with both OpenAI and Anthropic.

In other words, a building block that looks like frontier work, integrates like a closed model, and is operated like open source. That blend is new, and it puts real pressure on the market. Not marketing pressure — architectural and pricing pressure.

That's why, in my view, V4 deserves serious attention.

1. DeepSeek V4: what was actually announced

Facts first, no varnish.

DeepSeek released two models in the V4 family, both MoE:

  • DeepSeek-V4-Pro: 1.6 trillion total parameters, 49 billion active per token.
  • DeepSeek-V4-Flash: 284 billion total parameters, 13 billion active per token.

Both natively support a 1M-token context, with a max output of 384K, Thinking / Non-Thinking modes, JSON output, tool calls, chat prefix completion and FIM completion in non-thinking. Weights are available on Hugging Face under the MIT license, and the DeepSeek API exposes the new names deepseek-v4-pro and deepseek-v4-flash at the same base URL as before. On the integration side, the service stays compatible with OpenAI ChatCompletions and Anthropic APIs, which means most existing SDKs can plug it in with very few changes.

DeepSeek also explicitly announces support for agents like Claude Code, OpenClaw and OpenCode, and the gradual replacement of the older deepseek-chat and deepseek-reasoner endpoints.

On paper, this is coherent: a "high-end" model for long reasoning and agent tasks, and a "fast / cheap" model for the rest. With, in both cases, the same central argument — the 1M context is not a marketing promise but a playground for agents.

That's exactly where the technical work gets interesting.

2. The technical point that matters: making 1M context usable

A million tokens of context is pointless if latency explodes and the KV cache bill becomes unmanageable. As the DeepSeek Hugging Face blog puts it, "a 1M context window is just capacity, not performance." The real question isn't "how high can you push the window," but "at what cost can you actually use it."

V4 attacks this through architecture, not inference tricks.

CSA + HCA: compress attention rather than just enlarge the window

DeepSeek describes V4 as a Hybrid Attention Architecture combining two mechanisms:

  • Compressed Sparse Attention (CSA), which compresses KV entries by about 4x.
  • Heavily Compressed Attention (HCA), much more aggressive, compressing by about 128x.
  • CSA and HCA layers are interleaved in the stack, which keeps precision where it's needed and saves massively elsewhere.
  • A local sliding window (around 128 tokens in the vLLM implementation) preserves locality of the recent context.
  • All of this builds on DeepSeek's earlier work on DeepSeek Sparse Attention (DSA) introduced in V3.2.

The core idea is less "see all the context all the time" and more vary the attention resolution across layers and pay the cost of dense attention only where it actually helps.

Why it matters for agents

This is where the numbers start talking.

DeepSeek announces that, at 1M tokens, V4-Pro requires roughly 27% of the single-token FLOPs and 10% of the KV cache compared to V3.2. For V4-Flash, you fall to 10% of the FLOPs and 7% of the KV cache. NVIDIA, on its side, talks about roughly 73% reduction in inference FLOPs per token and 90% reduction in KV cache pressure vs. V3.2.

These orders of magnitude are confirmed on the serving side: per the vLLM blog, the bf16 KV cache for a 1M-token sequence falls to about 9.62 GiB, vs. roughly 83.9 GiB for a V3.2-style 61-layer stack. In fp8 or fp4, it drops further. For agents that hold a truly long context — tool-call history, a large indexed codebase, preserved reasoning traces — it's the difference between "theoretically possible" and "viable in production."

And it has to be said clearly: this work matters more than the benchmarks. It makes usable a capability many models advertise without being able to serve it at a decent cost.

3. Benchmarks: very strong, but not magical

On to the scores, with a level head. Everything below comes from DeepSeek / Hugging Face tables — useful, but not absolute independent truth.

Where DeepSeek V4-Pro-Max impresses

A few standout figures announced by DeepSeek:

  • LiveCodeBench: 93.5
  • Codeforces: 3,206
  • SWE Verified: 80.6%
  • SWE Pro: 55.4
  • Terminal Bench 2.0: 67.9
  • MCPAtlas Public: 73.6
  • Toolathlon: 51.8
  • MRCR 1M: 83.5
  • CorpusQA 1M: 62.0
  • MMLU-Pro: 87.5
  • GPQA Diamond: 90.1
  • SimpleQA Verified: 57.9

The profile is fairly clear. V4-Pro shines especially on agentic code, truly used long context (MRCR 1M, CorpusQA 1M) and tool workflows (MCPAtlas, Toolathlon). The Hugging Face blog also mentions that on MRCR 8-needle, the model stays above 0.82 up to 256K tokens and falls to 0.59 at 1M — so some degradation, but no collapse.

On the external evaluations side, platforms like Vals AI place it — according to what's relayed by Xinhua and VentureBeat — at #1 open-weights on Vibe Code Bench, on SWE-bench and on IOI, and #2 open-weights on Terminal-Bench 2.0. Take that as a directional indication, not absolute certainty.

What needs to be qualified

Now, where I think we have to avoid the easy take.

V4 isn't "best at everything." On several axes — overall average quality, very broad encyclopedic reasoning, product integration, perceived safety — Gemini, Claude and GPT keep measurable leads. On certain consumer or enterprise use cases, those leads are even decisive.

The tempting headline — "DeepSeek beats everyone" — would be both false and counterproductive. The credible framing is rather: DeepSeek V4 puts serious pressure on closed models, particularly on the triptych of agents + code + long context. And that's already a lot.

That's where the next part gets really interesting: once performance is "good enough," the deciding factor becomes inference economics.

4. The real shock: inference economics

DeepSeek published a pricing grid that, by itself, explains why everyone is watching V4 closely.

For 1M tokens:

  • DeepSeek-V4-Pro: input cache miss at $1.74, input cache hit at $0.145, output at $3.48.
  • DeepSeek-V4-Flash: input cache miss at $0.14, input cache hit at $0.028, output at $0.28.

For a typical agent usage — 1M tokens of input cache miss + 1M tokens of output on V4-Pro — you land around $5.22 per run. VentureBeat compares that figure to closed premium models that run several times more expensive on the same setup. The comparison should be handled with caution — caching, tokenization and enterprise discounts vary — but the order of magnitude is clear.

The real point isn't "DeepSeek is the cheapest." It's more subtle:

  • DeepSeek doesn't need to win every benchmark to change the economic calculation.
  • On agent workloads that consume tens or hundreds of millions of tokens per month, a 2x to 5x factor on cost changes what becomes rational to build.
  • The input cache hit at $0.028 on Flash is particularly interesting for architectures where the same context (codebase, docs, history) is replayed every turn.

Put differently, V4 doesn't just arrive "cheaper." It arrives with a profile that makes economically viable architectures that until now were marginal: long-running agents, massive re-runs, multi-agent setups, large-scale background processing.

That's exactly where closed models will have to respond — through price cuts, more generous cache tiers, or stronger product differentiation.

5. Why it matters for devs, agents and AI workflows

In concrete terms, what changes if you build applied AI today?

For long-running agents. An agent that reads a repo, plans, calls tools, corrects itself and starts over across hundreds of actions needs a stable context, an acceptable per-turn cost, and attention that doesn't collapse beyond a few tens of thousands of tokens. V4 targets that profile, with on top of that an interleaved thinking across tool calls mechanism that preserves reasoning across tool calls — described in the Hugging Face blog. It all relies on a tool-call schema with a DSML special token and an XML format designed to reduce the escape errors that are a classic pain on raw-JSON models.

For large codebases. Being able to load several files, their history, tests and specs in the same context — without paying a fortune in KV cache — changes what's possible in code assistance, guided refactoring or automated review. It's no longer "summarize this function," it's "understand this module in its context."

For OpenAI-compatible and Anthropic-compatible workflows. The API exposes both interfaces. So a product already built around the OpenAI or Anthropic ecosystem can test DeepSeek without a heavy rewrite. For teams that want to keep an abstraction layer and play providers against each other, that matters a lot.

For technical sovereignty. Eventually, not depending exclusively on a handful of closed providers is a real strategic advantage — for reasons of price, governance, service continuity and regulatory constraints.

For self-hosting. V4 is servable via vLLM and SGLang, and NVIDIA provides official recipes with NIM, multi-node and prefill/decode disaggregation. The vLLM examples mention, for instance, Pro on 8xB200/B300 and Flash on 4xB200/B300. NVIDIA also points to over 150 tokens/sec/user on GB200 NVL72 out of the box. It's doable, but clearly not laptop-grade.

Hence an important distinction to keep in mind: open weights ≠ easy to run on a personal machine. That's a nuance many articles avoid, and it deserves to be stated explicitly. Having the weights and the license means you have the option to self-host, fine-tune, quantize, audit. It is not a magic shortcut to lightweight infrastructure.

6. Conclusion: open source isn't only catching up on performance, it's attacking on efficiency

Closed models aren't dead. They keep real advantages, and they will keep dominating several use cases.

But the angle has changed.

For a long time, the choice between closed and "open" boiled down to a performance-vs-freedom trade-off. With V4, the trade-off becomes more complex. The market will increasingly play out across four axes simultaneously: performance × cost × control × integration. And on those four axes, open models become credible in more cells of the table than before.

DeepSeek V4 is, fundamentally, a signal. The gap between closed and open is no longer obvious for agent and code use cases. It becomes a product decision, one that depends on what you're optimizing: raw average quality, or quality / cost / freedom-of-deployment ratio.

The real question is no longer "will open models catch up to closed ones?" It is: should we keep building everything on closed models by default, when open options have become good enough to be the backbone of a product?

Over the next 12 months, that default reflex is probably what will move. Not for everyone, not everywhere. But enough that closed models will feel they're no longer the only ones that can carry a serious agent.

References