Strix Halo AI Benchmarks
gfx1151Ryzen AI Max+ 395ROCm / TheRock

vLLM auf Strix Halo

Einrichtung, Konfiguration und Betrieb von vLLM auf einer Strix-Halo-APU unter Linux — von den Kernel-Parametern bis zum systemd-Service. Stand: August 2026.

1

TL;DR — der schnellste Weg

Wenn du nur die Kurzfassung willst und ein Fedora-System hast:
bash

1) Kernel-Parameter in /etc/default/grub an GRUB_CMDLINE_LINUX anhängen:

amd_iommu=off amdgpu.gttsize=126976 ttm.pages_limit=32505856

2) Toolbox-Repo holen und Container anlegen

3) Rein und Modell starten

4) Testen

$sudo grub2-mkconfig -o /boot/grub2/grub.cfg

$sudo reboot

$sudo dnf install -y git toolbox

$git clone https://github.com/kyuz0/amd-strix-halo-vllm-toolboxes.git

$cd amd-strix-halo-vllm-toolboxes

$./refresh_toolbox.sh

$toolbox enter vllm

$start-vllm # interaktiver TUI-Assistent

$curl -s http://localhost:8000/v1/models | jq

Alles andere in diesem Dokument erklärt, warum diese Schritte so aussehen und was du drehen kannst.
2

Warum das überhaupt fummelig ist

Strix Halo ist keine normale GPU, und genau daraus ergeben sich alle Stolpersteine:

2.1 Es ist eine APU mit Unified Memory

Der Radeon 8060S hat keinen eigenen VRAM. Er greift über GPU-Virtual-Memory (GPUVM) auf den ganz normalen System-RAM zu. AMD beschreibt das so: Speicher wird auf RDNA3.5-APUs gemappt, nicht physisch partitioniert. Zwei Begriffe sind dabei zentral:
BegriffBedeutung
VRAM / Carve-out / GARTDer im BIOS fest für die GPU reservierte Block. Permanent weg vom OS.
GTTDer Pool an System-RAM, der dynamisch in GPU-Adressräume gemappt werden darf. Das ist der Topf, aus dem PyTorch und vLLM sich bedienen. Standardmäßig ca. 50 % des RAM.
Konsequenz für die Praxis: BIOS-VRAM klein lassen (0,5 GB reichen), stattdessen das GTT-/TTM-Limit hochziehen. Da CPU und GPU physisch denselben Speicher nutzen, gibt es hier — anders als bei dedizierten Karten — keinen Geschwindigkeitsvorteil durch „echtes“ VRAM. Reservieren kostet dich nur RAM.

2.2 gfx1151 war lange ein Sonderfall

