How a GPU Is Made: From Wafer to HBM Package and Accelerator Board

A data center GPU is built from several separately made parts. Logic dies are printed on 300 mm silicon wafers, DRAM dies are thinned, drilled with through-silicon vias and stacked into high bandwidth memory (HBM), and both are placed side by side on a silicon interposer in a 2.5D package. That package is then mounted on a module or card with power stages, a cold plate and several layers of firmware, and only after a final system test does it become an accelerator you can rent or rack.

This post goes one level deeper than our explainer on how semiconductors are made, following one accelerator from wafer to deployed board, including firmware, attestation and fleet inventory. For memory history, see memory evolution from core to DDR5, HBM and CXL. For the networks that link these boards, see scale-up vs scale-out AI networks, and for cooling, see air vs liquid cooling for AI servers.

Foundries and memory makers publish very few yield numbers. Where a figure comes from a vendor or standards body, we name the document; where a calculation uses illustrative inputs, we say so.

Key takeaways

• A large AI GPU die is mostly repeated compute blocks with matrix units, plus a big shared cache, HBM memory controllers and link interfaces. NVIDIA's full GH100 die has 144 SMs, 576 Tensor Cores, a 60 MB L2 cache and twelve 512-bit memory controllers.
• Lithography scanners expose a maximum field of 26 by 33 mm, or 858 square millimetres, per Nikon's published scanner specifications. GH100 is 814 square millimetres, about 95 percent of that field. A single die cannot grow much past this, which is why NVIDIA describes every Blackwell product as two "reticle-limited dies" joined by a 10 TB/s chip to chip link.
• Chiplets get around the limit. AMD's CDNA 3 white paper describes up to eight compute dies stacked on four I/O dies, connected to eight HBM stacks.
• HBM is thinned DRAM dies joined by through-silicon vias (TSVs) on a base die. JEDEC's HBM4 standard (JESD270-4, 16 April 2025) runs a 2048-bit interface at up to 8 Gb/s, up to 2 TB/s per stack, in stacks up to 16 high.
• Shipping parts are deliberately partly disabled. The H100 SXM5 enables 132 of 144 SMs and 5 of 6 HBM sites; each MI300X compute die enables 38 of 40 CUs "for yield management", in AMD's words.
• The Open Compute Project's OAM specification defines a 102 by 170 mm module of up to 1000 W, with secure boot, anti-rollback and PLDM firmware update requirements.
• A GPU runs firmware in several places: the board VBIOS, an onboard system or security processor (GSP on NVIDIA, PSP on AMD) and the InfoROM store. Inventory them with nvidia-smi -q, /proc/driver/nvidia, lspci and fwupdmgr.

The whole journey in one table

Yields at each stage are trade secrets, so this step table names the test point at each stage rather than inventing a percentage.

What does a GPU die contain?

A data center GPU die is a grid of identical compute blocks fed by a very wide memory system. NVIDIA's Hopper architecture post (22 March 2022) gives a clear published floor plan. The full GH100 die is built on "TSMC 4N process customized for NVIDIA" with 80 billion transistors and a die size of 814 square millimetres. It is organised as:

• 8 GPU processing clusters (GPCs), each with 9 texture processing clusters (TPCs), each TPC holding 2 streaming multiprocessors (SMs). That is 144 SMs on the full die.
• 128 FP32 CUDA cores per SM, 18,432 in total.
• 4 fourth generation Tensor Cores per SM, 576 in total. These are the matrix units that do most of the work in AI training and inference.
• A 60 MB L2 cache on the full die (50 MB enabled on the H100 SXM5 product).
• 6 HBM3 or HBM2e stack sites served by twelve 512-bit memory controllers.
• Fourth generation NVLink and PCIe Gen 5 interfaces.

AMD splits the same functions across dies, as the chiplet section shows. Whatever the vendor, the blocks fall into the same categories:

HBM PHYs sit on the die edges that face the stacks, because the wires to each stack run sideways through the interposer. Area buys compute; perimeter buys memory bandwidth.

Why are large AI GPUs reticle-limited?

