PantheonSim / GPUs / NVIDIA H200
Simulated NVIDIA H200: a GPU profile for CUDA and ROCm testing
PantheonSim, the GPU simulator for CUDA and ROCm, simulates the NVIDIA H200 (Hopper, 9.0) as the profile nvidia/h200.
The H100's GH100 die with 141 GB of HBM3e memory, for large-model inference and training. Its profile is built from public documents and not yet measured against a physical card.
The profile at a glance
These are the numbers a program can ask this simulated GPU, and the values nvidia-smi show for it. They come from the profile file in the simulator's repository, pinned to one commit of it.
| Property | Value |
|---|---|
| Profile id | nvidia/h200 |
| Vendor and architecture | NVIDIA, Hopper |
| Compute capability | 9.0 |
| Device memory | 141.0 GiB, HBM |
| Streaming multiprocessors | 132 |
| Warp size | 32 |
| Max threads per multiprocessor | 2048 |
| Shared memory per block (opt-in maximum) | 227 KiB |
| L2 cache | 50 MiB |
| Memory bus width | 6144-bit |
| Power limit (profile) | 700 W |
| Maximum clocks (profile) | 1980 MHz shader, 3201 MHz memory |
| ECC memory | yes |
| PCIe link reported | Gen5 x16 |
| NVLink reported | NVLink4 x18 |
| Tensor or matrix cores | yes |
| Verified (measured on a physical card) | not yet measured |
What this GPU is for
The H100's GH100 die with 141 GB of HBM3e memory, for large-model inference and training.
Hopper is compute capability 9.0. The simulator implements Hopper's warpgroup matrix instructions (wgmma), the tensor memory accelerator (TMA), thread-block clusters with their barriers, and distributed shared memory, and checks them against CUTLASS and CuTe's own Hopper unit tests.
Among the 37 NVIDIA profiles it ranks 5th by device memory (141.0 GiB) and 12th by SMs (132), counting the largest as first.
Is this profile verified?
No. This profile is marked not verified: it is built from public documents only, and nothing in it was measured on a physical card. Some figures are derived or copied from the nearest profile where the vendor publishes none, so treat them as approximate, and memory sizes as upper bounds. The profile file itself calls some of its values placeholders. Programs still run on it, and it still answers every call as the architecture's rules require, but a value such as a clock or a limit may differ from a real card's.
Simulate this GPU
Build the simulator (see the docs) or open the playground, then:
nvcc -cudart shared -arch=compute_90 my_app.cu -o my_app vgpu run --gpu nvidia/h200 ./my_app vgpu shell -y --gpu nvidia/h200 --count 4 vgpu info --gpu nvidia/h200
This profile is compute capability 9.0. A kernel built for compute_75 runs on it and on every other NVIDIA profile; a kernel built for a newer architecture is refused by a profile that is older than it. Link the CUDA runtime shared (-cudart shared) so the simulator can stand in for it.
To use it every time, put gpu: nvidia/h200 in a pantheonsim.yaml settings file, or in a GitHub Actions job give the PantheonSim action gpu: nvidia/h200 (see CUDA and HIP tests in GitHub Actions). The simulator checks behaviour and has no timing model, so a run on a physical GPU before a release still counts. The CUDA guide explains the rest.
Where the numbers come from
Each profile file begins with a note on its sources. This is the note for NVIDIA H200, as written in the file:
Source note for nvidia/h200
Provenance, because "placeholder" understated this one. The H200 is the same GH100 die as the H100 SXM5 at the same compute capability, so every field the execution model consults, the whole limits block, the features, the SM count, is inherited from nvidia/profiles/h100.yaml, which *was* read from a physical card and matches it on 512 conformance values. Diff the two files and the functional part is identical. Three fields were read from no device: vram_bytes, mem_clock_max_mhz and pci_device_id. Only the first is functional; the other two are telemetry, which is presentation and never consulted by the interpreter. verified stays false, and vram_bytes is exactly why. It is the one field that differs between two *physically identical* cards, an A10 with ECC on reads 1.5 GiB below the same A10 with it off, and two H100 SXM5s differed by 10 MiB of driver reservation. So the single functional value not inherited here is also the single least inferable one, and inheriting the rest correctly does not make it measured. `verified` means read from hardware; it does not mean believed to be right.
The GPU index lists every profile, and this one is not yet measured.
Related GPUs
Other Hopper profiles: