DeepSeek V4 Flash Is Almost Too Cheap to Meter

DeepSeek V4 Flash is a 284-billion-parameter mixture-of-experts model that activates about 13 billion parameters per token. The whale is back.

DeepSeek charges $0.14 per million uncached input tokens, $0.0028 per million cached input tokens, and $0.28 per million output tokens. The model supports a one-million-token context and up to 384K output, with non-thinking, Think High and Think Max modes.

That is insanely cheap. Bulk extraction, long agent histories, repeated tool schemas, evaluation runs and synthetic data barely move the budget.

The open checkpoint is useful too. The official mixed FP4/FP8 release is roughly 160 GB on Hugging Face. It may be 13B active but all 284B parameters still need somewhere to live.

What $100 actually buys

DeepSeek bills input and output separately. The following estimates use the official V4 Flash rates and count total tokens in both directions.

Workload split	Cache assumption	Blended cost per 1M total tokens	Total tokens for $100
70% input / 30% output	No input cache hits	$0.1820	549 million
80% input / 20% output	No input cache hits	$0.1680	595 million
70% input / 30% output	All input cached	$0.08596	1.16 billion
80% input / 20% output	All input cached	$0.05824	1.72 billion
90% input / 10% output	All input cached	$0.03052	3.28 billion
95% input / 5% output	All input cached	$0.01666	6.00 billion

Those extremes bracket the range. Realistic agentic coding lands somewhere in the middle.

Agentic coding scenario	Input / output	Cache hit rate	Blended cost per 1M	Tokens for $100
Short task (20 turns, ~3K in / 500 out)	86% / 14%	~60%	$0.0894	1.12 billion
Medium session (100 turns, ~5K in / 600 out)	89% / 11%	~65%	$0.0754	1.33 billion
Long session (300 turns, ~8K in / 800 out)	91% / 9%	~70%	$0.0653	1.53 billion

In absolute terms: the 20-turn task costs about $0.006, the 100-turn session roughly $0.04, and the 300-turn marathon under $0.18. A hundred dollars buys thousands of full coding sessions.

The cache is automatic. DeepSeek persists prompt-prefix units to disk and reuses them when a later request shares the same prefix. The response reports prompt_cache_hit_tokens and prompt_cache_miss_tokens, so you can verify rather than assume. Matching is best-effort, entries expire after hours or days of inactivity, and a prompt change near the beginning can invalidate most of the prefix.

Benchmarks: fast does not mean lightweight

V4 Flash is the smaller and cheaper member of the V4 family, but its benchmark profile is still close to frontier-model territory in several areas. The strongest results come from the reasoning modes, especially Think Max.

Benchmark	Non-Think	Think High	Think Max
MMLU-Pro	83.0	86.4	86.2
GPQA Diamond	71.2	87.4	88.1
LiveCodeBench	55.2	88.4	91.6
SWE-bench Verified	73.7	78.6	79.0
Terminal-Bench 2.0	49.1	56.6	56.9
MRCR at 1M context	37.5	76.9	78.7
CorpusQA at 1M context	15.5	59.3	60.5
SimpleQA Verified	23.1	28.9	34.1

The jump from Non-Think to Think High is substantial. GPQA Diamond rises from 71.2% to 87.4%, LiveCodeBench from 55.2% to 88.4%, and one-million-token MRCR from 37.5% to 76.9%. Think Max adds a smaller final improvement on most tasks, although it helps more on difficult coding, mathematics and browsing evaluations.

Coding is the clearest strength. Flash Max reaches 91.6% on LiveCodeBench and resolves 79.0% of SWE-bench Verified, only 1.6 points behind V4 Pro Max on the latter. Its agentic results are more mixed: 73.2% on BrowseComp is strong, while 56.9% on Terminal-Bench 2.0 leaves a larger gap to the best models.

The long-context results also need interpretation. On DeepSeek’s evaluations, the non-thinking mode performs poorly on the one-million-token tests, while the reasoning modes recover much more of the relevant information.

Knowledge is the main compromise. Flash Max scores 34.1% on SimpleQA Verified, compared with 57.9% for V4 Pro Max and 75.6% for Gemini 3.1 Pro in DeepSeek’s table. Flash can reason through difficult material, but its smaller active and total parameter counts leave it with less reliable factual recall than the larger Pro model.

Hallucinations: confident even when it does not know

Artificial Analysis reports a 96% hallucination rate for V4 Flash Max on its AA-Omniscience evaluation. The benchmark asks questions designed to test both knowledge and calibration. The reported rate means that when Flash did not know the answer, it almost always attempted one rather than abstaining. Its overall Omniscience score was -23, roughly in line with DeepSeek V3.2.

