Strix Halo Memory Bandwidth: Why 256 GB/s Isn't 256 GB/s (2026)

Quick answer: Strix Halo's 256-bit LPDDR5X-8000 bus is rated 256 GB/s theoretical, but real sustained throughput on the 128GB boxes lands near 215 GB/s — about 84% of spec. That ~215 GB/s, divided by the bytes each token must read, is the hard ceiling on local LLM generation speed. It is comfortably enough for Mixture-of-Experts models and 24–32B dense models; it is not enough to make a dense 70B feel interactive, because 20 tok/s on a 38.5 GB model would require roughly 770 GB/s. No amount of Infinity Cache changes that arithmetic — which is why a dense 70B crawls on the same silicon that runs a 30B MoE at conversational speed.

The two numbers on the spec sheet — and which one is real

Every Strix Halo product page leads with the same figure: 256 GB/s. AMD's own Ryzen AI Max+ 395 material describes a 256-bit LPDDR5X-8000 interface, and 256 bits × 8000 MT/s ÷ 8 bits per byte is exactly 256 GB/s. It is an honest number in the sense that the arithmetic is correct. It is a misleading number in the sense that nothing you run will ever see it.

Our catalog carries both figures because both matter. The GMKtec EVO-X2, Minisforum MS-S1 Max and Framework Desktop are all specified as "256 GB/s theoretical (~215 GB/s real)". That gap — 41 GB/s, or a 16% derate — is the single most useful number in this entire post, because 84% of peak is the ratio you should apply to any unified-memory bandwidth claim you read anywhere.

Two things follow immediately. First, if you sized your expectations off 256 GB/s, everything you predicted is about 16% optimistic. Second — and this is the part that saves people money — the derate is a property of DRAM and bus behaviour, not of the box you bought. Returning an EVO-X2 for a GTR9 Pro will not recover those 41 GB/s.

Where the missing 40 GB/s goes

Theoretical peak assumes the memory bus is transferring useful data on every single clock. Real DRAM does not work that way. Refresh cycles take the array offline periodically. Bank conflicts and row activations cost cycles that move no data. Read-to-write turnaround on a shared bus costs more. And a real inference engine interleaves weight streaming with KV-cache reads and writes, which is a messier access pattern than a pure sequential benchmark. Losing 15–20% to that is normal across every memory technology; LPDDR5X is not unusually bad here.

There is a second, less obvious asymmetry that catches people who benchmark with CPU-only tools. Chips and Cheese, in Strix Halo's Memory Subsystem: Tackling iGPU Challenges, measured the CPU side of the chip and found a single CCD's roughly 128 GB/s theoretical link delivering around 103 GB/s observed, with about 175 GB/s across both CCDs on a read-modify-add pattern. Those are Chips and Cheese's measurements on the CPU path, not ours and not the iGPU path — but they explain a very common support ticket. If you run inference on the CPU cores instead of the Radeon 8060S iGPU, you are working against a lower ceiling than the platform's headline number, and a single-threaded test is lower still.

This confusion reaches real owners. The ublue-os/bazzite tracker carries an issue titled "Abnormally low memory-bandwidth on a Strix Halo desktop" — a user hitting the theoretical-versus-real gap and reasonably filing it as a bug. The practical lesson: a badly configured Linux install, a wrong GPU memory carve-out, or a benchmark that only exercises one core can all put you below the ~215 GB/s baseline. Getting your allocation right is the difference between "normal" and "broken", and we cover exactly that in our Strix Halo VRAM allocation guide.

Worth stating plainly, because the internet gets this backwards: ~215 GB/s is not a defect. It is the expected result. The number to chase is not 256 — it is making sure you are not accidentally at 103.

Does Infinity Cache save you? (Partly — and not for the part you care about)

