FastFlowLM est passé en version 1.0 le 11 août 2026, et il l'a fait depuis une nouvelle adresse : l'organisation ROCm sur GitHub, et non plus une page de projet indépendante. Ce déménagement est la vraie nouvelle. FastFlowLM exécute des modèles de langage directement sur l'unité de traitement neuronal XDNA2 des portables Ryzen AI, sans GPU dédié, depuis une installation de 17 Mo qui se comporte comme les exécuteurs de modèles locaux que vous utilisez déjà. Jusqu'ici, l'histoire NPU d'AMD sous Linux était une collection d'efforts séparés. Placer celui-ci sous le parapluie ROCm en fait quelque chose sur quoi on peut raisonnablement bâtir.
The short answer
FastFlowLM 1.0 est la première version générale publiée sous l organisation ROCm d AMD sur GitHub, avec tout son historique de tickets et de demandes de fusion. Il exécute des modèles de langage, de vision, d audio, d embarquement et de type MoE sur les NPU XDNA2 Ryzen AI sans GPU dédié, expose un serveur local sur le port 52625, et ajoute la prise en charge du modèle vision langage action SmolVLA.
La plupart des portables vendus avec un logo Ryzen AI depuis deux ans contiennent un morceau de silicium que leur propriétaire n'a jamais utilisé volontairement. Le NPU est là, affiche une ligne plate dans le gestionnaire de tâches, et se fait parfois emprunter par une visioconférence pour flouter l'arrière-plan. FastFlowLM existe pour changer cela, et depuis le 11 août 2026 il le fait avec le nom d'AMD sur la porte.
La version 1.0 est décrite par le projet comme la première publication générale sous l'organisation ROCm, et la migration a emporté tickets, demandes de fusion et historique. Ce détail fait la différence entre un changement d'étiquette et une adoption. Ce qui était un moteur indépendant pour un accélérateur de niche fait désormais partie du même parapluie logiciel que le reste de la pile de calcul d'AMD.
De quoi il s'agit exactement
FastFlowLM, ou flm en ligne de commande, exécute des modèles sur les NPU Ryzen AI d'AMD. Pas sur le GPU intégré, pas sur le processeur avec assistance du NPU : sur le NPU. Le projet se décrit comme NPU d'abord et compare sa forme aux exécuteurs de modèles locaux que la plupart des développeurs ont déjà installés, ce qui décrit fidèlement son comportement.
Le périmètre a dépassé le texte. Le moteur couvre désormais les modèles de vision, d'audio, d'embarquement et de type mélange d'experts, et la 1.0 ajoute SmolVLA, un modèle vision langage action conçu pour la robotique. Les longueurs de contexte montent à 256k jetons. L'ensemble pèse 17 Mo installés et le projet revendique une installation en vingt secondes.
Le matériel pris en charge est plus étroit que la catégorie commerciale. Ce sont toutes les puces de la série Ryzen AI dotées d'un NPU XDNA2, que le projet nomme Strix, Strix Halo, Kraken et Gorgon Point. Il existe aussi un plancher de pilote à la version 32.0.203.304, avec la .311 recommandée, et ce plancher mérite d'être vérifié avant de conclure quoi que ce soit sur la compatibilité.
Ce qui compte vraiment pour votre machine
L'argument intéressant en faveur d'un NPU n'est pas la vitesse brute. C'est que l'inférence cesse d'entrer en concurrence avec tout ce que vous faites par ailleurs.
Un modèle qui tourne sur votre GPU dédié prend de la mémoire vidéo et des créneaux d'ordonnancement au compositeur, au navigateur et à tout ce qui a un chemin de rendu. Un modèle qui tourne sur le processeur prend des cœurs à votre compilation. Un modèle qui tourne sur le NPU prend une ressource qui, sur presque tous les portables, reste sinon inactive. Le projet revendique une efficacité énergétique plus de dix fois meilleure que les alternatives, ce qui, sur une machine sur batterie, fait la différence entre un assistant local qu'on laisse tourner et un qu'on démarre à dessein.
C'est l'argument pour installer durablement un petit modèle sur le NPU : complétion, classification, résumé, embarquement pour un index de recherche local. Les tâches où l'on veut une réponse en quelques centaines de millisecondes, disponible sans avoir à se demander ce qui tourne à côté.
L'intégrer à l'existant
La surface d'intégration est un serveur HTTP local. flm serve le démarre sur le port 52625 par défaut, éventuellement avec une étiquette de modèle à précharger. Si une requête arrive en nommant un autre modèle, le moteur bascule au lieu de renvoyer une erreur, ce qui supprime toute une catégorie d'orchestration que vous auriez sinon à écrire.
Pour le travail interactif, flm run llama3.2:1b ouvre une session dans le terminal. À l'intérieur, /verbose bascule le rapport de performance pour voir les jetons par seconde sans quitter la conversation, et /bye sort. flm list montre ce qui est disponible localement.
Le stockage des modèles diffère selon la plateforme, ce qui compte si vous gardez vos poids sur un volume séparé. Sous Linux, le défaut est ~/.config/flm, redéfinissable avec la variable d'environnement FLM_MODEL_PATH. Sous Windows, c'est sous Documents, ou là où vous avez pointé l'installeur. Les noyaux de modèles sont récupérés depuis Hugging Face au premier usage, donc la première exécution d'un modèle nécessite un accès réseau, et le projet documente flm pull <étiquette> --force pour le cas où un téléchargement arrive corrompu.
Pourquoi le passage sous ROCm est l'information
Le problème logiciel d'AMD n'a jamais été le manque de projets. C'est qu'un développeur cherchant à viser du matériel AMD devait deviner lequel de plusieurs efforts qui se chevauchent avait un avenir.
Rattacher FastFlowLM à ROCm répond à cette question pour le NPU précisément. Cela place l'inférence NPU dans la même organisation que la pile de calcul GPU, sous la même licence MIT que porte la publication, avec l'historique intact pour que tickets et discussions existants ne s'évaporent pas. Pour qui hésite à bâtir sur le NPU Ryzen AI sous Linux, le calcul de risque n'est plus le même qu'il y a une semaine.
Cela s'inscrit aussi dans une tendance que nous suivons. AMD absorbe régulièrement de l'outillage dans ROCm plutôt que de le laisser éparpillé, comme avec Spur, son ordonnanceur de tâches en Rust qui parle Slurm. Et la demande plaide exactement pour cette classe d'outils : Muse Glimmer de Meta a livré un modèle agentique de 30 milliards de paramètres visant un seul GPU, et les modèles plus petits que vise FastFlowLM sont ceux qui tiennent confortablement sur un NPU.
Sources et pour aller plus loin
- FastFlowLM 1.0 Released Now As Part Of The AMD ROCm Umbrella, Phoronix, 11 août 2026
- Notes de version FastFlowLM v1.0.0, GitHub
- Dépôt FastFlowLM sous l'organisation ROCm
- Documentation FastFlowLM
- Guide de démarrage Linux de FastFlowLM
Questions fréquentes
Qu'apporte l'exécution d'un modèle sur NPU par rapport au processeur ou au GPU ?
L'énergie, surtout, et la liberté de continuer à travailler pendant l'exécution. Un NPU est un moteur matriciel à fonction fixe, logé sur le même boîtier que le processeur, conçu pour de l'inférence soutenue à faible consommation plutôt que pour du débit de pointe. Le projet revendique une efficacité énergétique plus de dix fois meilleure que les alternatives sur le même portable. Le second bénéfice est moins discuté et compte souvent davantage au quotidien : le NPU est une ressource que presque rien d'autre ne se dispute sur votre machine. Y faire tourner un modèle ne prive pas votre GPU du compositeur, du navigateur ou d'un jeu, et ne sature pas les cœurs que votre compilation utilise.
Quel matériel fonctionne réellement ?
Toutes les puces de la série Ryzen AI dotées d'un NPU XDNA2, que le projet liste comme Strix, Strix Halo, Kraken et Gorgon Point. Tout ce qui est plus ancien, y compris les puces XDNA de première génération, est hors périmètre. Il existe aussi un plancher de pilote qui piège du monde : le projet exige la version de pilote NPU 32.0.203.304 ou plus récente et recommande la .311. Sous Windows, cela se vérifie dans le Gestionnaire des tâches, onglet Performances, ou dans le Gestionnaire de périphériques. Si le moteur se comporte étrangement sur du matériel compatible sur le papier, la version du pilote est la première chose à écarter, pas la dernière.
Est-ce un logiciel Linux ou un logiciel Windows ?
Les deux, avec Windows comme chemin actuellement le plus lisse. La version 1.0 livre des binaires précompilés pour Ubuntu, Debian, Linux x86_64 générique et Windows, et un guide de démarrage Linux dédié figure dans le dépôt. Le côté Windows dispose d'un installeur empaqueté et concentre l'essentiel de la documentation et des démonstrations. Sous Linux, les modèles atterrissent par défaut dans ~/.config/flm et cela se redirige avec la variable d'environnement FLM_MODEL_PATH, détail utile si vous rangez vos poids sur un volume séparé.
Comment l'intégrer à quelque chose que j'ai déjà construit ?
Par un serveur HTTP local sur le port 52625. `flm serve` le démarre, et si une requête nomme un modèle qui n'est pas chargé, le moteur bascule dessus au lieu d'échouer. Ce fonctionnement paraîtra familier à qui a déjà branché quelque chose sur un exécuteur de modèles local, et cela veut dire qu'un client existant pointé vers un autre port se règle en général en une ligne. Pour l'usage interactif, `flm run <modèle>` ouvre une session terminal, `/verbose` bascule le rapport de performance pendant la session, et `flm list` montre ce qui est disponible localement.
Qu'y a-t-il de nouveau dans la 1.0 au-delà du changement d'organisation ?
Trois choses à retenir. La prise en charge de SmolVLA, un modèle vision langage action destiné à la robotique, qui étend le moteur au-delà du texte et de l'image vers des modèles qui émettent des actions. Un `flm bench` retravaillé, qui exécute désormais deux itérations à chaque longueur de contexte de 1k à 32k par défaut, avec une option pour en demander davantage, ce qui rend sa sortie réellement comparable entre machines. Et un correctif sur la gestion multi-images de Qwen3-VL. La publication a aussi transféré chaque ticket, chaque demande de fusion et tout l'historique vers l'organisation ROCm, ce qui compte plus qu'il n'y paraît : un déménagement qui perd son historique est un redémarrage, et celui-ci n'en est pas un.