DeepSeek-V4.1-Flash

DeepSeek-V4.1-Flash is a 552B-parameter multimodal Mixture-of-Experts model from DeepSeek-AI, released September 10, 2026 under the MIT license. It's the smallest member of DeepSeek's new V4 architecture family, and it is the model DeepSeek is now routing its own API traffic to, including requests previously served by V4-Pro. That routing decision tells you most of what you need to know: this is not a budget tier, it's a replacement tier.

The headline is the architecture, not the parameter count. V4.1-Flash uses a Causal Encoder-Decoder design: 40 Transformer layers split into a 20-layer causal encoder and a 20-layer decoder, where the decoder's global KV cache is projected from the encoder's final hidden states rather than derived per decoder layer. The practical result is asymmetric activation8B parameters active per token during prefill and 16B during decode. For agentic workloads, which are overwhelmingly input-heavy (long tool outputs, large documents, accumulated conversation state), that asymmetry is where the cost savings live.

The second headline is KV cache compression, and it's the reason this model is interesting to anyone running inference locally rather than calling an API. DeepSeek reports a global KV cache footprint of 890 bytes per tokenroughly a quarter of DeepSeek-V4-Flash, and a persistent KV footprint around 1/8 of the previous generation, achieved through SWA Bounded Replay, Compressed Sparse Attention 2 (CSA2), and FP4 main KV caching. At one million tokens of context, that difference is the gap between a cache that fits in HBM and one that spills to SSD and destroys your throughput.

It competes directly with Qwen3-235B-A22B and Llama 4 Maverick in the open-weight tier, and with DeepSeek's own V4-Pro, which is being phased out in its favor.

The MoE specifics matter for anyone planning hardware. V4.1-Flash runs 1 shared expert and 384 routed experts per MoE layer, activating 6 routed experts per token. Total backbone parameters are 552B; active parameters are 8B (prefill) / 16B (decode).

For inference planning, the distinction between total and active parameters cuts in two directions:

• Compute scales with active parameters. 16B active means per-token FLOPs are closer to a mid-size dense model than to a 552B one. Decode throughput is governed by memory bandwidth for the active experts, not by the full weight set.
• Memory scales with total parameters. Every expert must be resident somewhere. You cannot stream 384 experts per layer off a slow disk and get usable tokens per second. A 552B model needs 552B worth of storage, whether that's HBM, unified memory, or system RAM.

The supporting components are worth knowing by name because they show up in the technical report and in quantization discussions:

• CSA2 assigns each attention layer one of three static modes, Full, Reindex, or Reuse, sharing main KV and indexer K across layers and reusing Top-K sparse-attention indices. A Hierarchical Sparse Indexer bounds deeper indexing cost independently of context length.
• FP4 main KV caching (E2M1 format, one E4M3 scale per 16 channels) is what gets the cache to 890 bytes per token.
• Engram conditional memory adds 196B parameters accessed sparsely by token-based lookup.
• DSpark speculative decoding uses semi-autoregressive draft generation with confidence-scheduled verification.
• Multimodal path: a DeepSeek-ViT vision encoder with 2D-RoPE and 3×3 pixel-unshuffle downsampling, plus a two-layer MLP projector. Vision was trained jointly with text from the start of pre-training, not bolted on afterward.

The 1,000,000-token context window is the feature that makes the cache compression consequential. Long-horizon agents that accumulate tool output across hundreds of turns, or pipelines that ingest entire codebases, are the target workload.

Capabilities: chat, code, vision, reasoning, and function-calling. Concrete places this lands:

• Long-horizon agentic loops. Multi-step tool use where context grows monotonically. The 1M window plus the reduced persistent KV footprint means you can keep a long session alive without paying a cache-hit penalty that dwarfs the generation cost.
• Repository-scale coding. Feed a full monorepo context and ask for cross-file refactors, dependency tracing, or migration planning. Function-calling support lets it drive build tools and test runners inside the loop.
• Document and screenshot reasoning. Native vision means you can pass UI screenshots, architecture diagrams, scanned tables, or chart images alongside text and get grounded answers without a separate OCR stage.
• Input-heavy batch processing. Classification, extraction, and summarization over large document sets, where the 8B prefill activation keeps cost per input token low.
• Reasoning-heavy analysis. DeepSeek reports post-training at larger RL scale than prior generations, with benchmark results ahead of V4-Pro on text and agentic evaluations.