Strix Halo carries a 32MB MALL (Memory Attached Last Level cache, AMD's Infinity Cache) sitting in front of DRAM. On paper this looks like the escape hatch: cache is far faster than DRAM, so surely it lifts the bandwidth ceiling.

The cache really is fast. In Chips and Cheese's Evaluating the Infinity Cache in AMD Strix Halo, Nemes's Vulkan bandwidth test measured the 32MB MALL delivering close to 1 TB/s, with the 4MB L2 above it around 2.5 TB/s. Again: those are Chips and Cheese's figures, cited here, not DataHardware measurements.

Now the honest limit that almost nobody writing about this chip will tell you. A 40GB quantised model does not fit in 32MB. It is not close — 32MB is roughly one part in twelve hundred of a 4-bit 70B. Token generation requires streaming the model's weights through the compute units once per token, and weights that large are read from DRAM every time, at DRAM speed. The cache is behaving correctly; it simply has nothing useful to hold when the working set is three orders of magnitude larger than it is.

What the MALL does help:

• Activations and intermediate tensors — small, hot, re-read within a layer. Genuine win.
• KV-cache traffic at short context lengths, before the cache grows past 32MB.
• Prefill and graphics workloads, which are compute-dense and reuse data — the reason AMD put a MALL on an iGPU-heavy chip in the first place.
• Small models — a 3B at Q4 is still ~1.7 GB, so even here the weights live in DRAM, but the surrounding traffic benefits.

What it does not help: the per-token weight read that sets your tokens-per-second ceiling. That is the honest answer, and it is why the formula below uses DRAM bandwidth and not cache bandwidth. If you want the compute-bound side of the picture, where cache matters much more, read our companion piece on prefill and time-to-first-token.

The formula: turning GB/s into tokens/sec

Here is the arithmetic that converts a bandwidth spec into something you can actually check against the model you want to run:

tokens/sec ceiling ≈ memory bandwidth ÷ bytes read per token

Two rules fill in the denominator. A dense model reads every parameter for every token. A Mixture-of-Experts model keeps all its parameters resident in memory but reads only the active ones (plus shared attention and routing layers) per token. At 4-bit quantization, a reasonable working figure is ~0.55 bytes per parameter — Q4_K_M-class quants land near 4.4 bits including per-block scaling overhead.

The table below applies that at ~215 GB/s. Every "ceiling" figure here is derived from the formula — it is an estimate, not a benchmark we ran. Measured results live in our Strix Halo tokens-per-second post, and the right-hand column shows how the two compare.

Read the right-hand column carefully, because it contains the second insight of this post. The gap between formula ceiling and measured result is not constant — it widens as models get smaller and sparser. A dense 70B lands within ~10% of its ceiling: the per-token read is one enormous sequential stream, which is the best case a memory controller ever sees, and there is so much of it that per-token software overhead disappears into the noise. A 3B-active MoE lands at roughly half its ceiling, because the read is short, scattered across experts, and dominated by routing, attention and framework overhead. GPT-OSS 120B lands lowest of all against the naive ceiling — its per-token traffic includes far more than just the active expert weights.

So the practical rule: derate the formula by 50–75% for MoE and small dense models, and treat it as near-exact for large dense models. Then use it in reverse, which is where it earns its keep — required bandwidth ≈ target tok/s × bytes per token:

• 20 tok/s on a dense 70B → 20 × 38.5 GB = ~770 GB/s. Only a Mac Studio M3 Ultra (819 GB/s) clears that, and only just.
• 20 tok/s on a dense 32B → 20 × 17.6 GB = ~352 GB/s. Out of reach for Strix Halo, comfortable for a Mac Studio M4 Max.
• 20 tok/s on a 3B-active MoE → 20 × 1.7 GB = ~34 GB/s. Almost any modern box does this.

That last line is the whole buying decision compressed into one number. Sizing capacity as well as speed? Run your specific model and context length through our VRAM calculator.

Strix Halo vs everything else: the bandwidth table

Here is the full field, straight from our catalog. Prices are the latest verified figures we hold, and they move — the 2026 DRAM crunch has been rewriting them all year.

The headline the table delivers: Apple's M3 Ultra moves roughly 3.8× the real bandwidth of a Strix Halo box (819 vs ~215 GB/s), while Strix Halo matches it on usable capacity — 128GB versus the 96GB Apple still sells — for several hundred dollars less. That is the trade in one sentence. Bandwidth buys you speed on dense models; capacity buys you the ability to load big ones at all. Strix Halo is a capacity play with adequate bandwidth; the Mac Studio line is a bandwidth play with adequate capacity.

The GB10 boxes sit in between, and the 273-vs-~215 GB/s gap is smaller than their price gap suggests — you buy a DGX Spark or Ascent GX10 for CUDA and clustering, not for the 27% bandwidth edge. We split that hair head-to-head on DGX Spark vs EVO-X2. If bandwidth is genuinely your binding constraint, M3 Ultra vs DGX Spark is the more honest comparison, and Mac Studio M4 Max vs Strix Halo is the natural next read.

One thing the table cannot show: all of these use soldered memory. There is no upgrade path on any row. Whatever you buy is what you own.

So is 215 GB/s enough? A model-by-model verdict

The buying section. Green, yellow, red — each with the box that answers it.

The reframe that should decide your purchase: the "not enough bandwidth" complaint is almost entirely a dense-70B complaint, and in 2026 the models most people actually run are MoE. For a walkthrough of what fits and what flies on a 128GB box, see the best local LLM models for a 128GB mini PC.

Which box to buy for your bandwidth budget

Peak bandwidth is a silicon fact — every Ryzen AI Max+ 395 box has the same ceiling, and the Strix Halo hub lists the full field. What differs is price, I/O and how long the cooling holds that ceiling under sustained load. Pick on those:

• Cheapest credible 128GB entry: Framework Desktop ($3,449) — same ~215 GB/s as anything else here, in a standard mini-ITX chassis.
• Flagship appliance: GMKtec EVO-X2 ($3,649) — quiet, dual-M.2, up to 96GB GPU-allocatable. EVO-X2 vs Framework Desktop splits them.
• Networking and I/O: Beelink GTR9 Pro ($4,349) — dual 10GbE and vapor-chamber cooling, spec'd at ~256–273 GB/s. See EVO-X2 vs GTR9 Pro.
• Expansion and rack mounting: Minisforum MS-S1 Max ($3,719) — PCIe x16, 320W PSU, 2U option.
• ECC and business support: HP Z2 Mini G1a ($3,300–$3,734) — the faster LPDDR5X-8533 memory, with ECC.
• CUDA at 273 GB/s: NVIDIA DGX Spark ($4,699+) or ASUS Ascent GX10 ($4,999–$6,540).
• Bandwidth over everything: Mac Studio M3 Ultra at 819 GB/s ($3,999 for 96GB), or Mac Studio M4 Max at 410–546 GB/s with up to 128GB — the Apple Silicon hub has the rest.

One timing note. AMD's Gorgon Halo (Ryzen AI Max 400) refresh pushes on-device memory to 192GB, and DRAM contract prices rose roughly 180% in Q1 2026 versus Q4 2025 (TrendForce) — which is why NVIDIA raised the DGX Spark from $3,999 to $4,699 citing memory supply. That is a capacity story, not a bandwidth story: more memory does not mean a faster bus. If you are timing a purchase around it, our wait-or-buy analysis works through it.

Bottom line

Strix Halo's 256 GB/s is a theoretical peak; real sustained memory bandwidth is approximately 215 GB/s — about 84% of spec — and that ~215 GB/s, divided by the bytes each token must read, is the hard ceiling on local LLM generation speed, which is why a dense 70B crawls on the same silicon that runs a 30B MoE at conversational speed. The 32MB Infinity Cache is genuinely fast (close to 1 TB/s, per Chips and Cheese) and genuinely irrelevant to weight streaming, because a 40GB model does not fit in 32MB. Run the formula against the model you actually intend to use before you spend $3,449 or more: if it is MoE or dense-32B-and-under, ~215 GB/s is plenty and Strix Halo's 128GB of unified memory is the best capacity-per-dollar on the market. If it is a dense 70B you want to chat with, no box in this class will satisfy you, and you should be shopping the 819 GB/s end of the table instead.