AMD Ryzen AI Max+ 395: Strix Halo, ROCm and Vulkan

By the end of this lesson you will be able to say what a Ryzen AI Max+ 395 machine is and what it is good for; explain how much of its memory the GPU can actually use and how that is decided on Windows and on Linux; state, with a date, what AMD’s own compatibility documentation says about this GPU; and say why the course’s default engine path on this machine is Vulkan and when to reach for ROCm instead.

This is the Track X lesson. It is the longest of the four platform lessons because this is the track where you have a genuine choice of software stack and where the two choices behave differently.

The machine

“Strix Halo” is the design name for AMD’s large-die mobile processor, sold as the Ryzen AI Max+ series, and the part this course is written against is the Ryzen AI Max+ 395. It appears in mini PCs and in a few laptops. The course validation machine is a GMKtec EVO-X2, whose specification page lists a Ryzen AI Max+ 395 with “16 cores / 32 threads” running “Up to 5.1 GHz (MAX)”, “Radeon 8060S Graphics” with a “40-core RDNA 3.5 architecture”, and “Onboard LPDDR5X (non-upgradeable)” memory at “8000MHz” in “64GB or 128GB” configurations, with dual M.2 slots, 2.5 GbE and Wi-Fi 7.

Three of those details matter more than the rest.

The memory is soldered. You choose 64 GB or 128 GB at purchase and you live with it, exactly as on the other two unified-memory tracks. The 128 GB configuration is the one this course’s Track X instructions assume when a lab needs the top tier, and the 64 GB machine follows the reduced path that every lab states.

The GPU is integrated, and it is large: forty compute units of RDNA 3.5, which the ROCm documentation identifies by the LLVM target name gfx1151. That target name is the string you will search for when you want to know whether a piece of software supports this chip, and it is worth committing to memory.

The processor also carries an XDNA 2 NPU, which is a separate accelerator from the GPU, with its own software stack. What it can and cannot do for this course is a section of its own below.

Vendor specification, not measuredRyzen AI Max+ 395, as recorded in the course hardware reference

Figure	Value	Source
Unified memory	64 GB or 128 GB LPDDR5X, 8000 MHz	GMKtec EVO-X2 specifications
Memory bandwidth	256 GB/s	Course hardware reference, verified 2026-09-08
GPU	Radeon 8060S, 40 RDNA 3.5 compute units, gfx1151	GMKtec specifications; ROCm compatibility matrix
CPU	16 cores / 32 threads	GMKtec EVO-X2 specifications
Networking	2.5 GbE, Wi-Fi 7, USB4	GMKtec EVO-X2 specifications

AMD Ryzen AI Max+ 395 (Strix Halo), GMKtec EVO-X2, not applicable · no engine; course hardware reference and vendor page retrieved 2026-09-09 · no model loaded, not applicable · 0 tokens of context · 2026-09-09

The bandwidth figure is the one carried by the course hardware reference; AMD's own product page for this processor could not be retrieved when this lesson was written, so treat that row as the course's figure rather than a quotation from AMD, and replace it with your own measurement from the second lab in this part.

✱Hardware note

Everything in this lesson applies to the processor, not to one vendor’s box. Other Ryzen AI Max+ 395 mini PCs and laptops exist, and they differ in cooling, in how much memory they are sold with and in what their firmware exposes. Cooling is not a footnote on a machine this small: a sustained matrix-multiply benchmark is exactly the workload that finds a thermal limit, which is one reason the next lab has you run one.

How much memory can the GPU actually use?

This is the question that separates this track from the other two unified-memory tracks, because here the answer is not “all of it” and it is set in two different places depending on the operating system.

On Windows, the amount of memory presented to the graphics driver is decided by the system firmware and the driver together, and the machine’s own documentation is the place to look for how to change it. The course hardware reference records the practical ceiling on a 128 GB machine as about 96 GB visible to the GPU. Check your own machine’s manual rather than assuming a number: this setting is where a Track X reader most often discovers that a model which should fit does not.

On Linux, the relevant mechanism is the GTT domain, the system memory the amdgpu driver lets the GPU address in addition to any carved-out VRAM. The kernel’s own module-parameter documentation describes the knob and, importantly, warns you off it:

gttsize (int) — Restrict the size of GTT domain (for userspace use) in MiB for testing. The default is -1 (Use value specified by TTM). This parameter is deprecated and will be removed in the future.

Two things follow. The default is not a fixed number: it is whatever the kernel’s memory manager decides, which is why two machines with the same memory can behave differently after a kernel upgrade. And a parameter documented as “for testing” and “deprecated” is not a foundation to build a workflow on. The same page documents vramlimit in the same spirit, as a testing restriction rather than a tuning control.