A scanner prints a die by projecting a mask (the reticle) onto the wafer at a quarter of its size, and the exposure field is fixed by the optics. Nikon's published ArF immersion scanner specifications list a 1:4 reduction ratio and a "maximum exposure field" of 26 mm by 33 mm.

Worked example 1, how close GH100 sits to the limit:

• Maximum field: 26 mm by 33 mm = 858 square millimetres.
• GH100 die: 814 square millimetres (NVIDIA).
• 814 divided by 858 = 0.949, so the die uses about 95 percent of the largest area a scanner can print in one exposure, before you allow for scribe lines between dies.

To put more transistors on one GPU, a designer can wait for a denser node, stitch exposures together (rare for logic), or split the design across dies. NVIDIA's Blackwell architecture page takes the third route and says so directly: "All NVIDIA Blackwell products feature two reticle-limited dies connected by a 10 terabytes per second (TB/s) chip-to-chip interconnect in a unified single GPU," for 208 billion transistors on "a custom-built TSMC 4NP process."

Big dies also yield badly

Yield makes approaching the ceiling expensive. Killer defects land roughly at random, so the chance a die escapes them falls quickly as it grows.

Worked example 2, dies per wafer and a simple yield model. The inputs here are illustrative and are not published by any foundry; the method is the standard textbook approximation.

• Gross dies per 300 mm wafer, using the common approximation (pi times d squared over 4S) minus (pi times d over the square root of 2S), with wafer diameter d = 300 mm and die area S = 814 square millimetres: 86.8 minus 23.4, which is about 63 candidate dies.
• Assume a defect density of 0.1 defects per square centimetre (illustrative). With a simple Poisson model, yield = e to the power of (minus defect density times area). Area is 8.14 square centimetres, so yield = e to the power of minus 0.814, which is about 0.44.
• That gives about 28 fully working dies per wafer.
• Now take a hypothetical 115 square millimetre chiplet at the same defect density. Gross dies are about 553, yield is e to the power of minus 0.115, about 0.89, so about 493 good chiplets. Seven of those chiplets cover about the same silicon area as one 814 square millimetre die, so the wafer gives about 70 large-die equivalents instead of 28.

Real numbers differ, but smaller dies waste less silicon per defect, and that is the economic case for chiplets.

Harvesting: shipping dies that are not perfect

Vendors also build dies with more compute blocks than the product enables, so a die with a defective block can still ship:

How do chiplets get around the reticle limit?

A chiplet design splits the GPU into dies that each fit inside one exposure field, joined so closely that software sees one device. Two published approaches:

• Two large twins. Blackwell joins two reticle-limited dies with a 10 TB/s link, per NVIDIA. AMD's CDNA 3 white paper says its previous MI200 generation did something similar, coupling two compute dies "through a single high-bandwidth and low latency interconnect formed over an interposer bridge."
• Many small, specialised dies. AMD's CDNA 3 white paper describes the MI300 series as "up to 8 vertically stacked accelerator complex dies (XCD) and 4 I/O dies (IOD)," connected to eight HBM stacks. The XCDs are made on TSMC's 5 nm process. The IODs are made on TSMC's 6 nm process and "vertically stacked beneath a pair of XCDs," and they hold the Infinity Cache and the HBM3 interface. AMD's MI300X product page lists 153 billion transistors and "TSMC 5nm | 6nm FinFET".

Splitting lets each die use the process that suits it: compute logic gains most from the newest node, while caches, analog PHYs and I/O shrink less and can sit on an older one. The cost is that thousands of signals now cross bonds between dies, which the package must carry at low energy per bit.

Chiplet trade-offs at a glance

How does 2.5D packaging work?

"2.5D" means dies sit side by side on a shared silicon layer with wiring far finer than a circuit board; "3D" means dies are stacked. Large AI GPUs use both: HBM is a 3D stack beside the GPU on a 2.5D interposer.

The silicon interposer

An interposer is a thin piece of silicon made with coarser lithography than the GPU, but far finer than any organic board. It carries:

• Fine wiring from the GPU's HBM PHYs to each stack. An HBM3 stack has a 1024-bit data interface and an HBM4 stack 2048 bits, per JEDEC and SK hynix. With command, address and power, that is thousands of connections per stack, beyond what an organic substrate can route.
• Through-silicon vias that carry power, ground and the off-package signals down to the organic package substrate below.
• Microbumps on top, where the GPU dies and HBM stacks land, and larger bumps on the bottom.

