AMD Instinct MI300X

8,192-bit memory interface x 5.2 Gbps per-pin data rate / 8 = 5,324.8 GB/s, rounded by AMD to '5.3 TB/s'. AMD states this derivation verbatim in footnote MI300-05A. Eight HBM3 stacks, one per XCD. The spec table's 'Memory Clock 5.2 GHz' column is the per-pin data rate, not a base clock.

AUDIT 2026-10-03 (AMD convention established and every row re-verified against the live MI300X page, no values changed): AMD's rule, confirmed on six Instinct pages and recorded at source acc2-amd-ml300-convention, is that 'Peak X Performance' is DENSE and the separately-labelled 'Peak X Performance with Structured Sparsity' row is SPARSE at exactly 2x. AMD's MI300X page prints FP8 '2.61 PFLOPs' and '5.22 PFLOPs' with sparsity, FP16 '1.3'/'2.61', TF32 '653.7 TFLOPs'/'1.3 PFLOPs', INT8 '2.6 POPs'/'5.22 POPs', BF16 '1.3'/'2.61' - every pair matching this record's dense and sparse rows exactly. The dense INT8 row's source_id was 'amd-rocm-mi300-microarch' while every sibling row cited the product page; it is now cited to the product page like the rest, since that page states INT8 directly. The 'vector' rows AMD also prints (FP32 163.4, FP64 81.7) carry NO sparsity variant, so they are dense by construction - the scalar paths on CDNA3 have no 2:4 path. THE CROSS-VENDOR TRAP THIS AUDIT FOUND, worth stating because it is exactly how a wrong number enters a comparison: AMD's own 'Specs Comparisons' chart on the MI300X page prints 'FP16/BF16 (Sparsity) 1978.9 | 2614.9' and 'FP8 (Sparsity) 3957.8 | 5229.8' comparing H100 SXM5 to MI300X. Those H100 numbers are the SPARSE figures. The same NVIDIA H100 SXM dense figures are 989 and 1,979. So an author reading AMD's chart and writing 'H100 = 1,979 dense BF16' would be wrong by exactly 2x - which is the mirror image of the NVIDIA-side trap where the sparse number is the headline. EIGHT compute dies in ONE OAM package. vram_gb 192 is the whole module: 8 Accelerator Complex Dies (XCDs) x 38 enabled CUs = 304 CUs, plus 4 I/O dies on one interposer. A reader must NOT assume this is two 96GB addressable halves - the 8 XCDs are fully connected on-package over Infinity Fabric and the 192GB is one coherent GPU address space. FP64 is absent from the flops list because the schema's precision enum has no fp64. AMD's two FP64 numbers: 163.4 TFLOPS Matrix (MFMA) and 81.7 TFLOPS Vector - MI300X is the first CDNA part where FP64 Matrix equals FP32 Matrix instead of being 2x it. Dense vs sparse is the most important thing on this record. AMD publishes every AI precision twice: once dense, once 'with Structured Sparsity' (2:4). The sparse number is exactly 2x dense, every time. Do not compare a MI300X sparse FP8 figure against an NVIDIA dense FP8 figure. CDNA3 added TF32 and FP8 (both absent on MI200, per the MI300X datasheet footnote) plus native structured sparsity. ROCm microarch FLOPS/clock/CU: Vector TF32 1024, Matrix FP16/BF16 2048, Matrix FP8/INT8 4096, Matrix FP64 256, Vector FP64 128, Matrix FP32 256, Vector FP32 256 - aggregated over 304 CUs at 2.1 GHz. Inference relevance: 192 GB HBM3 at 5.3 TB/s plus a 256 MB Infinity Cache LLC is capacity- and bandwidth-favourable for large-batch decode and KV-cache-resident models. 750W, 54V UBB, passive OAM, 8 Infinity Fabric links at 128 GB/s peak. ROCm LLVM target gfx942. ON-CHIP CACHE ROW ADDED 2026-10-05 (schema authority pass, agent w5-schema) - corrected to 2026-10-05 below. `onchip_cache` is new in schemas/accelerator.schema.json. This figure was already stated in these notes and was unqueryable; the schema field exists so it can be filtered and compared instead of grepped. The value was verified against the first-party source named in `source_note`, and the trap that source contains is recorded there too. NO new number was introduced: every value below was already present in this record's own prose.