AMD Strix Halo (128GB)

AMD Strix Halo (128GB): AMD unveiled Strix Halo (retail name: Ryzen AI Max 300 series) at CES on January 6, 2025. The flagship Ryzen AI Max+ 395 pairs 16 Zen 5 cores (32 threads, up to 5.1 GHz, 80MB combined cache) with a 40-compute-unit Radeon 8060S iGPU (RDNA 3.5, rated 14.8 TFLOPS FP16) and a 50 TOPS NPU, and it's the chip every vendor puts behind this 128GB tier: quad-channel LPDDR5X-8000 over a 256-bit bus gives a 256 GB/s theoretical ceiling that doesn't change anywhere in the 32-128GB range this site tracks, capacity scales 4x tier to tier, bandwidth doesn't move at all (see the VRAM/bandwidth chart below). Independent community bandwidth testing (a Level1Techs forum benchmark thread) measures around 215 GB/s actually achieved, about 84% of that ceiling. This top tier is also the priciest, and its price has moved fast: Framework Desktop's 128GB configuration launched at $1,999, but GMKtec's EVO-X2 128GB has since listed as high as $3,299-3,500. The driver is a 2026 LPDDR5X/DRAM shortage pushing unified-memory AI-PC pricing up broadly, not just this one vendor (compute-market.com cites the same shortage behind NVIDIA's own DGX Spark listing around $4,699 in mid-2026): one buyer's real purchase of a comparable 128GB mini PC (Bosgame M5) rose from roughly €1,700 to over €2,400 within months as the shortage took hold.

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, numbers this page shares bit-for-bit with every other Strix Halo tier, since decode speed here is set by bandwidth alone. Community llama.cpp benchmarks on the Vulkan/RADV backend 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 run, not this unified-memory iGPU architecture, so treat the figures here as a conservative floor rather than a hard ceiling. What 128GB actually buys over the smaller tiers: this site's own top-of-board picks for this capacity include Mistral Medium 3.5 128B, a 128B dense model that just fits at Q5_K_M (105.38 GB, 1.8 tok/s), and DeepSeek V4 Flash 0731, a 284B MoE release that fits at Q2_K (116.56 GB, 10.4 tok/s) because only a fraction of its parameters activate per token. More conventional 70B-class dense models fit too: Llama 3.3 70B and Llama 3.1 70B both reach Q4_K_M (50.75 GB, 3.7 tok/s), and Qwen 2.5 72B is close behind (52.12 GB, 3.6 tok/s), all with well over half this tier's 120 GB of usable memory still free, and GPT-OSS 120B fits at Q4 (80.15 GB, 15.6 tok/s). 72 of the 97 models this site tracks fit natively here, the most of any Strix Halo tier. 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. Independent backend testing (soothill.io, kyuz0's toolboxes benchmarks) found no single fastest backend: ROCm usually wins prompt processing, Vulkan usually wins token generation, so the right choice depends on whether you're bottlenecked on long prompts or on 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 to let the GPU reach further into system memory on demand.