AMD Strix Halo (32GB)

AMD Strix Halo (32GB): AMD unveiled Strix Halo (retail name: Ryzen AI Max 300 series) at CES on January 6, 2025, and 32GB is the one tier where the chip behind it genuinely varies by vendor. ASUS's ROG Flow Z13 (GZ302) pairs its 32GB configuration with the same flagship Ryzen AI Max+ 395 the larger tiers get (16 Zen 5 cores, 40-compute-unit Radeon 8060S iGPU, RDNA 3.5, 14.8 TFLOPS FP16), at roughly $2,999.99 MSRP; a Best Buy sale as recently as July 2026 cut the 64GB configuration of the same laptop to $2,099.99, briefly undercutting its own 32GB list price for double the memory. Framework Desktop's base $1,099 configuration instead substitutes the cut-down Ryzen AI Max 385: 8 Zen 5 cores and a 32-compute-unit Radeon 8050S rated 11.5 TFLOPS FP16, about 22% less than the full chip. Either way, memory bandwidth is unaffected: quad-channel LPDDR5X-8000 over a 256-bit bus gives the same 256 GB/s theoretical ceiling as every other Strix Halo tier this site tracks (independent testing measures roughly 215 GB/s, ~84%, of that actually achieved), so this site's bandwidth-bound tok/s estimate doesn't change between the two chips; what does change is compute-bound prompt processing, which this site doesn't model.

This site's calculator puts Llama 3.1 8B at its recommended Q5_K_M (7.58 GB) at 24.6 tok/s and Qwen3 8B at its recommended Q5_K_M (7.73 GB) at 24.1 tok/s, identical to every larger Strix Halo tier, since decode speed here is set by bandwidth, not capacity. Independent Vulkan/RADV community benchmarks report closer to 45 tok/s for a similar 7B Q4 build; this site's decode-efficiency constant was calibrated against a discrete RTX 4090, not this unified-memory architecture, so treat the figures here as a conservative floor. This tier's real ceiling is capacity, not speed: with roughly 24 GB usable after the OS reserve, 70B-class dense models don't fit at any quantization (even Llama 3.3 70B's smallest real build, Q2_K at 32.88 GB, overshoots it), so 64GB is the entry point for that class. This site's own top-of-board picks that do fit here include Qwen 3.8 27B and Qwen 3.6 27B at Q5_K_M (22.13 GB, 8.4 tok/s) and Gemma 4 31B at Q4_K_M (22.63 GB, 8.2 tok/s, barely over 1 GB of headroom left), but the fastest board-topper by far is a MoE release: Ornith 1.5 35B-A3B fits at Q3_K_M (19.04 GB) decoding at 33.4 tok/s, 4x a same-capacity dense model's speed, because only a fraction of its parameters activate per token. 52 of the 94 models this site tracks fit natively at this capacity, the fewest of any Strix Halo tier, but still more than double a typical 16GB discrete GPU. None of those tok/s figures capture this platform's most-discussed real-world weakness, though: prompt processing. Strix Halo's iGPU is bandwidth-bound rather than compute-bound, so long prompts are genuinely slow to chew through before the first output token appears. Independent benchmarking (datahardware.ai) measured GPT-OSS 120B prefilling at only about 340 tok/s on this chip, roughly a fifth of the ~1,700 tok/s NVIDIA's compute-bound DGX Spark reaches on the identical model, and real document text prefills 24-33% slower still than the synthetic prompts most benchmarks use. The practical effect: a 12,000-token prompt needs roughly 35 seconds of processing before generation even starts, versus about 7 seconds on DGX Spark. Decode itself keeps sliding well past this page's 8k-context estimate too: one independent long-context benchmark found generation speed dropping by roughly two-thirds once the KV cache filled to around 76k tokens.

Vulkan (RADV or AMDVLK) via llama.cpp works everywhere; ROCm 6.4+ targets this chip directly as gfx1151 on Linux, when your specific unit uses the full Ryzen AI Max+ 395; the cut-down Ryzen AI Max 385 some vendors ship at this capacity uses the same gfx1151 target too. Independent backend testing (soothill.io, kyuz0's toolboxes benchmarks) found no single fastest backend across the Strix Halo family: ROCm usually wins prompt processing, Vulkan usually wins token generation. On Windows, AMD's Adrenalin driver exposes a Variable Graphics Memory setting to split this pool between system RAM and VRAM; on Linux the more common approach is a small BIOS UMA carve-out plus the amdgpu.gttsize kernel parameter. With only 32GB total, leave enough headroom in that split for the OS, this is the one tier where over-allocating VRAM can actually starve the system side.