vLLM erkennt AMD-GPUs beim Start über amdsmi. Diese Bibliothek kannte gfx1151 lange nicht, und Build-Systeme kompilierten per Default für gfx1200/gfx1201 (RDNA4) statt für RDNA3.5. Deshalb kursieren so viele Anleitungen mit Patch-Orgien.
Das hat sich 2026 entspannt: Upstream-vLLM hat native gfx1151-Unterstützung bekommen (PR #25908), sodass man das offizielle ROCm-Dockerfile inzwischen ohne Workarounds mit AMDGPU_TARGETS=gfx1151 bauen kann. Die Community-Toolbox bleibt trotzdem der bequemste Weg, weil dort zusätzlich AITER-, Triton- und RCCL-Anpassungen für RDNA-APUs drinstecken.

2.3 Der Kernel muss neu genug sein

AMD nennt konkrete KFD-Fixes, ohne die Compute-Workloads gar nicht erst korrekt initialisieren oder sich unvorhersehbar verhalten. Mindestversionen:
DistributionMindest-Kernel
Ubuntu 24.04 HWE6.17.0-19.19~24.04.2
Ubuntu 24.04 OEM6.14.0-1018
Alle anderen (Fedora, Arch, …)6.18.4
Fedora 43, Ubuntu 26.04 und Arch (ab 2026.02) bringen die Fixes von Haus aus mit. Kernel älter als 6.18.4 haben auf gfx1151 einen bekannten Stabilitätsbug — nicht benutzen.
3

Voraussetzungen

Hardware

  • AMD Ryzen AI Max / Max+ (Strix Halo, gfx1151) — z. B. Framework Desktop, GMKtec EVO-X2, HP ZBook Ultra G1a
  • Idealerweise 128 GB LPDDR5X-8000 (64 GB geht, limitiert aber die Modellgröße hart)
  • Speicherbandbreite ~256 GB/s theoretisch, real eher ~215 GB/s — das ist dein eigentliches Limit bei der Token-Rate

Software

  • Fedora 43 (am besten getestet) oder Ubuntu 26.04 / 24.04 HWE
  • Kernel gemäß Tabelle oben
  • podman (Fedora) bzw. docker + distrobox (Ubuntu)
  • Genug Plattenplatz: ein 120B-Modell in BF16 sind ~120 GB Download

Vorab prüfen

bash

$uname -r # Kernel-Version

$lspci | grep -i vga # sollte "Radeon 8060S" o. ä. zeigen

$rocminfo | grep gfx # sollte gfx1151 melden (falls ROCm auf dem Host)

$free -g # verfügbarer RAM

4

Schritt 1: Host konfigurieren (der wichtigste Teil)

Wenn du diesen Schritt überspringst, bekommt die GPU nur einen Bruchteil des RAM und alles außer 7B-Modellen scheitert mit OOM.

4.1 BIOS

Setz die dedizierte GPU-Speicherzuweisung (heißt je nach Hersteller UMA Frame Buffer Size, Dedicated Graphics Memory, VGA Memory) auf einen kleinen Wert — 512 MB. Der Rest kommt dynamisch über GTT. AMD empfiehlt das ausdrücklich so.

4.2 Kernel-Parameter

Trag in /etc/default/grub bei GRUB_CMDLINE_LINUX diese drei Parameter ein:
/etc/default/grub

$amd_iommu=off amdgpu.gttsize=126976 ttm.pages_limit=32505856

ParameterZweck
amd_iommu=offSchaltet die IOMMU ab. Community-Benchmarks zeigen 5–12 % Vorteil gegenüber iommu=pt bzw. eingeschalteter IOMMU. Reduziert Overhead beim Unified-Memory-Zugriff (und bei RDMA-NICs).
amdgpu.gttsize=126976Deckelt den GTT-Pool auf 124 GiB (126976 MiB ÷ 1024).
ttm.pages_limit=32505856Deckelt den pinbaren Speicher auf dieselben 124 GiB (32505856 × 4 KiB). Beide Werte müssen zusammenpassen.
Rechnung für andere RAM-Größen: Lass dem OS mindestens 4 GiB. Bei 64 GB RAM also z. B. 60 GiB für die GPU: gttsize = 60 × 1024 = 61440 und pages_limit = 61440 × 1024 / 4 = 15728640.
Anwenden:
bash

$sudo grub2-mkconfig -o /boot/grub2/grub.cfg # Fedora

$# Ubuntu: sudo update-grub

$sudo reboot

Nach dem Reboot prüfen:
bash

$cat /proc/cmdline | grep gttsize

$cat /sys/module/ttm/parameters/pages_limit

4.3 Alternative: amd-ttm statt Kernel-Parametern

AMD liefert inzwischen ein Helferlein, das das TTM-Limit sauber über /etc/modprobe.d/ttm.conf setzt — bequemer als GRUB-Gefummel:
bash

$sudo apt install pipx # bzw. dnf install pipx

$pipx ensurepath

$pipx install amd-debug-tools

$amd-ttm # zeigt aktuelles Limit + Gesamt-RAM

$amd-ttm --set 120 # 120 GB freigeben

$# danach rebooten

$amd-ttm --clear # zurück auf Kernel-Default

5

Schritt 2: Container anlegen (Weg A — empfohlen)

Wir nutzen die amd-strix-halo-vllm-toolboxes von kyuz0. Das ist ein fertiges Image mit ROCm (TheRock-Builds), PyTorch, Flash-Attention, gepatchtem vLLM und angepasster RCCL — also genau der Stack, den du sonst mühsam selbst zusammenbauen müsstest.

5.1 Warum Container?

  • ROCm-Nightlies und die passenden PyTorch-Wheels sind eine sehr spezifische Kombination. Auf dem Host installiert zerschießt dir das früher oder später die Systempakete.
  • Toolbx/Distrobox teilen dein $HOME und deinen User mit dem Container. Modelle landen also in ~/.cache/huggingface auf dem Host und überleben jedes Image-Update.
  • Für den Produktivbetrieb kannst du dasselbe Image auch als reinen Docker/Podman-Container mit Host-Networking fahren.

5.2 Image-Kanäle

TagBeschreibung
:latestLetzter verifizierter Build. Für die meisten Leute die richtige Wahl.
:devBleeding Edge. Kann Upstream-Regressionen enthalten.

5.3 Fedora (Toolbx)

bash

$sudo dnf install -y git toolbox

$git clone https://github.com/kyuz0/amd-strix-halo-vllm-toolboxes.git

$cd amd-strix-halo-vllm-toolboxes

$./refresh_toolbox.sh # interaktiv; oder: ./refresh_toolbox.sh latest

Das Skript zieht das Image und legt die Toolbox mit den korrekten Flags an. Es erkennt außerdem automatisch, ob /dev/infiniband existiert, und reicht die Geräte für RDMA-Clustering durch. Manuell geht’s genauso:
bash

$toolbox create vllm \

$ --image docker.io/kyuz0/vllm-therock-gfx1151:latest \

$ -- --device /dev/dri --device /dev/kfd \

$ --group-add video --group-add render \

$ --security-opt seccomp=unconfined

$toolbox enter vllm

Was die Flags tun:
FlagZweck
--device /dev/kfdKernel-Fusion-Driver — das eigentliche Compute-Interface von ROCm
--device /dev/driDirect-Rendering-Interface — Zugriff auf die GPU-Knoten
--group-add video --group-add renderGruppenrechte für den GPU-Zugriff
--security-opt seccomp=unconfinedROCm braucht Syscalls, die das Default-seccomp-Profil blockt

5.4 Ubuntu / Debian / Arch (Distrobox)

Das toolbox-Paket unter Ubuntu bricht den GPU-Zugriff — nimm Distrobox:
bash

$distrobox create -n vllm \

$ --image docker.io/kyuz0/vllm-therock-gfx1151:latest \

$ --additional-flags "--device /dev/kfd --device /dev/dri \

$ --group-add video --group-add render --security-opt seccomp=unconfined"

$distrobox enter vllm

5.5 GPU im Container verifizieren

bash

$rocm-smi

$rocminfo | grep -i gfx

$python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

6

Schritt 3: Modell starten

6.1 Variante A: TUI-Assistent

Das Image bringt start-vllm mit — ein interaktiver Launcher mit vorkonfigurierten Modellen, der die passenden Flags, Attention-Backends und Cache-Einstellungen selbst setzt:
bash

$start-vllm

Für den Einstieg klar die beste Option: Die Profile dort sind auf gfx1151 getestet, inklusive der Modelle, die eigene Sonderbehandlung brauchen.

6.2 Variante B: Manueller Start

Volle Kontrolle:
bash

$vllm serve Qwen/Qwen3.6-35B-A3B \

$ --host 0.0.0.0 \

$ --port 8000 \

$ --tensor-parallel-size 1 \

$ --max-num-seqs 1 \

$ --max-model-len 32768 \

$ --gpu-memory-utilization 0.95 \

$ --dtype auto \

$ --trust-remote-code \

$ --attention-backend TRITON_ATTN

6.3 Die Flags im Detail

FlagErklärung
--host 0.0.0.0Lauscht auf allen Interfaces. Nur setzen, wenn du wirklich von außen zugreifen willst — vLLM hat standardmäßig keine Authentifizierung. Sonst 127.0.0.1 + SSH-Tunnel.
--port 8000Standardport der OpenAI-kompatiblen API
--tensor-parallel-size 1Eine „GPU“. Unified Memory heißt: kein TP nötig. TP=2 nur im Multi-Node-Cluster.
--max-num-seqs 1Maximal 1 Anfrage gleichzeitig → niedrigste Latenz für Einzelnutzer. Für Mehrbenutzer/Agenten unbedingt hochsetzen (8–32), sonst verschenkst du genau die Stärke von vLLM.
--max-model-len 32768Kontextfenster. Direkt proportional zum KV-Cache-Verbrauch — der erste Hebel bei OOM.
--gpu-memory-utilization 0.95Anteil des GPU-Speichers für Gewichte + KV-Cache. Bei Instabilität auf 0.90 oder 0.85.
--dtype autoNimmt den im Modell hinterlegten Typ (meist BF16).
--trust-remote-codeNötig für Modelle mit eigenem Python-Code im Repo (Qwen, MiniMax u. a.). Nur bei Repos, denen du vertraust.
--attention-backend TRITON_ATTNAttention-Implementierung — siehe nächster Abschnitt.
7

Schritt 4: Konfiguration verstehen und tunen

7.1 Attention-Backends

Der Launcher der Toolbox stellt drei Backends zur Auswahl:
BackendCharakteristik
TRITON_ATTNTriton-Kernel. Der solide Default auf gfx1151, breiteste Modellkompatibilität.
ROCM_ATTNRoutet in der Toolbox auf AITER Flash Attention. Kann schneller sein, aber nicht bei jedem Modell stabil.
ROCM_AITER_UNIFIED_ATTNAITERs Unified-Attention-Pfad. Ausprobieren, benchmarken, dann entscheiden.
Hintergrund zu AITER: Normalerweise crasht vLLM auf RDNA-APUs mit VLLM_ROCM_USE_AITER=1, weil AITER CDNA-spezifische Assembly für MoE- und CustomOps JIT-kompilieren will, die RDNA-Hardware schlicht nicht hat. Die Toolbox setzt dafür gezielte Guards: AITER-MoE und FP8-Linear werden auf gfx1x deaktiviert, das Env-Var-Override wird blockiert, und die RMSNorm-Custom-Op-Registrierung wird umgangen (die sonst beim CUDA-Graph-Capture während der Modellinitialisierung crasht). Ergebnis: Attention läuft über AITER, MoE-Matrizen fallen sicher auf Triton zurück.

7.2 Nützliche Environment-Variablen

bash

Speichermodell von Strix Halo — praktisch immer sinnvoll

Experimentelle AOTriton-Kernel, für gfx1151 nötig

Spürbarer Durchsatzgewinn durch besseren Allocator

hipBLASLt statt rocBLAS

Autotuning der GEMM-Kernel (langsamer erster Lauf, danach schneller)

$export HIP_FORCE_DEV_KERNARG=1

$export TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1

$export LD_PRELOAD=/usr/lib64/libtcmalloc_minimal.so.4

$export ROCBLAS_USE_HIPBLASLT=1

$export PYTORCH_TUNABLEOP_ENABLED=1

Wenn du Env-Vars systematisch durchgehen willst: Die maßgebliche Liste steht immer im Quellcode unter vllm/envs.py.

7.3 Kernel-Cache

Der allererste Inferenzlauf ist langsam, weil vLLM Triton-Kernel kompiliert. Die landen in ~/.cache/vllm/ und werden danach wiederverwendet. Nach einem Image-Update lohnt es sich, diesen Cache zu leeren:
bash

$rm -rf ~/.cache/vllm/

8

Schritt 5: API testen + Web-UI

8.1 API-Check

vLLM spricht das OpenAI-Protokoll:
bash

Welches Modell läuft gerade?

Chat-Completion

$curl -s http://localhost:8000/v1/models | jq -r '.data[0].id'

$MODEL=$(curl -s http://localhost:8000/v1/models | jq -r '.data[0].id')

$curl -X POST http://localhost:8000/v1/chat/completions \

$ -H "Content-Type: application/json" \

$ -d "{

$ \"model\": \"$MODEL\",

$ \"messages\": [{\"role\": \"user\", \"content\": \"Erklär mir GTT in zwei Sätzen.\"}]

$ }" | jq -r '.choices[0].message.content'

Damit funktioniert auch jeder OpenAI-kompatible Client — Open WebUI, Continue, Aider, OpenCode, LangChain, das OpenAI-Python-SDK mit base_url="http://localhost:8000/v1" und einem beliebigen Dummy-Key.

8.2 Remote-Zugriff

Da vLLM keine Authentifizierung hat, ist SSH-Portforwarding die richtige Antwort:
bash

$ssh -L 8000:localhost:8000 user@strix-halo-host

Danach zeigt http://localhost:8000 auf deinem Rechner auf den Server.

8.3 Web-UI

HuggingFace ChatUI als schnelle Oberfläche:
bash

$docker run -p 3000:3000 \

$ --add-host=host.docker.internal:host-gateway \

$ -e OPENAI_BASE_URL=http://host.docker.internal:8000/v1 \

$ -e OPENAI_API_KEY=dummy \

$ -v chat-ui-data:/data \

$ ghcr.io/huggingface/chat-ui-db

Open WebUI ist die featurereichere Alternative — funktioniert genauso über OPENAI_API_BASE_URL.
9

Dauerbetrieb: systemd-Service

Für einen Homeserver willst du vLLM nicht in einer interaktiven Toolbox laufen lassen. Beispiel für eine User-Unit mit Podman:
vllm.service (systemd)
# ~/.config/systemd/user/vllm.service
[Unit]
Description=vLLM (Strix Halo, gfx1151)
After=network-online.target
Wants=network-online.target

[Service]
Restart=always
RestartSec=10
TimeoutStartSec=900
ExecStartPre=-/usr/bin/podman rm -f vllm-server
ExecStart=/usr/bin/podman run --rm --name vllm-server \
  --device /dev/kfd --device /dev/dri \
  --group-add keep-groups \
  --security-opt seccomp=unconfined \
  --ipc=host \
  --network=host \
  -v %h/.cache/huggingface:/root/.cache/huggingface:z \
  -v %h/.cache/vllm:/root/.cache/vllm:z \
  -e HIP_FORCE_DEV_KERNARG=1 \
  -e TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1 \
  docker.io/kyuz0/vllm-therock-gfx1151:latest \
  vllm serve Qwen/Qwen3.6-35B-A3B \
    --host 127.0.0.1 --port 8000 \
    --max-num-seqs 8 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.92 \
    --attention-backend TRITON_ATTN
ExecStop=/usr/bin/podman stop -t 30 vllm-server

[Install]
WantedBy=default.target
Aktivieren:
bash

$systemctl --user daemon-reload

$systemctl --user enable --now vllm.service

$loginctl enable-linger $USER # damit's ohne aktive Session läuft

$journalctl --user -u vllm -f

Wer das lieber deklarativ hätte: Es gibt eine Ansible-Collection, die genau diesen Weg automatisiert (Toolbox- und Service-Modus, Kernel-Tuning, Model-Prefetching, optional Open WebUI).
10

Weg B: Eigenes Image aus vLLM-Upstream bauen

Seit gfx1151 nativ unterstützt wird, kannst du das offizielle ROCm-Dockerfile ohne Patches nutzen. Sinnvoll, wenn du die allerneuesten Modell-Implementierungen brauchst oder die Toolbox-Patches nicht willst:
bash

$git clone https://github.com/vllm-project/vllm.git

$cd vllm

$DOCKER_BUILDKIT=1 docker build \

$ --build-arg AMDGPU_TARGETS=gfx1151 \

$ -f docker/Dockerfile.rocm \

$ -t vllm-rocm-strix-halo .

Auf minimalen Server-Installationen musst du BuildKit ggf. erst nachinstallieren. Starten dann analog zur systemd-Unit oben, nur mit vllm-rocm-strix-halo als Image.
11

Weg C: Bare Metal aus dem Quellcode

Nur relevant, wenn du keine Container willst oder aktiv am Stack entwickelst. Grobe Skizze (Fedora 43):
bash

1) Build-Abhängigkeiten