The interposer is patterned by a scanner too, so it hits the same field limit. Larger interposers stitch exposures, or replace the full silicon layer with an organic layer that embeds small silicon bridges only where fine wiring is needed. TSMC calls its family CoWoS (chip on wafer on substrate). Its technology pages block scripted clients, so we do not quote its size figures here.

The order of assembly

The name "chip on wafer on substrate" describes the order:

1. Chip on wafer. Known good GPU dies and HBM stacks are placed face down on a whole interposer wafer and bonded through their microbumps. Underfill is dispensed around the joints to support them.
2. Wafer processing. The populated interposer wafer is thinned from the back to expose its TSVs, and bumps are added to the back side.
3. On substrate. The wafer is diced into individual interposer assemblies, and each is attached to an organic package substrate with larger bumps. The substrate fans the connections out to the ball grid array that solders to the module board.
4. Lid or stiffener. A metal lid or ring is attached to control warpage and spread heat.

Hybrid bonding

Microbumps are tiny solder joints. Hybrid bonding removes the solder: two very flat surfaces with copper pads set in oxide are pressed together, the oxide bonds, and annealing fuses the copper. Without solder the connection pitch can shrink a great deal, raising bandwidth and cutting energy per bit between stacked dies, which suits vertical stacks like the MI300 compute dies on I/O dies.

Why packaging is a bottleneck

Three things make advanced packaging a frequent constraint:

• Interposer area. Each package needs an interposer that can span several reticles, so interposer wafer starts scale with GPUs shipped.
• Compound yield. Every die, stack and bond must work. Eight stacks at an illustrative 99 percent each give 0.99 to the eighth power, about 92 percent, before bonding losses, which is why every part is tested before placement ("known good die").
• Dedicated lines. Bonding, thinning and large substrate handling need their own equipment and cleanrooms. NIST's CHIPS for America program, funded by the CHIPS and Science Act of 2022, lists a National Advanced Packaging Manufacturing Program among its research programs.

How is HBM made, and why is supply tight?

An HBM stack, or cube, is a base die with 4 to 16 DRAM core dies above it, linked by thousands of vertical copper connections.

Step by step

1. DRAM core dies. Made on a DRAM process; Micron says its HBM3E uses its "1β (1-beta)" process.
2. Through-silicon vias. Deep, narrow holes are etched, insulated and filled with copper. SK hynix's newsroom explains that stacked chips used to be joined by wires like steps, and longer wiring meant more delay; TSVs run straight through each die. It says I/O count rose from 1,024 up to HBM3E to 2,048 in HBM4.
3. Thinning. The wafer is bonded to a carrier and ground from the back until the TSV copper is exposed, leaving dies tens of micrometres thick so a tall stack fits the standard's height. Thin silicon warps, the central difficulty.
4. Bumping. Microbumps on the front and pads on the back let each die connect above and below.
5. Base die. A logic die holding the GPU interface, test and repair circuits. SK hynix says HBM4 uses a "logic base die," which enables custom HBM.
6. Stacking and bonding. Thermo-compression bonding places dies one at a time with heat and pressure, often with a non-conductive film. SK hynix describes its mass reflow molded underfill (MR-MUF) as fixing several chips temporarily, then injecting a liquid material and packaging them at once, which it says addresses warpage and improves heat dissipation and mass production.
7. Stack test and repair. The cube is tested through the base die; spare rows and columns map out failing cells.
8. Ship as known good stack, because a bad stack found after bonding wastes the GPU die beside it.

What the JEDEC HBM4 standard specifies

JEDEC announced the JESD270-4 HBM4 standard on 16 April 2025. According to its press release:

Worked example 3, bandwidth and capacity from first principles:

