AWS Trainium2

Derived, not published per chip: Trn2.48xlarge holds 16 Trainium2 chips with 1.5 TB HBM3 and 46 TB/s aggregate (aws.amazon.com/ec2/instance-types/trn2). 1.5 TB / 16 = 96 GB per chip and 46 TB/s / 16 = 2875 GB/s per chip. Per-chip figures are corroborated by the Trn2.3xlarge row, which lists 1 chip with 96 GB.

IMPORTANT: AWS does not publish a Trainium2 datasheet. The per-chip numbers here are DIVIDED OUT of the published Trn2 instance aggregates, so they carry the vendor-claim flag and lower confidence: 20.8 FP8 PFLOPS / 16 chips = 1300 TFLOPS FP8 per chip. Trainium2 ships with 8 HBM3 stacks per chip and NeuronLink chip-to-chip links inside each instance; Trn2.48xlarge = 16 chips, UltraServer = 64 chips across 4 instances at 83.2 FP8 PFLOPS and 6 TB HBM3 / 185 TB/s. BF16/FP16 per-chip peak is not published in either source, so it is left out rather than assumed to be half the FP8 number. The relevant architecture point for inference is Neuron's automatic casting: FP32 and FP16 models are autocast down to BF16/FP8/cFP8 at compile time, which changes effective throughput without changing the peak number. Trainium3 (144 GB HBM3e, 4.9 TB/s, 8 large cores with Tensor/Vector/Scalar/GPSIMD engines, hardware W4A8) exists and is shipping per the Trainium product page; it is deliberately not modelled 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). AWS publishes no memory-bus width for Inferentia or Trainium. The Neuron hardware documentation and the EC2 instance-type pages give capacity and aggregate bandwidth only. Not back-computed: Trainium2's published figure is a per-instance aggregate across a 16-chip pod, not a per-chip number, so dividing it by chip count yields a pod figure rather than a bus width. 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.