DeepSeek V4 Pro vs Qwen 3.6: 1.6T or 27B, for 3 Points

DeepSeek V4 Pro holds roughly 1.6 trillion parameters. Qwen 3.6 27B holds twenty-seven billion. On SWE-bench Verified they report 80.6 and 77.2 percent respectively.

A sixty-fold difference in size for about three and a half points of measured capability. That single comparison says more about the state of open-weight models in 2026 than any leaderboard.

Why the gap is so small

Two reasons, and both are worth understanding because they generalise.

First, V4 Pro is a mixture-of-experts model. It holds 1.6T parameters but activates only about 49B per token. The honest comparison is 49B active against Qwen's 27B active — under two to one, not sixty to one. The trillion-parameter headline measures storage, not thinking. Mixture-of-experts explained covers why those numbers diverge so wildly.

Second, SWE-bench Verified tasks are bounded. A model reads an issue, produces a patch, and a test suite decides. That structure rewards competence and does not particularly reward depth. Benchmarks that run models for dozens of unsupervised steps separate them much more cleanly.

Where the gap widens

Horizon length is the variable that matters.

In multi-step agent work, each step's output feeds the next step's input, so per-step error compounds instead of averaging. Two models three points apart on a single-turn benchmark can be far more than three points apart on completion rate over twenty turns. This is why Terminal-Bench 2.1 and FrontierSWE exist, and why the models that top them are the large ones.

So the fair summary is: on bounded tasks these models are close. On long unattended runs, V4 Pro is meaningfully ahead, and the gap grows with the number of steps.

If your workload is short and well-specified, you are paying for depth you will not use. If it is an agent that runs for forty tool calls against a large repository, you are not. Evaluating agent reliability covers measuring completion rate, which is the metric that exposes the difference.

Deployment is the real separator

Capability aside, these models have entirely different operational profiles.

V4 Pro's 1.6T parameters must all be held in memory even though only 49B are active per token. That is a serious deployment. Most teams reach V4 Pro through an API and never see the weights, which is fine — but it means self-hosting is effectively off the table for anyone without significant infrastructure.

Qwen 3.6 27B is dense, and quantised it fits on a single accelerator. For data-residency requirements, air-gapped environments, or predictable cost at high volume, that is not a preference — it is the deciding constraint. Self-hosting vs managed API cost covers where the crossover sits.

Both are permissively licensed

V4 Pro is MIT. Qwen ships under permissive terms across most tiers, though the exact licence varies by size, so verify the specific build you intend to ship.

This is worth naming because it is not universal. Kimi K3 requires a separate agreement above a revenue threshold. If you are building a commercial inference product, both of these models are safer ground than the top of the leaderboard.

The lesson beyond these two models

Do not read parameter counts as capability. In 2026 they correlate weakly at best, and the correlation is mediated by architecture, training quality and what you actually measure.

Three practical rules follow:

• Compare active parameters, not totals, when the models are mixture-of-experts. Totals tell you about memory, not thinking.
• Match the benchmark to your horizon. Bounded benchmarks flatter small models; long-horizon benchmarks flatter large ones. Neither is wrong; they measure different things.
• Test the smaller model first. If it is good enough, the savings and deployment flexibility are substantial. If it is not, you will find out quickly and cheaply.

How to decide

Take fifteen tasks spanning your real range, including your longest and most multi-step. Run both. Record completion rate, turns to completion, and whether you would merge the output unmodified.

Look at where Qwen fails rather than at the average. If failures cluster past a certain step count, that is a routing rule and you can run both. If Qwen holds up across your whole range, the size difference is buying you nothing and the smaller model wins on cost and deployment.

How to benchmark LLMs on your own work covers building the harness so this is repeatable when the next release lands.