FastFlowLM: eine NPU-Runtime für Ryzen AI, die ohne GPU auskommt

Welches Problem FastFlowLM adressiert

Die NPU in einem Ryzen-AI-Prozessor ist ohne passende Laufzeitumgebung weitgehend ungenutztes Silizium. FastFlowLM setzt genau dort an: Das Projekt beschreibt sich selbst als die einzige Out-of-the-box-Runtime, die ausschließlich für Ryzen AI gebaut ist, und nennt als Zielhardware alle Ryzen-AI-Chips mit XDNA2-NPU, namentlich Strix, Strix Halo, Kraken und Gorgon Point. Der Anspruch ist nicht, möglichst viele Beschleuniger abzudecken, sondern einen einzigen. Die Zielgruppe sind Entwickler, die ein lokales Modell auf einem Laptop oder Mini-PC betreiben wollen, ohne eine diskrete GPU einzubauen und ohne sich mit Kernel-Tuning zu befassen. Das README formuliert das als 'No model rewrites, no tuning'. Wer bereits eine GPU im System hat und dort Inferenz betreibt, gewinnt durch FLM nichts. Wer dagegen ein Gerät mit NPU besitzt und die Recheneinheit bisher nicht ansteuern kann, bekommt hier einen fertigen Pfad.

Wie die Runtime aufgebaut ist

Sichtbar ist eine Zweiteilung. Der Orchestrierungscode und die CLI stehen unter der MIT-Lizenz, die Datei heißt LICENSE_RUNTIME.txt. Die eigentlichen NPU-beschleunigten Kernel liegen als Binärdateien vor und werden laut README beim ersten Start von HuggingFace nachgeladen. Das erklärt die kleine Installationsgröße von 17 MB für die Runtime und gleichzeitig die Abhängigkeit von einer Internetverbindung: Ohne HuggingFace-Zugriff lässt sich ein Modell nicht in Betrieb nehmen. Das README verweist für diesen Fall auf Issue 2 und den manuellen Download. Die Modelle landen unter Windows in C:\Users\<USER>\.flm\models\, unter Linux in ~/.config/flm/. Die Trennung von offenem Laufzeitcode und geschlossenen Kernels ist eine bewusste Entscheidung, die Lizenzfragen aufwirft, aber auch erklärt, warum das Projekt pro Modell neue Kernel nachliefern muss. Die Release-Historie passt dazu: v1.0.3 brachte Gewichte mit höherer Genauigkeit für Qwen3.5 und Qwen3.6-MoE, v1.0.4 ein Gemma4-12B-IT. Jede Modellfreigabe ist demnach ein Kernel-Update, nicht nur ein neuer Eintrag in einer Liste.

Installation und erste Befehle

Unter Windows liefert das Projekt ein MSI-Paket, verlinkt im README als flm-setup.msi. Nach der Installation öffnet man PowerShell und startet ein Modell im Terminal: flm run llama3.2:1b. Für den Serverbetrieb lautet der Befehl flm serve llama3.2:1b, wobei das Modell-Tag optional ist; der Server läuft standardmäßig auf Port 52625 und wechselt das Modell automatisch, wenn ein anderes angefordert wird. flm list zeigt die verfügbaren Modelle. Während einer Sitzung schaltet /verbose die Leistungsanzeige um, /bye beendet die Unterhaltung. Zwei Umgebungsvariablen sind dokumentiert: FLM_DISABLE_UPDATE_CHECK=1 unterdrückt die Versionsprüfung beim Start, und unter Linux verschiebt FLM_MODEL_PATH den Modellordner. Bei der Windows-Installation lässt sich ein anderes Basisverzeichnis wählen; wer C:\Users\<USER>\flm angibt, findet die Modelle anschließend unter C:\Users\<USER>\flm\models\. Voraussetzung ist ein NPU-Treiber ab Version 32.0.203.311, prüfbar über Task Manager, Performance, NPU. Das README weist zudem darauf hin, dass HuggingFace-Downloads beschädigt ankommen können und dann flm pull <model_tag> --force hilft.

Wo die Grenzen liegen

