DeepSeek V4.1 Flash GPU Requirements: 552B MoE Image Input (2026)

DeepSeek V4.1 Flash GPU requirements come down to a change that has nothing to do with the parameter count bump from V4-Flash's 284B to 552B: image input now runs through the same endpoint as text, via a from-scratch DeepSeek-ViT encoder, instead of the separate V4-Flash-Vision-Exp variant DeepSeek retired to make room for it. That merger changes the KV-cache and activation-memory math enough that the flags in the DeepSeek V4-Flash deployment guide don't carry over as-is. DeepSeek released V4.1-Flash on September 10, 2026, and four days later began routing DeepSeek V4-Pro API traffic to it, a stronger signal of intent than anything in a benchmark table. This guide works through what changed, how to run V4.1-Flash for text, and how to serve it for image input without guessing at vLLM flags.

TL;DR: DeepSeek V4.1 Flash GPU Requirements

• Checkpoint: DeepSeek V4.1-Flash's 552B-parameter backbone plus 196B Engram memory ships as an ~511 GB checkpoint (MXFP4 experts, FP8 tables, BF16 embeddings), not a 1-byte-per-parameter estimate.
• Minimum hardware: the vLLM recipe defaults to 4x H200 SXM5 (564 GB, TP4) or 2x B200 (384 GB, TP2), both with Engram's 196B sparse parameters offloaded to CPU RAM.
• KV cache: Compressed Sparse Attention 2 with FP4 KV caching holds the GPU-resident KV footprint to about 890 bytes per token, roughly a quarter of V4-Flash's, so a 1M-token session uses under 1 GB of VRAM for KV regardless of whether the tokens are text or image.
• Software: vLLM 0.31.0+ is required, with model-specific --tokenizer-mode deepseek_v41 and --mm-encoder-tp-mode data for multi-image requests.
• Price: Spheron runs a 4x H200 node at $19.20/hr on-demand as of 18 Oct 2026; compare live GPU pricing before sizing a deployment.
• License: MIT, so commercial self-hosting carries no royalty, only the GPU bill.

What Changed in V4.1-Flash: 552B MoE Backbone Plus Native Image Input

Routing picks 6 of 384 total routed experts plus 1 shared expert per token, up from V4-Flash's pool of 256 routed experts, though both models activate the same seven-expert slice per forward pass.

The active-parameter count is where V4.1-Flash gets genuinely odd. V4-Flash had one flat figure (13B active per token, regardless of phase). V4.1-Flash splits it: 8B active during prefill, 16B during decode. That asymmetry tracks the CED split, lighter encoder compute processes the prompt once, while the decoder, which runs autoregressively for every generated token, carries the heavier load. If you're used to a single active-parameter number standing in for both compute phases, V4.1-Flash is the first model in this family where that shortcut breaks.

On top of the 552B backbone, Engram conditional memory adds 196B sparsely-accessed parameters, bringing the addressable total closer to 748B, though only a thin slice of Engram loads per forward pass. Engram's own table occupies 183.1 GiB of the checkpoint on disk, stored in FP8, which is the single biggest line item after the routed experts.

The multimodal piece is the real news for this version bump. V4.1-Flash adds native image input through a DeepSeek-ViT encoder trained from scratch, with a custom 2D-RoPE position scheme and 3x3 pixel-unshuffle downsampling, replacing V4-Flash-Vision-Exp, the separate vision variant DeepSeek retired specifically to fold this capability into the base model. Image and text requests now share one endpoint, one context budget, and one KV cache, which is the part that changes how you size a node, covered below. The model is released under the MIT license, same as the rest of the V4 family, so commercial self-hosting carries no licensing fee on top of the GPU bill.

Architecture and KV Cache: Causal Encoder-Decoder Cuts KV to 890 Bytes/Token

V4.1-Flash's KV cache paper, DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression, describes a two-tier cache. A small "global" slice stays resident in GPU HBM at all times; a much larger "persistent" slice lives on SSD or host memory and gets replayed back in only when needed. Combining Compressed Sparse Attention 2 (CSA2) with FP4 KV caching cuts that global, always-in-HBM footprint to about 890 bytes per token, roughly a quarter of V4-Flash's equivalent figure. A separate mechanism, SWA Bounded Replay, cuts the larger persistent footprint on SSD or host memory to roughly an eighth of V4-Flash's.