DeepSeek’s own factuality-oriented results tell a similar, though less dramatic, story. Flash Max reaches only 34.1% on SimpleQA Verified. The Flash base model scores 30.1% on SimpleQA Verified and 33.9% on FACTS Parametric, compared with 55.2% and 62.6% respectively for V4 Pro Base.

V4 Flash is better suited to transforming supplied information than acting as an unquestioned source of truth. Give it a repository, document set, database result or search tool and let it reason over evidence.

Where the savings come from

V4 Flash is cheap to run for three main reasons: it activates only a small part of the model for each token, it is trained to use low-precision numbers, and its serving software is designed around the architecture.

1. Only a small fraction of the model runs for each token

Each mixture-of-experts layer contains 256 routed experts, but only six are selected for a given token.

This distinction matters:

Total parameters determine how much knowledge and capacity the model can store.
Active parameters determine much of the computation required to process each token.

V4 Flash may have a large total parameter count, but only about 13 billion parameters are active for each token. It therefore gets some of the capacity of a much larger model without paying the full compute cost on every forward pass.

2. The checkpoint was trained for low-precision inference

The released instruct model does not rely on quantization being added only after training. Its routed expert weights use FP4, while most other parameters use FP8.

DeepSeek used MXFP4 quantization-aware training for the expert weights and for the query-key path in the sparse-attention indexer. During training, the model was exposed to the rounding and precision errors it would encounter during deployment. It could therefore adapt to those errors instead of being compressed only after training was complete.

This generally preserves accuracy better than taking a finished high-precision checkpoint and converting it to FP4 afterwards.

NVIDIA also provides an NVFP4 conversion for Blackwell GPUs. According to its model card, the converted model performs close to NVIDIA’s baseline across tests of reasoning, long-context recall, tool use, scientific coding and instruction following.

In NVIDIA’s version, the linear operations inside the MoE transformer blocks use quantized weights and activations. More sensitive parts of the model remain at higher precision. Running this version requires a supported Blackwell configuration in a serving engine such as vLLM or SGLang.

3. The serving system is optimized for the model

Poor scheduling can leave GPUs waiting even when the theoretical compute requirement is low.

DeepSeek designed its production stack to reduce this overhead. The V4 report describes fused MoE kernels that overlap three operations:

moving token data between experts;
performing the expert calculations;
reading and writing accelerator memory.

It also uses an expert-parallel schedule that processes experts in waves.

These optimizations improve accelerator utilization. At API scale, that matters as much as the model’s parameter count: lower precision and sparse activation reduce the amount of work, while the serving stack ensures that the hardware spends less time waiting.

Compressed attention at one million tokens

Standard attention is extremely expensive at a context length of one million tokens. For every new token, the model would need to compare against a huge key-value cache in every layer.

DeepSeek V4 reduces this cost by compressing older context. After two initial sliding-window layers, it alternates between two attention mechanisms:

Compressed Sparse Attention (CSA): Groups of four tokens are compressed into one KV entry. An indexer then selects the 512 compressed entries most relevant to the current token.
Heavily Compressed Attention (HCA): Groups of 128 tokens are compressed into one entry. Because this produces a much shorter sequence, the model can attend to all of these entries.

At the same time, a sliding-window branch keeps the most recent 128 tokens at full resolution. This gives the model precise access to nearby text while storing older text in a cheaper, lower-resolution form. CSA can then retrieve selected parts of that older context when more detail is needed.

DeepSeek estimates that, at one million tokens, the V4 family uses about 2% as much KV-cache memory as a BF16 GQA8 baseline. Compared with DeepSeek V3.2, V4 Flash reportedly uses 10% of the attention FLOPs for single-token generation and 7% of the KV-cache memory.

DeepSeek’s production system can also store KV state on disk when many requests share the same prefix. Compressed CSA and HCA entries can be saved directly. Sliding-window state is larger, so the paper describes several options: storing it in full, saving periodic checkpoints, or recomputing a limited recent section when needed.

These optimisations are part of what makes DeepSeek’s low cached-input pricing possible.

Speculative decoding with DSpark

V4 Flash already includes one Multi-Token Prediction (MTP) layer, which allows it to predict several future tokens during generation.

DeepSeek later released DeepSeek-V4-Flash-DSpark. It uses the same base model but adds a more advanced speculative-decoding module. Instead of generating every token one at a time, DSpark proposes several tokens ahead and then verifies them with the main model.

DSpark combines two drafting methods:

