Can a single GB200 NVL72 serve DeepSeek R1 in full precision, and what throughput should I expect?

Teams planning to serve DeepSeek R1 without quantization often ask whether a single GB200 NVL72 rack has the memory to hold it in full precision, and what throughput that would deliver. The rack is designed for exactly this class of problem, but the answer is a calculation, not a yes-or-no, because full-precision feasibility depends on the model's total memory footprint against the rack's pooled memory. A GB200 NVL72 pools 72 GPUs into a single high-bandwidth memory domain, which makes serving a large MoE model like DeepSeek R1 in full precision feasible when the model's total weight and KV cache footprint fits within the rack's aggregate memory, and the throughput you should expect is set by your concurrency and serving stack, not a fixed figure. This guide shows how to confirm the fit and how to form a realistic throughput expectation.

Full precision is a memory-fit question against the whole rack

Serving in full precision means holding the model's weights at FP16 or BF16 with no quantization, which is the largest possible memory footprint. For a large MoE model, that footprint is driven by the total parameter count, since all experts must be resident, plus the KV cache for active requests.

The rack's advantage is that you do not size against one GPU. Because a GB200 NVL72 presents 72 GPUs as one pooled NVLink domain, the full-precision fit for DeepSeek R1 is judged against the rack's aggregate memory rather than a single card, so a model that could never fit one GPU at full precision can be feasible across the pooled domain. This is the whole point of a rack-scale system for large models: the model shards across many GPUs, but the high-bandwidth NVLink domain lets them act as one large memory space without the network penalty a loose cluster would pay. To confirm the fit, compare the model's full-precision weight footprint plus KV cache against the rack's total memory, and leave headroom for the cache to grow with concurrency.

What throughput to actually expect

Throughput on a rack is not a single published number, because it moves with the same inputs that govern any serving deployment. Setting an expectation means naming those inputs rather than quoting a figure.

Three factors shape what you will see. Concurrency determines how much work the rack does in parallel, and a large MoE served at full precision on a pooled domain can sustain high concurrency when memory allows large batches. Sequence length expands the KV cache and lowers per-request throughput as it grows. And the serving stack, including how well it exploits the NVLink domain and MoE routing, can move real throughput significantly. Treat any headline tokens-per-second figure for R1 on NVL72 as directional until you measure it, because it was produced under a specific concurrency, sequence length, and stack that may not match yours. The reliable expectation is the one your own benchmark produces on the rack at your serving settings.

Confirming full-precision R1 on NVL72

Use the frame below to move from question to confirmed plan.

Step	What to check	Why it matters
Weight footprint	Full-precision total weights of R1	Sets the base memory demand
KV cache budget	Cache at your concurrency and context	Adds to weights; grows with load
Rack memory fit	Footprint plus cache vs rack aggregate	Confirms full precision is feasible
Throughput test	Measured tokens/sec at your settings	Replaces an assumed figure with a real one

The pattern is consistent: full-precision feasibility is a fit calculation against the rack's pooled memory, and throughput is a measurement at your serving settings. Both are answerable with certainty only on the hardware, which is why the last step is a benchmark rather than a spec-sheet lookup.

Serving full-precision R1 on GMI

Since the fit and throughput are confirmed by measurement, the practical step is using our platform, which carries GB200 NVL72 so you can test full-precision R1 on the pooled domain. We are an AI-native GPU and inference cloud that publishes dedicated NVIDIA GPU list pricing and lists GB200 NVL72.

We currently list GB200 NVL72 at from $8.00 per GPU-hour Available Now, so you can serve DeepSeek R1 in full precision across the rack's pooled 72-GPU memory domain, confirm the footprint fits, and measure real throughput at your concurrency rather than relying on a published figure. Verify the current rate and rack availability on our GPU infrastructure (https://www.gmicloud.ai/en/gpus) and pricing (https://www.gmicloud.ai/en/pricing), since Blackwell pricing and stock move quickly, and confirm rack quantity and region rather than assuming elastic supply. Benchmark at your production concurrency and sequence length, because those decide both whether the KV cache fits alongside full-precision weights and what throughput you get. When the workload is sustained R1 serving, our Prime Inference (https://www.gmicloud.ai/en/models/prime-inference) provides reserved GPU capacity with single-tenant isolation and warm, weights-preloaded serving, which keeps R1's expert weights resident for lower routing latency. Start on the console (https://console.gmicloud.ai) or contact our sales team.

Confirm the fit, then measure the throughput

If you assume a single GB200 NVL72 serves DeepSeek R1 in full precision, or accept a throughput number you did not measure, you risk a KV cache that does not fit at your concurrency or an expectation your traffic never meets. Do it in order: compare R1's full-precision weight and cache footprint against the rack's pooled memory to confirm feasibility, leave headroom for the cache to grow, then benchmark throughput at your real concurrency and sequence length. The NVL72's pooled domain is what makes full-precision large-MoE serving feasible on one rack, but the fit and the throughput are yours to confirm on the hardware, not to assume from a datasheet.