• HBM4 bandwidth: 2048 bits times 8 Gb/s = 16,384 Gb/s. Divide by 8 bits per byte: 2,048 GB/s, about 2 TB/s per stack, matching JEDEC's figure.
• HBM4 capacity: 32 Gb per die times 16 dies = 512 Gb. Divide by 8: 64 GB, matching JEDEC's largest cube.
• Micron's 36 GB 12-high HBM3E cube: 36 GB times 8 = 288 Gb, divided by 12 dies = 24 Gb per die.
• MI300X: AMD lists an 8192-bit memory interface and 5.3 TB/s. 5.3 TB/s is 42,400 Gb/s; divided by 8,192 pins that is about 5.2 Gb/s per pin, consistent with the 5.2 GHz memory clock AMD lists. 8,192 divided by 1,024 bits per HBM3 stack is 8 stacks, matching the white paper.
• H100 SXM5: 5 stacks served by ten 512-bit controllers is a 5,120-bit interface. NVIDIA quotes about 3 TB/s, which works out to roughly 4.7 Gb/s per pin.

Why HBM supply is tight

• More wafer per bit. TSV area and extra I/O mean a wafer yields fewer gigabytes as HBM than as ordinary DRAM.
• Stack yield compounds. A 12 or 16 high stack fails if any layer or bond fails.
• Each GPU needs many stacks. MI300X uses 8 for 192 GB; H100 SXM5 uses 5 for 80 GB.
• Specialised back end lines. Thinning, TSV reveal and stacking need their own equipment, and a logic base die adds a foundry dependency.
• Qualification per pairing. A stack is qualified with each GPU and package design, so supply cannot simply be redirected.

How are boards and modules assembled?

A tested, binned package goes onto a board in one of three broad forms.

The OAM specification in numbers

The Open Compute Project's OAI OAM Base Specification r2.0 v1.0 sets out the open module form factor. Its high level table lists:

• Module dimension: 102 mm by 170 mm.
• Power: "Supports up to 1000W, using 44V-59.5V DC as input power."
• Connectors: two mezzanine connectors, with a stack height of 5 mm or 8 mm and 90 ohm differential impedance.
• Host interface: "One or two x16 host links," for example PCIe Gen 5 or 6.
• Module to module: up to 7 links per module, each up to x16 lanes.

AMD's MI300X page lists an "OAM Module" form factor on a "54V UBB" (Universal Baseboard), with "750W Peak" typical board power.

Power delivery: why the regulators crowd the package

Worked example 4, the current problem (input values are illustrative except the OAM limits):

• At the OAM limit of 1000 W and a 54 V input, the module draws about 18.5 A, easy for a connector.
• If the core rail sat at 0.8 V (illustrative) and drew most of that power, it would carry about 1,250 A.
• Resistive loss scales with current squared, so carrying 1,250 A even a few centimetres wastes real power.

So the board steps 54 V down in stages, and the final stage of many parallel phases sits as close to the package as layout allows. Those regulators are run by digital controllers that also run firmware and report telemetry.

What firmware and software ship with a GPU?

An accelerator is a small computer in its own right:

VBIOS and InfoROM

NVIDIA's nvidia-smi documentation describes the VBIOS Version field as "The BIOS of the GPU board." It describes the InfoROM as "a small, persistent store of configuration and state data for the GPU," and nvidia-smi even has a dedicated return code for "infoROM is corrupted."

GSP firmware

NVIDIA's Linux driver README says some GPUs include a GPU System Processor (GSP) "which can be used to offload GPU initialization and management tasks." Its firmware ships as gsp_*.bin files under /lib/firmware/nvidia/<driver version>/ and is loaded by the driver; the README lists A100 parts among those using it by default. The GSP firmware version matches the driver version, so a driver update changes the firmware the GPU runs. The upstream nouveau documentation describes the driver sending remote procedure calls to the GSP through a command queue.

PSP on AMD

The Linux kernel's amdgpu documentation describes the PSP (Platform Security Processor) as the block that "handles security policy for the SoC and executes trusted applications, and validates and loads firmwares for other blocks." It also says that when certain firmware is loaded, the PSP "takes steps to ensure it has a valid signature" and keeps firmware images in a protected Trusted Memory Area so the operating system or driver cannot corrupt them. The same page describes the SMU, the power management microcontroller that controls clocks, voltages and power rails.

Drivers, runtimes and the container toolkit

