Zum Hauptinhalt springen
Nicht empfohlene Hardware. Tokios empfiehlt AMD Strix Halo (Ryzen AI Max+ 395) nicht als primäre Plattform für Inferenzaufgaben. Diese Hardware wurde bisher nur von der Community erkundet; die Treiberunterstützung ist uneinheitlich, die Stabilität von ROCm hängt von spezifischen Kernel- und Firmware-Versionen ab, und Vulkan stellt die einzige zuverlässige Schnittstelle dar. Für produktive oder alltägliche Inferenzanwendungen empfehlen wir stattdessen ein Mac Studio, ein DGX Spark oder eine RTX-Workstation. Diese Seite richtet sich an Nutzer, die bereits über Strix Halo-Hardware verfügen und diese optimal nutzen möchten.
Der AMD Ryzen AI Max+ 395 („Strix Halo“) verfügt über bis zu 128 GB gemeinsam genutzten Speicher für CPU und Radeon 8060S iGPU. Dieser Speicher reicht aus, um Modelle zu laden, die normalerweise eine dedizierte GPU im Wert von $2,000 oder mehr erfordern – doch die Speicherbandbreite von 215 GB/s sowie der Unterschied zwischen MoE- und dichten Modellen bestimmen, ob man 2 Tokens pro Sekunde oder nur 30 Tokens pro Sekunde erhält. Auf dieser Seite erfahren Sie genau, welche Modelle geeignet sind und was Sie erwarten können.

​
Kurzfazit: MoE-Modelle sind überlegen

MoE-Modelle (Mixture-of-Experts) sind auf Strix Halo 3 bis 14 Mal schneller als dichte Modelle mit gleicher Gesamtparameteranzahl. Der Grund liegt in der Bandbreite: Bei MoE-Modellen werden pro Token lediglich die aktiven Parameter aus dem Speicher gelesen; daher erzeugt ein 122B großes MoE-Modell mit 10B aktiven Parametern Tokens nahezu in der Geschwindigkeit eines 10B großen dichten Modells – nicht jedoch in der Geschwindigkeit eines 122B großen Modells. Wenn Sie ein Modell für den täglichen Gebrauch auswählen, empfiehlt es sich, ein MoE-Modell aus dem Bereich 35B bis 122B zu nutzen.

​
128GB unified memory explained

Strix Halo verfügt über keinen separaten VRAM. Die iGPU bezieht sich auf denselben DDR5-Speicherpool wie die CPU. Standardmäßig reservieren BIOS und Betriebssystem einen Teil der Gesamtmenge von 128 GB:

​
Speicherkonfiguration in der BIOS-Einstellung unter Linux

Unter Linux übernimmt das Kernel die Aufteilung automatisch. Nach dem Start stehen in der Regel 95–110 GB für GPU-Aufgaben zur Verfügung. Meist ist keine manuelle Änderung der BIOS-Einstellungen erforderlich.

​
Speicherkonfiguration unter Windows

Unter Windows müssen Sie 2 Einstellungen vornehmen:
  1. BIOS → UMA Frame Buffer – wählen Sie die größtmögliche verfügbare Option aus (meist „Auto“ oder ein fester Wert).
  2. AMD Adrenalin → VRAM allocation – Öffnen Sie AMD Software: Adrenalin Edition, navigieren Sie zu Settings → Graphics → Advanced und verschieben Sie den VRAM-Schieberegler auf 96 GB.
Ohne die VRAM-Zuweisung über Adrenalin unter Windows erkennt Ihre iGPU möglicherweise nur 15.5 GB – was für große Modelle bei weitem nicht ausreicht. Stellen Sie sowohl das BIOS als auch den Schieberegler in Adrenalin ein, bevor Sie ein Modell mit mehr als 30B Parametern laden.

​
Kompatibilität mit dichten Modellen

