AWS puts Trainium3 into production and makes chip speed only part of the test

On December 2, 2025, AWS announced general availability of EC2 Trn3 UltraServers powered by Trainium3. The official specification calls it AWS's first three-nanometer AI chip and the company's fourth generation of AI silicon. Each UltraServer can join as many as 144 chips through a fabric designed to move data among accelerators.

The launch arrived alongside Amazon Nova models and services, but it does not by itself demonstrate a break with Nvidia or lower cost for every application. The durable skill is to compare accelerators by correct task and total migration cost, not by the largest multiplier on a slide.

What AWS's figures measure

AWS says each Trainium3 provides 2.52 petaflops of FP8 compute, 144 GB of HBM3e memory, and 4.9 TB per second of bandwidth. A full UltraServer totals 20.7 TB of memory and 706 TB per second of aggregate bandwidth. These theoretical or system capacities help show which models fit and how quickly data can move; they do not directly predict application tokens per second.

AWS reports up to 4.4 times higher performance, 3.9 times more memory bandwidth, and four times better performance per watt than Trn2 UltraServers. In Bedrock, it attributes up to three times more performance and more than five times the output tokens per megawatt at similar user latency to Trainium3. Every baseline is an earlier Trainium system measured by the vendor.

Transferring those figures requires the full axis: model, precision, batch size, input and output length, concurrency, latency target, software, and quality. FP8 accelerates certain operations, but a workflow may require another precision. “Up to” identifies a best observed point, not the workload distribution.

Cost per correct task

The numerator includes instance rental, storage, networking, compilation, engineering time, observability, and idle capacity. The denominator should not be tokens alone, but tasks satisfying the criterion. If precision changes or model adaptation degrade answers, apparent savings per token can raise the cost per acceptable result.

Training and inference need separate scorecards. Training cares about time to a target metric, stability, restarts, and cluster utilization. Inference cares about time to first token, total latency, throughput under concurrency, cache memory, and error rate. A chip can win one axis and lose another.

Energy also needs a boundary. Accelerator performance per watt is not data-center consumption. CPU, networking, memory, cooling, and electrical losses remain. Tokens per megawatt includes more of the system but still depends on the model and output quality. A fair comparison holds task, service level, and quality constant.

Compatibility is not performance portability

AWS says native PyTorch integration allows training and deployment without changing model code. Trainium3 nevertheless relies on the Neuron SDK, compilers, and libraries to map operations to the chip. Code that starts is not necessarily code that uses the architecture efficiently, and every operator may not be optimized.

A migration trial records code changes, compile time, operations falling back to another processor, and debugging tools. It also keeps a working version on another platform. That second route may cost something while unused, but it reduces exposure to capacity, pricing, and future compatibility changes.

Portability has three levels. Source portability runs the same program. Artifact portability moves weights and checkpoints. Performance portability preserves cost and latency targets. A provider may satisfy the first without the third. A decision must name the level the business requires.

Networking and utilization determine the outcome

Large models exchange gradients, activations, or experts across accelerators. UltraServer includes NeuronSwitch for chip-to-chip communication. When a workload waits for data or synchronizes imbalanced components, more compute does not yield proportional speed. Tests should separate computation time from communication and identify the saturated resource.

Utilization also follows demand shape. A service with spikes may reserve hardware to meet latency and leave it idle later. Dynamic batching increases throughput but can add waiting. The trial needs the real hourly pattern and percentiles, not a continuous run that keeps every chip occupied.

Regional availability, quotas, and provisioning time are also part of the system. A cheaper accelerator is not useful if it cannot be obtained when training begins or requires regulated data to move. The decision table includes regions, reserved capacity, failure recovery, and transfer costs.

Nova Forge deepens customization and attachment

AWS introduced Nova Forge the same day. Customers can start from Nova checkpoints at pretraining, mid-training, or post-training, mix proprietary data with Amazon-curated data, and host the result in Bedrock. At launch, it was available in US East in Northern Virginia.

Amazon calls the approach open training, but it should not be confused with an open-weight model deployable on any infrastructure. Forge opens customization stages inside a managed service. It may avoid training from scratch and reduce catastrophic forgetting through data mixing; it also couples Nova checkpoints, recipes, SageMaker, and Bedrock.

Before using it, teams should ask who controls the resulting model, whether weights and optimizer state can be exported, how data is deleted, which logs remain, and what happens when service ends. Depth of customization and freedom to leave are separate axes.

Nova Act shows that the chip is not the product

AWS also made Nova Act generally available for browser-interface automation. It combines a model, orchestration, browser, logs, and human escalation. AWS reported more than 90% task reliability, but the public post does not provide a full distribution that transfers the percentage to every website.

A five-step flow has more failure opportunities than a one-step task. Authentication, pop-ups, languages, and layout change. Useful evaluation measures end-to-end completion, silent errors, irreversible actions, recovery time, and intervention. For purchases, messages, or account changes, an average cannot replace confirmation before execution.

This layer shows why an accelerator does not determine product value. Reliable applications depend on models, tools, permissions, interfaces, and observability. Optimizing tokens without measuring the flow can accelerate an agent doing the wrong thing.

Test the exit before entering

A practical comparison starts with tasks and a quality floor. Run them on Trainium3 and at least one alternative, using the same model where possible and documented configurations. Record accuracy, latency, throughput, memory, energy, price, adaptation hours, and failures. Then simulate real demand and an interruption.

The exit test asks whether weights, data, logs, and code can migrate, how long that would take, and which functions disappear. It also prevents “less reliance on Nvidia” from becoming “no dependency.” Diversifying silicon can still concentrate cloud, compiler, and services inside AWS.

Trainium3 expanded a production alternative, while Nova extended the stack from chip to agent. The transferable skill is to evaluate that stack by cost per correct task, three levels of portability, utilization, and an exit route. Only then does a technical multiplier become a business decision.