✕Common mistake

The symptom is a model that loads on one boot and not on the next, or an engine that reports far less GPU memory than the machine has. Before changing kernel parameters, check what the driver is actually offering, which is the first thing the Track X preparation script in this part’s lab prints. Reaching for a deprecated boot parameter as the first response is how people end up with a machine whose behaviour they can no longer explain.

ROCm and gfx1151, with a date

Software support for this GPU has moved quickly enough that any undated statement about it is useless. Here is a dated one.

The ROCm 10.0.0 compatibility matrix, which carries the date 2026-08-14 on the page and was read for this lesson on 2026-09-09, lists gfx1151 in its table of AMD APU series, under the RDNA 3.5 architecture, alongside the Ryzen AI Max+ family and the Radeon 8060S. The table’s columns give the supported Ubuntu version, the supported Windows version and driver versions; for the gfx1151 row it lists Ubuntu 26.04 with the GA 7.0 kernel, and Windows 11 25H2. The table does not carry a separate support-tier column, and there is no footnote or asterisk on that row.

Two caveats keep that from being the whole story, and both are the kind of thing this course insists on saying out loud.

First, AMD’s own pages did not agree on the day they were read. The ROCm installation documentation’s Linux system-requirements page, read on the same date, did not name gfx1151, the Radeon 8060S or the Ryzen AI Max+ 395 anywhere. The quick-start installation guide, read the same day, described its instructions as covering Ubuntu 22.04 and 24.04, while the compatibility matrix lists 26.04 for this chip. When the compatibility matrix and the install guide disagree about which distribution to be on, the honest position is that you should read both before installing and expect to be on a recent kernel.

Second, a listing is not a guarantee that every library works. ROCm is a stack: kernel driver, runtime, math libraries, and framework builds on top. A target being listed means AMD is building for it, not that every downstream project has caught up. The way to find out is the way this course always finds out, which is to run something and look.

⌚Version note

Statements like the one above expire. Re-read the compatibility matrix at https://rocm.docs.amd.com/en/latest/compatibility/compatibility-matrix.html before you install, note the ROCm version and the date on the page, and write both into your lab notebook next to whatever you observe. A dated observation stays useful; an undated one does not.

The installation itself, when you choose ROCm, follows AMD’s quick-start guide: fetch the amdgpu-install package from the repository URL that page gives for your distribution, install the kernel driver with the matching headers, add yourself to the render and video groups, install the rocm metapackage, and reboot. The exact repository URL carries a version number that changes, so take it from the page rather than from any tutorial, this one included.

Fragment — not complete on its own

# From AMD's quick-start guide: the group membership that most first-time
# installs forget, and without which the GPU is invisible to user-space.
sudo usermod -a -G render,video "$LOGNAME"

Two GPU paths, and which one this course defaults to

llama.cpp, the engine Part 6 builds on every track, has more than one backend that can drive this GPU. On Track X the two that matter are Vulkan and HIP, and they are different bargains.

The two Track X GPU paths

towards the GPU

1. What you runllama.cpp on either path; PyTorch and anything built on it only on the ROCm path.
2. Vulkan backendBuilt with -DGGML_VULKAN=1. Uses the Vulkan driver the distribution already has. Fewer moving parts, works on Windows and Linux, and is the course default on this track.default
3. HIP / ROCm backendBuilt with -DGGML_HIP=ON and a GPU target. Needs the ROCm stack installed and matched to the kernel. The path to PyTorch, and to the training parts in Level 3.
4. Kernel: amdgpu driver, GTT and VRAM domainsCommon to both paths. Decides how much system memory the GPU may address.
5. Radeon 8060S, gfx1151, 40 RDNA 3.5 compute unitsOn the same package and the same memory as the CPU.

Both paths end at the same silicon. Vulkan goes through the graphics driver stack that every Linux distribution already ships and that Windows has natively; ROCm/HIP goes through AMD's compute stack, which has to be installed and version-matched, and which is what PyTorch needs.

The course’s platform decision, recorded in the project’s second architecture decision record, is that Vulkan is the default llama.cpp path on Track X, and ROCm is the path taken deliberately when something needs it. The reasoning is not that ROCm is bad; it is that a reader following a lab should meet the fewest possible version-matching problems between them and the first token, and the Vulkan build has fewer of them.

llama.cpp’s build guide gives both. For Vulkan on Linux, after sourcing the Vulkan SDK’s setup_env.sh:

Fragment — not complete on its own

cmake -B build -DGGML_VULKAN=1
cmake --build build --config Release

And for HIP, the guide’s example is:

Fragment — not complete on its own

HIPCXX="$(hipconfig -l)/clang" HIP_PATH="$(hipconfig -R)" \
    cmake -S . -B build -DGGML_HIP=ON -DGPU_TARGETS=gfx1030

The guide’s example names gfx1030, which is a different GPU; on this machine the target is gfx1151. The same page documents HSA_OVERRIDE_GFX_VERSION as a way to make the runtime pretend a GPU is a different one. Treat that as a diagnostic, not a configuration: if you need it to make something run, record that you needed it, because it means the software does not really support the chip and the results deserve suspicion.

⌚Version note

Part 6 does the builds properly, per track, with the pinned llama.cpp version and a smoke test that proves which backend is in use. This lesson is here so that when you get there you already know which of the two you are choosing and why.

vLLM, and what is listed here

vLLM’s installation documentation lists the platforms it supports: NVIDIA CUDA, AMD ROCm, Intel XPU and Apple silicon, with CPU builds for x86, AArch64, Apple silicon and IBM Z. Under AMD ROCm, the GPU installation page read on 2026-09-09 names “Ryzen AI MAX / AI 300 Series (gfx1151/1150)” among the supported GPUs, with pre-built wheels for ROCm 7.0 and 7.2.1 and a vllm-openai-rocm container image. Earlier readings of the same page did not name the chip, and the course’s own data recorded it as unlisted until this reading; that history is why every vLLM page on Track X carries a date.

The course therefore treats vLLM on Track X as listed but not yet exercised: Part 9 gives the ROCm install path with that status, the validation pass on the reference machine decides whether the Track X labs run on it, and until then llama.cpp remains the serving default here, with Part 8’s alternatives where a page needs a feature llama.cpp lacks. A listing is a statement about what the project intends to support; a lab still has to rest on what was run.

What the NPU can and cannot do for you here

AMD’s Ryzen AI Software documentation describes a stack that targets “the neural processing unit (NPU) built in the AMD XDNA architecture, as well as on the integrated GPU”, supports CNN and transformer models, and includes an LLM flow with, in its words, three development interfaces.

So the NPU is not a marketing sticker: there is a documented path for running language models on it. It is, however, not the path this course takes, for reasons worth stating plainly rather than hiding behind a recommendation. The engines this course teaches, llama.cpp, vLLM, SGLang, MLX and the rest, target GPUs. The NPU’s strength is efficiency on sustained, modest workloads rather than peak throughput on a large model, and this machine’s large unified memory is reachable at full speed by the GPU. If you want to explore the NPU path, AMD’s documentation is the place to start, and the result belongs in your lab notebook as a comparison; nothing in this course depends on it.

Windows or Linux on this machine

Both work, and the choice is a real one on this track in a way it is not on the others.

Windows 11 is what these machines usually ship with. The Vulkan path for llama.cpp works there, LM Studio and Ollama both run there, and the memory allocated to the graphics driver is configured through firmware and driver settings. If your goal is to run models and use them, this is a perfectly good place to be, and Part 7 is largely reachable from it.

Linux is what the rest of the course assumes when a lab needs a compute stack. ROCm’s compatibility matrix lists this chip against Ubuntu 26.04 with a recent kernel; the course hardware reference names Ubuntu 24.04 with the hardware-enablement kernel, Ubuntu 26.04 or Fedora 43 as the distributions in use. Anything that needs PyTorch on the GPU, which means all of Level 3’s fine-tuning work, needs the ROCm path and therefore Linux.

The pragmatic answer for a reader who wants the whole course: install Linux. The pragmatic answer for a reader who wants Level 2 and a private chat service: Windows is fine, and the labs say so per task.

Diagnose the graphics path before changing the model

Distinguish the operating system seeing the integrated GPU, a runtime enumerating it, and an inference engine executing the intended kernels on it. These are successive checks. A successful device listing is useful, but it does not establish that a particular PyTorch build, attention implementation or quantisation kernel is supported.

For an inference failure, retain the engine’s device enumeration and startup placement log. Test a small model with the documented backend first. If that works but a larger model fails, investigate allocation and context. If even the small model fails at kernel launch, changing its sampling temperature will not help; return to the driver/runtime/backend combination.

Treat Vulkan inference and ROCm training as separate environments with separate acceptance tests. Do not replace working graphics drivers merely to follow a recipe for another distribution. In the notebook, record your actual chip identifier and package versions, the supported path you chose, and any operation that falls back to the CPU. This converts a vague “AMD support” claim into a reproducible account of what ran.

Recap