Dichte Modelle aktivieren bei jedem Token alle Parameter; daher muss bei jedem Schritt der gesamte Gewichtstensor aus dem Speicher gelesen werden. Bei einer Geschwindigkeit von 215 GB/s ergibt sich somit eine harte Obergrenze für die Token-Geschwindigkeit.
Qwen3-Coder-30B in der Variante Q4_K_M ist das bevorzugte dichte Modell der Community für Codier-Agenten (Cline, Aider, OpenCode) auf Strix Halo. Es lässt sich problemlos nutzen und erreicht eine Geschwindigkeit von 10 bis 15 Tokens pro Sekunde.

​
Kompatibilität mit MoE-Modellen

MoE-Modelle weisen zwar eine hohe Gesamtanzahl an Parametern auf, aktivieren jedoch pro Token nur einen kleinen Teil davon. Dadurch wird der Speicherdurchsatz pro Schritt deutlich reduziert, was zu einer wesentlich schnelleren Generierung führt. MoE-Modelle mit 3 bis 12B aktiven Parametern stellen die ideale Wahl dar. Sie liefern Spitzenqualität bei einer Geschwindigkeit, die in Chats oder beim Programmieren reaktionsschnell wirkt.
GLM-4.6 (insgesamt 357B Parameter / 32B aktiv) passt nicht auf Strix Halo. Bei einer Quantisierung von Q4_K_M benötigt das Modell ca. 178 GB – deutlich mehr als der verfügbare 128-GB-Speicherpool, selbst bei Einsatz von RDMA-Cluster mit 2 Knoten (Gesamtspeicher: 256 GB). Für Strix Halo sollte stattdessen GLM-4.5-Air genutzt werden. Die vollständige Übersicht der Varianten finden Sie unter GLM-Familie.

​
Kimi K3 auf Strix Halo

Kimi K3 does not fit Strix Halo. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Strix Halo’s full 128 GB pool — roughly 90–110 GB after OS overhead — is about 1.27 TB short of the raw weight floor. Moonshot recommends serving K3 on a supernode with 64 or more accelerators. For the full memory calculation, see the Kimi K3 hardware deep dive. Für Strix Halo stehen die geeigneten Modelle in den obigen Tabellen zur Verfügung; sie umfassen bis zu ~122B MoE bei Q4 auf einem einzelnen Knoten. Unter was anstelle von Kimi K3 ausgeführt werden sollte finden Sie die optimale Wahl für einen Speicherbedarf von 128 GB.

​
Qwen3.8 auf Strix Halo

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit Strix Halo — see below.

​
Speicherbedarf pro Quantisierungsstufe bei rein gewichtsbasierter Speicherung

Even at the most aggressive quantization, Strix Halo cannot run Qwen3.8-2.4T-A95B. This is a multi-node cluster model that requires at least 5 DGX Sparks (or equivalent) at Q2 — and realistically 10+ nodes at Q4 for reasonable KV cache headroom. For full cluster sizing, see the Qwen3.8 model page.
Bei MoE-Modellen werden alle Expertengewichte in den Arbeitsspeicher geladen, obwohl pro Token nur ein Teil davon aktiv wird. Qwen3.8-2.4T-A95B aktiviert 95B von insgesamt 2.4T Experten, doch die Speicheranforderung von 1.2 Terabyte bei Q4 stellt eine harte Untergrenze dar. Der Vorteil von MoE liegt in der Rechenleistung – weniger FLOPs pro Token – nicht im Speicherbedarf.

​
Das Qwen3.8-Modell, das zu Strix Halo passt

Qwen3.8-27B ist das Einzelrechner-Modell dieser Generation: ein dichtes 27B Vision-Language-Modell, das am 2026-08-14 unter der Apache-2.0-Lizenz veröffentlicht wurde. Die offizielle 30.9-GB-FP8-Version benötigt lediglich 96 GB GPU-Speicher – sogar die 55.6-GB-BF16-Version passt noch dazu. Dennoch stellt die Q4_K_M-GB-GGUF-Version (~17 GB, noch nicht veröffentlicht) die praktikable Wahl für llama.cpp/Vulkan auf dieser Hardware dar. Alle Details zu Speicheranforderungen finden Sie auf der Qwen3.8-Modellseite; getestete Konfigurationen werden nach Überprüfung dort ergänzt.

