Exact VRAM memory allocation, dynamic KV-cache requirements, and tensor parallelism slicing for DeepSeek-R1 Reasoning 671B quantized in FP16 Uncompressed Native deployed on NVIDIA H100 80GB SXM5.
The weights are the same size. R1 needs more cache and GPU time per answer because its chains of thought are long, so budget for output length and concurrency.
FP8 weights are 671 GB, which suits one 8 × H200 node or two 8 × H100 nodes. 4-bit builds of roughly 340–380 GB fit one 8 × H100 node.
No. They are Qwen 2.5 and Llama models fine-tuned on R1's outputs, from 1.5B to 70B parameters. They are far cheaper to run but less capable than the full 671B model.
DeepSeek-R1 (January 2025, MIT licence) is a reasoning model: before it answers, it writes out a long chain of thought, and that visible "thinking" is what made it notable. It was trained from the DeepSeek-V3 base model with large-scale reinforcement learning, so its architecture and size are identical to V3: 671B total parameters, about 37B active per token, 61 layers, Multi-head Latent Attention, and a 128K-token context window. DeepSeek later published an updated checkpoint, R1-0528, with the same shape. Alongside R1 it released six much smaller "distilled" models (1.5B, 7B, 14B and 32B based on Qwen 2.5, and 8B and 70B based on Llama) that imitate R1's reasoning style.
For hardware planning the important difference from V3 is not the weights but the length of the outputs. A single R1 answer to a maths or coding question routinely runs to thousands of tokens of reasoning, and DeepSeek's own evaluations allowed up to 32,768 generated tokens. Every one of those tokens adds to the KV cache and occupies the GPU for a decoding step.
This page uses the same estimator as the other model pages on the site: weight memory is parameters times bytes per parameter; KV cache is context length × concurrent requests × a per-token figure that the calculator scales from a 70B reference (0.5 MB per token at 16-bit, half that at 8-bit or below); and a flat 1.8 GB covers the CUDA context and framework. The GPU count divides the total by 92% of one card's memory.
The per-token KV figure is where R1 needs care. The scaling rule assigns 671B parameters about 4.8 MB per token. R1's latent attention actually caches 576 numbers per layer per token, about 69 KiB in BF16. If you run R1 on an engine that supports MLA properly, the true cache is a small fraction of the calculator's number, which is why the long reasoning traces are affordable at all.
Defaults: 671B parameters, 16-bit precision, 8,192-token window, 2 concurrent requests, 80 GB GPUs.
An 8,192-token window is short for a reasoning model. Set the context to 32,768 with one request at FP8 and the calculator gives 671 GB of weights plus 76.7 GB of cache, 749.5 GB in total, or 11 H100s. With MLA sizing the cache for that request is closer to 2.3 GB. The gap shows how much the choice of estimator matters for long generations.
| Option | Approximate memory | Typical hardware |
|---|---|---|
| R1 FP8 (as released) | 671 GB weights + cache | One 8 × H200 node, or two 8 × H100 nodes |
| R1 community 4-bit | about 340–380 GB weights | One 8 × H100 node; large-RAM CPU offload for slow local use |
| R1-Distill-Llama-70B, BF16 | 140 GB weights | 2–4 × 80 GB GPUs |
| R1-Distill-Qwen-32B, 4-bit | about 17–20 GB weights | One 24 GB consumer GPU |
| R1-Distill-Qwen-7B, BF16 | about 15 GB weights | One 24 GB GPU |
Weights in this table are parameter count times bytes per parameter; 4-bit formats carry some extra scale data, so real files are slightly larger. If you want the full R1 behaviour, plan for FP8 on H200-class memory. If you mostly need "think step by step" quality on a budget, the distilled models change the problem from a multi-node cluster to a single card, at a real cost in capability that you should measure on your own prompts.