BetterSWE DigestWhat is BetterSWE?

Deep Dive · Issue 23

How ECC Memory Silently Steals GPU VRAM

An 80 GB A100 only gives you 70 GB. The missing 10 GB is parity bits you can never use.

A100 GPU with HBM stacks, data and parity blocks

The hidden tax

Your 80 GB GPU Has 70 GB of Usable Memory

A100 GPU with HBM stacks, data and parity blocks

An NVIDIA A100 advertises 80 GB of HBM2e. When you partition it into its maximum 7 MIG instances, each one gets 10 GB, totaling 70 GB. The remaining 10 GB is not available to any workload.

That missing slice is the cost of ECC memory, the error-correcting code that every datacenter GPU enables by default on its VRAM. The parity bits live in the same physical memory arrays as your data, and the advertised capacity counts them.

The advertised 80 GB splits into 70 GB you can use and 10 GB of parity you cannot.

The mechanism

Eight Parity Bits Per Word, Stored in Your VRAM

72-bit memory word: 64 data bits + 8 ECC parity bits

ECC memory stores 8 extra bits for every 64-bit data word, bringing the physical storage to 72 bits per word. Those 8 bits hold a SECDED Hamming code that can correct any single-bit error and detect double-bit errors.

overhead=864=12.5%\text{overhead} = \frac{8}{64} = 12.5\%
ECC parity overhead per 64-bit word

The memory controller recalculates the checksum on every read and corrects single-bit errors inline, with no performance penalty. Double-bit errors are detected but not corrected; the controller signals an uncorrectable error and typically halts the process.

How SECDED correction works

SECDED (Single Error Correction, Double Error Detection) uses an extended Hamming code. The 8 parity bits are computed from the 64 data bits using XOR operations across specific bit positions. On every read, the controller recomputes the checksum and compares it to the stored parity. A mismatch in one parity bit points to a specific bit position; the controller flips that bit and returns corrected data. If two bits disagree, the controller detects the error but cannot identify which two bits flipped, so it signals an uncorrectable error.

HBM uses the same SECDED code family for its mandatory ECC. The parity bits occupy physical memory cells that could otherwise store user data, which is why 12.5% of your VRAM holds checksums instead of model weights.

The evidence

MIG Partitions Expose the Missing 12.5%

A100 80GB partitioned into 7 MIG instances of 10GB each

The A100 datasheet lists two configurations: 40 GB HBM2 with up to 7 MIGs at 5 GB each, and 80 GB HBM2e with up to 7 MIGs at 10 GB each. The 40 GB card partitions into 35 GB; the 80 GB card into 70 GB. Both leave exactly 12.5% unallocated.

Both A100 variants leave a 12.5% gap that matches the ECC parity ratio. The gap could also include CUDA context or driver reservations, but the exact match to 8/64 is a strong signal.

NVIDIA does not explicitly attribute this gap to ECC. CUDA context, driver overhead, and BAR reservations also consume VRAM. But the ratio matches the ECC overhead precisely, and the gap scales linearly with capacity, which driver reservations typically do not.

No opt-out

HBM Makes ECC Mandatory, GeForce Gets a Pass

Datacenter GPU with ECC vs consumer GPU without

HBM builds ECC into the specification as mandatory, with no option to disable it. DDR and GDDR treat ECC as optional, on in servers and off on consumer cards.

Every HBM-based GPU, from the A100 to the H100 and H200, pays this overhead. Consumer GeForce cards like the RTX 5090 do not enable ECC on their VRAM, so a 24 GB card delivers close to 24 GB usable.

Datacenter HBM (ECC mandatory, ~12.5% overhead)

Consumer GDDR (ECC off, full capacity)

The cost is capacity, not bandwidth. The A100 80GB SXM delivers 2,039 GB/s, and ECC correction happens inline in the memory controller on every read with no penalty.

Google's fleet study measured roughly one correctable bit error per GB of RAM per year. On an 80 GB card, that is dozens of silent corrections annually.

The bottom line

The Capacity You See Is Not the Capacity You Get

Why it matters

The spec sheet says 80 GB. The GPU gives you 70. The missing 10 GB is ECC parity, stored in the same HBM arrays as your data and counted in the advertised total. Google's fleet data measured roughly one correctable bit error per GB of RAM per year, so on an 80 GB card that is dozens of silent corrections annually. The protection justifies the cost, but the cost is never stated, and the parity bits are counted in the number on the box.

The short version

  • ECC on datacenter GPU VRAM stores **8 parity bits per 64-bit word**, a **12.5% capacity overhead** with no bandwidth penalty.
  • An A100 80GB delivers **~70 GB usable**; the gap is visible in MIG partition sizes (7 × 10 GB = 70 GB).
  • HBM makes ECC **mandatory** with no opt-out; consumer GeForce cards do not enable it, so they deliver close to full advertised capacity.
  • The 12.5% gap **matches the ECC overhead ratio** exactly, though NVIDIA does not explicitly confirm the connection.
  • Google's fleet data shows ~1 correctable error per GB per year, so an 80 GB card sees dozens of silent corrections annually.

Sources

  1. 2.NVIDIA A100 GPU: Full Specs, Performance, and Use Cases ...
  2. 5.NVIDIA A100 | Tensor Core GPU
  3. 12.ECC vs Non-ECC Memory and Silent Render Failures
  4. 13.How GPU Memory (HBM/GDDR) Differ from DDR | Ravichandran Paramasivam posted on the topic | LinkedIn