DeepSeek V4 Requirements: VRAM, GPU & API Pricing (2026)

To run DeepSeek V4 locally at a practical 4-bit quantization, plan on roughly 160GB of inference memory (VRAM + RAM combined) for V4-Flash (284B total) and about 920GB for V4-Pro (1.6T total). Only Flash is realistically within reach of a high-end workstation; Pro assumes server-class hardware equivalent to ten 80GB H100s. If local execution is not a hard requirement, the official API is remarkably cheap for this capability class: $0.28 per 1M output tokens for Flash and $0.87 for Pro.

This is a requirements reference based on the July 2026 general-availability release. For the April 2026 preview announcement, see our DeepSeek V4 Preview write-up.

Both are MoE (Mixture-of-Experts) models, so only a fraction of the parameters are active per token. For local inference, however, all expert weights must be resident in memory, which means memory requirements are driven by total parameters, not active ones. Active parameter count affects generation speed, not footprint.

The figures below take raw weight size (total parameters × bits ÷ 8) and add roughly 15% for KV cache, activations and other inference overhead, assuming an 8K context.

Community quantizations line up with these estimates: for V4-Pro, Q2_K-XL is reported at about 498GiB (needing 520GiB or more of headroom) and Q4_K_M-XL at about 828GiB (needing 870GiB or more).

The table above assumes an 8K context. Actually using V4's headline 1M-token context is reported to add 50GB or more of KV cache. In other words, running V4-Flash at 4-bit with long context means budgeting 210GB or more rather than 160GB.

Because KV cache scales with input length, a practical deployment switches to long context only when needed rather than running at 1M by default. If long context is the primary use case, the API is usually the better answer on both cost and operations.

Quantization reduces the number of bits used to represent each weight, shrinking the memory footprint. Dropping from BF16 (16-bit) to 4-bit cuts weight size to roughly a quarter. Accuracy degrades in exchange, but at 4-bit the loss is minor for most practical tasks. Below 3-bit the drop in output quality becomes clearly noticeable, so stay at 3-bit or above when quality matters.

MoE models offer one more lever: offloading routed expert weights to CPU memory (the -cmoe style option in llama.cpp). Generation slows down, but it turns "does not fit" into "runs, slowly" — often the difference between a usable and unusable setup.

An important caveat as of July 2026: V4 architecture support is not yet in upstream llama.cpp (ggml-org/llama.cpp). The GGUF quantizations being distributed load only in V4-aware forks and fail on upstream binaries. Check which fork and branch the model card specifies before you start.

For server deployments, vLLM and SGLang are the usual choices. Supported backends are Apple Silicon (Metal), NVIDIA CUDA (Ada / Blackwell), and CPU.

Apple Silicon treats unified memory as inference memory, so a large-memory Mac Studio brings V4-Flash into range: ~160GB at 4-bit fits comfortably in a 512GB configuration, with room for KV cache even at long context. V4-Pro, at ~920GB even at 4-bit, is not viable on a single Mac at any quantization.

On a 128GB Mac, 3-bit (~122GB) is the theoretical edge. After the OS and other applications, stable operation is unlikely in practice — expect to drop to 2-bit or combine with CPU expert offload.

A single 24–32GB consumer GPU cannot hold V4 at any quantization. On that class of hardware, either pick a smaller model such as Gemma 4 or use V4 through the official API. Our VRAM calculator can check what your current GPU can handle.

The striking number is the cache-hit input rate — between 1/50th and 1/120th of the cache-miss rate. For workloads that repeatedly send the same system prompt or the same long document (internal document QA, codebase analysis), designing prompts for prefix reuse translates directly into cost savings.

The API accepts both OpenAI ChatCompletions-compatible and Anthropic-style requests, so existing clients can often be pointed at it by changing the endpoint.

Alongside the GA release, reporting indicates DeepSeek is introducing time-based pricing: 9:00–12:00 and 14:00–18:00 daily are peak hours billed at twice the off-peak rate. That is unusual among major AI APIs and would make scheduling batch work outside those windows worthwhile.

As of this writing (July 21, 2026), however, the official pricing documentation lists only the flat rates above, with no time-based tiers. Confirm the current state — including which timezone the windows are defined in — against the official docs before building it into a batch schedule.

This is the most urgent item for existing DeepSeek API users. The legacy model IDs deepseek-chat and deepseek-reasoner are fully retired after July 24, 2026, 15:59 UTC and become inaccessible. If you have not switched by then, production API calls will start failing at that moment.

Three practical checks when migrating. First, find every hardcoded model ID (moving them to environment variables pays off next time). Second, adapt to reasoning being selected by Thinking / Non-Thinking mode rather than by choosing a different model. Third, revisit cost estimates and timeout settings, since both token pricing and maximum output (384K) have changed.

At this model class, the reason to run locally is almost entirely keeping data in-house, not performance. With output priced at $0.28–$0.87 per 1M tokens, racking H100s to save money does not pencil out.

So the decision is simple: if confidential data cannot leave your environment, evaluate V4-Flash on-premise (4-bit, ~160GB class); otherwise use the API. Smaller organizations considering on-premise LLMs should first check whether requirements can be met at Flash class or below rather than reaching for a frontier model like Pro.

- Fails to load / OOM: Drop one quantization step (4-bit → 3-bit) first, then add CPU expert offload if still short
- GGUF will not load: Upstream llama.cpp lacks V4 support — use the fork named on the model card
- Crashes once you send long input: KV cache exhaustion. Lower the context limit (1M → 128K)
- Extremely slow: Too much CPU offload. A smaller quantization that fits in VRAM is often faster
- Poor output quality: You may be at 2-bit or below. Move back to 3-bit or higher and compare

The open-weight frontier in July 2026 is Kimi K3 (2.8T), GLM-5.2 (753B), Inkling (975B), and DeepSeek V4 (1.6T / 284B). What sets V4 apart is shipping two sizes under MIT — a frontier-class Pro and a Flash that is actually runnable locally.

At ~160GB for 4-bit, the 284B Flash is meaningfully more accessible than the others, all of which demand several hundred gigabytes to a terabyte. If your requirement is running open weights inside your own environment, it is often the first candidate worth testing.

- Models & Pricing (DeepSeek API Docs)
- DeepSeek V4 Preview Release (DeepSeek API Docs, April 24, 2026)
- DeepSeek to launch V4 in mid-July with new peak-time API pricing (TechNode, June 30, 2026)