Tutorial

Deploy DeepSeek V4 on GPU Cloud: MoE Inference with vLLM and Expert Parallelism

Back to BlogWritten by Published May 18, 2026Updated
DeepSeek V4LLM DeploymentvLLMGPU CloudMoEExpert ParallelismH100H200
Deploy DeepSeek V4 on GPU Cloud: MoE Inference with vLLM and Expert Parallelism

Last updated: September 30, 2026

DeepSeek V4 is out as two open-weight Mixture-of-Experts models under the MIT license, both with a 1M-token context window: V4-Pro, with 1.6T total parameters and 49B active per token, and V4-Flash, with 284B total and 13B active. This guide covers the deployment path for both: sizing VRAM from the real checkpoint, picking a GPU configuration, running vLLM with expert parallelism, and tuning for production throughput. DeepSeek has since shipped a larger successor with image input; see the DeepSeek V4.1 Flash GPU requirements guide for the 552B model.

This post is the overview for the whole V4 family. For variant-specific tuning, the DeepSeek V4-Flash deployment guide goes deeper on the 284B model, and the DeepSeek V4-Pro deployment guide covers the 1.6T model, including multi-node setups for long-context workloads.

For a DeepSeek V4 vs GLM-5.1 vs GPT-OSS 120B benchmark comparison, see the open-weight frontier model showdown post. If you are also considering GLM-5.1 as an alternative, the GLM-5.1 deployment guide covers a similar 8x H200 FP8 setup for a model with slightly higher Chatbot Arena scores on coding tasks. If your workload involves document processing, the DeepSeek family also includes DeepSeek-OCR, which runs efficiently on the same GPUs for PDF and image extraction. If your primary constraint is 1M+ token context at affordable TTFT, SubQ 1M-Preview with 12M context trades MoE model quality for linear prefill scaling and fits the full context window on a single H200 node. For a smaller multi-GPU footprint at comparable active-parameter scale, see the Mistral Large 3 deployment guide. For context on the Huawei Ascend hardware that was part of DeepSeek's training compute, the Ascend 950 vs B200 and B300 inference comparison explains why most teams outside China use NVIDIA for DeepSeek inference serving.

TL;DR: Deploy DeepSeek V4 on GPU Cloud

  • Models: DeepSeek V4-Pro is 1.6T total / 49B active; V4-Flash is 284B total / 13B active. Both have a 1M-token context and MIT-licensed weights.
  • V4-Pro VRAM: the native FP4+FP8 checkpoint is about 865GB, so it fits one 8x H200 141GB node (1,128GB) or 8x B200, but not 8x H100 80GB (640GB).
  • V4-Flash VRAM: the checkpoint is about 160GB, so it fits 2x H200 (282GB) or 4x H100; 2x H100 is too tight.
  • Spheron cost: 8x H200 runs $44.16/hr on-demand and 2x H200 runs $11.04/hr, as of 15 Nov 2026, on Spheron H200 instances.

What Is DeepSeek V4

DeepSeek V4 is a family of two sparse MoE models:

  • V4-Pro: 1.6T total parameters, 49B active per token. The flagship, aimed at coding, agentic and long-context reasoning work.
  • V4-Flash: 284B total parameters, 13B active per token. The same design at a size that fits on two H200s.

Both use top-K routing to pick which experts process each token, which keeps per-token compute tied to the active count rather than the total. Both ship with a 1M-token context window and open weights under the MIT license.

Compared to DeepSeek V3 (671B total, 37B active, 128K context), V4-Pro is bigger on both counts: more than twice the total parameters and 49B active instead of 37B, so you pay more for storage, weight loading and per-token compute. V4-Flash goes the other way, with fewer total and active parameters than V3, which makes it the cheaper model to host of the three. Both V4 models raise the context window from 128K to 1M tokens.

For background on why active parameter count doesn't reduce memory requirements, see our GPU memory requirements guide for LLMs.

GPU Hardware Requirements for DeepSeek V4

DeepSeek publishes V4 as a mixed-precision checkpoint: FP4 for the MoE expert weights and FP8 for everything else. That brings V4-Pro to about 865GB on disk and V4-Flash to about 160GB. Size your cluster from those figures plus KV cache and activation memory. For live per-precision estimates and the cheapest matching GPUs, see the DeepSeek V4 VRAM requirements breakdown.

