What R1’s shape means for cost
DeepSeek R1 is 685B total parameters with 37B active per token. That gap between total and active params drives every cost decision below. You pay compute for 37B active params per forward pass, but VRAM for all 685B, because every expert needs to sit in memory even when most of them stay idle on a given token.
At roughly 1.1GB per billion params in FP8, weights alone run near 750GB. Add the standard 25% KV headroom and you’re near 950GB before you’ve served a single long reasoning trace. Drop to INT4 and base weight footprint falls to around 375GB, closer to 470GB with headroom. Run your own context length and concurrency assumptions through the calculator rather than trusting this rule of thumb blind. MoE memory scaling and MoE compute scaling are two different curves, and the calculator separates them; a back-of-envelope estimate using only total params will oversize your compute and undersize your memory.
Three paths, priced against each other
API. Someone else already amortizes the cluster across thousands of concurrent requests. This wins by default at low-to-moderate volume because you can’t replicate that pooling efficiency alone. Check the DeepSeek R1 model page directly rather than assuming a flat per-token rate: this site tracks rows across every provider serving R1, and they are not close to each other.
Managed/serverless. A dedicated deployment without the self-management. Sits between API and self-hosting on cost in most cases, but the gap depends entirely on your traffic shape. If your load is bursty, the value here is avoiding idle-GPU cost between spikes, not avoiding markup.
Self-hosted rental. You provision the memory to hold weights plus KV cache and run vLLM or SGLang across multiple cards. Only wins at sustained, near-continuous utilization, because idle GPU-hours are the same price as busy ones.
For self-hosting math: H200 at 141GB per card clears full FP8 R1 with 8 GPUs and real headroom left for context. H100 SXM at 80GB needs 10 GPUs just to cover the 750GB weight footprint, which is too tight once you add KV cache for R1’s actual reasoning-trace output lengths. This is where naive sizing from smaller dense models breaks, because R1 generates much longer intermediate output than its parameter count alone implies. B200 at 180GB per card gets you to full FP8 capacity in six cards instead of eight, trading GPU count for interconnect and power complexity.
The distillation trap
Common advice treats “R1 Distill” models as a cheap way to get R1’s reasoning at a fraction of the footprint. They are not the same model. DeepSeek R1 Distill Qwen 32B and DeepSeek R1 Distill Llama 70B are dense Llama and Qwen checkpoints fine-tuned on R1’s traces, not the 685B MoE. The 32B distill fits on a single 80GB card. Full R1 needs the multi-GPU footprint above regardless of quantization choices.
The failure mode: a team benchmarks the distill, likes the output on easy cases, and provisions distill-level infrastructure for R1-class problems. It underperforms exactly where reasoning depth matters most, and that gap only shows up once real, hard queries hit production. Compare the R1 page against the distill page for your actual eval set before deciding which model, not just which infrastructure, you need.
Why provider choice matters more than architecture choice
As of this writing, spreads between the cheapest and priciest provider for the same open model exceed 20x on this site for models like Llama 4 Maverick, Qwen3 235B A22B, and GPT-OSS 120B. R1’s own spread moves independently day to day, which is exactly why picking the first API result you find is a bigger cost risk than picking API over self-hosting in general. Check the live spread on the R1 model page before committing to a provider.
If you self-host, the same logic applies to GPU tier. Marketplace and community tiers on cards like H200 NVL and MI300X have been running 70%+ below secure/dedicated tier pricing. That discount can make self-hosting viable at lower sustained volume than secure-tier pricing would suggest, provided you can tolerate the reliability tradeoffs of non-dedicated capacity.
Decision rule
Check the current spread on the R1 model page first. If it’s wide (which it usually is for MoE models this size), don’t anchor to any single provider’s quoted rate before comparing at least three.
Then apply this: if your sustained R1 traffic would keep a full 6-8 GPU node busy around the clock, price H200 or B200 nodes, including marketplace tiers, on /gpus and run your concurrency and context assumptions through the calculator. If that self-hosted cost, at marketplace pricing, undercuts your cheapest API quote from the R1 page, self-host. If your traffic is spikier or smaller than that, stay on API or managed and let the spread-shopping do the savings work instead.
Before either path, confirm your evals actually require full R1’s reasoning depth and not just R1-style output. If a distill scores acceptably on your real workload, you’ve just cut your infrastructure requirement by roughly an order of magnitude, not a percentage, and the entire cost comparison above becomes moot.