The capstone › Seven lines, eight chapters
The Datasheet Walk
You can now read a spec sheet like a story. Prove it.
Below is the H100's spec sheet, reduced to the seven lines this Topic taught you to read — all spec-sheet peaks from the NVIDIA H100 whitepaper, Hopper generation. Every line was earned by a chapter: 132 SMs by 1.6, the 256 KB register file by 1.3, the 64-warp budget by 1.4, the fire hose and the drinking straw by 1.5 and 1.7, the mobile ridge point by 1.8. Walk the sheet; each line tells you what it lets you predict.
The Annotated Datasheet
Every line on this sheet was earned by a chapter. Hover one to see which — and what it lets you predict.
Hover or tap a spec-sheet line to decode it.
The exam › Predict before you run
Three predictions from the sheet alone
We are going to predict runtime from the datasheet alone, before running a single line of code.
Predict first
Exam 1 — the bandwidth-bound kernel. An element-wise vector addition of three 1 GB float32 arrays (x[i] = y[i] + z[i]). From the sheet alone, predicted runtime?
Compute the number › exam 1 · vecadd, from the sheet
| traffic | read 2 GB + write 1 GB = 3 GB |
| runtime | 3 GB ÷ 3,352 GB/s = 0.89 ms |
| Result | memory-bound: the sheet's bandwidth line IS the runtime |
Predict first
Exam 2 — the compute-bound kernel. A GEMM of two 16,384 × 16,384 matrices on FP16 Tensor Cores. Predicted runtime?
Compute the number › exam 2 · GEMM 16,384³, from the sheet
| FLOPs | 2N³ ≈ 8.79 trillion |
| classification | N/6 ≈ 2,730 FLOPs/B > ridge 295 → compute-bound |
| runtime | 8.79 TFLOPs ÷ 989.4 TFLOPS = 8.89 ms |
| Result | compute-bound: the sheet's TFLOPS line IS the runtime |
Predict first
Exam 3 — the transfer-bound kernel. The same 0.89 ms vector addition, but the 3 GB currently sits in the host CPU's system memory. Total time?
Compute the number › exam 3 · the trip over the straw
| transfer | 3 GB ÷ 64 GB/s = 46.9 ms |
| compute | 0.89 ms — a rounding error |
| Result | transfer-bound: the sheet's PCIe line IS the runtime |
The consequence › Peak vs. reality
The Honesty Lesson
You have just read the spec sheet exactly as the manufacturer intended. Now look at what the sheet's own publisher already admitted.
First, the binning gap — whitepaper against whitepaper. In 1.6 you watched it physically: the GH100 die was designed with 144 SMs; the H100 you were sold enables 132. That is 91.7% of the silicon, straight from the same document every peak on this sheet came from. The spec sheet and the die disagree, and both sides of the disagreement are [WP] facts. Yield and binning are not a scandal — they are how silicon ships — but they mean the design and the product are different machines, and only one of them is in your server.
Compute the number › the honesty number, from the whitepaper alone
| designed (full GH100) | 144 SMs |
| shipped (H100 SXM5) | 132 SMs |
| Result | 132 ÷ 144 = 91.7% — the publisher of the peaks ships 91.7% of the design |
Second, the runtime gap — you already predicted it. Your exam-2 expectation said a well-tiled GEMM lands 20–30% below the Tensor Core ceiling. That was not hedging; that is where real kernels live. The ceiling is real — sustained silicon just does not live at it.
Third, corroboration from outside.When independent researchers at Chips & Cheese measured VRAM bandwidth on the H100 PCIe card, they captured 1,898.15 GB/sagainst that card's 2,039 GB/s claim — ~93.1%. The PCIe card runs HBM2e, a different memory system from the SXM5's HBM3 you used above — so read this as evidence that the spec-vs-measured gap is general, not as a measurement of your SXM5 numbers.
Every prediction you just made used a ceiling. The whitepaper itself ships 91.7% of the die it designed; your own exam expected a real GEMM to land 20–30% under the Tensor Core roof; outside measurement agrees the gap is everywhere. The spec sheet is a ceiling, not a promise. That gap — between the theoretical peak on the PDF and what sustained silicon delivers — is what Topic 2 spends its life closing.
The full story › what I simplified: gradual saturation
When performing the exam arithmetic above, I calculated runtime by treating the maximum limits as independent, cleanly achievable values. I deliberately ignored the gradual saturation effect — the reality that as a kernel approaches the ridge point from either direction, it suffers combined latency effects and fails to reach 100% of either the memory bandwidth or the compute throughput. This simplification is honest here because the capstone is an upper-bound limit test: we are establishing the mathematical floor for execution time. Topic 2 will introduce the profiling tools that measure the friction that keeps us from hitting the floor.
You can read a datasheet cold. You know exactly what the hardware is capable of. Now, you have to write the code that proves it.
Seven spec-sheet lines, each earned by a chapter, are enough to predict the runtime of a bandwidth-bound, a compute-bound, and a transfer-bound kernel before writing any code — as ceilings. The die you bought is already 91.7% of the die designed, and real kernels land 20–30% under the roof; closing that gap is Topic 2's whole job.