ConfigurationModelTotal VRAMWeights (native FP4+FP8)Fits?Notes
8x H200 SXM5V4-Pro1,128GB~865GBYesRecommended; ~260GB left for KV cache
8x B200V4-Pro1,536GB~865GBYesMost KV headroom on one node; native FP4
8x H100 SXM5V4-Pro640GB~865GBNoWeights alone exceed the node
2x H200 SXM5V4-Flash282GB~160GBYesRecommended; ~120GB left for KV cache
4x H100 SXM5V4-Flash320GB~160GBYesWorks; ~160GB left for KV cache
2x H100 SXM5V4-Flash160GB~160GBNoWeights fill the GPUs; no room for KV cache

VRAM math: do not size V4 as parameters times one byte. The native checkpoint stores expert weights in FP4, which is why V4-Pro is ~865GB rather than 1.6TB. Converting to pure FP8 roughly doubles the expert weights, so V4-Pro at FP8 is about 1.6TB and no longer fits a single 8x H200 node. Re-quantizing to 4-bit does not help either: real INT4 and GGUF Q4_K_M files land at about 0.6 bytes per parameter, roughly 960GB for V4-Pro and 170GB for V4-Flash, which is larger than the native checkpoint.

The active parameter count (49B for Pro, 13B for Flash) does not reduce VRAM. All expert weights must be loaded into GPU memory because the router selects different experts per token. You can't lazy-load experts without major latency spikes.

For hardware comparisons between H100 and H200, see H100 vs H200: which GPU for LLM inference. For a quick lookup of memory requirements across different models, see our GPU requirements cheat sheet 2026.

Step-by-Step Deployment with vLLM

Prerequisites

  • A recent vLLM release with DeepSeek V4 support (check the vLLM release notes for the minimum version)
  • CUDA 12.4+, Python 3.10+
  • Hugging Face account to download deepseek-ai/DeepSeek-V4-Pro or deepseek-ai/DeepSeek-V4-Flash
  • 8x H200 SXM5 or 8x B200 for V4-Pro; 2x H200 SXM5 or 4x H100 SXM5 for V4-Flash

Install vLLM

bash
pip install vllm  # installs latest; confirm the release notes list DeepSeek V4 support

Download Model Weights

bash
# V4-Pro: ~865GB
huggingface-cli download deepseek-ai/DeepSeek-V4-Pro --local-dir ./deepseek-v4-pro

# V4-Flash: ~160GB
huggingface-cli download deepseek-ai/DeepSeek-V4-Flash --local-dir ./deepseek-v4-flash

The V4-Pro download is about 865GB and V4-Flash about 160GB. Use a persistent storage volume so you don't re-download on instance restarts.

Launch V4-Pro on 8x H200 (Tensor Parallelism)

bash
vllm serve deepseek-ai/DeepSeek-V4-Pro \
  --tensor-parallel-size 8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --enable-chunked-prefill \
  --host 0.0.0.0 \
  --port 8000

This splits every transformer layer across all 8 GPUs simultaneously. All 8 GPUs participate in every forward pass, which minimizes time-to-first-token at the cost of higher NVLink bandwidth usage. vLLM picks up the checkpoint's FP4+FP8 quantization from the model config, so there is no precision flag to set.

For V4-Flash, use the same command with deepseek-ai/DeepSeek-V4-Flash and --tensor-parallel-size 2 on 2x H200, or --tensor-parallel-size 4 on 4x H100.

Launch with Mixed Expert and Tensor Parallelism

bash
vllm serve deepseek-ai/DeepSeek-V4-Pro \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --host 0.0.0.0 \
  --port 8000

--tensor-parallel-size splits attention layers across GPUs. --enable-expert-parallel activates expert parallelism, splitting the MoE expert layers across GPUs so each GPU holds a subset of whole experts and the router dispatches tokens to the GPU that holds the relevant expert. The EP size is auto-calculated from TP and DP sizes when this flag is enabled.

For DeepSeek V4's performance ceiling, the DeepEP and DeepGEMM deployment guide covers the kernel-level setup that takes expert parallelism from baseline NCCL to overlapped NVSHMEM dispatch.

