Data Center GPUs by Memory Capacity: Compare the Exact Variant

Set the comparison boundary before calling a GPU the largest

This is a selected comparison of vendor-published data center GPU memory specifications checked on October 15, 2026. It answers a specific question: how much local GPU memory does the named variant list? It does not rank every accelerator on the market, establish which product is most popular or choose the fastest GPU for an application. The table retains the manufacturer's GB labels and memory types; it does not silently convert them into a measured application allocation.

The selection includes AMD Instinct OAM modules and named NVIDIA data center configurations. RTX PRO 6000 is explicitly the Blackwell Server Edition, not a shorthand for every workstation card. Consumer GeForce products, modified cards, CPU RAM, host-memory expansion and non-GPU accelerators are outside this table. Those products can be useful, but adding them without their own support, form-factor and workload boundaries would make a data center comparison less precise.

Treat each row as a specification reference. A product page establishes a documented product; it does not establish an OEM's stock, a cloud provider's inventory, a delivery date or compatibility with your existing server.

References: [N4]

Compare selected documented variants by published memory capacity

The rows below are ordered by the cited capacity figure, with ties kept explicit. The two Blackwell Ultra rows deliberately retain their system-column names. Quoting one unqualified B300 number would hide a distinction that NVIDIA's current datasheet makes.

The OAM entries describe accelerator modules in a supported server platform, not interchangeable PCIe add-in cards. Likewise, an SXM or HGX label is not permission to fit a GPU into another generation's chassis. The memory figure is a shortlist input; obtain the complete OEM system identifier before turning it into an installation or purchase requirement.

References: [A1][A2][A3][A4][N1][N2][N4]

Resolve architecture and system numbers without inventing an explanation

NVIDIA's Blackwell Ultra architecture article describes a maximum of 288 GB and explicitly says available HBM capacity varies by SKU. Its current Blackwell Ultra datasheet lists 279 GB and 270 GB in the individual-GPU rows for two different system columns. These are different source scopes. Use the figure belonging to the product you are evaluating, and attach its document edition to the comparison.

Do not explain the numerical difference as ECC overhead, a GB-to-GiB conversion or a particular reserved-memory mechanism unless the applicable product documentation establishes that explanation. The arithmetic alone cannot tell you why the figures differ. The same discipline applies when a Blackwell architecture headline and a B200 system specification show different capacities.

A useful vendor clarification is concrete: which full system SKU and revision are you quoting, what GPU-local capacity does its specification promise, and what total should the supported runtime report? That question is more useful than asking the seller whether its GPU has the internet's most frequently repeated number.

References: [N1][N2][N3]

Keep newer platform specifications separate from delivery evidence

AMD publishes 432 GB HBM4 for MI455X in its MI400-series material. NVIDIA publishes 288 GB HBM4 per Rubin GPU on the Vera Rubin NVL72 product page. These newer-platform specifications belong in a current research shortlist, but they do not establish that a buyer can obtain the required OEM system in a particular country, quantity or project window.

AMD describes Helios as a reference design for partners, rather than a finished AMD system for sale. Its stated deployment timetable is a vendor expectation, not a verified delivery commitment for your project. For both platforms, ask the actual supplier to identify the complete offered system, release state, qualification status, supported software and delivery conditions. A sales-contact button or a date on a roadmap does not close those questions.

The highest published capacity in this guide's selected examples is MI455X's 432 GB. That is a statement about the cited specification set. It is not a claim that MI455X is the largest GPU ever made, generally available in every region or the best choice for every workload.

References: [A5][N5]

Do not turn a server or rack total into one GPU

NVIDIA's cited HGX reference table gives H200 SXM 141 GB per GPU. Eight times that capacity is 1,128 GB across eight GPUs. That multiplication tells you the aggregate installed capacity in the named configuration. It does not turn the node into a single 1,128 GB GPU or establish how an application partitions its data.

The Vera Rubin page makes the hierarchy especially clear: its table separately lists 288 GB of HBM4 for one Rubin GPU, 576 GB for a two-GPU superchip and 20.7 TB for the 72-GPU rack. The same page lists Vera CPU memory separately. Do not relabel a combined fast-memory or CPU-plus-GPU total as GPU VRAM.

For a buyer's comparison, retain three fields: local memory per GPU, GPU count and aggregate GPU memory. Keep host CPU memory in a fourth field. Then ask the software owner how the intended job uses multiple devices. A large aggregate can be relevant, but the allocation and communication model still needs confirmation for that workload.

References: [N1][N5]

Distinguish published capacity, assigned memory and free memory

A published capacity figure is not a promise that the entire amount is free for one process. NVIDIA's nvidia-smi documentation distinguishes total, reserved, used and free frame-buffer memory. It also notes that reporting can depend on ECC state and that the driver may reserve some memory internally. These are reasons to record the actual supported configuration and observed figures, not reasons to subtract an invented universal percentage from every GPU.

A shared or partitioned offering adds another boundary. Confirm whether the service provides a complete physical GPU or an assigned instance/profile, and record the memory exposed to that allocation. The physical device's headline capacity is not automatically the tenant's entitlement. This guide does not prescribe a partition configuration or establish that every listed product exposes the same features.

Ask the workload owner to define the memory needed by the actual software and request profile. The answer should cover the selected model or dataset, precision, context/concurrency where applicable, runtime buffers and the intended operating margin. Keep the measured requirement separate from the product's advertised total, and retain the test configuration with the result.

References: [N6][N3]

Use memory to build a shortlist, then test the actual job

Hypothetical screening example: the software team records a need for 120 GB on each complete GPU allocation before applying its separately agreed operating margin. An 80 GB or 96 GB allocation fails that stated single-device capacity screen. A published 141 GB device passes the headline-capacity screen, but the team still has to confirm the actual allocation and free-memory behavior. Passing this screen does not establish that the application is supported, meets its latency target or leaves enough margin.

For a speed comparison, require a named workload, precision, software versions, batch or concurrency settings, hardware configuration and a measured outcome. Memory capacity is the amount the named device lists; memory bandwidth is a different specification. Neither is itself an end-to-end tokens-per-second result. A larger-capacity product can solve a fit constraint without establishing the fastest implementation for the buyer's job.

Record why a device was excluded: insufficient local memory, unsupported software, unsuitable system, unconfirmed delivery or an unmet measured target. That makes the shortlist auditable and avoids turning one attractive specification into a recommendation that has never been tested.

Close the system and site handoff after the hardware choice

Before the selection becomes an installation request, collect the exact OEM server or rack model, GPU variant and count, supported configuration, relevant document revisions and a named owner for software acceptance. The physical plan then needs its own approved rack layout, equipment interfaces, cable schedule, facility permissions and handoff criteria. More memory does not establish a site's power, cooling, access or support compatibility.

Use the existing server-comparison guide to organize OEM evidence, and the cloud-capacity guide when you are evaluating rented compute rather than buying equipment. If the project requires physical installation of customer-furnished equipment, Leviathan can discuss an agreed rack-and-stack and cabling scope at customer facilities. This comparison is not a quotation or a stock-availability statement. Identify the equipment supplier and delivery responsibilities in the project scope. Workload benchmarking and cloud provisioning are outside the physical installation package. Electrical, cooling and system commissioning responsibilities must remain with the project's appointed qualified owners.

References: [L1]