Strix Halo Guide Open the guide
Strix Halo GuideIndependent community project

Setup · evidence · cross-system validation

From AI PC to working local AI.

A tested route through BIOS, Linux, Vulkan/RADV, ROCm, Ollama, llama.cpp, model choice and quantization—so buyers can spend less time assembling scattered advice and more time running real workloads.

Start with the guide Inspect the evidence
  • Public commands and raw logs
  • Known-good and failed paths
  • Independent conclusions
Buyer path Evidence linked
01
HardwareMemory · thermals · firmware
02
BIOS & UMAIOMMU · allocation · profile
03
Linux stackKernel · Mesa · device access
04
RuntimeOllama · llama.cpp · ROCm
05
Model & quantFit · quality · context
06
ReproduceCommands · CSV · raw evidence
verified route
Evidence index updated through 21 July 2026 Open claim index

The problem

The hardware can be capable. The buyer path is still fragmented.

Good Strix Halo results depend on choices scattered across firmware notes, Linux threads, driver releases, runtime flags, model pages and benchmark posts. The guide turns those choices into routes that can be checked and repeated.

Without a tested route

  1. 1Choose an AI PC from incomplete comparisons
  2. 2Search for BIOS and UMA advice
  3. 3Resolve Linux and GPU access issues
  4. 4Choose Vulkan, ROCm or a packaged runtime
  5. 5Guess which model and quantization will fit
  6. 6Wonder whether benchmark claims transfer

With the guide

  1. 1Start from a buyer or workload goal
  2. 2Use a named, measured setup path
  3. 3Copy exact commands and versions
  4. 4Check caveats, failures and alternatives
  5. 5Follow every claim to public evidence

One route to a working baseline. Then tune from evidence, not folklore.

Verified evidence

Claims you can inspect, not a performance collage.

Each result below is scoped to its exact system, runtime, model, quantization and workload. The linked repository preserves raw output and caveats.

Beginner buyer path

Ollama, installed as a normal system service.

Qwen3.6 35B-A3B Q4_K_M retained the Radeon 8060S, averaged 60.57 t/s in warm API generation, passed vision, and survived service restart plus full-host reboot.

Measured on one 128 GB Beelink GTR9 Pro. This is buyer-path evidence, not a universal speed claim.

View raw evidence
60.57t/s Ollama 0.31.2
warm generation mean

Balanced coding route

96.76 t/s

Qwen3-Coder 30B-A3B

Direct llama-bench with the balanced UD-Q4_K_XL route on Vulkan/RADV.

Open measured CSV

Direct capacity proof

284.33B

Ordinary GGUF, one box

A 90.86 GB DeepSeek V4 Flash low-bit artifact loaded and generated through official llama.cpp Vulkan/RADV.

Capacity and basic-correctness proof—not a broad quality recommendation.

Inspect the run

Cross-system evidence map

One guide, multiple systems and independent sources.

First-party measurements remain separate from community results. The evidence map covers Linux and Windows routes, multiple OEM systems, power, thermal behavior, RPC, NPU sidecars, ROCmFP4, capacity tests and failed paths.

See the evidence map Meet contributors
11
systems or independent sources
8
credited community benchmark contributors

Evidence coverage counts are taken from the repository’s dated evidence map. Performance results are not directly comparable across different backends, workloads or quantizations.

Useful to the whole category

One public proof layer. Four practical audiences.

01

Buyers

Understand what fits, which route to try first and where the remaining setup risk is.

02

Vendors

See where firmware, drivers, cooling and documentation help—or block—the buyer journey.

03

Reviewers

Reproduce named workloads with public commands, versions, caveats and raw evidence.

04

Contributors

Add systems, failures and corrections without losing source links or individual credit.

How the guide earns trust

Evidence before positioning.

Reproducible by default

Commands, versions, settings, CSVs and raw output stay connected to the claims they support.

Failures stay visible

Broken paths, regressions and negative findings are part of the buyer guidance—not cleaned out of the story.

Claim types stay separate

Direct benchmarks, APIs, speculative decoding, concurrency, community rows and experimental work are not blended.

Community credit is preserved

Contributor names, systems and original evidence remain visible as the project expands.

Vendor input can improve facts

Engineering and setup corrections are welcome. They do not buy editorial control.

Support is disclosed

Loaned, gifted, sponsored, affiliate or early-access work is labelled near the relevant results.

Vendors, DevRel & reviewers

Help turn more retail systems into repeatable local-AI evidence.

Useful collaboration can be as small as a BIOS correction or engineering contact, or as substantial as a loaner system and a scoped cross-system validation campaign.

Explore collaboration Contact the maintainer
Independent by design.

Strix Halo Guide is an independent community project. It is not affiliated with, endorsed by, or an official publication of AMD or any OEM. Product and company names identify tested hardware or relevant platforms—not partnerships.

Read the disclosure policy