Soot / Silicon Storage · GPU · infrastructure

GPU field notes / Series 01Ongoing / 2026

AMD Strix Halo
under sustained local-AI use.

This is an ongoing investigation, not a final verdict on the platform. I test what runs, whether the answer is correct, how the runtime behaves over time and which result is strong enough to change what I would use.

ScopeEnd to end
PlatformUbuntu / Linux
RuntimesROCm / Vulkan / vLLM
ChecksFit / correctness / stability

Why this machine

128GB of shared memory answers the fit question. It does not answer the product question.

Strix Halo combines Zen 5 CPU cores, integrated RDNA 3.5 graphics and up to 128 GB of fast system memory. On Linux, GPUVM and a large GTT aperture let supported runtimes address that shared memory without a huge fixed graphics partition.

That does not automatically make it a mature LLM platform. Runtime support is changing quickly, and software that can load a model may still behave differently under a longer context, repeated requests or recovery. I therefore treat can run, good to use and worth deploying as separate findings.

Platform details are based on AMD’s published Ryzen AI Max+ 395 specifications and Strix Halo Linux guidance. Every article records its own test-machine and software context.

Start here

Choose the article that matches the decision you are trying to make.

Establish the machine first: the hardware, BIOS and NVMe baseline separates verified system facts from assumptions.

Choose what is useful, not merely what fits: the quantisation comparison looks at quality, speed and operating headroom together.

See the current decision: the local LLM stack I would keep connects the earlier tests and states what would make me revisit it.

Publication record32 published so far