​
Vergleich zwischen ROCm- und Vulkan-Backends

Die Radeon 8060S iGPU (gfx1151) von Strix Halo kann Inferenzen über verschiedene 2-Backends ausführen. Jedes dieser Backends weist dabei eigene Vor- und Nachteile auf. Nutzen Sie Vulkan, es sei denn, Sie haben einen konkreten Grund für die Verwendung von ROCm – etwa die BF16-Genauigkeit bei der Feinabstimmungsauswertung.
Weitere Laufzeitoptionen, darunter llama.cpp mit Vulkan sowie Ollama, finden Sie unter vLLM und Alternativen auf Strix Halo.

​
Bandbreitenbeschränkungen

Der DDR5-Speicher von Strix Halo bietet eine theoretische Bandbreite von 215 GB/s. Diese Zahl ist entscheidend, um die Leistungsfähigkeit zu beurteilen:
  • Token generation is memory-bandwidth-bound. Each token requires reading the model’s active weights from memory.
  • Ein 70B-Modell mit Q4-Quantisierung (~40 GB Umfang) benötigt 40 GB ÷ 215 GB/s ≈ 186m Sekunden pro Token – das entspricht etwa 5 Tokens pro Sekunde.
  • Ein 122B-MoE-Modell mit 10B aktiven Komponenten bei Q4 (~7 GB aktiver Gewichte) benötigt 7 GB ÷ 215 GB/s ≈ 33m Sekunden pro Token – das ergibt etwa 30 Tokens pro Sekunde.
Die Verarbeitung von Prompts (Prefill) ist rechenlastig und verläuft schneller als die Token-Generierung. Lange Prompts werden rasch verarbeitet, danach pendelt die Geschwindigkeit sich auf den bandbreitenbegrenzten Wert ein.

​
Erwartete Leistung je nach Anwendungsfall

​
Experimentelle Clustering-Funktion für 2 Knoten mittels RDMA

2 Strix Halo nodes can provide 256 GB of aggregate unified memory through llama.cpp RPC, but this is a proof-of-concept path, not a production configuration.
llama.cpp bezeichnet RPC als instabil, unsicher sowie lediglich konzeptuell verwertbar. Setzen Sie einen RPC-Worker niemals in ein ungeschütztes Netzwerk ein, noch verlassen Sie sich auf ihn als produktiven Endpunkt. Netzwerkeinrichtung, Modellunterstützung, Kontextkapazität sowie Leistung müssen lokal überprüft werden.
Verfolgen Sie diesen Weg nur bei kontrollierten Experimenten, falls ein einzelner Knoten das Modell nicht aufnehmen kann. Im Artikel DeepSeek V4 Flash lokale Hardware wird erläutert, weshalb das verlustfreie GGUF-Format in den Gesamtspeicher passt – dennoch handelt es sich um eine experimentelle Strix Halo Deployment-Variante.

​
Überprüfen Sie Ihren Speicherverbrauch

Vor dem Laden eines Modells sollten Sie prüfen, wie viel GPU-Speicher verfügbar ist:
Subtract OS overhead (~4GB) and leave 2–4GB for KV cache at your target context length. A 70GB model in Q4 leaves roughly 20GB for KV cache on a 96GB allocation — enough for 8K–16K context on most models.

​
Nächste Schritte

Anwendungsfall für Strix Halo

Richten Sie den Tokios-Connector auf Ihrem Strix Halo-Gerät ein, um eine Fernzugriffsmöglichkeit zu gewährleisten.

vLLM sowie weitere Alternativen auf Strix Halo

Laufzeitoptionen wie llama.cpp Vulkan und Ollama

Leitfaden zur Quantisierung

Erfahren Sie mehr über die verschiedenen GGUF-Quantisierungsstufen sowie deren Auswirkungen auf die Qualität.