It is not a model you run for short, latency-critical single-turn chat. The activation asymmetry is designed for workloads where input dominates output.

Start with the honest constraint: 552B parameters is not a consumer-GPU model. There is no quantization that puts this on a single RTX 4090. What follows is what's actually achievable.

Approximate weight footprints (weights only; add KV cache and activation overhead on top):

KV cache: at 890 bytes per token, a full 1M-token context costs roughly 890 GB of global KV. In practice you will not fill the window on local hardware, budget for 32K–128K contexts (≈28 GB–114 GB) unless you're on a large unified-memory machine. The persistent portion is far smaller thanks to SWA Bounded Replay, which is what makes long sessions viable on SSD-backed setups.

• RTX 4090 / 5090 (24–32 GB): Not viable for the full model. Use it for smaller distills or quantized variants in the 30B class, or for speculative-decoding drafts against a remote host.
• M4 Max (128 GB): Not enough for the full weights at any usable quant. Viable for Qwen3-235B-A22B-class models instead.
• Mac Studio M3 Ultra (256–512 GB): The realistic single-box option. At 512 GB you can hold Q4_K_M with room for a 64K–128K KV cache. Expect memory bandwidth to be the bottleneck.
• Multi-GPU workstations (4–8× 48–80 GB): The high-throughput path. Tensor parallelism across 4× RTX 6000 Ada at Q2/Q3, or 8× H100 at Q8.

Q4_K_M is the right default if you have the memory. It preserves most of the model's reasoning and coding quality, and the MoE routing is relatively tolerant of 4-bit weights. Drop to Q3_K_M or Q2_K only to fit a hard memory ceiling, expect measurable degradation on multi-step reasoning and function-calling accuracy first, before you see it on chat. Avoid Q2 on agentic workloads where a malformed tool call costs a full retry.

Rough ranges, batch size 1, output tokens:

• 8× H100, FP8: ~50–90 tok/s
• 8× RTX 6000 Ada, Q4: ~20–35 tok/s
• Mac Studio M3 Ultra 512GB, Q4_K_M: ~15–30 tok/s
• CPU + RAM offload (Q2): under 5 tok/s, usable for batch jobs, not interactive use

Prefill on long inputs will be dramatically faster than decode thanks to the 8B prefill activation. That's the design working as intended.

Ollama is the fastest path if a GGUF build is available for your quantollama pull the model, confirm it fits in unified or system memory, and run. For anything above Q4 on multi-GPU, use llama.cpp directly with -ngl set to offload all layers and --tensor-split tuned to your GPU memory ratio. vLLM is the better choice for serving multiple concurrent requests, and it's where the FP4 KV cache path is implemented.

vs. Qwen3-235B-A22B (Apache 2.0, 235B total / 22B active): Qwen3-235B is roughly half the total parameters and needs about half the memory, call it 140–150 GB at Q4_K_M, which fits a 192GB Mac Studio or a 4-GPU box comfortably. V4.1-Flash wins on context length (1M vs. 256K–1M depending on config), on native vision, and on KV cache efficiency per token. Choose Qwen3-235B if your memory budget is the binding constraint and you don't need million-token contexts; choose V4.1-Flash if you're running long agent sessions where cache cost dominates.

vs. Llama 4 Maverick (400B total / 17B active): Closer in active-parameter count, so raw decode throughput is comparable on similar hardware. Maverick is lighter on total weights (~200 GB at Q4) and has a mature serving ecosystem. V4.1-Flash's advantages are the 1M context with compressed KV, the encoder-decoder prefill savings, and MIT licensing with no usage restrictions. Maverick's advantage is that more tooling has been tuned for it.

vs. DeepSeek-V4-Pro: DeepSeek's own testing puts V4.1-Flash ahead of V4-Pro on performance, cost, speed, and total runtime, and V4-Pro requests are being routed to V4.1-Flash until V4.1-Pro ships. For local deployment, V4.1-Flash is the one to target.