In this article
The checked HGX reference architecture specifies 180 GB usable HBM3e per B200. Nominal capacity, MIG profiles and node totals must remain distinct.
Use the capacity defined by the platform document
NVIDIA’s HGX reference architecture records 180 GB usable memory per B200 accelerator. Other documents may use nominal capacity or describe a different Blackwell platform; choosing the largest number across those tables creates an unreliable inventory. This guide uses the explicit HGX usable figure. Preserve the server identity and memory-reporting context with it. An eight-device node has an aggregate total, but that sum is not a local allocation on one GPU or proof that any model can run without distributed execution.
| Variant | Local memory, GB | Memory type | Published board power, W |
|---|---|---|---|
| HGX B200 usable memory | 180 | HBM3e | Not verified |
The product or OEM specification establishes the configuration: manufacturer source.
Require a Blackwell-capable inference build
A package that works on an older CUDA accelerator is not automatically a suitable Blackwell build. Verify architecture targets, runtime, driver and the serving engine’s supported installation route together. Test the selected model format and attention path, including correctness against a reference. New numerical formats are not enabled merely by loading a checkpoint with a familiar filename. Record fallback kernels and compilation steps. A broad minimum compute-capability statement is an initial hardware condition, not confirmation that an old binary contains every required Blackwell implementation.
The software boundary is documented in the inference compatibility reference.
Distinguish physical packaging from process devices
Datacenter Blackwell combines dies within a GPU design, but die count is not a reason to double the published per-GPU memory figure. Device enumeration, framework-visible GPUs and model-parallel ranks should be recorded from the actual server. This is different from a multi-GPU board whose independent GPUs each own a smaller memory pool. When MIG is used, inspect its documented memory profiles and the allocation visible inside the partition. Do not replace that smaller budget with the whole accelerator or node capacity.
Assess rendering without a desktop-card analogy
B200 is an HGX compute-platform accelerator, not an RTX desktop product. A current Cycles backend and compatible driver must recognise the device before rendering can be evaluated. Check scene features, output and memory peaks using the actual headless configuration. A large HBM allocation is useful only if the engine can use it through a supported path. Do not promise RTX-specific ray-tracing hardware or interactive graphics behaviour from the shared Blackwell architecture name. Another renderer needs its own device support evidence.
Renderer requirements are separate in the Cycles GPU manual.
Keep a reproducible HGX acceptance record
A practical B200 assessment includes the qualified HGX server, firmware, network topology, power configuration and thermal system. Compare inference at fixed request limits, including tail latency, failures and recovery after restart. Retain the usable memory value actually reported under that configuration. Peak vendor specifications do not provide token throughput or deployment economics by themselves. The catalogue explains public platform boundaries; it does not announce B200 stock at Retrivium or imply that a provider endpoint is already available through OpenRouter.
Related reading: RAM and VRAM and a reproducible inference benchmark. GPU catalogue records the scope, model variants and unresolved specifications.