When to use each:

  • Pure tensor parallelism: better for latency-sensitive serving; every expert is sharded across all GPUs, so all GPUs are always active
  • Mixed TP+EP: better for throughput-maximizing workloads where you can tolerate higher TTFT; whole experts live on one GPU, which trades the per-layer all-reduce on expert weights for all-to-all token dispatch

DeepSeek V4's native sparse attention architecture can be activated via the DSA backend: see the DSA inference guide for step-by-step configuration of --attention-backend dsa alongside expert parallelism.

Test the Endpoint

python
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-Pro",  # or deepseek-ai/DeepSeek-V4-Flash
    messages=[{"role": "user", "content": "Write a Python function to binary search a sorted list."}],
    max_tokens=512,
)
print(response.choices[0].message.content)

For full vLLM setup details including Docker deployment, monitoring, and load balancing, see the vLLM production deployment guide. For setting up an OpenAI-compatible API layer for self-hosted models, see the self-hosted OpenAI-compatible API guide.

Hardware Comparison: H200 vs B200 vs H100 vs A100

Throughput depends heavily on batch size, context length and parallelism layout, so benchmark your own traffic before committing. What decides the shortlist is whether the weights fit with room left for KV cache:

HardwareConfigV4-ProV4-FlashNotes
H200 SXM58xFits, ~260GB KV headroomFits with lots of roomDefault for V4-Pro on a single node
H200 SXM52xNoFits, ~120GB headroomDefault for V4-Flash
B2008xFits, ~670GB KV headroomOversizedNative FP4 tensor cores match the expert weight format
H100 SXM54x/8xNo (640GB max on one node)Fits on 4xUse for V4-Flash; V4-Pro needs a larger node
A100 SXM4 80GB8xNoFits on 4xNo hardware FP8 or FP4; expect the slowest path of the set

For V4-Pro, the choice is between 8x H200 and 8x B200. B200 adds headroom for long contexts and more concurrent sessions, and its Blackwell tensor cores handle FP4 natively, while H200 and H100 have no FP4 tensor cores. For V4-Flash, 2x H200 is the smallest footprint and 4x H100 is the alternative when H200 capacity is short. A100 lacks the Hopper Transformer Engine used for hardware-accelerated FP8, so it only makes sense if you already own the capacity.

For a detailed comparison of vLLM, TensorRT-LLM, and SGLang throughput numbers, see vLLM vs TensorRT-LLM vs SGLang benchmarks.

Spheron GPU Pricing for DeepSeek V4

Spheron rates for the configurations above, resolved from the live pricing API:

GPU ConfigRunsOn-Demand ($/hr)Spot ($/hr)
2x H200 SXM5V4-Flash$11.04/hr$6.70/hr
4x H100 SXM5V4-Flash$10.60/hr$8.80/hr
8x H200 SXM5V4-Pro$44.16/hr$26.80/hr
8x B200V4-Pro$81.36/hr$42.00/hr

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

Spot instances are viable for batch inference jobs: document processing pipelines, offline evaluation, or any workload where you can handle interruptions, since spot capacity can be reclaimed without notice. For real-time serving with SLA requirements, on-demand is the right choice.

Whether self-hosting beats a per-token API depends on your monthly token volume and context length distribution. For the full break-even model against DeepSeek's own endpoint, including data-privacy considerations, see the DeepSeek API pricing vs self-hosted comparison.

A third route sits between the two: Spheron's fixed-price inference plan serves DeepSeek V4.1 Flash, the successor to V4-Flash, through an OpenAI-compatible API at a monthly price fixed for the term, with no GPUs to run. Teams that need V4-Pro itself can ask about a Dedicated plan, which runs another open model on single-tenant nodes pinned to the EU or US.

For a full competitive pricing comparison across GPU cloud providers, see GPU cloud pricing comparison 2026.

Production Optimization

Precision: Stay on the Native Checkpoint

The native FP4+FP8 checkpoint is the right default for DeepSeek V4. It is the format DeepSeek released, so there is no conversion step and no extra quantization loss to test for. The alternatives all cost memory:

  • Pure FP8: roughly doubles the expert weights. V4-Pro grows to about 1.6TB, which no longer fits one 8x H200 node.
  • BF16: 2 bytes per parameter, about 3.2TB for V4-Pro and 570GB for V4-Flash. Only worth it for research that needs unquantized weights.
  • INT4 / GGUF Q4_K_M: about 0.6 bytes per parameter, roughly 960GB for V4-Pro and 170GB for V4-Flash. Both are larger than the native checkpoint, so re-quantizing saves nothing.