2) ROCm aus TheRock-Nightlies (nach GFX-Target indiziert)

3) PyTorch aus dem target-spezifischen Nightly-Index

4) vLLM bauen — WICHTIG: ROCms clang, nicht Fedoras GCC

$sudo dnf install -y python3.13 python3.13-devel libatomic gcc gcc-c++ make \

$ ffmpeg-free aria2 libdrm-devel zlib-devel openssl-devel procps-ng \

$ numactl-devel gperftools-libs libibverbs-utils

$GFX=gfx1151

$ROCM_PATH=/opt/rocm

$S3="https://therock-nightly-tarball.s3.amazonaws.com"

$KEY="$(curl -s "${S3}?list-type=2&prefix=therock-dist-linux-${GFX}-7" \

$ | grep -oP '(?<=<Key>)[^<]+' | sort -V | tail -n1)"

$aria2c -x 16 -s 16 -j 16 "${S3}/${KEY}" -o therock.tar.gz

$sudo mkdir -p "$ROCM_PATH"

$sudo tar xzf therock.tar.gz -C "$ROCM_PATH" --strip-components=1

$python -m pip install --pre torch torchaudio torchvision \

$ --index-url "https://rocm.nightlies.amd.com/v2-staging/${GFX}/"

$export CC="$ROCM_PATH/llvm/bin/clang"