Above the firmware sit the kernel driver and user mode libraries. NVIDIA's container toolkit guide configures Docker with the nvidia-ctk runtime configure command, which it says edits /etc/docker/daemon.json. A training image then carries a CUDA-class runtime, communication libraries, a framework and hundreds of Python packages, ordinary components with their own vulnerability histories, rebuilt far more often than the firmware below them.

Firmware security requirements in the open spec

The OAM specification's security section is a good vendor-neutral checklist:

• Hardware root of trust. An immutable root of trust, for example one time programmable fuses, holds the key used to verify firmware, plus ROM code for secure boot.
• Boot time verification. "On every boot, the ROM code should cryptographically verify mutable firmware code," and all mutable code must be signature checked before it runs. ROM patching is not allowed in production devices.
• Anti-rollback through a security version number in immutable memory, plus time of check and time of use protection.
• Key revocation for a compromised intermediate signing key, and recovery to a known good image.
• Updates in band through a supplier utility, and out of band through PLDM for firmware update over MCTP (DMTF DSP0267). FRU data, including serial, part number and firmware version, is exposed through PLDM for FRU data (DSP0257).

If your fleet uses BMCs to manage these modules, our post on Redfish and BMC security covers the management plane.

How do GPU confidential computing and attestation work?

Confidential computing protects data while it is processed. For GPUs, it extends a CPU trusted execution environment (TEE) so a confidential VM or container can use the GPU without the host, hypervisor or operator reading the data or model weights. NVIDIA's Hopper post says H100 "extends the trusted execution environment (TEE) with CPUs at full PCIe line rate," with TEEs available per Multi-Instance GPU partition.

Three deployment modalities

NVIDIA's overview defines three modalities, each with a different trust boundary:

NVIDIA says the modalities "do not provide interchangeable security guarantees" and that the boundaries do not "eliminate shared-hardware, fabric, physical, or side-channel risks." That honesty is worth carrying into any internal design review.

Attestation in plain language

Attestation asks, before a secret is released: is this the expected GPU, running the expected firmware, in confidential mode? The flow NVIDIA documents:

1. Evidence. CPU and GPU evidence, reference values and identity information are gathered about the environment's hardware and security configuration.
2. Reference values. A verifier compares the evidence with known good values; in NVIDIA's confidential containers documentation, a Reference Value Provider Service holds them.
3. Policy. NVIDIA's overview stresses that attestation "provides evidence for a trust decision; it does not replace the policy that determines whether a workload can receive secrets."
4. Secret release. A key broker service releases a secret, such as a model decryption key, only if the evidence satisfies policy. In the Trustee architecture NVIDIA documents, the default policy denies requests from clients that have not presented valid TEE evidence.

NVIDIA's open source nvtrust repository holds an attestation SDK for GPU and NVSwitch attestation, local and remote, and a Protected PCIe (PPCIE) verifier for multi-GPU setups. It marks the Python SDK and local GPU verifier as deprecated in favour of a C++ SDK and command line tool.

The practical lesson: confidential computing makes firmware versions a security input. A node whose firmware does not match the verifier's reference values fails attestation, which makes the inventory below part of keeping confidential AI running.

How do you inventory GPU firmware and driver versions in a cluster?

The commands below read versions only, except the final block, which is marked.

Step 1: find every GPU on the PCI bus

# List NVIDIA (vendor 10de) and AMD (vendor 1002) devices with numeric IDs
lspci -nn | grep -Ei 'vga|3d controller|display|processing accelerator'

# Detailed view of one device, including link width and speed
sudo lspci -vvv -s 0000:17:00.0 | grep -E 'LnkCap|LnkSta|Kernel driver|Subsystem'

lspci works without a vendor driver loaded. A link trained at x8 instead of x16, or at a lower generation, shows in LnkSta.

Step 2: read driver, VBIOS, InfoROM and GSP versions on NVIDIA hosts

# Driver version as the kernel module reports it
cat /proc/driver/nvidia/version
modinfo nvidia | grep -E '^version'

# Firmware fields from the full query
nvidia-smi -q | grep -E 'Product Name|Serial Number|GPU UUID|Bus Id|VBIOS Version|GSP Firmware Version|Image Version|OEM Object|ECC Object'