Quantization decision guide:

  • Native FP4+FP8 (default): V4-Pro on 8x H200 or 8x B200, V4-Flash on 2x H200 or 4x H100
  • FP8 or BF16: only when a toolchain can't read the mixed-precision checkpoint, and only with a multi-node budget for V4-Pro
  • 4-bit re-quantization: skip it for V4; the native checkpoint is already smaller

KV Cache Tuning

FP8 KV cache cuts memory usage by half compared to BF16 KV cache:

bash
vllm serve deepseek-ai/DeepSeek-V4-Pro \
  --tensor-parallel-size 8 \
  --kv-cache-dtype fp8_e5m2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

--max-model-len vs --gpu-memory-utilization tradeoff:

max-model-lenVRAM for KV cacheMax concurrent seqs (at max context)
65536HighLow
32768MediumMedium
16384LowHigh

For most applications, 32768 tokens is a practical ceiling. Both V4 models accept up to 1M tokens, but very few real requests use anything close to that, and reserving VRAM for a maximum context length you never use leaves fewer slots for concurrent users. On 8x H200 the ~260GB left after V4-Pro's weights is the budget every session shares.

For a deeper dive on PagedAttention, prefix caching, and CPU offloading, see the KV cache optimization guide.

Continuous Batching and Throughput

Enable chunked prefill for long-context requests:

bash
--enable-chunked-prefill

Tune maximum concurrent sequences for your latency target:

bash
--max-num-seqs 32   # lower = lower latency, higher = higher throughput

Monitor GPU utilization during load testing:

bash
nvidia-smi dmon -s u -d 5

Watch for GPU utilization below 70% on loaded instances: that usually means --max-num-seqs is too low and the GPU is waiting for more concurrent requests.

For additional throughput techniques including speculative decoding, see the speculative decoding production guide. For an additional 2-4x throughput gain on top of base expert-parallel serving, see draft-head speculative decoding for DeepSeek V4. For block-diffusion variants that pair well with vLLM on Blackwell GPUs, see our dFlash block-diffusion speculative decoding guide.

DeepSeek V4 vs V3 vs Llama 4 Maverick

ModelTotal ParamsActive ParamsContextBest For
DeepSeek V4-Pro1.6T49B1MCoding, agentic tasks, reasoning
DeepSeek V4-Flash284B13B1MCost-efficient serving on 2-4 GPUs
DeepSeek R2~685B\*~37B\*128K\*Math, logic, scientific reasoning
DeepSeek V3671B37B128KGeneral purpose, production-stable
Llama 4 Maverick400B17B1MLong-context, open weights

\*R2 figures are unconfirmed; see the R2 deployment guide linked below for the latest details.

Decision guidance:

Choose DeepSeek V4-Pro when coding quality and agentic reasoning are the primary requirements and you can dedicate a full 8x H200 or 8x B200 node to it.

Choose DeepSeek V4-Flash when you want a 1M-context DeepSeek model on a small footprint: 2x H200 or 4x H100, with 13B active parameters keeping per-token compute low.

Choose DeepSeek R2 when reasoning accuracy on math, logic, or science tasks is the priority over coding throughput. See the DeepSeek R2 deployment guide for hardware requirements and vLLM configuration specific to reasoning workloads.

Choose DeepSeek V3 if you want a more established model with a larger community of deployment guides, known quirks, and benchmarked configurations. V3 is production-stable; V4 is newer.

Choose Llama 4 Maverick when you prefer Meta's open-weights license or want a middle point between the two V4 models (17B active, against 49B for V4-Pro and 13B for V4-Flash).

For Llama 4 deployment steps, see Deploy Llama 4 on GPU cloud. For GPU hardware selection guidance, see Best GPU for AI inference 2026. Teams evaluating Alibaba's alternatives should note that Qwen3.7 Max is API-only, so it can be compared on quality through its API but not self-hosted on the same hardware.


DeepSeek V4-Pro needs a full 8x H200 or B200 node and V4-Flash runs on two H200s, and Spheron has both configurations on demand without you managing physical hardware. Spot capacity is available for batch workloads that can handle interruptions.

H100 SXM5 on Spheron → | Spheron B200 instances → | View all GPU pricing →

