Strix Halo: die Hardware verstehen
Ein Ryzen AI Max+ 395 mit einer iGPU, die keinen eigenen Speicher hat. Fast jedes Problem auf dieser Maschine — von der Token-Rate ueber das BIOS bis zur Modellgroesse — laeuft auf dieselbe Ursache zurueck: Es gibt nur einen Speicher, und alle wollen ihn gleichzeitig. Diese Seite erklaert das Modell, die Zahl, an der alles haengt, und die Widersprueche, die dabei in diesem Repo entstanden sind.
Die Maschine
| Merkmal | Erfasst |
|---|---|
| CPU | AMD Ryzen AI MAX+ PRO 395 (6C Zen4 + 8C Strix Point Zen5, max 5,1 GHz) |
| GPU | Radeon 8060S / 890M (40 CUs RDNA 3.5) mit Infinity Fabric <-> CPU |
| Arbeitsspeicher | LPDDR5X-8533 on-die, bis zu 94 GB nutzbar als Unified Memory |
| Storage | 1,9 TB NVMe · 512 eMMC |
| GPU-Compute | RDNA 3.5 FP16: ~ 182 TFLOP · Ray Tracing: ~ 447 TFLOP |
| OS | Fedora Workstation 44 / Kernel ~7.x (AMDGPU-Treiber) |
| Backend | ROCm Standard + OpenCL über OLLAMA_OPENCL=1 |
| Ollama | 0.32.5 |
| GPU-Target | gfx1151 (RDNA 3.5) |
Quelle: src/data/models.ts · hardwareSpecs. Der Punkt „Bandbreite“ fehlt hier bewusst — dazu Abschnitt 3 und Abschnitt 5.
Unified Memory statt VRAM
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. CPU und GPU nutzen dasselbe Blech — es gibt hier, anders als bei dedizierten Karten, keinen Geschwindigkeitsvorteil durch „echtes“ VRAM.
| Begriff | Bedeutung |
|---|---|
| VRAM / Carve-out / GART | Der im BIOS fest fuer die GPU reservierte Block. Permanent weg vom Betriebssystem, auch wenn die GPU nichts tut. |
| GTT | Der Pool an System-RAM, der dynamisch in GPU-Adressraeume gemappt werden darf. Das ist der Topf, aus dem PyTorch und vLLM sich bedienen — standardmaessig ca. 50 % des RAM. |
Praktisch heisst das: Die Frage ist nie „wie viel VRAM hat die GPU“, sondern „wie viel von den 117 GiB passen gleichzeitig in den GPU-Adressraum und bleiben dem OS noch“. Ein 68-GiB-Modell ist moeglich, aber nur, weil nichts anderes gleichzeitig grossflaechig Speicher belegt.
Die Bandbreiten-Wand
Bei der Token-Erzeugung passiert pro Token genau eine Sache: alle aktiven Gewichte muessen einmal komplett durch den Speicherbus. Rechenleistung ist dabei nicht das Limit — die GPU wartet auf Daten. Strix Halo hat nominell 256 GB/s, real erreichbar sind ~200–220 GB/s. Das ist die Wand, und sie gilt fuer jedes Modell und jedes Backend.
| Quant | Modellgroesse | theoretisch moeglich | gemessen | Ausnutzung |
|---|---|---|---|---|
| IQ4_XS | 14,6 GiB | ~14,5 t/s | 13,3 t/s | 92 % |
| UD-Q4_K_XL | 17,1 GiB | ~12,5 t/s | 12,0 t/s | 96 % |
| Q8_0 | 28,0 GiB | ~7,7 t/s | 7,7 t/s | 100 % |
Zum Vergleich: dense 27B ist der unguenstigste Fall fuer diese Hardware. MoE-Modelle auf derselben Maschine erreichen 69 t/s (qwen3-coder:30b) bzw. 51 t/s (glm-4.7-flash) — nicht, weil sie besser optimiert waeren, sondern weil sie pro Token nur einen Bruchteil ihrer Gewichte anfassen.
Was das fuer die Modellwahl heisst
Aus der Wand folgen genau drei Hebel — und eine Reihe von Dingen, die ausdrucklich keine Hebel sind.
| Hebel | Wirkung | Grenze |
|---|---|---|
| MoE statt dense | Weniger aktive Gewichte pro Token, direkt mehr t/s. 69 t/s (MoE 30B) gegen 7,7 t/s (dense 27B, Q8_0) auf derselben Maschine. | Qualitaet haengt nicht an der Aktivrate — das kleinere Modell ist oft das bessere. |
| Kleineres Quant | Der einzige Weg unter die Grenze. Q8_0 → IQ4_XS: 28 → 15 GB, 7,7 → 13,3 t/s. | Irgendwann leidet die Qualitaet; unter Q4 wird es je nach Modell deutlich. |
| Speculative Decoding | Der einzige Weg ueber die Grenze. MTP hebt 13,3 auf 30,9 t/s (Code) bzw. 25,0 t/s (Prosa). | Braucht einen passenden Draft; Gewinn haengt von der Akzeptanzrate ab. |
| Backend / Treiber / Flags | Bei der Generierung irrelevant: 13,29 vs 13,38 t/s zwischen Vulkan und ROCm — unter 1 %. Die GPU wartet auf Speicher, nicht auf Rechenwerke. | Beim Prompt-Processing gewinnt ROCm klar (+15 %), weil das compute-bound ist. |
Die einzige Regel, die aus alldem uebrig bleibt: Immer MoE-Modelle, niemals dense — ausser, ein bestimmtes dichtes Modell ist qualitativ alternativlos. Dann ist Speculative Decoding der einzige Ausweg.
Widersprueche in den eigenen Zahlen
Diese Seite wurde nicht von einer einzigen Quelle geschrieben. Dabei sind Werte entstanden, die sich gegenseitig widersprechen — und ein Teil der kursierenden Rechnungen ist auf den falschen Wert gestuetzt. Hier steht, was gilt und warum.
Speicherbandbreite
- src/data/constants.ts→ Infinity Fabric ca. 1 GB/s
- src/data/models.ts→ ~10 GB/s (Infinity Fabric)
- src/data/setup.ts→ ~256 GB/s
- vllm.md→ ~256 GB/s theoretisch, real ~215 GB/s
- QWEN38-STRIX-HALO.md→ nominell 256 GB/s, real 200–220 GB/s
Nur dieser Wert erklaert die gemessene Rate: 28 GiB Modell bei 7,7 t/s Q8_0 ergeben rund 216 GB/s — und genau dort liegt die Ausnutzung laut Messung bei 100 %. Die 1 GB/s und 10 GB/s beschreiben den CPU-GPU-Link, nicht den Speicherbus, und gehoeren in keine Token-Rechnung.
Nutzbarer Arbeitsspeicher
- src/data/models.ts→ bis zu 94 GB Unified Memory
- src/data/media.ts→ 117 GB nutzbar
- bench/ergebnisse · speicher.gesamt_ram_gib→ 117,678 GiB
Der Wert 94 GB stammt aus der fruehen Ollama-Phase und taucht in den neueren Messungen nicht wieder auf. Belegbar ist MemTotal aus dem Messprotokoll.
GPU-Bezeichnung
- src/data/models.ts→ Radeon 8060S / 890M
- src/data/constants.ts→ Radeon 890M
- bench/ergebnisse · system.cpu_modell→ AMD Ryzen AI Max+ PRO 395 w/ Radeon 8060S
Die 890M ist das benachbarte Die-Modell, nicht die hier verbaute Variante. Die 8060S steht so in der erfassten CPU-Kennung.
Storage
- src/data/models.ts→ 1,9 TB NVMe + 512 GB eMMC
- src/data/constants.ts→ 960 GB eMMC + 1,6 TB NVMe
Konflikt ohne Auswirkung auf Messungen. Aufgeloest nach dem neueren Datenmodell; constants.ts ist Altbestand.
Weiter zur Praxis
Setup-Guide
Ollama auf gfx1151 zum Laufen bringen: FlashAttention, Kontextlaenge, GPU-Nachweis, Pulls ueber nohup — 10 Schritte, jeweils mit dem Stolperstein, der dabei wirklich passiert.
vLLM auf gfx1151
Container-Build mit AMDGPU_TARGETS=gfx1151, AITER/Triton-Anpassungen, Tuning, systemd-Unit und Troubleshooting. Native Unterstuetzung seit PR #25908.