DeepSeek V4.1 Flash: low API prices, huge open weights

DeepSeek V4.1 Flash combines low API prices with a very large open-weight model. Released on 10 September 2026, it activates 8 billion parameters while processing input and 16 billion while generating output, but its backbone alone contains 552 billion. The improvement concerns how much work the model performs at each stage, not a small download for your laptop. [1] [2]

What does “8B active” actually mean?

The active parameter count describes the part of the model used for a token, not the total model that must be stored. V4.1 Flash is a mixture-of-experts model, which selects parts of its network for computation. DeepSeek’s new design also separates input processing from output generation, giving the two stages different active counts. [2]

Input processing is usually called prefill: the model reads the prompt before producing its answer. Output generation is decode: the model generates tokens in sequence. DeepSeek’s technical report describes a causal encoder-decoder architecture with a 20-layer encoder and a 20-layer decoder. Its stated active counts are 8B for prefill and 16B for decode. [2]

That explains why averaging the two numbers into “a 12B model” would be misleading. A long prompt followed by a short answer spends its work differently from a short prompt followed by a large generated patch. The architecture assigns different computation to those stages, but neither stage turns the full model into a consumer-sized checkpoint.

The storage accounting makes this visible. DeepSeek reports a 552B backbone plus roughly 196B of Engram conditional memory, a lookup component. The vLLM project’s deployment recipe also accounts for the DSpark drafting model and other tensors. The full Hugging Face artifact is currently displayed as 763B parameters. Those numbers count different parts of the same release. [2] [3]

The 10 September r/LocalLLaMA launch discussion put architecture and deployment questions next to enthusiasm about the release. That is the useful tension here: the model can use computation selectively while still being large to host. [5]

Why does a smaller context cache matter?

A smaller context cache reduces one of the memory costs of serving long conversations. The KV cache stores attention information from tokens the model has already processed so it can reuse it during generation. This is separate from the memory needed to hold the model’s weights.

DeepSeek’s report puts the global KV footprint at 890 bytes per token, roughly one quarter of V4 Flash’s figure. The launch announcement separately claims one quarter of the high-bandwidth memory requirement and one eighth of the SSD requirement for the KV cache relative to the previous generation. These are related measurements, not interchangeable descriptions of total model memory. [1] [2]

This is relevant to coding agents because a task can accumulate repository content, tool output and successive edits. Lower cache requirements make that accumulated context less expensive to hold. They do not prove that the model will correctly remember every dependency or choose a good patch. The published context capacity is about one million tokens, with the serving recipe specifying 1,048,576. [2] [3]

I would therefore read the memory change as an infrastructure improvement. It makes the long-context design more practical to serve, while the quality of a long coding task remains a separate question.

Are the coding improvements independently verified?

The comparison here comes from DeepSeek’s own evaluation, not an independent test by this publication. Its instruction-tuned model table reports clear gains over V4 Flash on several agent benchmarks. The useful comparison is with that previous model under the disclosed conditions, rather than with unrelated scores from another vendor’s launch.

DeepSeek reports a rise from 54.4% to 74.2% on DeepSWE v1.1, a gain of 19.8 percentage points. Its model card specifies reasoning_effort=100, temperature=1.0 and top_p=0.95. Code-agent evaluations use DeepSeek Harness Minimal with a one-million-token context; DeepSWE uses mini-SWE. Those conditions belong with the numbers. [2]

My reading is that the release deserves a fresh coding evaluation. My earlier V4 Flash comparison concerns the previous model and cannot decide how V4.1 behaves. I would rerun representative tasks with the same tests and review criteria before transferring either an old negative verdict or a new launch score to daily work.

What does DeepSeek V4.1 Flash cost through the API?

The current price table lists deepseek-flash as the model identifier and applies different rates during peak and off-peak hours. As checked on 14 September 2026, uncached input costs $0.15 per million tokens off-peak and $0.30 at peak; output costs $0.60 and $1.20 respectively. Cached input has its own lower rate. [4]

Peak rates are twice the off-peak rates. A price comparison needs the time window and cache category, not just the cheapest number in the table. Total task cost also depends on how much reasoning, tool output and retry work the task requires. A low output-token price is attractive, but a reviewable result is what I would measure.

Can you run the open weights locally?

The weights are available under the MIT License, but the documented deployment is for substantial server hardware. The vLLM recipe describes a checkpoint of roughly 511 GB and a minimum GPU-memory budget of 614 GB. Its examples include a GB200 NVL4 tray and an eight-GPU H200 node. These are recipe-specific requirements, not a universal minimum for every possible future implementation. [2] [3]

That is why I would separate the API decision from the hosting decision. Trying a fixed set of tasks through the API tests whether the model is useful for your workload. Hosting the weights additionally requires an operating plan for the model, memory, runtime and capacity. Open weights give operators that option; they do not remove the work of operating it.

For an individual developer, my first step would be a bounded API comparison against the model already doing the job. For a serving team, I would start with the deployment recipe and measure the actual prompt and output lengths that drive its workload. The 8B headline becomes useful once you know which stage of your workload it describes.