FastFlowLM : faire tourner un LLM sur le NPU Ryzen AI, sans GPU

Le problème : un NPU présent mais inutilisé

Les puces Ryzen AI embarquent un NPU XDNA2 qui reste largement inexploité par les outils d'inférence grand public. PyTorch, llama.cpp ou Ollama ciblent en priorité le CPU et le GPU ; sur un portable sans carte graphique dédiée, cela signifie des tokens par seconde modestes et une consommation qui grimpe dès que le CPU soutient la charge. FastFlowLM prend le problème par l'autre bout : le README annonce que le runtime tourne entièrement sur le NPU, sans charge GPU ni CPU. La cible est donc étroite et assumée : les machines équipées d'un NPU XDNA2, citées nommément (Strix, Strix Halo, Kraken, Gorgon Point). Un développeur sur desktop avec une RTX n'a aucune raison d'ouvrir ce dépôt. Un développeur qui déploie sur un parc de portables Ryzen AI, si.

Ce que le dépôt contient réellement

La séparation des composants est le point le plus intéressant du projet. Le README indique que le code d'orchestration et les outils en ligne de commande sont open source sous MIT (LICENSE_RUNTIME.txt), tandis que les noyaux binaires accélérés pour le NPU sont distribués gratuitement, y compris pour un usage commercial. Autrement dit : la partie que vous pouvez lire, modifier et recompiler est la couche d'orchestration ; la partie qui fait la performance reste un binaire. C'est un choix cohérent avec la nature du matériel (les compilateurs NPU et les micro-kernels sont difficiles à ouvrir), mais il faut en tirer les conséquences pratiques : vous ne pouvez pas auditer ce qui s'exécute sur le NPU, ni le recompiler pour une architecture non prévue. Le README demande en contrepartie une mention « Powered by FastFlowLM » dans le README, la page projet ou le produit. Ce n'est pas une clause de licence à proprement parler, c'est une requête formulée dans la documentation ; à vous de juger si vous l'inscrivez dans vos obligations internes.

Le trajet d'une requête, du tag au NPU

Le mécanisme visible tient en trois étapes. Vous nommez un modèle par un tag au format ollama (llama3.2:1b, par exemple). FastFlowLM résout ce tag vers des poids et des noyaux optimisés hébergés sur HuggingFace, puis les télécharge. Le runtime charge ensuite le tout sur le NPU XDNA2. Le README précise que les modèles sont stockés par défaut dans C:\Users\<USER>\.flm\models\ sous Windows et dans ~/.config/flm/ sous Linux, et que l'emplacement Linux se surcharge avec la variable d'environnement FLM_MODEL_PATH. Deux conséquences de ce flux : la première exécution dépend d'un accès réseau à HuggingFace, et les téléchargements peuvent être corrompus, cas pour lequel la documentation donne la commande de réparation flm pull <model_tag> --force. Le README mentionne aussi une vérification de version au démarrage, désactivable avec FLM_DISABLE_UPDATE_CHECK=1 : utile en environnement cloisonné, mais cela suppose de gérer les mises à jour soi-même. En mode serveur, flm serve expose une API locale sur le port 52625 par défaut, et le README indique qu'un changement de modèle demandé par le client déclenche un basculement automatique.

Mise en route : les commandes et les prérequis

Sous Windows, l'installation passe par le paquet MSI publié dans les releases (flm-setup.msi). Le prérequis matériel est explicite : un pilote NPU AMD en version 32.0.203.311 ou supérieure, vérifiable dans le Gestionnaire des tâches, onglet Performance, ou dans le Gestionnaire de périphériques. Le README signale que les versions antérieures ne sont plus prises en charge. C'est le point de friction le plus probable d'un premier essai : un pilote trop ancien et rien ne démarre. Une fois installé, deux usages : flm run llama3.2:1b pour une session interactive en terminal, flm serve llama3.2:1b pour le serveur local. Dans une session, /verbose active le rapport de performance et /bye quitte, tandis que flm list affiche les modèles disponibles. Sous Linux, le README renvoie à un guide dédié (docs/linux-getting-started.md) et à une intégration via Lemonade Server ; la page ne détaille pas la procédure d'installation Linux elle-même, donc prévoyez de lire ce guide avant de promettre quoi que ce soit à votre équipe. Le runtime est annoncé à 17 Mo, ce qui rend l'empreinte disque du binaire négligeable face à celle des poids.