a parallel path that proposes multiple future tokens quickly;
a lightweight sequential path that improves the draft when later tokens depend strongly on earlier ones.

It also estimates how likely a proposed token sequence is to be accepted. When confidence is high, it verifies a longer draft. When confidence is lower, or the server is under heavier load, it uses a shorter one.

In DeepSeek’s production V4 traffic, the DSpark paper reports 60–85% faster generation for each user than the MTP-1 baseline while maintaining the same overall server throughput. Users receive tokens sooner without requiring the service to handle fewer requests.

This likely contributes substantially to the speed of DeepSeek’s hosted API. In my own use (3rd party providers, not official deepseek api), output has repeatedly approached 100 tokens per second, making long reasoning traces feel closer to live transcription than ordinary model generation.

Community results also show meaningful gains, although they are smaller than the best production figures. One two-Spark setup reports 60–67 tokens per second for code generation, compared with 40–45 tokens per second using plain V4. With six requests running concurrently, the same system reached 182 tokens per second in aggregate.

Actual performance depends heavily on how often the main model accepts the drafted tokens. Predictable output, such as code or structured agent actions, usually produces higher acceptance rates than creative prose. Memory bandwidth and hardware support also remain important bottlenecks.

The official vLLM example asks DSpark to propose seven speculative tokens at a time:

--speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

On unsupported hardware or a generic vLLM installation, enabling speculative decoding may provide a much smaller gain—or fail to work correctly at all.

Running it locally

The 13B active count describes compute, not storage. The official checkpoint occupies roughly 160 GB in mixed FP4/FP8 format. For 96–128 GB machines, the practical route is a custom GGUF: the DwarfStar/ds4 project quantizes routed experts to IQ2_XXS and Q2_K while leaving shared experts, attention and output layers at higher precision. Its current Q2 model is about 81 GB — aggressive, but more sensible than flattening every tensor to two bits.

DwarfStar can also stream routed experts from SSD when the model exceeds RAM. A community test on one GB10 reported roughly 15 tok/s for the 81 GB IQ2 build, 2 tok/s for a 154 GB Q4 build, and 5.5 tok/s for that Q4 build with a 64 GB expert cache. Not pleasant, but a big achievement.

Recent community work has moved quickly:

Hardware and build	Reported result	Important caveat
M3 Max 128 GB, DwarfStar Q2	26.7 tok/s short; 21.5 tok/s after an 11.7K prompt	Metal, greedy, non-thinking
M5 Max 128 GB, DwarfStar Q2	34.3 tok/s short; 25.9 tok/s after an 11.7K prompt	Metal, greedy, non-thinking
1x DGX Spark, tuned Q2	18.8–20.6 tok/s plain; 27.7 tok/s DSpark suite mean; 34.5 tok/s on stepwise maths	81 GB community quant and custom engine
2x DGX Spark, official FP8 + MTP	About 35–44 tok/s warm single-stream	200K–262K recipes; long prefill is much slower
2x DGX Spark, DSpark community build	About 60–67 tok/s on code; about 40 tok/s on mixed text	Custom branch; acceptance and stability vary
2x RTX PRO 6000 Blackwell, vLLM MTP2	138 tok/s at concurrency 1; 229–363 tok/s aggregate at C2–C24	Tuned preview branch, 131K validation ceiling

The RTX PRO 6000 result shows what the architecture can do with bandwidth and mature kernels: roughly 6,350 input tok/s at 1K, 4,561 at 64K, 141.6 decode tok/s after a 59K prompt, and 105.5 after 124K. Two DGX Sparks offer 256 GB of unified memory for the official checkpoint, with community recipes reaching 200K context and experimental one-million-token paths.

Estimate the hardware DeepSeek V4 Flash needs at a chosen quantization, context window, and decode target.

Verdict

V4 Flash is not the best model at everything. Its strongest results are in reasoning, coding and cost-efficient agent work, while factual recall, calibration and the hardest autonomous tasks remain weaker. DeepSeek’s own table puts Flash Max behind V4 Pro Max on knowledge and complex agentic benchmarks, and independent testing suggests that Flash is too willing to answer questions it does not know. Aggressive local quantization can widen those quality gaps further.

The combination is still rare: capable reasoning and coding, a real one-million-token architecture, open weights, useful local paths, and API prices low enough for bulk work. Keep stable instructions and tools at the front of prompts, measure cache-hit tokens, and reserve Think High or Max for decisions that justify the extra output.

DeepSeek has stacked sparse experts, FP4-aware training, compressed long-context attention, disk-backed KV reuse, specialised MoE kernels and speculative decoding. The price is the result of the whole stack.