$export CXX="$ROCM_PATH/llvm/bin/clang++"

$export PYTORCH_ROCM_ARCH="$GFX" AMDGPU_TARGETS="$GFX" HIP_ARCHITECTURES="$GFX"

$export VLLM_TARGET_DEVICE=rocm

$git clone https://github.com/vllm-project/vllm.git && cd vllm

$python -m pip wheel --no-build-isolation --no-deps -w /tmp/dist -v .

$python -m pip install /tmp/dist/*.whl

Zwei Fallen, die dich sonst Stunden kosten:
  1. Compiler-ABI: Mit GCC gebaute vLLM-Extensions sind inkompatibel zu dem mit Clang gebauten PyTorch. Immer ROCms Clang nehmen.
  2. Bitcode-Pfad: TheRock-Nightlies haben keinen stabilen Pfad zum Device-Bitcode. Dynamisch suchen: find "$ROCM_PATH" -type d -name bitcode -print -quit und als HIP_DEVICE_LIB_PATH setzen.
12

Modellauswahl für 128 GB Unified Memory

Faustregel: BF16 ≈ 2 GB pro Milliarde Parameter, plus KV-Cache. Bei ~124 GB nutzbarem Speicher passen also rund 50B in BF16 oder deutlich mehr in 4-Bit-AWQ — plus Reserve für Kontext.
Getestete Kombinationen aus dem Toolbox-Projekt:
ModellGröße / QuantAnforderung
meta-llama/Meta-Llama-3.1-8B-Instruct8B / BF161 GPU
google/gemma-4-26B-A4B-it26B / BF161 GPU
openai/gpt-oss-20b20B / BF161 GPU
openai/gpt-oss-120b120B / BF161 GPU
Qwen/Qwen3.6-35B-A3B35B / BF161 GPU
cyankiwi/Qwen3.5-122B-A10B-AWQ-4bit122B / AWQ 4-bit1 GPU
cyankiwi/Qwen3.5-122B-A10B-AWQ-8bit122B / AWQ 8-bitnur 2 Nodes (TP=2)
cyankiwi/MiniMax-M2.7-AWQ-4bitAWQ 4-bitnur 2 Nodes (TP=2)

Warum MoE-Modelle hier besonders gut passen

Bei Qwen3.6-35B-A3B stehen 35B Gesamtparameter nur ~3B aktiven Parametern pro Forward-Pass gegenüber. Auf Strix Halo ist das ideal: Der große Gesamtumfang lebt bequem im Unified Memory, aber pro Token muss nur ein Bruchteil davon durch die Speicherbandbreite — und die Bandbreite ist auf dieser Plattform der Flaschenhals, nicht die Rechenleistung. Du bekommst also annähernd Qualität eines großen Modells bei der Geschwindigkeit eines kleinen.

Zu den Benchmark-Zahlen im Netz

Die Durchsatzangaben des Toolbox-Projekts messen Peak-Durchsatz bei hoher Parallelität — also viele Sequenzen gleichzeitig, um die Speicherbandbreite zu sättigen. Bei einer einzelnen Anfrage (Concurrency = 1) liegst du deutlich darunter. Nicht wundern, wenn deine Zahlen nicht den Tabellen entsprechen: Du misst wahrscheinlich etwas anderes.
13

Troubleshooting

SymptomUrsache & Lösung
rocm-smi findet nichts im ContainerContainer ohne --device /dev/kfd --device /dev/dri angelegt; oder User nicht in video/render; oder unter rootless Podman → --group-add keep-groups statt der benannten Gruppen
OOM beim Modell-LadenKernel-Parameter prüfen (cat /proc/cmdline). Dann --gpu-memory-utilization auf 0.90/0.85, --max-model-len halbieren
OOM erst mitten im Betrieb--max-num-seqs zu hoch — jede parallele Sequenz braucht eigenen KV-Cache
Container startet gar nicht (rootless)Die benannten GPU-Gruppen können unter rootless Podman den Start blockieren → --group-add keep-groups
Crash beim Init mit CUDA-Graph-CaptureBekanntes RMSNorm-/AITER-Problem auf RDNA. Toolbox-Image nutzen (bringt den Guard mit) oder AITER abschalten
Erste Inferenz extrem langsamTriton-Kernel werden kompiliert. Normal. Cache liegt in ~/.cache/vllm/
Nach Image-Update seltsame FehlerKernel-Cache leeren: rm -rf ~/.cache/vllm/
Instabilität, zufällige HängerKernel < 6.18.4? Upgraden. Auf gfx1151 gibt es dort einen bekannten Bug
Nur ~64 GB nutzbar trotz korrekter ParameterBekannter Bug in manchen ROCm-Nightlies, der die Allokation deckelt. Auf einen stabilen ROCm-7.x-Build wechseln
unrecognized environment variableImage zu alt für die Variable. Aktualisieren oder Variable weglassen
Modell lädt, Ausgabe ist KauderwelschFalsches Attention-Backend oder inkompatible Quantisierung. Auf TRITON_ATTN + BF16 zurückfallen und von dort neu tunen
Diagnose-Einzeiler:
bash

$cat /proc/cmdline # Kernel-Parameter aktiv?

$cat /sys/module/ttm/parameters/pages_limit # TTM-Limit

$rocm-smi --showmeminfo vram # was sieht ROCm?

$uname -r # Kernel neu genug?

$journalctl -k | grep -i amdgpu | tail -50 # Treiberfehler

14

Realistische Erwartungen: vLLM vs. llama.cpp

Ehrliche Einordnung, bevor du Zeit investierst:
vLLM ist für Rechenzentrums-Batching gebaut. Seine Stärke ist Durchsatz bei vielen gleichzeitigen Anfragen — Continuous Batching, PagedAttention, niedrige TTFT für eine Gruppe von Nutzern. Auf Strix Halo heißt das: Wenn du mehrere Agenten oder Nutzer parallel bedienst, ist vLLM die richtige Wahl.
Für einen einzelnen Nutzer ist llama.cpp auf dieser Hardware oft schneller und deutlich einfacher aufzusetzen. Es kann inzwischen ebenfalls Prompt-Caching und parallele Ausführung, und die Vulkan-Backends auf Strix Halo sind sehr ausgereift. Wer nur lokal chatten will, ist damit meist zufriedener.
Bandbreite ist das Limit. ~215 GB/s gemessen gegenüber 1.000+ GB/s bei diskreten GPUs. Bei kleinen Modellen, die in 24 GB VRAM passen, verliert Strix Halo klar gegen eine dedizierte Karte. Der Vorteil liegt woanders: 120B-Modelle in einem leisen Desktop unterhalb von Mac-Studio-Preisen.
15

Quellen

Das Ökosystem um gfx1151 bewegt sich schnell. Bevor du bei einem Problem lange gräbst: erst Image aktualisieren und in die Issues des Toolbox-Repos schauen — die meisten Stolpersteine sind dort schon dokumentiert.
Basierend auf kyuz0/amd-strix-halo-vllm-toolboxes · Stand August 2026 · Fedora 43, Kernel ≥ 6.18.4