Les angles morts de la documentation

Le README avance des chiffres de performance (plus de 10× plus économe en énergie, contexte jusqu'à 256k tokens) mais renvoie à une page de benchmarks externe ; rien dans le matériel fourni ne permet de reproduire ni de contextualiser ces mesures. Le lecteur doit donc traiter ces valeurs comme des affirmations du projet, pas comme des résultats vérifiés. Autre zone floue : la compatibilité. Le README cite les séries XDNA2, mais ne dit pas ce qui se passe sur un NPU XDNA de première génération, ni si un repli CPU existe. Il faut supposer que non, faute d'information. La gestion mémoire est également absente : la taille des poids par modèle, la RAM système nécessaire et le comportement quand un modèle dépasse la mémoire disponible ne sont pas documentés dans cet extrait. Enfin, le rythme des releases (v1.0.3, v1.0.4, v1.0.5 entre fin août et début septembre 2026, avec des changements de poids et de modèles) suggère une évolution rapide ; cela veut dire qu'une version figée dans le temps peut devenir incompatible avec les noyaux publiés ultérieurement. Ce n'est pas une critique en soi, mais c'est un coût de maintenance à intégrer.

Face à llama.cpp et Ollama, la différence est le backend

L'alternative la plus directe est llama.cpp, et derrière lui Ollama pour l'expérience CLI et serveur. La différence n'est pas l'interface, qui se ressemble beaucoup (tags de modèles, commande unique, serveur local), mais le backend de calcul. llama.cpp cible CPU et GPU via ses backends, avec une couverture matérielle large et un code entièrement ouvert, y compris les noyaux. FastFlowLM cible un seul type de silicium, le NPU XDNA2, avec des noyaux binaires fermés. Le compromis est clair : vous gagnez un chemin d'exécution spécifiquement optimisé pour ce NPU, vous perdez la portabilité et une partie de l'auditabilité. Un projet qui doit tourner sur des machines hétérogènes n'a pas intérêt à s'enfermer dans FLM ; un projet dont le parc est homogène en Ryzen AI peut y trouver un gain que llama.cpp n'offre pas, puisque ce dernier n'exploite pas le NPU. Rappelons aussi que FLM s'intègre à Lemonade Server, ce qui laisse la porte ouverte à une couche d'abstraction au-dessus du runtime.

Coût de maintenance et cadre de licence

Le coût réel ne se situe pas dans le binaire de 17 Mo, mais dans le suivi des versions. Les notes de release montrent des changements de poids et de modèles entre deux versions mineures, et le README impose un pilote NPU minimal qui évoluera avec les générations de puces. Toute mise à jour du pilote côté AMD, ou toute nouvelle release de FLM, demande une revalidation de votre côté. Sur la licence : le code d'orchestration est en MIT, ce qui autorise la modification et la redistribution ; les noyaux binaires sont annoncés comme gratuits, y compris en usage commercial, mais ils ne sont pas couverts par le fichier MIT puisqu'ils ne sont pas du code source. La demande d'attribution « Powered by FastFlowLM » n'est pas présentée comme une condition légale, et je ne suis pas en mesure de trancher ce point à partir du README seul. Si votre produit embarque FLM, faites relire la formulation par quelqu'un dont c'est le métier plutôt que de vous fier à cette page.

Conclusion éditoriale

FastFlowLM vise un public précis : développeurs sur portable ou mini-PC Ryzen AI qui veulent de l'inférence locale sans GPU discret, avec une CLI et une API REST. Ceux qui ont déjà une carte graphique, ou dont le matériel n'est pas un XDNA2, n'ont rien à y gagner. Avant d'adopter, vérifiez deux choses concrètes : la version du pilote NPU dans le Gestionnaire de périphériques (32.0.203.311 minimum selon le README) et la disponibilité des poids du modèle voulu sur HuggingFace depuis votre réseau, puisque le contournement documenté passe par un téléchargement manuel.

Sources officielles

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