DeepSeek V4.1-Flash: 552B MoE, 890-byte/token KV Cache, MIT

DeepSeek announced V4.1-Flash on September 10, 2026 (Beijing time). It is a 552B-total MoE model with lightweight active parameters — 8B at prefill and 16B at decode. Its headline technical feature is a KV cache built primarily around FP4, compressed to roughly 890 bytes per token, about a quarter (1/3.9) of the previous V4-Flash generation. Weights are released under the MIT license, open for both local deployment and commercial use.

This article is based on day-one primary sources and published model-card figures. DeepSeek's official system card and a complete benchmark table are not yet public, and some speed and quality numbers now circulating come from community measurements or press reporting rather than official disclosure. See also our existing V4-series coverage: DeepSeek V4 requirements reference, DeepSeek V4-Pro 0813 GA, and DeepSeek V4-Flash vision support.

Unlike a conventional decoder-only Transformer, V4.1-Flash uses an asymmetric causal encoder-decoder design (20 encoder layers, 20 decoder layers). Its MoE layers combine one shared expert with 384 routed experts, and only the routed experts selected for a given token participate in computation. This is what lets a 552B-parameter model keep its active compute down to just 8B at prefill and 16B at decode.

Context length reaches up to 1M tokens, and reasoning effort can be tuned continuously on a 1-to-100 scale rather than through discrete mode switches — a knob that makes it easier to trade latency against cost.

Multimodal support is also expanded: a DeepSeek-ViT vision encoder is built in natively, trained with 2D-RoPE (two-dimensional rotary position encoding) so images and text share the same architecture. Pretraining used 45T multimodal tokens, and context length was extended to 1M at the 34T-token mark.

The most practically significant change in V4.1-Flash is KV cache compression. An FP4-based representation (mostly E2M1 format) brings the per-token footprint down to roughly 890 bytes — about a quarter (1/3.9) of the prior V4-Flash generation.

The math is simple: 890 bytes × 1,000,000 tokens ≈ 0.89GB. In other words, even a fully-used 1M-token context keeps the KV cache under 1GB. Long-context models routinely push KV cache into the tens or even hundreds of gigabytes, so this level of compression fundamentally changes memory planning for long-context deployments. With KV cache now nearly negligible next to weight size, teams no longer need to budget it separately when sizing a long-context deployment.

Published benchmark figures are limited so far, but the pattern is clear. Security and automation-agent tasks show results that beat existing top models, while general reasoning and sustained terminal-operation tasks show the model falling behind.

It beats reference models on CyberGym (security offense/defense) and Automation-Bench (automation tasks), and is roughly on par with Claude Opus 5 on DeepSWE (software-engineering agents). It falls clearly behind on Terminal-Bench 3.0 (sustained terminal operations) and, more notably, on HLE (Humanity's Last Exam, general reasoning). Given a 552B MoE with only 8B/16B active parameters, the most natural reading is that post-training focused on security and automation tasks first, leaving general reasoning capability still developing.

Worth repeating: DeepSeek's official system card and a complete benchmark table are not public as of this writing, and some of the figures above — like other numbers currently circulating — come from community measurement or press reporting rather than official disclosure. Check for official updates before making adoption decisions based on them.

These are off-peak rates. Peak hours — weekdays UTC 01:00-04:00 and 06:00-10:00 — are billed at double. In JST (UTC+9) that roughly corresponds to 10:00-13:00 and 15:00-19:00 (check carefully around day boundaries). Whether batch and bulk-inference work can be scheduled outside those windows directly determines effective cost, by as much as 2x.

Cache-hit input pricing runs at 1/50th of cache-miss pricing, so workloads that repeatedly reuse the same system prompt or long reference document — codebase analysis, internal document QA — turn prompt-prefix design directly into cost savings.

Weight footprint follows the usual formula: total parameters × bits ÷ 8. For 552B, that works out to roughly 276GB at 4-bit, 552GB at 8-bit (FP8), and 1.1TB at BF16. Real deployments should add 10-20% overhead on top of that. KV cache, as noted above, stays under about 0.89GB even at a full 1M-token context — so for V4.1-Flash, memory requirements are driven almost entirely by weight size rather than by context length.

To be candid, 552B is not a size built for consumer GPUs or a single Mac. Even at 4-bit, roughly 276GB of weights need to fit in VRAM, which means a multi-H100/H200 server cluster even for a smaller organization. The lightweight KV cache is a genuine advantage — it removes almost all of the extra memory burden that long context normally brings — but it does not make this model "runnable at home." Anyone evaluating on-premise deployment should first confirm they can actually provision a GPU cluster at this scale. See also our earlier DeepSeek V4 requirements reference for the underlying quantization math.

V4.1-Flash suits, first, organizations that want to evaluate security-testing and automation-agent workflows through the API. Given results that beat reference models on CyberGym- and Automation-Bench-style tasks, it's worth testing in vulnerability-assessment or operations-automation pipelines. Second, developers working with million-token contexts through the API stand to benefit from the lightweight KV cache indirectly, through better server-side throughput and latency, even without self-hosting.

For general reasoning or sustained terminal-operation workloads, other models currently have the edge based on the HLE and Terminal-Bench 3.0 results. If self-hosting is the goal, the deciding question is whether your organization can actually build and operate a GPU cluster sized for 552B. If budget or infrastructure can't stretch that far, starting with API evaluation is the practical path.