Intel Gaudi 3 (HL-325 OAM / HL-338 PCIe)

Vendor-published per-accelerator figure from the Gaudi 3 technical paper: 128 GB HBM2e across 8 chips and 3.7 TB/s of HBM bandwidth.

Two compute dies on an interposer bridge, presented to software as one unified die: 8 MME engines, 64 TPC engines and 24x 200 Gbps RDMA NIC ports in total. The published BF16 and FP8 MME TFLOPS are IDENTICAL at 1678, which is unusual and worth not misreading as a typo: Intel's paper reports both matrix engines at that figure, and separately quotes BF16 VECTOR TFLOPS at 28.7. Dense/sparse is not stated in the paper, so both rows are marked dense on the vendor's own framing. TDP is not published in the technical paper. THE HIERARCHY POINT: unlike the SRAM-only parts, Gaudi 3 has a real memory hierarchy with a meaningful SRAM tier between HBM and compute - 96 MB on-die (double Gaudi 2's 48 MB) at 12.8/6.4 TB/s read/write - which is what lets it run batch-1 decode with less pure HBM traffic than its compute peak would suggest. At 3.7 TB/s and 128 GB it sits at 453 FLOP/byte BF16, so it is memory-bound at batch 1 but far less severely than a 3-4x faster compute part would be. Ethernet-first scaling is the strategic point: 1200 GB/s bidirectional of RoCE versus H100's 900 GB/s of closed NVLink, and 24 200G NICs per part versus H100's 18. That trades a software problem (collectives over standard Ethernet) for avoiding proprietary fabric lock-in. Ships as OAM HL-325/HL-325L, PCIe HL-338, and the HLB-325 baseboard. AUDIT 2026-10-04 (PCIE PER-DIRECTION VERIFIED, no value changed): Intel's Gaudi 3 technical paper Table 1 prints 'Host Interface Peak BW | 128 GB/s (64 GB/s per direction)' against Gaudi 2's '64 GB/s (32 GB/s per direction)'. Intel's published peak figure is the BIDIRECTIONAL AGGREGATE; per direction it is half. 64 GB/s per direction on Gen5 x16 is exactly 32 GT/s x 16 lanes / 8 = 64 GB/s, confirming the convention. Do not halve the 128 GB/s aggregate again. The same table independently confirms this record's other stored values: HBM Capacity 128 GB, HBM Bandwidth 3.7 TB/s (stored 3700 GB/s), Networking (bidirectional) 1200 GB/s, BF16 MME TFLOPS 1678, FP8 MME TFLOPS 1678 - note Intel prints the SAME 1678 for BF16 and FP8, which is why both rows here are 1678 and is NOT a transcription error; Gaudi 3's FP8 MME rate equals its BF16 MME rate because FP8 arrives at no MME throughput gain on this part. POWER: tdp_w was null with a note asserting 'TDP is not published in the technical paper'. That is FALSE. Intel publishes it twice in the Gaudi 3 technical paper: Table 8 gives '600 W | 900 W' for Gaudi 2 OAM vs Gaudi 3 OAM, and the prose gives 'up to 900W Total Device Power' for the HL-325L OAM. 900 W is the Gaudi 3 OAM (HL-325 OAM) figure; the Gaudi 3 PCIe form factor HL-338 is 600 W. The single tdp_w field cannot hold both form factors, so it holds the OAM value and the alternative is named here. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). READ THIS ONE, IT IS THE CLOSEST CALL IN THE REPO AND IT IS STILL LEFT NULL. Intel's Gaudi 3 technical paper DOES publish everything needed to DERIVE the width - 'Intel Gaudi 3 AI accelerator integrates 8 HBM2e devices running at 3.6GHz frequency, providing 3.7 TB/s peak HBM bandwidth', plus Table 8's '8 x HBM2E | 128 GB | 3.7 TB/s' against Gaudi 2's '6 x HBM2E | 96 GB | 2.46 TB/s'. The stack counts (6 and 8) and the per-stack capacity (16 GB each) are vendor-stated. What Intel does NOT state is the width of a single HBM2E stack, so the derivation has a free parameter: the same 8 stacks and 3.7 TB/s are consistent with any per-stack width yielding 462.5 GB/s per stack, and the arithmetic does not close on a clean number without also assuming a per-pin rate. 8192 bits total is the physically plausible answer for 8 stacks, but 'physically plausible' is exactly the standard this repo forbids. LEFT NULL with what was looked for recorded here, per AGENTS.md rule 5. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.