Strix Halo Guide: local LLM setup and benchmark evidence for AMD Ryzen AI MAX+ 395
Evidence-backed AMD Strix Halo local-AI setup and benchmarks: Qwen3.8, Ollama, llama.cpp, Vulkan/ROCm, large GGUFs, and cross-OEM results.
At a glance
- What is it?
- This repository is documentation, scripts and raw benchmark logs for running large language models on Strix Halo mini PCs with unified memory. Its selling point is not a single speed number but a claim index that separates measured results from community reports.
- Who is it for?
- Adopt it if you already own or have ordered a Strix Halo machine and want copyable Ubuntu, Vulkan/RADV, Ollama and llama.cpp steps plus a claim index that tells you which numbers were measured on one Beelink GTR9 Pro and which came from community contributors. Skip it if you need vendor support, a packaged installer, or throughput figures for hardware other than the 13 systems and sources it lists.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Strix Halo Guide actually is, and who it is for
This is not a runtime. It is a documentation repository: Markdown guides, Python tooling, CSV data and charts that describe how to run local models on AMD Strix Halo systems, specifically the Ryzen AI MAX+ 395 with Radeon 8060S graphics (gfx1151) and 96GB or 128GB of unified memory. The README states plainly that the repository ships docs, scripts, data and charts only, with no executables, binary archives, browser extensions or model weights. Everything you run comes from elsewhere: Ollama, llama.cpp, ROCm, vLLM.
The audience is narrow and well defined. The README's own table routes people by situation: someone setting up a machine they already own, someone deciding which model or backend to run, someone evaluating Qwen3.8 claims, someone comparing or buying Strix Halo hardware, and someone reproducing benchmarks. If you are choosing between a Strix Halo mini PC and a discrete GPU workstation, this repository will help with the first and say little about the second.
The stated scope boundary matters. The README says results were measured primarily on one Beelink GTR9 Pro, and that community results are kept separate from local headline claims. That separation is the whole editorial premise: a page of numbers copied from one machine is not evidence that your machine will behave the same way.
How the evidence model works: claims, routes and raw logs
The core mechanism is a claim index rather than a leaderboard. The README points to data/headline_claims.csv as the index of headline rows, and says each headline row links to a CSV, a raw log, a chart, or an explicit n/a. That last option is unusual and worth noting: a project that writes n/a into a table instead of omitting the row is telling you where it does not have proof.
Claims are split by route. The README lists direct, API/server, MTP/speculative, concurrency, capacity, power, NPU, RPC, first-party and community claims as separate categories. The Qwen3.8 material is the clearest example of why: the README says measured 20.42 t/s and community 22-65 t/s routes are different claims, and links QWEN38_STRIX_HALO.md plus data/qwen38_route_matrix.csv. A single "Qwen3.8 on Strix Halo" number would collapse those into something that is true for nobody.
There is also a freshness record. The README names data/public_state.json as the machine-readable freshness record and gives a dated evidence state: Qwen3.8 27B measured through the official Ollama route, an August 30 b10687 Vulkan sentinel and Flash-Next scout indexed with their own stack and caveats, and Ollama 0.33.2 described as the unmeasured target from the August 30 upstream review. Reproducibility.md and a benchmark issue template handle contributions, and COMMUNITY_RESULTS.md holds cross-OEM evidence covering 13 systems or independent sources from 10 credited contributors. The repository also keeps EVIDENCE_CORRECTIONS.md, which is where corrections live instead of being quietly edited away.
Installing the Strix Halo stack: BIOS, Ubuntu, Vulkan and a first model
The README's Quick Start is described as six steps and points to setup.sh and STRIX_HALO_LOCAL_LLM_SETUP.md for the working beginner path. The repository does not reproduce the full step list in the README excerpt, so treat the setup document as the source of truth rather than any summary, including this one. What the README does confirm is the shape of the stack: BIOS configuration, Ubuntu 24.04 with kernel setup, memory allocation, Vulkan/RADV, Ollama, and llama.cpp with Vulkan or ROCm/HIP experiments.
The repository provides a shell script at the top level. Running it is the intended entry point, and it is a script in the repository rather than a published package, so read it before executing it:
bash setup.shThe README also describes a smoke-test path, which is the sensible way to confirm a new machine before you spend an evening on model downloads. The repository lists SMOKE_TESTS.md at the top level:
ollama run qwen3The README does not document the exact prompt or expected output of that check, so the thing to look for is simply that a model loads and returns tokens at all. If it does not, the problem is in the BIOS memory split, the Vulkan/RADV stack, or the Ollama install, in roughly that order of likelihood.
For the measured Qwen3.8 route, the README names the official Ollama route as the one that was measured, and points to QWEN38_STRIX_HALO.md and the route matrix CSV for the commands and caveats. It does not print those commands in the README, so read the linked document before comparing your own throughput against the 20.42 t/s figure.
Where the Strix Halo Guide stops being useful
The biggest limitation is stated by the project itself: results were measured primarily on one Beelink GTR9 Pro. Cross-OEM evidence exists, but it is community-contributed and kept separate, which means the headline table is a single-machine dataset. If you own a different OEM chassis, the headline rows are a hypothesis about your machine, not a measurement of it. Thermal design, power limits and firmware differ between mini PCs, and the repository's own THERMAL_STABILITY.md and POWER_BASELINE.md files exist precisely because those variables move results.
The second limitation is version drift. The README calls out Ollama 0.33.2 as an unmeasured target and records an August 30 b10687 Vulkan sentinel with its own stack and caveats. That is honest, but it also means a reader who upgrades Ollama the day after reading will be running a configuration the guide has not measured. There is no compatibility matrix promising that a given Ollama or llama.cpp build reproduces the indexed numbers.
The third is that this is documentation, not support. There is no installer, no binary distribution, and the README explicitly disclaims official AMD or OEM endorsement. If your evaluation process requires a vendor to stand behind the configuration, this repository is the wrong artifact. It is a record of what one maintainer and a group of contributors got working, with the failures preserved alongside the successes.
Strix Halo Guide compared with a general-purpose local inference bundle
The obvious alternative is to skip the guide and use a general local-inference installer or a vendor bundle that ships a runtime plus a model catalog. Those tools optimize for getting a model answering questions in a few minutes on whatever hardware you have. They typically pick a backend for you, hide the flags, and present a single throughput number when they present one at all. The difference in approach is not quality, it is what gets recorded. A general bundle is built to work; this repository is built to be checked.
That distinction has practical consequences. A general installer will not tell you whether a result came from a direct llama.cpp run, an API server, or a speculative decoding configuration, because it does not maintain those categories. The Strix Halo Guide keeps them apart by design, and its README argues that MTP and speculative decoding results belong in their own bucket. If you want one command that produces a chat prompt, the bundle wins. If you need to know whether a 100 t/s figure was a direct 30B Qwen run or an MTP server result, only the categorized approach answers that.
The other alternative is doing it yourself from upstream documentation. That is viable, and the maintainer's upstream pull requests to llama.cpp and other projects suggest the author works at that level. But you would then be rebuilding the parts of this repository that are hardest to reproduce alone: the preserved failures, the corrections file, and the cross-OEM matrix with credited contributors.
Maintenance, licensing and what upgrading costs you
The repository is not archived, and the last push was on 2026-09-13, two days before this writing. Releases are versioned with descriptive names: v3.0.0 on 2026-08-25 covering Qwen3.8 evidence, v2.3.0 on 2026-05-26 for a GMKtec pp/tg follow-up, and v2.2.0 on 2026-05-17 for MTP, wall power and community flow. The cadence suggests the project follows upstream changes rather than a fixed schedule.
Licensing is MIT, which is permissive and imposes few obligations on reuse. Two caveats are worth flagging without giving legal advice. First, the MIT licence covers the repository's own contents; the models, runtimes and OEM firmware you install alongside it carry their own terms, and the README notes the project is not endorsed by AMD or any OEM. Second, several files describe vendor outreach, partnership scope and sponsorship, and the repository keeps a VENDOR_DISCLOSURE.md. If you are citing this work in a purchasing decision, read that disclosure file so you know what relationships exist.
The upgrade cost is your own time, not a subscription. There is no paid tier described in the README. The recurring cost is that each Ollama or llama.cpp bump can invalidate rows you were relying on, and the freshness record in data/public_state.json is where the project tracks that gap. Budget for re-running the smoke test after any backend upgrade.
Editorial conclusion
Adopt it if you already own or have ordered a Strix Halo machine and want copyable Ubuntu, Vulkan/RADV, Ollama and llama.cpp steps plus a claim index that tells you which numbers were measured on one Beelink GTR9 Pro and which came from community contributors. Skip it if you need vendor support, a packaged installer, or throughput figures for hardware other than the 13 systems and sources it lists. Before trusting any row, open the linked CSV or raw log, check the backend and model revision recorded there, and confirm your own machine's BIOS memory setting matches the one in the setup document.
Frequently asked questions
Do I need to own a Strix Halo machine to use the Strix Halo Guide?
You do not need the hardware to read it, but the setup and benchmark material targets AMD Ryzen AI MAX+ 395 systems with Radeon 8060S graphics and 96GB or 128GB of unified memory. The repository ships documentation, scripts and data only, so there is nothing to install on unrelated hardware.
Does the Strix Halo Guide include the model weights or a prebuilt installer?
No. The README states the repository ships docs, scripts, data and charts only, with no executables, binary archives, browser extensions or model weights. You install Ollama, llama.cpp or another runtime yourself and follow the linked setup document.
Why does the Strix Halo Guide report different Qwen3.8 speeds?
Because it treats them as different claims rather than one number. The README says measured 20.42 t/s and community 22-65 t/s routes are separate, and points to QWEN38_STRIX_HALO.md and data/qwen38_route_matrix.csv for the backend and configuration behind each row.
Community notes