In this article
HGX B300 publishes 288 GB HBM3e per GPU. Physical capacity, partition profiles and a multi-GPU node total describe different resource budgets.
Start with the HGX B300 configuration
The checked NVIDIA reference architecture identifies 288 GB HBM3e per B300 in an HGX server. That figure describes a datacenter accelerator configuration, not a similarly named desktop RTX product. Record the platform and installed accelerator identity rather than shortening every Blackwell Ultra system to one generic specification. A node can contain several such devices, but aggregate HBM is not automatically usable by one process. The server and its connection topology remain necessary parts of any claim about a model spanning the node.
| Variant | Local memory, GB | Memory type | Published board power, W |
|---|---|---|---|
| HGX B300 physical capacity | 288 | HBM3e | Not verified |
The product or OEM specification establishes the configuration: manufacturer source.
Validate the exact architecture target
An inference package must include support for the installed Blackwell Ultra architecture and the selected execution route. Do not assume that passing an older accelerator’s minimum capability test proves this. Preserve driver, runtime, framework and serving engine versions, then test the intended checkpoint and numerical format. Correctness and kernel selection should be checked before concurrency is increased. If compilation or a fallback implementation is required, report it explicitly so the result can be reproduced rather than compared with an undocumented optimised configuration.
The software boundary is documented in the inference compatibility reference.
Do not equate a MIG profile with physical HBM
The MIG documentation uses allocation profiles whose memory figures can be smaller than the published physical 288 GB capacity. Those are different descriptions, not a reason to silently overwrite one number with the other. Record the chosen profile and framework-visible allocation. For inference, reserve space for weights, caches and runtime workspaces within that actual budget. A full-device result and a partition result must be labelled separately. Neither should be multiplied by the number of GPUs and presented as one device’s available memory.
Keep graphics-engine eligibility independent
Shared architecture branding does not make an HGX B300 a workstation graphics card. Cycles rendering needs a compatible current driver and device backend, followed by a real scene test. Check material support, image output, geometry expansion and peak allocations. Do not infer dedicated RTX ray-tracing features or display functionality from an AI accelerator specification. Rendering throughput cannot be derived from advertised AI arithmetic figures. Where another engine is considered, use that vendor’s current support matrix and keep its result separate from a Blender assessment.
Renderer requirements are separate in the Cycles GPU manual.
Report a complete platform result
Cooling, power delivery, OEM firmware and the host/network arrangement are prerequisites for an operational HGX B300 deployment. A useful benchmark fixes the service objective and request distribution, then records completed output, failures and tail latency over sustained work. Include restart recovery and the actual visible capacity. Avoid converting memory growth into a promised speedup or income estimate. This public profile describes evaluation of a platform and does not claim that Retrivium currently operates B300 servers or that marketplace provider approval has been completed.
Related reading: RAM and VRAM and a reproducible inference benchmark. GPU catalogue records the scope, model variants and unresolved specifications.