That split matters because GPU VRAM sizing only cares about the global slice. At 890 bytes per token, a 128K-token session costs about 114 MB of GPU-resident KV; even a full 1M-token session costs under 900 MB. For comparison, the DeepSeek Sparse Attention guide walks through the CSA/HCA mechanism V4-Flash uses to get its own KV bound, and the KV cache optimization guide covers the PagedAttention budgeting math this two-tier design is compressing further. The practical result: for V4.1-Flash, KV cache essentially stops being the sizing constraint it was for V4-Flash and V4-Pro. Weights are now what decide your node.

That doesn't change the MoE rule that every expert weight has to be resident in fast memory somewhere, VRAM or offloaded CPU RAM, because the router can send any token to any expert on any forward pass. The MoE inference optimization guide covers why "active parameters" never shrinks the memory footprint, only the compute footprint, a distinction V4.1-Flash's split prefill/decode active-parameter figures make even more visible than a single flat number would.

DeepSeek V4.1 Flash GPU Requirements: VRAM Math for Text-Only vs Multimodal Input

The checkpoint breaks down like this on disk:

The vLLM recipe's default configs offload Engram's 196B parameters to CPU RAM rather than loading the full 183.1 GiB table into VRAM, which leaves roughly 314 GB (the total minus the Engram slice) that has to be resident on GPU. That's the number that actually decides node size:

Image tokens aren't free of cost, they just cost the same per-token rate as text once the vision tower has encoded them into the decoder's token stream. That's the practical consequence of running multimodal through the main endpoint instead of a separate vision-exp model: there's one context budget to manage, not two memory pools.

The same weight-resident math applies to the Blackwell default: 2x B200 (384 GB total) carries the same ~314 GB of VRAM-resident weights, leaving roughly 70 GB for KV and runtime, which is still comfortable given how small the global KV figure is per session. The vLLM recipe also lists MI300X and MI325X at tensor-parallel-size 4 and MI355X at tensor-parallel-size 2 for AMD hardware; of those, only MI300X is in Spheron's current fleet. The recipe's matrix doesn't list an H100 configuration, likely because MXFP4's native execution path targets Blackwell's hardware FP4 tensor cores, and nothing in the published recipe confirms a validated dequantized path on Hopper.

For the general weights-plus-KV-plus-activations formula this table is built from, see the LLM VRAM requirements guide. For a side-by-side on what other multimodal MoE models need, the vision language model deployment guide covers Qwen3-VL, Llama 4 Scout, and InternVL3 sizing on the same kind of hardware.

How to Run DeepSeek V4.1 Flash: Minimal Inference Setup

Minimal text-only inference needs vLLM 0.31.0 or newer and the model-specific flags DeepSeek ships for this release: --tokenizer-mode deepseek_v41, --tool-call-parser deepseek_v41, and --reasoning-parser deepseek_v41.

# Install vLLM 0.31.0+
pip install "vllm>=0.31.0"

# Verify CUDA
nvidia-smi

# Download weights (~511 GB)
huggingface-cli download deepseek-ai/DeepSeek-V4.1-Flash \
  --local-dir ./deepseek-v4.1-flash

# Launch vLLM on 4x H200 SXM5
vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --tokenizer-mode deepseek_v41 \
  --tool-call-parser deepseek_v41 \
  --reasoning-parser deepseek_v41 \
  --kv-cache-dtype fp8 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.90 \
  --host 0.0.0.0 \
  --port 8000

DeepSeek's recommended minimal-inference sampling is temperature 1.0 and top_p 0.95, with a max-tokens setting of at least 256K inside the 1M-token context window if you want the model's full reasoning behavior rather than a truncated response. That's a deliberately generous generation budget, not a typo: cut it down for short-form tasks, but don't be surprised if the model wants room to think on anything that benefits from its reasoning path.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4.1-Flash",
    messages=[{"role": "user", "content": "Summarize the tradeoffs between tensor parallelism and pipeline parallelism for MoE inference."}],
    temperature=1.0,
    top_p=0.95,
    max_tokens=4096,
)
print(response.choices[0].message.content)