# Per-GPU information file, which also reports GSP firmware
cat /proc/driver/nvidia/gpus/*/information

# GSP firmware files shipped with this driver
ls /lib/firmware/nvidia/

For machine readable output, the nvidia-smi documentation describes selective GPU queries and a help option that lists the field names your driver supports.

nvidia-smi --help-query-gpu | less
nvidia-smi --query-gpu=index,name,pci.bus_id,uuid,serial,driver_version,vbios_version --format=csv,noheader

Key your inventory on UUID or PCI bus ID: the documentation warns that enumeration order "is not guaranteed to be consistent between reboots" and a board serial "might be shared between multiple GPUs on the same board."

Step 3: read versions on AMD hosts and through fwupd

# amdgpu exposes a VBIOS version string in sysfs on many systems
cat /sys/class/drm/card*/device/vbios_version 2>/dev/null

# Devices fwupd knows about, with current firmware versions
fwupdmgr get-devices

# Kernel messages about firmware loading
sudo dmesg | grep -Ei 'amdgpu.*(psp|smu|firmware)|nvidia.*gsp'

fwupd's AMDGPU plugin "reports the vbios version of APU devices supported by amdgpu and supports flashing the IFWI of some dGPU devices," with updates supported since fwupd 1.9.6.

Step 4: record the container toolkit and runtime libraries

nvidia-ctk --version
dpkg -l | grep -E 'nvidia-container-toolkit|libnvidia-container' || rpm -qa | grep -E 'nvidia-container'

Images are where most version drift happens, because each rebuild pulls fresh dependencies.

Step 5: collect across the cluster

#!/usr/bin/env bash
# gpu-inventory.sh: read-only inventory across a list of hosts
# Usage: ./gpu-inventory.sh hosts.txt > inventory.csv
echo "host,index,name,bus_id,uuid,driver,vbios"
while read -r host; do
  ssh -o BatchMode=yes "$host" \
    "nvidia-smi --query-gpu=index,name,pci.bus_id,uuid,driver_version,vbios_version --format=csv,noheader" \
    | sed "s/^/${host},/"
done < "$1"

Group the CSV by driver and VBIOS version. Mixed versions in one job cause hard to explain failures, and in a confidential computing fleet they fail attestation.

Step 6 (changes firmware): apply a vendor-published firmware update

Warning: an interrupted or misdirected firmware update can leave a GPU unusable. Drain the node, confirm the device path and ID, and follow the vendor's tool and release notes. The fwupd AMDGPU plugin writes the inactive partition, which takes effect after reboot.

# 1. Confirm exactly which device you are about to update
fwupdmgr get-devices
sudo lspci -nn -s 0000:17:00.0

# 2. See what updates are offered and for which device ID
fwupdmgr get-updates

# 3. Only after the checks above, on a drained node
sudo fwupdmgr update <DEVICE-ID>

Common mistakes

• Recording only the driver. VBIOS, InfoROM and board management firmware change separately.
• Keying inventory on index or serial. Use the GPU UUID or PCI bus ID.
• Assuming GSP firmware lives on the card. It loads from the host driver package, so a stale driver means stale GSP firmware.
• Ignoring link training. A GPU at x8 or a lower PCIe generation still works, slowly. Check LnkSta.
• Mixed firmware in a confidential fleet. Nodes that do not match reference values will not receive secrets.
• Equating attestation with security. NVIDIA's docs say it supports a policy decision and does not remove side channel, fabric or physical risks.
• Rebuilding images blind. Without an SBOM per image, nobody can say which nodes carry a vulnerable library.
• Quoting peak bandwidth as delivered. Interface rates are peaks.
• Flashing a live node. Drain, confirm, update, reboot, re-check.

FAQ

What is the difference between a GPU die and a GPU package?

The die is one piece of silicon. The package is the assembly of logic dies, HBM stacks, interposer, substrate and lid. Blackwell has two logic dies in one package that NVIDIA presents as one GPU.

What does reticle limit mean for chips?

It is the largest area a lithography scanner can print in one exposure, 26 by 33 mm or 858 square millimetres on current scanners. A single die cannot exceed it without stitching multiple exposures, so the largest GPUs either sit just under it or split into several dies.

Why do AI GPUs use HBM instead of GDDR memory?

