inference/research
verifiedhigh · 0.90updated 2026-10-08

Intel Gaudi 2

intel gaudi-2 2022

Fields

id
accelerators/intel-gaudi2
Vendor
intel
Architecture
gaudi-2
Release year
2022
Process (nm)
7
Form factors
oam
VRAM (GB)
96
Memory type
hbm2e
Memory bandwidth (GB/s)
2,460
Bandwidth basis
Vendor-published per-accelerator figure from the Gaudi 3 technical paper's Gaudi 2 vs Gaudi 3 comparison table: 96 GB HBM2e at 2.46 TB/s.
Peak FLOPS
precisionbf16tflops432denseyesvendor_claimyessource_idasic-intel-gaudi3-tech-paperbasisvendor-whitepaperbasis_detailGaudi 3 technical paper's Gaudi 2 comparison column - Intel has never published a standalone Gaudi 2 datasheet, so these are vendor numbers reached second-hand. The 112 row is VECTOR bf16 (unit bf16-vector-tflops), a different unit from the 432 MME row and not a contradiction of it.precisionfp8tflops865denseyesvendor_claimyessource_idasic-intel-gaudi3-tech-paperbasisvendor-whitepaperbasis_detailGaudi 3 technical paper's Gaudi 2 comparison column - Intel has never published a standalone Gaudi 2 datasheet, so these are vendor numbers reached second-hand. The 112 row is VECTOR bf16 (unit bf16-vector-tflops), a different unit from the 432 MME row and not a contradiction of it.precisionbf16tflops112denseyesvendor_claimyessource_idasic-intel-gaudi3-tech-paperunitbf16-vector-tflopsnotesBF16 VECTOR path (scalar ALUs), not the MME matrix path. Recorded as its own row with a distinct unit because Gaudi quotes 432 MME BF16 TFLOPS and 112 BF16 vector TFLOPS on the same part; they are different quantities and must not be compared or summed. MME is the tensor-core path that runs matrix work; the vector path is what runs elementwise and reduction work.basisvendor-whitepaperbasis_detailGaudi 3 technical paper's Gaudi 2 comparison column - Intel has never published a standalone Gaudi 2 datasheet, so these are vendor numbers reached second-hand. The 112 row is VECTOR bf16 (unit bf16-vector-tflops), a different unit from the 432 MME row and not a contradiction of it.
TDP (W)
600
Unified memory
yes
Consumer part
no
notes
Numbers are taken from the Gaudi 3 technical paper's comparison table, since Intel never published a standalone Gaudi 2 datasheet that is reachable; treat them as vendor-published but second-hand. The third flops row is BF16 VECTOR TFLOPS (112), a different unit to the first two (MME TFLOPS 432) and therefore NOT a contradiction - it is recorded as its own flops row with unit 'bf16-vector-tflops' so the two quantities are never compared or summed. CORRECTED 2026-10-04: the notes previously claimed this row existed in the flops array when it did not - only the 432 MME and 865 FP8 rows were present.. On-die SRAM is 48 MB at 6.4/6.4 TB/s, half of Gaudi 3. 2 MME units and 24 TPC units. 600 GB/s bidirectional networking versus Gaudi 3's 1200. Host interface is PCIe Gen4 x16 at 64 GB/s peak versus Gaudi 3's PCIe Gen5 at 128. AUDIT 2026-10-04 (PCIE PER-DIRECTION VERIFIED, no value changed): Intel's Gaudi 3 technical paper Table 1 prints the host link with an explicit direction split that removes all ambiguity - 'Host Interface Peak BW | 64 GB/s (32 GB/s per direction) | 128 GB/s (64 GB/s per direction)' for Gaudi 2 and Gaudi 3 respectively. So Intel's own 'peak BW' figure is the BIDIRECTIONAL AGGREGATE and the per-direction number is half of it. 32 GB/s per direction on Gen4 x16 is exactly 16 GT/s x 16 lanes / 8 = 32 GB/s, confirming the convention. The 64 GB/s in this record is therefore already the aggregate and must NOT be halved again - this is the specific double-halving failure mode flagged for this repo, and Intel publishing both numbers in the same table cell is what makes it preventable. Nothing in this record stores a per-direction PCIe figure, so no numeric field changed; the annotation exists so a future reader does not 'fix' a number that is already right. Included as a separate record because it remains in cloud and OEM fleets and because the architectural delta (SRAM tier, MME/TPC split, die count) is what makes the Gaudi 3 comparison meaningful. Still shipping in Intel's own and OEM racks and on IBM Cloud / AWS DL1. 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. 600 W is the Gaudi 2 OAM (HL-225 OAM) figure. 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.

Notes

Numbers are taken from the Gaudi 3 technical paper's comparison table, since Intel never published a standalone Gaudi 2 datasheet that is reachable; treat them as vendor-published but second-hand. The third flops row is BF16 VECTOR TFLOPS (112), a different unit to the first two (MME TFLOPS 432) and therefore NOT a contradiction - it is recorded as its own flops row with unit 'bf16-vector-tflops' so the two quantities are never compared or summed. CORRECTED 2026-10-04: the notes previously claimed this row existed in the flops array when it did not - only the 432 MME and 865 FP8 rows were present.. On-die SRAM is 48 MB at 6.4/6.4 TB/s, half of Gaudi 3. 2 MME units and 24 TPC units. 600 GB/s bidirectional networking versus Gaudi 3's 1200. Host interface is PCIe Gen4 x16 at 64 GB/s peak versus Gaudi 3's PCIe Gen5 at 128. AUDIT 2026-10-04 (PCIE PER-DIRECTION VERIFIED, no value changed): Intel's Gaudi 3 technical paper Table 1 prints the host link with an explicit direction split that removes all ambiguity - 'Host Interface Peak BW | 64 GB/s (32 GB/s per direction) | 128 GB/s (64 GB/s per direction)' for Gaudi 2 and Gaudi 3 respectively. So Intel's own 'peak BW' figure is the BIDIRECTIONAL AGGREGATE and the per-direction number is half of it. 32 GB/s per direction on Gen4 x16 is exactly 16 GT/s x 16 lanes / 8 = 32 GB/s, confirming the convention. The 64 GB/s in this record is therefore already the aggregate and must NOT be halved again - this is the specific double-halving failure mode flagged for this repo, and Intel publishing both numbers in the same table cell is what makes it preventable. Nothing in this record stores a per-direction PCIe figure, so no numeric field changed; the annotation exists so a future reader does not 'fix' a number that is already right. Included as a separate record because it remains in cloud and OEM fleets and because the architectural delta (SRAM tier, MME/TPC split, die count) is what makes the Gaudi 3 comparison meaningful. Still shipping in Intel's own and OEM racks and on IBM Cloud / AWS DL1.

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. 600 W is the Gaudi 2 OAM (HL-225 OAM) figure. 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.

Cross-references

Interconnect (2)