Lokale KI unter Linux: Ollama und ROCm auf AMD Strix Halo einrichten

Mit dem BOSGAME M5 hatten wir Anfang August eine kompakte Linux-Workstation mit AMD Ryzen AI MAX+ 395, Radeon 8060S und 128 GB LPDDR5X im Test. Statt des vorinstallierten Windows 11 Pro kam bei uns Debian 13 zum Einsatz. Darauf haben wir verschiedene Sprachmodelle mit Ollama und GPU-Beschleunigung über AMD ROCm getestet. In den Kommentaren kam anschließend die Frage auf, wie eine solche lokale KI-Umgebung eingerichtet wird. Genau das reichen wir mit diesem HowTo nach. Wir bleiben dabei bewusst bei Linux und orientieren uns an der Konfiguration, die wir für den Test des BOSGAME M5 verwendet haben. Dabei zeigte sich auch, dass lokale KI unter Linux keineswegs mit jedem Workload gleich gut funktioniert. Sprachmodelle liefen mit Ollama auf Strix Halo überzeugend. Bei anderen Anwendungen und insbesondere der Videogenerierung stießen wir dagegen auf deutlich größere Hürden.

Warum lokale KI überhaupt interessant ist

Cloud-Dienste wie ChatGPT, Claude oder Gemini bieten einen unkomplizierten Zugang zu leistungsfähigen Sprachmodellen. Die Verarbeitung findet dabei allerdings auf der Infrastruktur des jeweiligen Anbieters statt. Bei einer lokalen Installation liegen sowohl das Modell als auch die Rechenarbeit auf dem eigenen System. Prompts, Quellcode, Dokumente oder andere Informationen müssen für die eigentliche Inferenz deshalb nicht an einen externen LLM-Anbieter übertragen werden. Gerade bei vertraulichen Daten kann das interessant sein. Gleichzeitig entscheidet der Betreiber selbst über Modell, Software und Netzwerkzugriff. Dafür muss er sich allerdings auch selbst um Betriebssystem, Treiber, Modelle und Updates kümmern. Lokal bedeutet zudem nicht automatisch offline. Werden später externe APIs, Suchmaschinen oder andere Cloud-Dienste eingebunden, können weiterhin Daten das eigene Netzwerk verlassen. Entscheidend ist deshalb immer der gesamte Datenfluss.

Debian 13 als Grundlage

Auf dem BOSGAME M5 haben wir Windows 11 Pro durch Debian 13 ersetzt. Prozessor, NVMe-SSD, Netzwerk und Radeon-Grafik wurden direkt erkannt. Für den gewöhnlichen Linux-Betrieb war deshalb keine umfangreiche Nacharbeit notwendig.

Vor der Einrichtung von ROCm sollte Debian zunächst aktualisiert werden:

sudo apt update
sudo apt full-upgrade
sudo reboot

Nach dem Neustart lässt sich überprüfen, ob die Grafikhardware erkannt wird:

lspci | grep -Ei "VGA|Display"

Für die Berechnung der Sprachmodelle benötigen wir anschließend AMD ROCm.

ROCm ermöglicht den Zugriff auf die Radeon 8060S

ROCm ist AMDs Compute-Plattform und stellt die notwendigen Komponenten bereit, damit Anwendungen die Radeon-GPU für entsprechende Berechnungen verwenden können. Die konkreten Installationsschritte hängen von der verwendeten ROCm- und Linux-Version ab. Gerade bei einer jungen Architektur wie Strix Halo empfiehlt es sich deshalb, die jeweils aktuelle AMD-Dokumentation zu verwenden.

Nach der Installation lässt sich die Erkennung mit:

rocminfo

kontrollieren.

Auf unserem BOSGAME M5 wurde die Radeon 8060S als gfx1151 erkannt. ROCm meldete außerdem die erwarteten 40 Compute Units und einen maximalen GPU-Takt von 2.900 MHz.

Zugriffsrechte verhinderten zunächst den GPU-Zugriff

ROCm erkannte die Hardware korrekt, der verwendete Benutzer hatte zunächst aber nicht die erforderlichen Zugriffsrechte auf die Render-Geräte. Wir haben ihn deshalb der Gruppe render hinzugefügt:

sudo usermod -aG render $USER

Abhängig von der Konfiguration kann zusätzlich die Gruppe video erforderlich sein:

sudo usermod -aG video $USER