32 field notes published so far. The investigation is still growing.

  1. 32Published

    Qwen3.8 in vLLM: the 95 GiB table stays on disk

    Qwen3.8 Flash Next runs in vLLM on my 128 GB Strix Halo with disk-backed embeddings. At 32K, first output falls from 306 to 81 seconds.

  2. 31Published

    Qwen Vulkan PRs 28489 and 28501: below noise

    I benchmark llama.cpp PR 28489 and PR 28501 with the 103.7 GiB Qwen3.8 Flash Next model on Strix Halo. Both are correct; neither is a production speed-up.

  3. 30Published

    Two draft changes delivered most of Qwen3.8's stack gain

    I isolate five Qwen3.8 27B optimisations on Strix Halo. Two improve the current Vulkan stack; IQ4 main and TOP_K do not.

  4. 29Published

    Lemonade 11.9 on EVO-X3: the control plane changed, inference did not

    I upgraded EVO-X3 from a patched Lemonade 11.8 daemon to official 11.9. Fixed prefill held, decode moved -1.93% and every route passed.

  5. 28Published

    Two QSA gather patches attack Qwen3.8's long-context decode cost

    PRs 28213 and 28244 gather QSA-selected K/V cells instead of masking the full cache. The long-context gains are real leads, not Vulkan results.

  6. 27Published

    A one-line Vulkan fix may unlock Q8 K/V prefill, but 125B still needs proving

    Merged PR 28190 makes Vulkan's Flash Attention dequant path engage before the KV cache is full. It is promising, not yet a 125B result.

  7. 26Published

    Lazy auto mode can halve Qwen3.8 prefill on Strix Halo

    An exact Strix Halo report measures 216 versus 406 prompt tokens/s from one llama.cpp lazy-mode switch. New canaries need it made explicit.

  8. 25Published

    A Qwen3.8 prompt-cache slot can loop forever

    Issue 28280 records a Qwen3.8 prompt-cache checkpoint livelock on Strix Halo. Health alone can miss it, so slot progress needs watching.

  9. 24Published

    Qwen3.8 MTP can mix users' answers across slots

    A gfx1151 report shows Qwen3.8 draft-MTP content crossing between concurrent slots. That is a correctness blocker for my dual-slot service.

  10. 23Published

    Six Qwen3.8 MTP heads; only one fits my next test

    Unsloth's six Qwen3.8 MTP GGUF sidecars range from 1.776 to 7.237 GiB. Shared Q8_0 is the sensible canary, not a production download.

  11. 22Published

    Qwen3.8 can now roll back recurrent state, but that is only half the MTP story

    PR 28123 makes Qwen3.8 recurrent rollback practical for MTP. It removes a large copy cost, but does not make concurrent drafting safe.

  12. 21Published

    The Qwen3.8 correctness merge I would carry before chasing speed

    PR 27941 fixes five Qwen3.8 state and QSA correctness faults. I would carry it into the next EVO-X3 canary, but not promote it untested.

  13. 20Published

    Two llama.cpp Qwen fixes on Strix Halo: no free speed-up

    I backported two merged llama.cpp Qwen fixes into the qualified Strix Halo runtime. One was 3–5% slower; the other lost the Vulkan device during model load.

  14. 19Published

    Qwen3.8 Flash Next: Vulkan 0.7.1 and Q8 in production

    I moved Qwen3.8 Flash Next to a Q8 dual-slot Vulkan 0.7.1 profile, measured 5–8% gains and passed a 30-minute cached concurrency soak.

  15. 18Published

    Qwen3.8 Flash Next on AMD Strix Halo: ROCm vs Vulkan

    I compare ROCm and Vulkan for Qwen3.8 Flash Next on AMD Strix Halo, then tune a 104GiB model to 15.6 tok/s single-stream and 24.3 tok/s aggregate.

  16. 17Published

    Ornith 1.5 on Strix Halo: the 32K production profile

    I qualified a patched Vulkan build for Ornith 1.5 35B on Strix Halo, lifting 32K prefill by 24% and passing two 30-minute production soaks.

  17. 16Published

    Qwen3.8 at 262K: fixing DFlash2 for production

    I repaired Qwen3.8 DFlash2 state reuse and a deterministic Vulkan stall, then deployed separate fast and exact 262K routes with memory-aware eviction.

  18. 15Published

    Vulkan 0.6.10 on Strix Halo: the MTP fix has a cost

    Vulkan 0.6.10 fixes the long MTP stall on my Strix Halo machine, but Qwen3.6 decode falls about 11% and DeepSeek does not improve.

  19. 14Published

    Vulkan 0.6.4 on Strix Halo: the coding models moved

    I compared Vulkan 0.6.2 and 0.6.4 with ROCm 7.14 on Strix Halo. The new release improved prefill by up to 72%, while decode performance stayed unchanged.

  20. 13Published

    23 coding deployments on Strix Halo: what I would run

    I ran 23 local coding-model deployments through 230 executable tasks on a 128GB Strix Halo workstation, comparing accuracy, latency and context limits.

  21. 12Published

    Muse Glimmer 30B on Strix Halo: Vulkan passed the 8K test

    Muse Glimmer 30B reaches 42 tok/s with DFlash on ROCm, but an 8K correctness test makes Vulkan the safer Strix Halo text route.

  22. 11Published

    Strix Halo LLM upgrades: what got faster and what failed

    Matched before-and-after tests of llama.cpp, vLLM and Lemonade on Strix Halo, plus quantised KV, BF16, MTP, DFlash and ROCmFPX experiments.

  23. 10Published

    SGLang vs vLLM vs llama.cpp on Strix Halo: five models, three winners

    Twenty matched SGLang-vLLM points plus llama.cpp and DeepSeek tests show why vLLM wins native Qwen while specialised runtimes win large quants.

  24. 09Published

    DeepSeek V4 Flash on Strix Halo: tuning ROCm, matching Vulkan

    Matched DeepSeek V4 Flash tests on Strix Halo show a 44% ROCm prefill gain from tuning, but patched Vulkan still wins all four llama.cpp workloads.

  25. 08Published

    EVO-X3 from BIOS to Lemonade: a reproducible build

    A tested route from EVO-X3 firmware settings to a signed Ubuntu USB image, 120 GiB dynamic GTT, SSH-key-only access, Lemonade and verified updates.

  26. 07Published

    DeepSeek V4 Flash 0731 on EVO-X3: the repeat that changed deployment

    A measured DeepSeek V4 Flash 0731 study on Strix Halo: ROCm optimisation, a four-hour 32K thermal soak and 20 cold model loads.

  27. 06Published

    A local LLM stack worth keeping

    The Strix Halo stack I would keep after the first benchmark sequence: hardware, Linux memory, runtimes, models and operating controls.

  28. 05Published

    The long-session test: 122B at a 256K context

    A 101-minute, 165-request soak of Qwen3.5 122B at a nearly full 256K context, including throughput, memory, thermals and request-retention fixes.

  29. 04Published

    Finding the useful quant: what fits is not what wins

    A measured 0.8B-to-397B Strix Halo model sweep showing why file size, active parameters, context cost and answer quality must be separate decisions.

  30. 03Published

    llama.cpp on Strix Halo: Vulkan versus ROCm

    Matched llama.cpp benchmarks show why Strix Halo has no single fastest backend: ROCm wins prompt processing while Vulkan can win generation.

  31. 02Published

    ROCm on Strix Halo, without the folklore

    A measured Linux setup for ROCm on the Ryzen AI Max+ 395: memory, build provenance, model lifecycle, failure modes and a recovery runbook.

  32. 01Published

    GMKtec EVO-X3: the hardware, BIOS and NVMe baseline

    A product-led examination of my Linux-based GMKtec EVO-X3: Strix Halo hardware, its provable firmware state and measured NVMe performance.

The test contract

What I record before I trust a result.

Download the headline results and model checksums or the separate 20-variant loading-time dataset. These files transcribe the published measurements; the articles remain the source for protocol, caveats and interpretation.