AWS EC2 Trn1 / Trn2 (AWS Trainium and Trainium2)

per Trainium chip-hour. trn1.32xlarge = 16x Trainium, on-demand $21.50/instance-hr / 16 = $1.3438; Capacity Block $9.532/16 = $0.596 (AWS's own per-accelerator figure). trn1n.32xlarge = $24.78/16 = $1.5488. trn2.48xlarge = 16x Trainium2, NO on-demand rate published in the us-east-1 price list - Capacity Block only, $35.7608/16 = $2.235; trn2.3xlarge = 1x Trainium2 at $2.235. Fetched 2026-10-03 PERISHABLE-FIGURE STAMP (added 2026-10-04, uniform across data/supply/ so it is greppable). PRICE CLASS: PUBLISHED LIST PRICE - an asking rate a new customer is quoted, NOT a realised, discounted or negotiated transaction rate. A real bill is at or below this and typically well below it once commitments, credits and committed-use discounts apply. OBSERVED: 2026-10-03 RE-VERIFY BY: 2027-01-04 - the repo's quarterly re-verification bar. After that date this figure is presumed drifted and must be re-checked against its source before it is quoted again. A price without its observation date is noise; this stamp exists so a reader can tell a fresh figure from a stale one without reading prose. UNIT: per Trainium chip-hour READING RULE: No further perishable flag is published for this figure.

lead_time_weeks is null because the quantity is structurally not applicable: on-demand cloud capacity starts on request, so there is no order-to-delivery lead time. The constraint is the price per GPU-hour and the availability snapshot, not an interval. The one caveat worth keeping: scarce tiers gate capacity behind a reservation or Capacity Block commitment (AWS caps the booking horizon at 8 weeks, source spl-aws-capacity-block-booking-horizon), and that is a commitment window, not a lead time.

not an EAR citation: provider service terms and end-use policy (the AI Diffusion Rule briefly tiered service access before its 2025-05-13 rescission)

MECHANISM: first-party silicon (AWS Trainium/Inferentia, Google TPU), which is not US-origin and is not classified under ECCN 3A090 at all, so the hardware regime does not apply. The live controls are the provider's own regional service-availability policy and the destination's import rules; this repo has no primary source for either, which is why the boolean is null rather than false.

Trainium1 at $1.34/chip-hour is the cheapest on-demand accelerator hour any hyperscaler publishes in this slice, and 4x cheaper again via Capacity Block at $0.596 - but that is an apples-to-oranges comparison against GPU pricing and should not be read as 'Trainium is cheap'. You pay in Portability: workloads run through AWS Neuron (PyTorch and JAX native), not CUDA, and every kernel, quantization format and engine elsewhere in this repo assumes CUDA unless it lists a TPU or Neuron path. trn2 has NO on-demand rate published at all in the price list fetched, the same capacity signal as the p5 $0.00 sentinel - you get it via Capacity Block reservation. Trainium2 spec from the product page: 96GB HBM per chip; 1.5TB and 46TB/s per 16-chip instance; trn2u.48xlarge joins a 64-chip UltraServer over NeuronLink. AWS claims 30-40% better price-performance than GPU-based P5e and P5en - a vendor claim, and price-performance is not price. No published commitment or savings-plan discount for trn1/trn2; Capacity Block is the discount channel. Anthropic's Project Rainier runs on Trainium2, which is evidence the software path is real, not that it is easy. EXPORT CONTROL (2026-10-04): this is a first-party silicon SKUs record (AWS Trainium / Google TPU) - non-US-origin designs that are not classified under the US ECCN 3A090 advanced-computing regime at all. Recorded null deliberately rather than false: the EAR does not govern the part, so the relevant controls are AWS's and Google's own regional service-availability policies plus the destination's import rules, which this repo has no primary source for. Do NOT read null here as 'unrestricted'. Sources for why a null is the honest answer rather than a gap: spl-eccn-3a090-ccl (the US regime whose scope is defined by US-origin classification), spl-bis-2026-05-d5-guidance (end-user/parent screening, which applies to where the customer is rather than to which silicon is supplied). LEAD TIME: null, and correct as null. For a listed on-demand instance type the provisioning delay is effectively zero - capacity is allocated per request - so a week count would be meaningless; the real gate for scarce shapes is either a quota increase or a capacity reservation, not a lead time. Where a published commitment horizon exists it IS recorded: AWS documents that a Capacity Block may be reserved with a start time up to EIGHT WEEKS in the future (source spl-aws-capacity-block-booking-horizon), which is a floor on how far ahead scarce capacity must be committed, not a wait. On-demand and Spot tiers publish no lead time at all; their constraint is availability, and the repo records that as availability=in-stock or a spot/reality note rather than as a fabricated week figure. Probe log in source spl-negative-no-oem-publishes-lead-time.