Zum Hauptinhalt springen
Hardware, die nicht empfohlen wird. Tokios empfiehlt AMD Strix Halo (Ryzen AI Max+ 395) nicht als primite Plattform für Inferenzaufgaben. Diese Hardware wurde bislang nur von der Community erprobt; sie ist noch nicht für den produktiven Einsatz geeignet, und die Unterstützung durch Treiber sowie ROCm ist unzuverlässig. Für zuverlässige Inferenzergebnisse 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 wissen möchten, welche Lösungen funktionieren.

Kurz gesagt: vLLM arbeitet auf Strix Halo nicht zuverlässig.

Die Kombination aus vLLM und PyTorch Flash Attention führt auf der Radeon 8060S (gfx1151)-GPU zu Abstürzen. Die von TheRock bereitgestellten PyTorch-Versionen für diese GPU sind mit den CUDA-basierten Code-Elementen von vLLM inkompatibel; außerdem führt der Workaround im Eager-Modus zu Problemen bei der Tool-Nutzung. Zahlreiche Community-Berichte bestätigen dies für verschiedene Kernel- sowie ROCm-Versionen. Stattdessen können Sie eine der folgenden Alternativen nutzen:

Gründe, warum vLLM scheitert

Die iGPU von Strix Halo ist gfx1151 (RDNA 3.5). vLLM wurde ursprünglich für NVIDIA CUDA-GPUs entwickelt und erhielt später ROCm-Unterstützung für Rechenzentrums-GPUs von AMD (MI250, MI300X). Die Consumer-iGPU in Strix Halo fällt jedoch außerhalb dieses unterstützten Spektrums. Die Abfolge der Fehler:
  1. PyTorch TheRock-Builds – AMD stellt TheRock-Builds für gfx1151 bereit, doch diese funktionieren nicht reibungslos mit vLLMs Flash Attention-Implementierung.
  2. Flash Attention in Kombination mit vLLM verursacht GPU-Abstürze – sobald Flash Attention bei gfx1151 aktiviert wird, reagiert die GPU nicht mehr; ein Neustart ist zwingend erforderlich.
  3. Abhilfe durch Eager-Modus – die Deaktivierung von Flash Attention verhindert Abstürze, mindert jedoch die Leistung stark und macht Tool-Aufrufe völlig unmöglich.
  4. Tool-Aufrufe scheitern bei AMD – selbst im Eager-Modus kann vLLMs Parser für Tool-Aufrufe unter AMD ROCm keine Befehle ausführen; somit ist die Nutzung als Coding-Agent ausgeschlossen.

Empfohlene Alternative: llama.cpp mit Vulkan-Unterstützung

llama.cpp compiled with the Vulkan backend is the most reliable and fastest option on Strix Halo. Vulkan delivers 21% faster token generation than ROCm on this hardware and works on both Linux and Windows.

Voraussetzungen

  • Ein System mit Strix Halo sowie 128 GB gemeinsam genutztem Arbeitsspeicher
  • Installierte Vulkan-Treiber (unter Linux Teil von Mesa, unter Windows Teil von Adrenalin)
  • cmake, gcc/clang sowie git

Kompilieren Sie llama.cpp mit Vulkan-Unterstützung

Unter Windows funktionieren dieselben Befehle in der PowerShell – vorausgesetzt, das Visual Studio- oder MinGW-Toolset ist installiert.

Starten Sie den Server

Das Argument -ngl 999 überträgt alle Rechenschichten auf die GPU. Prüfen Sie, ob der Server reagiert:
Unter Windows müssen Sie vor dem Start den AMD Adrenalin VRAM-Schieberegler auf 96 GB einstellen. Ohne diese Einstellung erkennt die iGPU lediglich ~15.5 GB Speicher; große Modelle lassen sich dann nicht laden. Die vollständige Anleitung zur Speicherzuweisung finden Sie unter Strix Halo Modellkompatibilität.

Alternative: Ollama (auf 0.17.7 fixieren)

Ollama is the easiest path if you want ollama run simplicity. You must pin version 0.17.7 — all 0.18.x versions have a GPU detection regression on Strix Halo that causes Ollama to fall back to CPU-only inference.

Installieren und fixieren Sie Ollama in der Version 0.17.7

Laden Sie ein Modell aus

Do not run ollama update or let a package manager upgrade Ollama past 0.17.7. The 0.18.x GPU detection regression is unresolved. If you accidentally upgrade, reinstall 0.17.7 from the GitHub releases page.

Workaround: vLLM im Eager-Modus (nur teilweise nutzbar, nicht empfohlen)

Falls Sie aus bestimmten Gründen exakt die API-Struktur von vLLM benötigen, können Sie den Eager-Modus nutzen. Rechnen Sie jedoch mit reduziertem Durchsatz sowie fehlerhafter Tool-Nutzung.
Bekannte Einschränkungen:
  • Keine Flash Attention-Unterstützung – die Durchsatzrate ist deutlich geringer als bei funktionierenden Deployment-Konfigurationen
  • Werkzeugaufrufe funktionieren nicht – der Parser für strukturierte Ausgaben scheitert bei AMD-Hardware
  • Begrenzte Kontextlänge – ohne Paged Attention entsteht schnell ein hoher Speicherdruck
  • GPU-Abstürze bleiben möglich – auch bei langen Kontexten können Abstürze auftreten

Zusammenfassung des Backend-Vergleichs

Stellen Sie Ihr Modell über Tokios bereit

Sobald Sie eine funktionierende Laufzeitumgebung (llama.cpp oder Ollama) eingerichtet haben, starten Sie den Tokios-Connector daneben. Der Connector verbindet sich mit https://api.tokios.com – ohne dass dazu eingehende Ports auf Ihrem System erforderlich sind – und stellt Ihnen schließlich einen authentifizierten Endpunkt zur Verfügung.
Auf der Anleitung zur Konfiguration von Strix Halo finden Sie eine vollständige Beschreibung zur Verknüpfung des Connectors.

Falls Sie heute Hardware erwerben möchten

Die 128 GB umfassende gemeinsame Speichereinheit von Strix Halo klingt zwar verlockend, doch das zugehörige Software-Ökosystem ist noch instabil. Für eine zuverlässige lokale Ausführung von LLMs gilt Folgendes: Jede dieser Optionen gewährleistet ein flüssigeres Erlebnis als Strix Halo – bei gleichem oder geringerem Aufwand.

Weitere Schritte

Kompatibilität der Strix Halo-Modelle

Welche Modelle passen in 128 GB Speicher und bei welcher Quantisierung?

Anwendungsfälle für Strix Halo

Ausführliche Anleitung zur Paarung des Connectors mit Strix Halo.

Anwendungsfälle für DGX Spark

Die empfohlene Alternative mit 128 GB gemeinsamem Speicher.

Fernzugriff auf vLLM

Sichere Bereitstellung von vLLM auf kompatibler NVIDIA-Hardware.