Deploy DeepSeek V4 on Spheron →

STEPS / 06

Quick Setup Guide

  1. Verify GPU hardware requirements for DeepSeek V4

    Pick the variant first. V4-Pro (1.6T total, 49B active) needs about 865GB for its native FP4+FP8 checkpoint, so plan on one 8x H200 or 8x B200 node. V4-Flash (284B total, 13B active) needs about 160GB, so 2x H200 or 4x H100 works. Size from the native checkpoint, not from parameter count times one byte.

  2. Provision a multi-GPU cluster on Spheron

    Log in to app.spheron.ai, select your GPU type (H200 SXM5 or B200 for V4-Pro, H200 or H100 SXM5 for V4-Flash), choose cluster size (2, 4 or 8 GPUs), and deploy an instance with NVLink or high-bandwidth interconnect enabled.

  3. Install vLLM and download the DeepSeek V4 weights

    On your GPU instance, install a recent vLLM release with DeepSeek V4 support (check the vLLM release notes) on CUDA 12.4+. Download the weights from Hugging Face: deepseek-ai/DeepSeek-V4-Pro (about 865GB) or deepseek-ai/DeepSeek-V4-Flash (about 160GB), to a persistent volume.

  4. Configure expert parallelism and tensor parallelism

    Set --tensor-parallel-size equal to your GPU count and use --enable-expert-parallel to activate expert parallelism for MoE layers. For V4-Pro on 8x H200, use tensor-parallel-size=8. For V4-Flash, use tensor-parallel-size=2 on 2x H200 or 4 on 4x H100.

  5. Launch the vLLM OpenAI-compatible server

    Run vllm serve with the V4-Pro or V4-Flash model ID, parallelism flags, and max-model-len tuned to your VRAM. vLLM reads the checkpoint's native FP4+FP8 quantization from the model config. The server exposes an OpenAI-compatible /v1/chat/completions endpoint.

  6. Tune for production throughput

    Benchmark with varying batch sizes and context lengths. Enable FP8 KV cache, set gpu-memory-utilization to 0.90, and adjust max-num-seqs based on your latency/throughput tradeoff. Monitor with nvidia-smi or DCGM.

FAQ / 05

Frequently Asked Questions

It depends on the variant. DeepSeek V4-Pro (1.6T total, 49B active) ships as a mixed FP4+FP8 checkpoint of about 865GB, so it fits one 8x H200 141GB node (1,128GB) or an 8x B200 node, but not 8x H100 80GB (640GB). DeepSeek V4-Flash (284B total, 13B active) is about 160GB on disk and fits 2x H200 (282GB) or 4x H100 (320GB). 2x H100 (160GB) is too tight once you add KV cache.

Expert parallelism splits the MoE expert layers across multiple GPUs, so each GPU holds a subset of experts. Combined with tensor parallelism for the attention layers, it lets you efficiently distribute a large MoE model like DeepSeek V4 across a GPU cluster without bottlenecking on expert routing.

DeepSeek V3 is a single 671B-parameter MoE with 37B active and a 128K context window. V4 ships as two open-weight models under the MIT license, both with a 1M-token context: V4-Pro at 1.6T total and 49B active, and V4-Flash at 284B total and 13B active. V4-Pro is larger than V3 in both total and active parameters, while V4-Flash is smaller than V3 on both counts and much cheaper to host.

No. The smallest variant, V4-Flash, has a native checkpoint of about 160GB, twice the 80GB on one H100, and even 2x H100 leaves no room for KV cache. Plan on 4x H100 or 2x H200 for V4-Flash. V4-Pro needs about 865GB for weights alone, so it runs on a full 8x H200 or 8x B200 node.

Yes, for batch inference and non-latency-sensitive workloads. On Spheron an 8x H200 node lists at $26.80/hr spot and $44.16/hr on-demand as of 15 Nov 2026. Spot capacity can be reclaimed without notice, so for real-time serving where uptime matters, on-demand or reserved capacity is more appropriate.

// Try It Yourself

Try It on Real GPUs

The GPUs behind these guides are the ones you can rent here: H100s, H200s, B200s, and more, billed per minute after a 20-minute minimum runtime, with no contracts. Pick one and you are live in under two minutes.

View Pricing
→
Or talk to our team
Spheron GPU instance going live and linking data centers across the globe