Nach einer erneuten Anmeldung beziehungsweise einem Neustart lässt sich mit:

groups

kontrollieren, ob die Gruppenzugehörigkeit übernommen wurde. Die vorhandenen Render-Geräte zeigt:

ls -l /dev/dri/

Nach der Anpassung konnte Ollama bei uns zuverlässig auf die Radeon 8060S zugreifen.

Nicht jedes ROCm-Werkzeug arbeitete fehlerfrei

Die eigentliche Compute-Unterstützung funktionierte, bei den begleitenden Werkzeugen zeigte sich die junge Plattform allerdings noch. rocm-smi konnte zwar unter anderem Temperatur, Leistungsaufnahme und Auslastung anzeigen, einzelne Abfragen endeten bei uns jedoch mit Exception caught: map::at. Das hatte keinen Einfluss auf die GPU-Beschleunigung. Ein fehlerhaftes Monitoring-Werkzeug bedeutet deshalb nicht automatisch, dass ROCm insgesamt nicht funktioniert.

Ollama unter Linux installieren

Nachdem ROCm funktionierte, haben wir Ollama eingerichtet:

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

Die installierte Version lässt sich anschließend mit:

ollama --version

überprüfen. Unter Linux läuft Ollama normalerweise als Dienst:

systemctl status ollama

Ollama übernimmt das Herunterladen, Laden und Ausführen der Sprachmodelle und stellt zusätzlich eine API für andere Anwendungen bereit.

Modelle bewusst über die CLI getestet

Für einen ersten Test empfiehlt sich ein vergleichsweise kleines Modell. Qwen3 lässt sich beispielsweise mit:

ollama run qwen3:8b

starten.

Beim ersten Aufruf lädt Ollama die benötigten Modelldateien herunter. Danach kann direkt im Terminal mit dem Modell gearbeitet werden.

Installierte Modelle zeigt:

ollama list

Nicht mehr benötigte Modelle lassen sich beispielsweise mit:

ollama rm qwen3:8b

entfernen.

Für unseren BOSGAME-Test haben wir bewusst ausschließlich die Kommandozeile verwendet. Die Benchmarks wurden direkt über Ollama durchgeführt. Eine zusätzliche Weboberfläche war nicht Bestandteil des Testaufbaus.

Prüfen, ob Ollama wirklich die GPU nutzt

Eine erfolgreiche Textausgabe bedeutet noch nicht zwangsläufig, dass Ollama das Modell über die Radeon ausführt. Die Software kann Modelle auch über die CPU berechnen.

Während ein Modell geladen ist, hilft:

ollama ps

Der Befehl zeigt unter anderem, ob ein Modell auf der GPU oder teilweise über die CPU ausgeführt wird. Gerade bei unerwartet niedriger Leistung sollte deshalb zunächst kontrolliert werden, wo das Modell tatsächlich berechnet wird.

Open WebUI als optionale Oberfläche

Wer Ollama dauerhaft einsetzt, muss nicht ausschließlich im Terminal arbeiten. Mit Open WebUI steht beispielsweise eine browserbasierte Oberfläche zur Verfügung, die sich direkt mit einer vorhandenen Ollama-Instanz verbinden lässt. Ollama bleibt dabei das eigentliche Backend. Open WebUI setzt lediglich eine komfortablere Oberfläche davor und greift über die Ollama-API auf die Modelle zu. Läuft Open WebUI etwa in einem Docker-Container und Ollama direkt auf dem Linux-Host, kann die Verbindung über Port 11434 beziehungsweise host.docker.internal hergestellt werden. Gerade wenn der Rechner später als zentraler KI-Server im Netzwerk arbeitet, kann eine Weboberfläche komfortabler sein als die CLI.

Strix Halo profitiert vom großen gemeinsamen Speicher

Eine der interessantesten Eigenschaften des Ryzen AI MAX+ 395 ist seine Speicherarchitektur. CPU und Radeon 8060S greifen auf denselben LPDDR5X-Speicher zu. In unserem BOSGAME M5 sind davon 128 GB verbaut. Im UEFI konnten wir bis zu 96 GB für die Grafikeinheit reservieren.