The recipe also documents DSpark, a 5-token speculative-decoding draft step, as an optional throughput optimization once your baseline serving config is stable; configure it through vLLM's speculative decoding interface rather than treating it as a day-one requirement.

vLLM Setup for Multimodal Requests: Vision Tower Flags and Image Token Limits

The vision tower is a 32-layer ViT at hidden size 1024, patch size 14, with a hard cap of 1,024 tokens per image, and no separate limit on how many images one prompt can carry; the overall context window is the only real ceiling. To enable it, add --trust-remote-code for the vision processor and --mm-encoder-tp-mode data to turn on encoder data-parallel mode, which spreads vision encoding across GPUs that would otherwise be idle during that phase of a multi-image request:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --trust-remote-code \
  --mm-encoder-tp-mode data \
  --tokenizer-mode deepseek_v41 \
  --tool-call-parser deepseek_v41 \
  --reasoning-parser deepseek_v41 \
  --kv-cache-dtype fp8 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.90 \
  --host 0.0.0.0 \
  --port 8000

Send images the standard OpenAI way, as image_url content blocks inside a chat completion request. Each image costs up to 1,024 tokens against whatever --max-model-len you've set, on top of the text in the same request, so a prompt with 50 images can burn 51,200 tokens of context before a single word of text is counted. Since there's no separate image-token budget, plan context length the same way you'd plan for a long text-only request: against the full 1M-token ceiling, not a special multimodal allowance.

Evaluation Results: Is V4.1-Flash Actually Better Than V4-Pro?

V4.1-Flash's Codeforces rating climbed from V4-Flash's 3,289 to 3,471, and on the new multimodal path it posts an MMMU-Pro score of 56.5 and a DocVQA score of 95.6. The DocVQA number is the one worth paying attention to if your use case is document or chart extraction; it's a strong score for a model that bolted vision onto an MoE backbone rather than being built vision-first. MMMU-Pro, a broader multimodal reasoning benchmark, is more middling, consistent with Flash being a capable generalist rather than a dedicated vision model. If your workload leans heavily on open-ended visual reasoning rather than document understanding, it's worth checking it against dedicated vision-first models before committing.

Whether V4.1-Flash is "better than V4-Pro" depends on what you mean by better. There's no independently published head-to-head benchmark table between the two models as of this writing. What we do have is DeepSeek's own routing decision: starting September 14, 2026, DeepSeek began sending V4-Pro API traffic to V4.1-Flash. That's a company putting its production traffic where its confidence is, which is a meaningfully stronger signal than a leaderboard screenshot, but it's still a product decision made by the model's own creator, not a third-party evaluation. If your workload is sensitive to the gap between a 552B Flash model and a ~1.6T Pro model on genuinely hard multi-step tasks, benchmark your own task mix before retiring a V4-Pro deployment; the DeepSeek V4-Pro deployment guide covers what that model still needs if you keep it around for the hardest slice of your traffic.

GPU Sizing on Spheron: H200, B200, and Where It Doesn't Fit

The vLLM recipe's default configs map onto Spheron's own GPU lineup like this:

On-demand H200 and B200 on Spheron are, per-GPU, the exact unit this model's own recipe asks for, and per-minute billing with no lock-in is a reasonable fit for testing a model whose multimodal vLLM support is only weeks old at the time of writing. B200 on Spheron is the TP2 default's home; spot capacity on either GPU fits batch or offline multimodal jobs, like the document and chart extraction work V4.1-Flash's DocVQA score suggests it's good at, that can tolerate a reclaim and retry. Production serving with a hard uptime SLA is a better match for Spheron's reserved tier than spot, since spot capacity can be reclaimed mid-request without notice. One gap worth naming: Spheron doesn't list a discrete "GB200 NVL4 tray" rental SKU the way some sizing tables describe a quarter-rack slice of an NVL72 system; GB200 and GB300 on Spheron are reservation products, so match your target tensor-parallel size against a full reserved node rather than assuming a partial-tray rental exists. MI300X on Spheron covers the AMD path if your fleet is ROCm-based.