HBM puts very wide interfaces (1024 bits per HBM3 stack, 2048 per HBM4 stack) right beside the GPU on an interposer, giving far more bandwidth per watt and per board area than narrow memory chips spread across a board. The trade-off is cost and supply.

What is a through-silicon via?

A copper connection that passes straight through a thinned silicon die, letting the dies in an HBM stack connect vertically instead of through wires bonded at the edges.

What is the difference between SXM, OAM and PCIe GPUs?

A PCIe card plugs into a standard slot. SXM style modules are vendor specific mezzanine boards on a vendor baseboard. OAM is the Open Compute Project's open module, 102 by 170 mm and up to 1000 W, on a Universal Baseboard.

How do I check my GPU firmware version on Linux?

On NVIDIA hosts, run nvidia-smi -q and look for VBIOS Version, Inforom Version and GSP Firmware Version, or read /proc/driver/nvidia/gpus/*/information. On AMD hosts, read the vbios_version attribute in sysfs where present, and run fwupdmgr get-devices for devices fwupd supports.

Does GPU confidential computing protect against everything?

No. NVIDIA's documentation says the trust boundaries do not automatically protect end user data from the model owner and do not eliminate shared hardware, fabric, physical or side channel risks. It protects data in use from the parties outside the chosen boundary, when deployed with the required controls.

Why are some GPU cores disabled?

To raise yield. Large dies are designed with spare compute blocks. A die with a few defects ships with those blocks switched off. NVIDIA's H100 SXM5 enables 132 of 144 SMs, and each MI300X compute die enables 38 of 40 CUs.

Where Safeguard fits, honestly

Safeguard does not make, test or analyse GPUs, packages or memory, and it does not scan GPU firmware, generate a hardware bill of materials or manage devices. Its models are single-purpose security models for software, so nothing here about lithography, stacking or yield is something they analyse. The fit is narrower: the software on accelerators, such as training and inference images, runtime layers, Python frameworks and cluster tooling, is ordinary software. Safeguard scans repositories, container images (safeguard scan --image <name>) and SBOM files for known vulnerable components, shows which projects carry a given component and version, applies policies and gates, and can open fix pull requests when a fixed version exists, with autonomous remediation switched off by default.

A GPU cluster pulls its software stack again every time an image is rebuilt or a node is reimaged, and those images carry hundreds of open source components with their own known vulnerabilities. The fit is indirect, since Safeguard does not touch the hardware or its firmware, but the images that run on the hardware are part of your software supply chain like everything else.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, open the interactive terminal and ask it to fix a lodash CVE. It reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval and pushes nothing. The same flow applies to the repository that builds your training or inference image.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits teams who build GPU images on their own build hosts and want the scan to run where the build runs.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use, so a platform team already working in Claude can reach Safeguard's findings in the same conversation.

Click through it at your own pace, or open it full screen.

To try it on your own repositories and images, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NVIDIA Technical Blog, NVIDIA Hopper Architecture In-Depth (22 March 2022)
• NVIDIA, Blackwell architecture
• AMD, Instinct MI300X accelerator product page
• AMD, Introducing AMD CDNA 3 Architecture white paper
• JEDEC press release via Business Wire, JESD270-4 HBM4 Standard (16 April 2025), as republished by Silicon UK
• SK hynix Newsroom (Korean), Future Talents Class: TSV and MR-MUF
• Micron, HBM3E
• Nikon, semiconductor lithography product archive (ArF immersion scanner specifications)
• Open Compute Project, OAI OCP Accelerator Module (OAM) Base Specification r2.0 v1.0
• NVIDIA Linux driver README, Chapter 43: GSP Firmware (550.54.14)
• NVIDIA, nvidia-smi documentation
• NVIDIA, Container Toolkit installation guide
• NVIDIA, Confidential Computing overview
• NVIDIA, Confidential Containers attestation
• NVIDIA, nvtrust repository
• Linux kernel documentation, GPU driver developer's guide
• Linux kernel documentation, amdgpu core driver infrastructure
• Linux kernel documentation, drm/nouveau NVIDIA GPU driver
• fwupd, Plugin: AMDGPU
• NIST, CHIPS for America

Last reviewed: 23 October 2026.