Gerade bei lokalen Sprachmodellen ist das ein Vorteil gegenüber vielen klassischen Grafikkarten. Eine leistungsfähige Desktop-GPU kann erheblich mehr Rechenleistung bieten, verfügt aber häufig nur über 12, 16 oder 24 GB eigenen VRAM. Passt ein Modell dort nicht hinein, hilft die höhere Rohleistung nur bedingt. Strix Halo kann der Radeon dagegen einen deutlich größeren Speicherbereich zur Verfügung stellen. Gleichzeitig muss genügend Speicher für Betriebssystem und andere Anwendungen verbleiben.

30B-Modelle liefen mit mehr als 60 Tokens pro Sekunde

Für den ursprünglichen BOSGAME-Test haben wir mehrere Modelle unter möglichst vergleichbaren Bedingungen ausgeführt. Dabei verwendeten wir Temperatur 0, Seed 42 und maximal 512 Ausgabetokens. qwen3:30b-a3b erreichte 66,10 Tokens pro Sekunde. qwen3-coder:30b kam auf 63,84 Tokens pro Sekunde. Beide Modelle konnten damit ausgesprochen flüssig genutzt werden. Das kleinere qwen3:8b erreichte 39,05 Tokens pro Sekunde, qwen3:14b kam auf 23,32 Tokens pro Sekunde. Bei den größeren dichten Modellen lagen gemma3:27b bei 11,56 und qwen3:32b bei 10,64 Tokens pro Sekunde. Die Ergebnisse zeigen zugleich, warum die reine Parameterzahl wenig über die Geschwindigkeit aussagt. qwen3:30b-a3b arbeitet als Mixture-of-Experts-Modell und aktiviert pro Token nur einen Teil seiner Parameter.

DeepSeek-R1 70B scheiterte am Speicher

Nicht jedes Modell ließ sich auf unserem Aufbau starten. Bei DeepSeek-R1 mit 70 Milliarden Parametern war in der damaligen Konfiguration Schluss. ROCm konnte den benötigten GPU-Speicher nicht reservieren. Die insgesamt vorhandenen 128 GB LPDDR5X bedeuten also nicht, dass automatisch jedes Modell entsprechender Größe ausgeführt werden kann. Neben den Modellgewichten benötigen unter anderem Kontext, Cache, Zwischenergebnisse, ROCm und das Betriebssystem zusätzlichen Speicher. Auch Quantisierung und die im UEFI konfigurierte Speicheraufteilung spielen eine Rolle.

Videogenerierung zeigte die derzeitigen Grenzen von ROCm

Noch deutlicher wurden die Einschränkungen bei anderen KI-Workloads. Die guten Erfahrungen mit Ollama lassen sich nicht ohne Weiteres auf Bild- oder Videogenerierung übertragen. Wir haben auf dem BOSGAME M5 auch mit PyTorch und ComfyUI experimentiert. Dabei bereiteten Abhängigkeiten, unterstützte PyTorch-Versionen und die noch junge gfx1151-Architektur deutlich mehr Probleme. Eine funktionierende lokale Videogenerierung konnten wir unter Linux auf dem M5 letztlich nicht einrichten.

Das zeigt, dass nicht allein die Hardware entscheidend ist. Die Radeon 8060S besitzt ausreichend Rechenleistung und kann auf einen großen Speicherbereich zugreifen. Unterstützt der jeweilige Software-Stack die Architektur aber nicht sauber, lassen sich diese Ressourcen nicht ohne Weiteres nutzen.

CUDA bleibt bei einigen Workloads im Vorteil

Nvidia besitzt an dieser Stelle mit CUDA weiterhin einen praktischen Vorteil. Viele Projekte aus dem Bereich Bild- und Videogenerierung werden primär für CUDA entwickelt oder dort zumindest umfangreicher getestet. ROCm-Unterstützung ist bei zahlreichen Projekten vorhanden, kann bei neuer AMD-Hardware aber bestimmte Kombinationen aus ROCm, PyTorch und weiteren Abhängigkeiten voraussetzen. Für unseren Test war die Trennlinie deshalb relativ deutlich: Lokale Sprachmodelle mit Ollama funktionierten unter Linux gut, bei der Videogenerierung kamen wir dagegen nicht ans Ziel.

Datenschutz endet nicht beim lokalen Modell