A Ryzen AI Max+ 395 machine is unified memory on x86: sixteen Zen cores and a forty-compute-unit Radeon 8060S, known to software as gfx1151, sharing 64 GB or 128 GB of soldered LPDDR5X. It is the cheapest way in this course to have more than a hundred gigabytes of model memory, and it asks for more attention to the software stack than the other tracks do.

How much of that memory the GPU may use is decided by firmware and driver on Windows, and by the amdgpu driver’s GTT domain on Linux, where the kernel documents the size knob as a deprecated testing parameter rather than a tuning control. AMD’s ROCm 10.0.0 compatibility matrix, dated 2026-08-14 and read on 2026-09-09, lists gfx1151 in its APU table against Ubuntu 26.04 and Windows 11 25H2, while AMD’s own installation pages read the same day did not mention the chip and named older Ubuntu releases; read both before installing. The course’s default llama.cpp path here is Vulkan, with ROCm taken deliberately when PyTorch or a training lab needs it, and vLLM listed for this hardware on its installation page as of 2026-09-09 but not yet exercised by the course.

Check your understanding

Question 1. What is gfx1151, and why should a Track X reader remember it?

• A model file format used by AMD
• The LLVM target name for the Radeon 8060S in the Ryzen AI Max+ 395, and therefore the string to search for when checking whether software supports this GPU
• The kernel module that drives the GPU
• The firmware version of the memory controller

Show the answer and why

Answer: The LLVM target name for the Radeon 8060S in the Ryzen AI Max+ 395, and therefore the string to search for when checking whether software supports this GPU

Compatibility tables, build flags such as -DGPU_TARGETS, and bug reports all use the LLVM target name rather than the marketing name. Searching for gfx1151 answers support questions that searching for "Ryzen AI Max" does not.

Question 2. On Linux, a model that fits in 128 GB refuses to load and the engine reports far less GPU memory than the machine has. Which explanation fits what this lesson described?

• The model file is corrupt
• The GPU can only address the memory the amdgpu driver gives it as VRAM plus GTT, and that amount is decided by the kernel rather than being the whole pool
• LPDDR5X cannot hold model weights
• ROCm has been uninstalled

Show the answer and why

Answer: The GPU can only address the memory the amdgpu driver gives it as VRAM plus GTT, and that amount is decided by the kernel rather than being the whole pool

On this track the GPU-visible amount is not automatically the whole pool. The kernel documents the GTT size knob as a deprecated testing parameter, so the first step is to look at what the driver is offering rather than to change boot parameters.

Question 3. Which statement about ROCm support for this GPU is the one this course would accept?

• ROCm supports it
• ROCm does not support it
• The ROCm 10.0.0 compatibility matrix, dated 2026-08-14 and read on 2026-09-09, lists gfx1151 in its APU table against Ubuntu 26.04 and Windows 11 25H2
• Support is expected in a future release

Show the answer and why

Answer: The ROCm 10.0.0 compatibility matrix, dated 2026-08-14 and read on 2026-09-09, lists gfx1151 in its APU table against Ubuntu 26.04 and Windows 11 25H2

A support claim without a document, a version and a date decays into folklore within a release cycle. The third answer can be checked, contradicted or updated by anyone reading it later, which is the whole point.

Question 4. Why does this course default to the Vulkan backend of llama.cpp on Track X rather than the HIP/ROCm backend?

• Vulkan produces higher-quality output
• ROCm cannot drive this GPU at all
• Vulkan uses the graphics driver the system already has, so there are fewer version-matching steps between a reader and their first token; ROCm is taken deliberately when PyTorch or a training lab needs it
• Vulkan supports larger models

Show the answer and why

Answer: Vulkan uses the graphics driver the system already has, so there are fewer version-matching steps between a reader and their first token; ROCm is taken deliberately when PyTorch or a training lab needs it

Both backends reach the same silicon. The default is chosen for the number of things that must line up before a lab works, not for output quality, and the ROCm path is still required for anything built on PyTorch.

Question 5. A colleague says vLLM runs fine on their Ryzen AI Max+ 395. How should a course page treat that?

• Add vLLM to the Track X labs on the strength of the report
• Note the report, check the dated listing on the vLLM installation page, and keep the Track X labs on the path the validation pass has actually run until vLLM has been exercised there too
• Dispute that it is possible
• Remove vLLM from the course

Show the answer and why

Answer: Note the report, check the dated listing on the vLLM installation page, and keep the Track X labs on the path the validation pass has actually run until vLLM has been exercised there too

A report is evidence that it can work, and the dated listing is evidence that the project intends it to; neither is a lab. The course keeps Track X on the path its validation pass has run and adds vLLM there once that pass has exercised it.

Check my answersClear