Die Bindung an eine Treiberversion ist die härteste Einschränkung. Das README erklärt frühere Treiberstände ausdrücklich für nicht mehr unterstützt, und die verlinkte AMD-Installationsdokumentation verlangt ein AMD-Konto. Wer keinen aktuellen Treiber bekommt, etwa auf einem verwalteten Firmengerät ohne Administratorrechte, hat keine Alternative innerhalb des Projekts. Dazu kommt die Hardwaregrenze: Ohne XDNA2-NPU gibt es keinen Ausweichpfad, das Projekt nennt keine CPU- oder GPU-Fallback-Option. Die Abhängigkeit von HuggingFace beim ersten Start ist ein weiterer Bruchpunkt, den das README selbst einräumt und nur mit manuellem Download beantwortet. Und die Kernel sind Binärdateien: Wer nachvollziehen will, was auf der NPU gerechnet wird, kann das anhand des Repositories nicht. Die Angaben zu Leistungsaufnahme und Geschwindigkeit stammen aus der Projektbeschreibung und den verlinkten Benchmarks, nicht aus einer unabhängigen Messung.

Abgrenzung zu llama.cpp und Ollama

llama.cpp und Ollama verfolgen den entgegengesetzten Ansatz: breite Hardwareabdeckung über CPU, CUDA, Metal, Vulkan und weitere Backends, mit einer gemeinsamen Modell- und Quantisierungsbasis. Deren Stärke ist Portabilität; dieselbe GGUF-Datei läuft auf vielen Geräten. FastFlowLM wählt den schmalen Weg. Es unterstützt genau eine NPU-Familie, dafür mit Kernel-Binärdateien, die auf diese Einheit zugeschnitten sind, und mit Modell-Tags wie llama3.2:1b statt frei wählbarer Gewichtsdateien. Wer ein Modell aus einer eigenen Feinabstimmung betreiben will, findet im README keinen Hinweis auf einen solchen Importweg; die Modellliste ist kuratiert. Umgekehrt bekommt man bei llama.cpp auf einem Ryzen-AI-Gerät ohne GPU keine NPU-Beschleunigung, weil die NPU dort kein Backend ist. Die Entscheidung ist also nicht Geschwindigkeit gegen Bequemlichkeit, sondern Portabilität gegen Hardwarebindung.

Lizenz und Wartungsaufwand

Der Laufzeitcode steht unter MIT, die NPU-Kernel sind laut README kostenlos nutzbar, auch kommerziell. Das README bittet um eine Nennung in der Form 'Powered by [FastFlowLM](https://github.com/ROCm/FastFlowLM)' im README, auf der Projektseite oder im Produkt. Ob diese Bitte rechtlich bindend ist, geht aus dem Text nicht hervor; sie ist als Bitte formuliert, nicht als Lizenzbedingung. Wer das klären muss, sollte die LICENSE_RUNTIME.txt und die Bedingungen der Kernel prüfen, statt sich auf die README-Formulierung zu verlassen. Beim Wartungsaufwand fällt auf, dass das Projekt im August 2026 in die ROCm-Organisation von AMD gewechselt ist und seither im Monatsrhythmus Releases mit neuen Modellen liefert. Diese Kadenz bedeutet für Betreiber, dass ein Upgrade nicht nur die Runtime betrifft, sondern auch die Kernel. Wer eine feste Modellversion produktiv einsetzt, sollte vor jedem flm pull prüfen, ob die neue Kernel-Version dieselben Modelle weiterhin abdeckt.

Für wen sich der Einsatz lohnt

Der praktische Nutzen hängt an einem einzigen Kriterium: Steht ein Ryzen-AI-System mit XDNA2-NPU zur Verfügung, und ist der Treiber aktuell genug? Ist beides erfüllt, ist der Einstieg kurz. MSI installieren, flm run llama3.2:1b, fertig. Wer den Servermodus braucht, bekommt mit flm serve auf Port 52625 eine lokale Schnittstelle, die laut README REST und die OpenAI-API abdeckt. Wer dagegen auf einem Gerät ohne NPU arbeitet oder die Treiberinstallation nicht kontrolliert, sollte bei llama.cpp oder Ollama bleiben. Ein Punkt, der sich aus dem Material nicht beantworten lässt: ob und wie eigene Modelle eingebunden werden können. Das README beschreibt nur den Bezug über Modell-Tags. Wer diesen Weg braucht, muss das vor der Entscheidung klären.

Redaktionelles Fazit

Wer einen Ryzen-AI-Chip mit XDNA2-NPU besitzt und Inferenz ohne GPU-Beteiligung sucht, findet in FastFlowLM einen schlanken Einstieg: eine MSI unter Windows, ein Modell-Tag, ein Befehl. Wer Intel, Qualcomm oder eine reine CPU-Umgebung einsetzt, ist hier falsch, denn das Projekt nennt als Zielhardware ausschließlich Ryzen AI mit XDNA2. Vor dem ersten produktiven Einsatz sollte man den NPU-Treiberstand prüfen; das README verlangt 32.0.203.311 oder höher und erklärt ältere Versionen für nicht mehr unterstützt.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. ROCm/FastFlowLM on GitHub