DeepSeek V4's scores are the least interesting part of this article.
Over the past few days, the tech world's attention has been completely absorbed by DeepSeek.
Everywhere you look, it's rumored valuation premiums or press releases about compatibility with various domestic AI accelerator chips. The market's feverish excitement can easily get people lost in a maze of massive numbers. The public's focus is either on the "one-million context" label, which sounds intimidating, or on arithmetic problems like "who beat whom by a few tenths of a point" on benchmark leaderboards.
DeepSeek V4-Pro's scores do look impressive. Based on the details disclosed in its technical report, in the SimpleQA-Verified test, it left all open-source rivals behind by a margin of 20 absolute percentage points; in Codeforces coding competitions, its expected score directly matched GPT-5.4. Of course, in terms of the breadth of world knowledge, it still falls slightly short of Gemini-3.1-Pro; and when it comes to extremely difficult complex tasks, there is still a small gap compared to Claude Opus 4.6.
But none of that matters.
If you only focus on leaderboard rankings, you're completely missing the real ambition of this organization.
DeepSeek is not simply releasing a model parameter package designed to top the charts. What it's actually doing is systematically dismantling and rebuilding the foundation of "one-million context."
The battle in large language models has already moved beyond the model layer and is now fully taking over the systems layer.
In recent years, the industry has been competing on brain capacity—who has more parameters, who scores higher on benchmarks. But that game is over. The arrival of V4 is about defining a new set of rules: the model itself is merely a natural byproduct of an efficient engineering system.
When 1M context becomes the factory default across all official services, a clear fact emerges from its open-source implementation: this is definitely not achieved by brute-forcing compute power. The second half of the long-context era has never been about raw intelligence.
It's about data center scheduling capabilities.
13B Active Parameters, Pinning Down the 37B
Where do the scheduling capabilities show up? Start with the most counterintuitive design in V4: the symbiotic relationship between Pro and Flash.
When the industry sees "Pro" and "Flash," the first reaction is precise product segmentation: Pro is for setting the benchmark, Flash is for the lower-end market, capturing small and medium-sized businesses.
That typical commercial packaging logic misses the mark when applied to V4. These two are not a compute-downscaling relationship; they are a control group validating the same underlying architecture.
In the past, long-context capability in large models was essentially a fake capability built by brute-forcing VRAM. As long as you threw enough GPUs and enough memory at it, you could stuff any length of text in. But the cost was so high that it could never be deployed in a real commercial environment.
V4-Pro pushes capacity to the limit with 1.6T total parameters and 49B active parameters. But the real killer is V4-Flash, with only 284B total parameters and 13B active parameters.
A single data point in the documentation cuts straight through the industry's smoke and mirrors: across a wide range of highly challenging tests, Flash-Base, with only 13B active parameters, directly outperforms the previous generation's V3.2-Base, which had 37B active parameters.
The extremely small activation cost of 13B is not a downgrade in capability—it's a fundamental efficiency overhaul. The point of Flash isn't to prove how much money it can save; it's to prove that "compute hegemony can be broken by architectural restructuring."
Parameter scale has completely lost its decisive significance.
Scheduling capability is replacing parameters as the new main battlefield. This makes one-million context no longer an exclusive toy for high-end NVIDIA clusters; domestic chips can smoothly take over the game as well. The future dividing line among open-source models is no longer about who has the biggest base, but who can do the same work with a fraction of the effort.
Blending Experts Is Muddying the Waters—Better to Divide and Conquer
Hardware efficiency is one side; the other side is software efficiency. V4 has also taken a different path in the "post-training" stage.
The "post-training" stage of large models has been stuck in a dead end.
The industry-standard Mixed Reinforcement Learning (Mixed RL), to put it bluntly, is about muddling things together. If you want a model to understand calculus, write C++, and handle daily planning, the traditional approach is to forcibly squeeze all the parameters toward the middle. The result is "regression to the mean."
Forcibly squeezing them together grinds down all specialized capabilities, and you end up with an average, mediocre generalist.
V4 takes a different path. Not an improvement—a complete lane change. The technical report lays out the new solution: train the experts independently first. The math expert only does math; the code expert only does programming. Push each single dimension to its limit.
The key lies in how they are finally merged. V4 doesn't use the industry's ubiquitous parameter averaging; it uses On-Policy Distillation (OPD).
Traditional weight merging is a static compromise, while OPD is a dynamic takeover.
When the unified model generates its own trajectories, if it encounters a math problem, the system precisely introduces the math expert's gradients to guide the way; when it encounters code, it seamlessly switches to the code expert. Each does its own job without fighting at the parameter level.
Following this thread, the wildly popular "three reasoning modes" (no thinking, high-effort thinking, extreme thinking) on the V4 application side are not just about adding a UI button. It's the direct monetization of the OPD mechanism on the product side.
In extreme thinking mode, the underlying prompt forces the model to decompose problems and exhaust edge cases. This extremely stubborn, relentless behavior is precisely the instinct forged during the OPD stage through intense hammering by the "math expert" and "coding expert."
OPD doesn't do averaging. When it hits a math problem, it connects to the math expert; when it hits code, it connects to the code expert. Each manages its own segment, without fighting at the parameter level.
An Agent Runs for Three Hours—It Can't Afford to Lose Its Memory
After overhauling the training method, it's time to overhaul the application scenarios. What can long context really do?
If it's just to find a single sentence in a hundred-thousand-word research report, that's not long context—that's advanced search. In real business scenarios, an Agent is supposed to refactor your code, validate data across systems, or even run a workflow all night long.
In that process, the most fatal issue is "memory loss."
V3.2 had a pain point that drove engineers crazy: the moment a new message came in, the model's previous chain of thought was completely wiped clean. For casual chat, that's fine and saves resources. But if it's a three-hour Agent task, and a message gets inserted halfway through, the model's mind goes blank, the entire state is lost, and it has to start over from scratch.
This kind of chain break simply can't hold up in real business operations.
V4's solution is "interwoven thinking." The logic is cold and calculated by scenario.
For long-horizon scenarios involving tool calls, the reasoning chain is fully preserved across message boundaries. For casual chat, it continues to clear the context, not wasting a single bit of compute. The model is beginning to truly understand "what to remember, in which context."
Even more impressive is its Quick Instruction feature.
Previously, the industry's approach to intent recognition was to hang a small model on the side. That meant every time a new request came in, regardless of length, the system had to re-process the user's entire prompt from scratch. Essentially, that was a waste of prefill computation.
V4 doesn't do that. As seen in its open-source code: it directly injects a few implicit instructions at the end of the input sequence. The massive amount of features (KV Cache) already computed by the main model is directly reused.
The core problem of long context has never been "remembering a lot"; it's "being able to afford the computation."
This effectively eliminates an entire redundant prefill computation. The industry default is to pair every feature with a small model. V4 proves with action: not needed. Once KV Cache reuse is fully mastered, long-horizon Agents can actually run.
Full Caching, Periodic Checkpoints, No Caching—All Have Their Drawbacks
Being able to run doesn't mean being able to sell.
There's a detail on page 17: the automatically generated kernel is compared bit-by-bit against handwritten CUDA. Not "roughly the same"—every single bit is identical. That kind of engineering obsession is rare in business. Only with that baseline can you dare to do the deployment math.
With high-concurrency one-million context, the competition isn't about whether the large model understands humans; it's about whether you understand the physical limits of the hardware.
The document lays out all three scheduling strategies, with nothing hidden—all trade-offs.
Want zero redundant computation? Go with "full caching." But the cost is that the SSD's I/O channels could be slammed by high-frequency writes within seconds.
Want to protect the drives? Go with "periodic checkpoints." Save every so often. The drives are safe, but the GPU has to periodically divert compute power to clean up the lost tail data.
What if you skip physical drive caching altogether? Then choose "zero caching." Saves all storage bandwidth, relying entirely on long-range features as anchors, and the GPU just brute-forces the computation on the spot when it hits a problem.
None of these three paths is perfect. At its core, this is an extreme calculation balancing hardware lifespan, concurrency peaks, and user latency tolerance. It puts the cold, hard reality in front of everyone: AI is no longer purely a compute-intensive industry; it's rapidly becoming a scheduling-intensive industry.
Final Thoughts
If you're still looking at DeepSeek V4 through the lens of benchmark scores, you haven't even touched the threshold.
OPD's dynamic capability takeover, interwoven thinking's memory retention, Quick Instruction's elimination of prefill, and those disk persistence strategies that squeeze every last drop out of storage and VRAM.
These dry details are all part of the same chain.
Large models are changing.
No longer toys for casual conversation.
They are beginning to take over real-world business workflows.
DeepSeek isn't betting on the future; it's building the server rooms. The outside world is still talking about scores, but scores are just a byproduct of the server rooms in operation.
While competitors are still basking in the glory of a few tenths of a point on leaderboards and showing off their tens of billions of parameters to the market, DeepSeek is already calculating the electricity cost per million tokens.
The battlefield is already clear:
The next long-context war will be won not by intelligence, but by data center costs.