We don't yet have fleet throughput numbers for V4.1-Flash itself, it's too new. What we do have is firsthand numbers for its 284B predecessor, DeepSeek V4-Flash (the 0731 checkpoint), measured on our own 8x B200 fleet on 15 Oct 2026, which is the closest real anchor available until V4.1-Flash accumulates its own numbers. On that node, four 2-GPU copies of V4-Flash ran side by side under vLLM with FP8 weights and FP4 KV at 1M context, for 128 concurrent agent sessions per node. Per-copy throughput came in at 272 tokens/sec for one user, 170 tok/s at 8 concurrent users, 140 at 16, and 116 at 32, with a time-to-first-token of 0.64 seconds; each copy sustained 137,509 prompt tokens/sec and 1,607 output tokens/sec, with zero errors across the run. That same 8x B200 node ran one GLM-5.3-Flash copy on 4 GPUs alongside the two V4-Flash copies on 2 GPUs each, which is where those benchmark numbers came from.

Two lessons from that run carry over directly to sizing V4.1-Flash's much larger checkpoint. First, cold starts aren't instant: the fresh 8x B200 node with empty caches took about 29 minutes to start serving GLM-5.3-Flash and V4-Flash together, against about 16 minutes for GLM-5.3 alone, and a parallel weight loader cut V4-Flash's own load time from about 25 minutes to about a minute, which will matter more for V4.1-Flash's roughly 511 GB checkpoint than it did for V4-Flash's smaller one. Second, every 8-GPU spot instance type on the fleet was reclaimed at least once on 14 Oct 2026 during that same testing window, which is exactly why the reserved-tier recommendation above exists: if you serve inference on spot, keep spare capacity and set up automatic recovery.

A separate lesson on tensor-parallel sizing, from the same fleet: splitting an 8-GPU Blackwell node into smaller TP groups trades per-user speed for session count. On an 8x B300 node split into two 4-GPU copies, GLM-5.3 ran at 254 tok/s for a single user against 324 tok/s on one 8-GPU copy on 8x B200, in exchange for serving 64 concurrent sessions instead of 32. V4.1-Flash's own TP4 default on H200 sits on that same curve, four GPUs instead of a wider tensor-parallel group, so expect a similar session-count-for-per-user-speed tradeoff if you run two TP4 replicas on one 8x H200 node rather than committing the whole node to a single, wider configuration.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 18 Oct 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.

Self-Hosting vs the DeepSeek API: Cost Per Million Tokens

DeepSeek's own API, as of September 10, 2026, prices V4.1-Flash on a peak/off-peak schedule: cached input at $0.003/1M tokens off-peak and $0.006/1M peak, uncached input at $0.15/1M off-peak and $0.30/1M peak, and output at $0.60/1M off-peak and $1.20/1M peak. Independent testing measured roughly 207 output tokens/sec through the API, which gives a rough sense of real-world latency if you're weighing the API against a self-hosted node.

Those API numbers are a clean reference point precisely because self-hosted cost per token for V4.1-Flash specifically needs to be measured on your own deployment; the fleet numbers above are for its predecessor, not this model, so don't carry them over as a V4.1-Flash cost figure. Once you have a real throughput number from your own 4x H200 or 2x B200 node, the conversion is the same formula every self-hosted comparison in this family uses:

Node $/hr / 3,600 sec/hr = $/sec
$/sec / throughput tok/s = $/tok
$/tok x 1,000,000 = $/M tokens

Run that against your measured throughput and compare it to the API's $0.60-$1.20/1M output rate above. The MIT license means there's no licensing cost on either side of that comparison, only infrastructure versus per-token API fees. The DeepSeek API pricing vs self-hosted cost and privacy guide walks through the fuller break-even math, including the privacy and data-residency reasons teams choose self-hosting even when the API is cheaper per token at low volume.

DeepSeek V4.1-Flash's ~511 GB checkpoint and sub-gigabyte KV cache per session mean the new multimodal path fits comfortably on a 4-GPU node at $19.20/hr on-demand, with spot capacity available for batch document and chart extraction jobs.

View all GPU pricing

Deploy DeepSeek V4.1-Flash on Spheron →