NVIDIA H200 SXM

CORRECTED 2026-10-03: no value changed; dense flags re-verified against NVIDIA's H200 spec table, whose footnote 2 'With sparsity' attaches to TF32/BF16/FP16/FP8/INT8 only. In the H200 SXM column 989 / 1,979 / 1,979 / 3,958 / 3,958 are SPARSE; dense is half, i.e. the 494.5 / 989.5 / 989.5 / 1,979 / 1,979 already stored here with dense true. Note the deliberate asymmetry with nvidia-h100-sxm: both parts print the same sparse 1,979 BF16 and 3,958 FP8, so their DENSE figures are identical too - the H200's advantage over the H100 SXM is memory (141GB/4.8TB/s vs 80GB/3.35TB/s), not tensor FLOPS. AUDIT VERIFIED against NVIDIA's own H200 spec table (nvidia.com/en-us/data-center/h200): the table prints FP8/INT8 3,958 TFLOPS, BF16/FP16 1,979 and TF32 989, all carrying footnote '2 With sparsity'. The dense values stored here (1,979 / 989 / 494.5) are therefore correct as dense and are now flagged dense:true. AUDIT CORRECTION: the dense/sparse flag on the tensor rows was inverted. FP16 989.5 / FP8 1979 TFLOPS are DENSE; NVIDIA prints 1,979/3,958 'With sparsity'. These rows were previously flagged dense:false, which wrongly told a reader they were sparse. The stored numbers are correct dense values. H200 is an H100 SXM with the SAME compute (identical Tensor Core rows: 989 TF32 / 1,979 BF16+FP16 / 3,958 FP8+INT8 printed, all WITH SPARITY - dense is half) and the SAME 700W envelope, but 141GB HBM3e at 4.8TB/s instead of 80GB HBM3 at 3.35TB/s. So H200 is purely a memory-capacity and bandwidth uplift: it wins wherever KV cache or weights do not fit, and loses on nothing. That makes H200 the memory-bandwidth-per-watt inflection point of the Hopper generation. NVIDIA marks the whole table 'preliminary specifications, may be subject to change'. Bus width 6144-bit is inferred from the 141GB/4.8TB/s pair, not printed. The 'other' row is FP64 34 TFLOPS (dense) - this schema's precision enum has no fp64 member.