AMD's Helios 34x Claim, Decomposed: How Much Is Silicon and How Much Is Workload?

At its AAI 2026 launch, AMD put a single number on the new MI455X GPU — the engine of the Helios rack: 34x the token throughput of its own previous-generation MI355X on DeepSeek V4 Flash FP4¹². (The MI355X carries the same 288 GB at 8 TB/s memory system as an NVIDIA GB300³, so every silicon factor below happens to hold against either baseline — but the 34x itself is a generational claim, not a cross-vendor one.) Thirty-four is a strange number to hang a product on — vendors prefer round figures they can defend with one slide. AMD chose it because it survives the one test marketing numbers usually fail: the arithmetic on the chosen workload is real. The question this article answers is cheaper than buying either rack: which parts of the 34x are silicon, and which parts are choices about the workload? The decomposition is unforgiving — of the 34x, roughly 4.4x is hardware, and roughly 7.8x is everything else.

Factor the Claim Before Believing It

34x is a composite of multiplicative factors. Split it into what you can read off datasheets and what you cannot.

Two things are immediately visible. First, both silicon factors are real: the MI455X ships 2.9x the per-GPU bandwidth and 1.5x the capacity of the MI355X, and multiplying them gives 4.37x — call it 4.4x. Bandwidth matters because decode is memory-bound; capacity matters because batch size and KV-cache headroom scale with it. Because the MI355X matches a GB300 NVL72's 288 GB at 8 TB/s memory system exactly⁵³, the same factors hold against NVIDIA's Blackwell Ultra rack — but that cross-vendor comparison is ours, not AMD's: the disclosed 34x is a generational number.

Second, and this is the whole story: 34 ÷ 4.37 = 7.78. Roughly 7.8x of the claimed advantage is not silicon — it must come from workload configuration, serving-stack settings, quantization choices, and batch assumptions. AMD measured DeepSeek V4 Flash at FP4 on 432 GB cards¹; that configuration is doing enormous work in this ratio, and it is the part no datasheet can verify or refute.

Interrogating the Residual 7.8x

The residual has to be built from named, checkable mechanisms. Enumerate the plausible contributors and grade each.

FP4 model choice (large, real, partially fair). DeepSeek V4 Flash was measured at FP4 on Helios¹. Lower precision does two things at once: weights shrink (more model copies per rack, more KV room) and — if the baseline runs denser — the comparison inherits a precision mismatch. The MI355X baseline AMD actually used makes the precision question sharper: the MI355X supports FP4 as well (MXFP4 on CDNA 4)⁵, so if the baseline had also run FP4, the residual would carry no precision mismatch at all. How AMD clocked the MI355X side of the comparison is not disclosed — and against NVIDIA's GB300 (which also runs NVFP4 natively³) the same caveat applies vertically: the honest version of this factor is only the kernel and stack maturity difference, not a precision entitlement. Plausible contribution: up to 1.5–2.5x of the residual if the baseline was run at FP8; near 1x if both sides ran FP4.

Speculative decoding acceptance (large, workload-dependent). Spec decode multiplies effective throughput by the token acceptance length — 2–4x is achievable on well-tuned draft/target pairs, and it is pure software. If AMD's stack ran MTP or an external draft model and the baseline did not, this alone can carry most of the residual. Verdict: real mechanism, but it is a configuration property, not a property of 432 GB of HBM4.

MoE routing and expert-parallel placement. With 31 TB of HBM4 in a 72-GPU UALoE domain (3.6 TB/s per GPU)⁴, an MoE model keeps more experts resident and routes fewer all-to-alls off-node — this is where capacity genuinely converts to throughput for MoE serving. It is the one residual contributor that is arguably silicon-adjacent: it would not exist without the 1.5x capacity and the 72-GPU fabric. Plausible contribution: 1.3–2x, and the most defensible part of the residual.

Batch scaling off the capacity headroom. Decode throughput scales with batch size until compute-bound; batch size scales with free HBM. 432 GB versus 288 GB means 1.5x the KV cache, hence deeper batching before the memory-bound ceiling. But careful — this factor is already half-counted: the capacity ratio is the 1.5x in the silicon product. Counting it again in the residual is double-counting, the most common way vendor decompositions cheat. Verdict: only the nonlinear tail (batch past the GB300 ceiling) is legitimately additive, and it is modest, maybe 1.2x.

Serving-stack tuning. Engine choice, scheduler settings, chunked prefill, KV eviction policy — each swings tens of percent, and the banked serving-runtime churn record shows these change under your feet⁶. A benchmark team that tunes one side harder buys 1.3–1.7x without touching hardware. Verdict: real, unverifiable from the disclosure, and the buyer's discount.

