AMD Instinct MI355X
Fields
accelerators/amd-instinct-mi355xNotes
EIGHT compute dies, eight XCDs, ONE OAM package - same multi-die trap as MI300X. 288 GB is one package-level address space across 8 compute dies, NOT four 72GB devices or two 144GB devices. Each XCD has 32 CUs (8 x 32 = 256 CUs, 16,384 SPs, 1024 matrix cores), 4 MB shared L2, and 256 MB Infinity Cache shared across all 8 XCDs.
CDNA4 / TSMC 3nm compute dies paired with 6nm I/O dies; 185B transistors. ROCm LLVM target gfx950.
CONTESTED / EASY TO MISREAD: the product page and the datasheet brochure give DIFFERENT peak numbers for the same datatypes, and the difference is not error - they are two different data formats. - Product page: OCP-FP8 (E5M2/E4M3) = 5.0 PFLOPs dense / 10.1 sparse; MXFP8 = 5 PFLOPs; MXFP6 and MXFP4 = 10.1 PFLOPs. - Datasheet (GD-176): OCP-FP8 = 5.0332 / 10.0664; MXFP8 = 5.0332; MXFP6 = 10.0664; MXFP4 = 10.0663; INT8 = 5.0332 / 10.0663. Plus rows the product page omits: FP16 VECTOR 157.3 TFLOPS (vector path is 157.3 while the matrix path is 2500) and FP64 78.6 TFLOPs (vector and matrix, dense). Both are vendor numbers from AMD Performance Labs calculations dated May 2025; the ~0.06% spread is rounding to 4 significant figures vs 2. Recorded both because they are published as different figures.
Two fp16 entries above on purpose: 157.3 TFLOPS is the VECTOR path, 2500 TFLOPS is the MATRIX path. CDNA4 is the first AMD part where fp16 vector and fp16 matrix differ by ~16x on the same die. A record that only lists 2500 loses real information.
FP64: 78.6 TFLOPs, the highest of any part in this repo and roughly 2x B200's 37. AMD's own chart makes this the headline HPC comparison. MI350X 72.1, MI350P 36.
TF32: AMD's footnote says 'TF32 support through software emulation' - there is NO native TF32 matrix path on CDNA4, unlike CDNA3 (MI300X: 653.7 dense TFLOPS). Do not carry a MI300X TF32 figure forward to MI355X. There is deliberately no tf32 entry in the flops list.
Sparse figures are all exactly 2x dense (native structured sparsity), consistent with CDNA3. AMD labels sparse rows explicitly 'with Structured Sparsity', which makes AMD's tables unambiguous in a way NVIDIA's footnotes are not - do not apply an NVIDIA footnote convention to an AMD row.
MXFP6 and MXFP4 are the headline CDNA4 addition for inference: 10.1 PFLOPs, 2x the FP8 rate, which is why AMD's MI355X vs B200 comparison charts lean on FP6/MXFP6 rather than on FP4. AMD's charts quote B200 at 4.5 PFLOPS FP6 - which is the HGX B200 column's dense FP6 (9 printed sparse), consistent with nvidia-b200.
MEMORY BANDWIDTH: 8 TB/s on 8192-bit, per the product page and the MI350X spec table ('Memory Interface 8192-bit', 'Memory Clock 8 GHz'). AMD does not publish the arithmetic, so treat it as 'up to 8 TB/s'. Note the per-pin rate that 8 TB/s implies on 8192-bit is 7.81 Gbps, NOT the 8 Gb/s the 'Memory Clock 8 GHz' row suggests if read as a DDR data rate (8192 x 8 / 8 = 8,192 GB/s). The printed 8 TB/s is the vendor figure and is what is stored.
SCALE-UP: 7 Infinity Fabric links, 153 GB/s peak per link (brochure GD-176 gives the more precise 153.6), 128 GB/s scale-out link, PCIe Gen5 x16 host. The MI355X brochure states '160 GB/s bidirectional bandwidth between each GPU' on the UBB 2.0 platform. 1400 W max TBP - the highest of any part in this repo. Passive & active cooling.
AMD's own B200 comparison charts (AI Performance, HPC Performance, Memory Capacity & Bandwidth) are the independent check on NVIDIA's Blackwell figures and they quote B200 SXM 5 as 180 GB / 7.7 TB/s / FP64 37 / FP32 75 / FP16-BF16 4.5 sparse / FP8 9 sparse / FP6 4.5 - every one of which is the HGX B200 column, which is what nvidia-b200 now records.
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.