NVIDIA H20

VERIFIED NEGATIVE, 2026-10-05: the claim 'NVIDIA has never published an H20 datasheet', which this record has asserted since it was written and which every downstream reader would have taken on trust, has now actually been tested. IT STANDS, and it now stands on evidence rather than on absence of effort. Five independent searches were run, all site-restricted to NVIDIA's own domains - 'NVIDIA H20 datasheet site:nvidia.com', 'site:resources.nvidia.com H20', 'NVIDIA H20 site:developer.nvidia.com', '"HGX H20" datasheet nvidia pdf', and a developer-blog query. Every one returned ZERO nvidia.com results. Direct probes of the canonical first-party URLs confirm it: nvidia.com/en-us/data-center/h20/ resolves to no specification document, resources.nvidia.com's HGX H20 entry is a JS PDF viewer with no extractable text, and nvidianews.com carries only the press release. The only hits anywhere were aggregators and news (flopper.io, inferencebench.io, qscompute.com, baike.baidu.com) plus one Scribd upload titled 'Nvidia H20 GPU Datasheet' - a user upload on a document-sharing site, not an NVIDIA publication, recorded so a future pass does not mistake it for the missing document. The shape of the absence is itself consistent with the explanation: H20 is the export-restricted Hopper part whose compute was cut to satisfy US export controls while its memory subsystem was left generous, so the compute table is exactly the thing a vendor would omit. WHAT THE NEGATIVE DOES NOT DO: it does not make the six figures right. They still come from flopper.io, typed kind 'database', which is why vendor_claim is false on all six rows and status stays 'draft'. This is the lowest-confidence set in data/ deliberately, and the honest statement is 'NVIDIA does not publish these', not 'these are NVIDIA's figures'. BUS WIDTH IS STILL INFERRED, not sourced: 6144-bit follows from 96GB across eight 12GB HBM3 stacks and no document prints it. Treat as low-confidence - it is the weakest field on this record. WHY THE PART MATTERS, restated because it is the reason to keep a draft record at all: 148 dense FP16 TFLOPS against 96 GB at 4.0 TB/s is roughly two-thirds of H100 SXM's dense 989 TFLOPS but a HIGHER bandwidth-per-FLOP ratio than H100's. That is a memory-rich, compute-poor Hopper - the opposite trade from H100 - and for inference, where decode is bandwidth-bound, it is the more interesting half of the part. The FP8/INT8 296 figure is sparse per the source, so dense would be 148.