Ist ein Modell einmal heruntergeladen, kann eine gewöhnliche Unterhaltung vollständig auf dem eigenen Linux-System verarbeitet werden. Der Prompt muss dabei nicht an OpenAI, Google, Anthropic oder einen anderen LLM-Anbieter übertragen werden. Bei internen Dokumenten, Quellcode oder Protokolldateien kann das ein wesentlicher Vorteil sein. Eine lokale Installation ist allerdings kein automatischer Garant für Datenschutz. Entscheidend bleibt, welche Anwendungen zusätzlich auf Ollama zugreifen, ob Gesprächsverläufe gespeichert werden, welche Benutzer Zugriff haben und wo mögliche Backups liegen. Wer sensible Daten verarbeitet, sollte deshalb immer den gesamten Workflow betrachten.

Externe Dienste können Daten trotzdem nach außen senden

Besonders relevant wird das, sobald Ollama um weitere Komponenten ergänzt wird. RAG-Systeme, Agenten oder Weboberflächen können ihrerseits externe Dienste verwenden. Ein lokal ausgeführtes Sprachmodell kann beispielsweise eine externe Such-API ansprechen. Die eigentliche Inferenz findet dann weiterhin auf dem BOSGAME M5 statt, Teile der Anfrage können das eigene Netzwerk trotzdem verlassen. Das gleiche gilt für Cloud-basierte Embedding-Dienste oder andere APIs. Wer lokale KI gerade aus Datenschutzgründen einsetzt, sollte bei jeder Erweiterung prüfen, welche Daten wohin übertragen werden.

Die Ollama-API gehört nicht offen ins Internet

Über seine API kann Ollama auch anderen Geräten im Netzwerk zur Verfügung gestellt werden. Der BOSGAME M5 lässt sich dadurch als zentraler KI-Rechner verwenden, während die Bedienung über Notebook oder Desktop erfolgt. Die Ollama-Schnittstelle sollte aber nicht einfach per Portfreigabe ins öffentliche Internet gestellt werden. Für externen Zugriff bietet sich stattdessen ein VPN wie WireGuard an. Tailscale kann ebenfalls eine unkompliziertere Alternative sein. Firewall-Regeln können zusätzlich einschränken, welche Geräte Ollama überhaupt erreichen dürfen.

Agenten erweitern auch das Sicherheitsrisiko

Auf Ollama lässt sich später deutlich mehr als ein einfacher Chat aufbauen. Unterstützte Modelle können Werkzeuge verwenden und damit beispielsweise Informationen aus einer lokalen Wissensdatenbank abrufen, Skripte starten oder mit anderen Diensten kommunizieren. Damit verändert sich allerdings auch das Sicherheitsmodell. Ein Agent mit Dateizugriff, Shell, Datenbankzugang oder anderen Werkzeugen kann tatsächlich Aktionen auf dem System ausführen. Solche Werkzeuge sollten deshalb nur die Rechte erhalten, die sie für ihre jeweilige Aufgabe benötigen. Ein Agent zur Analyse von Logdateien braucht beispielsweise keinen Schreibzugriff auf das gesamte Dateisystem. Auch Prompt Injection bleibt relevant. Verarbeitet ein Agent fremde Dokumente oder Inhalte aus dem Internet, können darin Anweisungen enthalten sein, die unerwünschte Werkzeugaufrufe provozieren. Lokale Ausführung schützt davor nicht.

Lokale KI verlangt Eigenverantwortung

Unser Aufbau mit Debian 13, ROCm und Ollama hat gezeigt, dass für eine leistungsfähige lokale KI kein klassischer GPU-Server notwendig ist. Die Kombination aus Radeon 8060S und großem gemeinsamem Speicher kann selbst Sprachmodelle mit mehreren Dutzend Milliarden Parametern sinnvoll ausführen. Gleichzeitig sollte man die Grenzen kennen. Während Ollama auf unserem BOSGAME M5 nach der Einrichtung zuverlässig funktionierte, ist das ROCm-Ökosystem bei anderen KI-Workloads noch nicht überall so unkompliziert. Unsere erfolglosen Versuche mit lokaler Videogenerierung unter Linux sind dafür ein gutes Beispiel.

Hinzu kommt die Administration. Betriebssystem, ROCm, Modelle, Zugriffsrechte, Netzwerk und Updates müssen selbst gepflegt werden. Dafür bleibt die technische Kontrolle beim Betreiber und es lässt sich wesentlich genauer bestimmen, welche Daten das eigene System verlassen dürfen. Für den Einstieg ist Ollama damit eine vergleichsweise überschaubare Basis. Wer später mehr Komfort benötigt, kann Open WebUI ergänzen. Wissensdatenbanken, RAG und Agenten lassen sich anschließend ebenfalls darauf aufbauen.