Ollama on Strix Halo (Ryzen AI Max+ 395): install, GPU detection, first model

Ollama is the shortest path from a bare box to a model answering on this hardware, and the setup genuinely is the default path — one script, one pull, one run. What the generic tutorials skip is the part specific to this machine: what GPU detection actually prints on a Ryzen AI Max+ 395, which of those lines is a trap, and how to confirm the model landed on the GPU. We wrote this while performing the install on one of our own boxes; the log lines below are real.

If you want full control over flags, context and pinned versions instead of a managed default, that is the llama.cpp guide — Ollama runs llama.cpp underneath, and which layer to operate at is its own question.

Step 0 — the memory ceiling, same as always

Before anything else: on Linux, how much memory the GPU can reach is decided by a TTM kernel parameter, not the BIOS. If you skipped it, big models will refuse to fit no matter what runtime you use — the memory allocation page covers it. Done right, Ollama will report the full ceiling at startup; ours shows just under the machine’s total RAM.

Step 1 — install

The official path works on this hardware:

curl -fsSL https://ollama.com/install.sh | sh

Expect a multi-gigabyte download — the bundle carries CPU, CUDA, ROCm and Vulkan backends. It registers a systemd service and starts it. Verify:

ollama --version
systemctl is-active ollama

Step 2 — read the GPU detection like a local, not like a bug report

This is where this machine differs from the tutorials. Check what the service saw:

journalctl -u ollama -n 80 | grep -iE "gpu|rocm|gfx|compute"

On our box, a fresh install prints two lines that look contradictory:

msg="dropping integrated GPU; to enable, set OLLAMA_IGPU_ENABLE=1"
     id=0 library=Vulkan name=Vulkan0 description="AMD Radeon Graphics (RADV GFX1151)"
msg="inference compute" id=0 library=ROCm compute=gfx1151
     description="Radeon 8060S Graphics" type=iGPU total="117.4 GiB" available="117.4 GiB"

Decoded: Ollama’s Vulkan path drops integrated GPUs by default — that first line is the one that sends people to the issue tracker convinced their GPU is unsupported. But the bundled ROCm backend recognizes gfx1151 directly and takes the device, with the full memory ceiling visible. On a current Ollama, this hardware works out of the box through ROCm; you only need OLLAMA_IGPU_ENABLE=1 if you specifically want the Vulkan path. If your log shows the drop line and no ROCm line, your Ollama predates the bundled gfx1151 support — update it before touching anything else.

Step 3 — pull and run

ollama pull llama3.2:3b
ollama run llama3.2:3b "Reply with one short sentence: what is inference?"

Start small to validate the pipeline; size up after. What actually fits in this machine’s memory class is measured separately.

Step 4 — prove it landed on the GPU

The check almost nobody runs, and the one that matters most on an iGPU machine where a silent CPU fallback produces plausible-but-slow behavior:

ollama ps

The PROCESSOR column must say 100% GPU. Ours does. Anything like XX%/XX% CPU/GPU means part of the model spilled — too big for the ceiling you configured in step 0, or the GPU was not picked up at all. A model “working” on CPU is the classic green-but-broken state: answers arrive, everything looks fine, and you quietly get a fraction of what the box can do.

Also worth knowing: Ollama sizes its default context from detected memory (ours picked a six-figure token window on its own) and unloads idle models after a few minutes — the UNTIL column in ollama ps is that countdown, not an error.

Where this path ends

Ollama’s defaults are chosen for convenience, and they move between releases. The day you want to measure anything, or your numbers disagree with someone else’s, switch to asking the server what it actually runs and pinning what you deploy: that discipline is the whole difference between a setup and a configuration. For serving a team, mind the concurrency ladder; Ollama ships with a single parallel slot by default.