Memory-bound ceiling itself. On batch-heavy decode, the bandwidth factor converts close to linearly — 2.9x bandwidth is ~2.9x tokens at ceiling. No residual available here; this is the part already counted.

The honest ledger: 4.4x silicon, roughly 1.3–2x MoE/fabric adjacency, 1.2x nonlinear batching, and the remaining 3–5x rides on FP4-vs-FP8 baseline parity and spec-decode/batch configuration. None of it is fabricated; all of it is conditional on running DeepSeek V4 Flash the way AMD ran it.

Why FP4 on a Capacity-Rich Card Flatters the Ratio

The measurement configuration deserves its own scrutiny. DeepSeek V4 Flash at FP4 on 432 GB cards is the most favorable place for Helios to stand, for three stacked reasons. First, FP4 weights halve again versus FP8, so the 1.5x capacity lead becomes a multiplier on an even larger free pool — KV cache room, resident expert copies, deeper batches. Second, a capacity-rich card quantizing hard maximizes the bandwidth-per-model-byte advantage: the 2.9x bandwidth reads are buying 4-bit reads, the densest possible traffic, which is precisely where memory-bound decode is fastest. Third, the comparison's NVIDIA baseline moves the other way: a baseline loaded denser (FP8) spends more bytes per token and looks slower on the same silicon that could also run FP4³.

None of this makes the measurement wrong. It makes it a best-case corner: the multiplication of precision, model shape, and capacity is chosen so every silicon factor is fully exercised simultaneously. A buyer serving a dense FP8 model, or a latency-sensitive low-batch workload, sits nowhere near this corner. The claim is true where it was measured, and the disclosure (AMD Performance Labs, measurements and calculations, DeepSeek V4 Flash FP4 vs MI355X)¹ says so if you read it precisely — what it does not say is what the ratio collapses to at your workload's operating point.

Ramp Reality: What Is Shipping and When

The silicon argument may survive; the delivery calendar is where hype historically goes to hide. The ground truth as of late September 2026:

• AMD CFO Jean Hu, at the Citi Global TMT Conference (September 2026): MI450 production shipments begin late Q3 2026 with revenue starting then, a "very significant step up" in Q4, further increases into early 2027, and 2027 demand "above our original initial expectation" — supply being expanded to match⁷.
• Oracle and AMD announced (October 14, 2025) that OCI will be a launch partner for the first publicly available MI450 supercluster — an initial 50,000 GPUs beginning in calendar Q3 2026⁸; Jean Hu's late-Q3 shipment guidance above is consistent with first racks reaching Oracle data centers now.
• "In production" is not "available to you": 2026 HBM4 supply is allocated to hyperscaler-class buyers; for everyone else Helios volume is a 2027 conversation⁷. Meanwhile SemiAnalysis (via CNBC, July 6, 2026) reported NVIDIA's next-gen Kyber NVL144 rack architecture — the Rubin Ultra carrier — delayed to 2028 over PCB-midplane manufacturability, while the same-generation Vera Rubin NVL72 is in full production shipping this fall⁹. The calendar comparison is in flux on both sides.
• The check that matters is not the keynote but the Q4 revenue step a CFO has now publicly guided to⁷. If it prints, the ramp is real; if it softens, the 34x was the easy part.

Verdict: Real Arithmetic on a Chosen Workload, Not a Silicon Verdict

The 34x is honest arithmetic on the configuration AMD chose: every factor is plausibly real, the silicon half is datasheet-verifiable, and the disclosure names the model, precision, and baseline — AMD's own MI355X¹. What it is not is 34x the delivered throughput you will see. A buyer should discount in this order:

1. Keep the 4.4x. Bandwidth and capacity are physical; they convert roughly linearly on memory-bound workloads.
2. Discount the precision corner. If your model runs FP8, or your SLA forbids FP4 corner behavior, a chunk of the residual was never yours.
3. Re-run the spec-decode and batch assumptions at your traffic shape. Acceptance length and batch depth are workload-specific, not purchaseable.
4. Price the stack, not just the GPU. Runtime churn on both platforms moves measured numbers by tens of percent between releases⁶.

Our critical-review verdict on the MI400 generation stands⁴: the paper roofline favors both decode and prefill for the first time, and Helios is the first credible rack-scale answer AMD has offered. The 34x decomposes the way every good marketing number does — a true fact about silicon, multiplied by a chosen workload, presented as a single number. Buy the silicon; re-derive the rest.

Article first published: September 24, 2026 Author: flozi00

Related Reading

• AMD MI300X/MI350/MI400 Critical Review — the datasheet-level foundation this decomposition is built on
• Serving Engine Churn 2026 — why stack assumptions in any benchmark drift
• The KV Cache: Bit-Exact Memory Math — how capacity converts to batch depth