DeepSeek V4 Pro and Flash need very different hardware. Here's the real VRAM math for both, and why active parameters won't tell you what actually fits.
DeepSeek V4 ships as two very different models under one name. V4-Flash (284B total, 13B active) fits on a single B200. V4-Pro (1.6T total, 49B active) needs a cluster. In both cases, the active parameter count tells you almost nothing about the VRAM you actually need.
Key takeaways
Ask "how much VRAM does DeepSeek V4 need" and you'll get wildly different answers depending on which variant someone means, and most of those answers quietly assume active parameters set the memory footprint. Neither assumption holds up, and getting both wrong is the fastest way to either overpay for hardware you don't need or undersize a deployment that never had a chance of fitting.
DeepSeek released V4 as a preview covering two distinct models, and treating them as size variants of the same thing is the first mistake to avoid.
Both are sparse mixture-of-experts models routing through 256 routed experts plus 1 shared expert, both support a 1-million-token context window and up to 384K output tokens, and both ship with separate thinking and non-thinking modes. The difference that actually matters for hardware is the roughly 5.6x gap in total parameters between them, since that's what determines how much memory the model needs regardless of how fast either one generates tokens.
This is the single most common mistake in DeepSeek V4 hardware planning, and it isn't specific to DeepSeek: it shows up with every mixture-of-experts model.
Active parameters describe how much computation happens for each generated token. VRAM planning is about everything that must be resident in memory at once, which is why the total footprint is much larger.
⚡ Note
"13B active parameters" describes compute per token, not memory footprint. The router can select any of the 256 experts on any given token, so all 284B parameters in V4-Flash (or all 1.6T in V4-Pro) have to sit in VRAM at once. Treating V4-Flash like a 13B model because that's the active count is the fastest way to undersize a deployment.
The practical result: V4-Flash needs meaningfully more VRAM than its 13B active count would suggest, and V4-Pro needs vastly more, since 49B active is a rounding error against a 1.6T total. Active parameters affect inference speed, since fewer active parameters means less compute per token and faster generation. They tell you nothing about whether the model fits on your hardware in the first place.
V4-Flash is the realistically self-hostable half of the V4 family, and it's still a genuinely large model by any normal standard.
At native precision, ~170-175GB fits on a single B200 (192GB), which is the simplest deployment path since it avoids multi-GPU coordination entirely. The same footprint also fits comfortably across 4x A100 80GB cards (320GB combined), a reasonable alternative if B200 isn't the right fit for other reasons. Community INT4 quantization brings V4-Flash within reach of a 4x RTX 4090 setup, though at a real quality tradeoff worth testing against your actual use case before committing to it.
V4-Pro is not a bigger version of the same deployment story. It's a different category of hardware decision entirely.
Even at Q4, ~430GB doesn't fit on a single 8-GPU H100 node (640GB combined) once KV cache and runtime overhead are added for a 1M-token context, and the native FP8 checkpoint doesn't come close on any single-node configuration. V4-Pro is a multi-node cluster decision from the outset, not a "which single GPU is big enough" question.
The parameter counts get most of the attention, but the more meaningful upgrade in V4 is architectural. DeepSeek built a hybrid attention mechanism combining Compressed Sparse Attention (CSA) and Heavily Compressed Attention (HCA) specifically to make the 1-million-token context window efficient rather than just possible.
The result, according to DeepSeek's own published figures: at a 1M-token context, V4-Pro requires only about 27% of the single-token inference FLOPs and roughly 10% of the KV cache that DeepSeek V3.2 needed for the same context length. That's a substantially bigger efficiency gain than the raw parameter count comparison suggests, and it's the reason V4's long-context behavior doesn't degrade the way naive scaling would predict.
Once you know which variant you're deploying, matching it to hardware follows directly from the VRAM figures above. V4-Flash's native footprint fits a single B200 with room to spare, which is the simplest path if you want to avoid multi-GPU coordination. The 4x A100 80GB alternative is worth considering if B200 availability or pricing doesn't fit your specific setup.
V4-Pro is a different conversation entirely. Since it needs cluster-scale hardware regardless of quantization, that's where packet.ai's GPU Clusters come in, InfiniBand-connected multi-node fabric built for exactly this kind of deployment, rather than trying to force a model this size onto single-node hardware.
If you'd rather not manage inference infrastructure yourself at all, packet.ai's Token Factory is worth a look, a managed, OpenAI-compatible inference API. It's currently accepting waitlist signups, so it's worth joining if a managed path is what you're after, even if self-hosting is the more immediate option today.
For sizing other models before deciding on infrastructure, packet.ai's general VRAM requirements guide covers the same kind of sizing math across the broader model landscape.
Last reviewed: July 27, 2026. VRAM figures cross-referenced across multiple independent sources and DeepSeek's official model documentation. GPU availability and pricing confirmed against packet.ai's live product pages; Token Factory availability confirmed as waitlist-based at time of writing.
Same models. Same API. Fraction of the cost. Start free — no credit card required.
Start Building →
