AMD n’a pas intégré un benchmark
Dans sa courte annonce du 17 juillet, AMD indique que l’équipe FastFlowLM rejoint son groupe IA afin d’accélérer la pile logicielle de ses PC et stations de travail ainsi que la prise en charge des nouveaux modèles dès leur sortie. Le rapprochement ne crée pas le runtime : FastFlowLM était déjà construit avec IRON et son dépôt date son intégration à Lemonade du 1er octobre 2025. AMD internalise désormais une équipe dont le logiciel était déjà aligné avec ses deux projets. Aucun prix, aucune structure de transaction, aucun mot sur une acquisition ne sont publiés. Dire qu’AMD « rachète FastFlowLM » ajouterait donc un fait absent de l’annonce.
Le contraste explique l’opération. Un Ryzen AI 7 350 annonce jusqu’à 50 TOPS Tera Operations Per Second. Mille milliards d'opérations par seconde : métrique brute de débit d'un accélérateur, généralement annoncée en INT8 ou INT4. Elle ne dit rien du débit réel d'un modèle, qui dépend du compilateur et du repli éventuel sur CPU. Approfondir dans le glossaire sur son NPU. Ce nombre décrit un débit maximal d’opérations à basse précision dans un cas optimal. Il ne dit pas si un Qwen sait y entrer, si son attention dispose d’un kernel, si ses poids arrivent assez vite jusqu’aux unités de calcul, ni si le runtime peut conserver son KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire pendant 32 000 tokens. Le silicium ne voit pas un « LLM » : il voit une suite de multiplications, de normalisations, de rotations positionnelles et de mouvements mémoire. Tant que cette suite n’est pas découpée et planifiée pour lui, ses 50 TOPS restent une capacité sans chemin d’accès.
FastFlowLM spécialise le chemin entièrement NPU. AMD proposait déjà un mode hybride, avec prefill sur NPU et decode sur iGPU, ainsi qu’un mode NPU-only via Ryzen AI LLM. FastFlowLM se distingue surtout par la fraîcheur de son catalogue, les contextes longs annoncés et une boucle d’inférence conçue pour XDNA2. Il descend jusqu’au placement des opérateurs et des données sur les tuiles, puis remonte jusqu’à un serveur local que Continue, Open WebUI et les autres clients utilisant les endpoints compatibles implémentés peuvent appeler. L’annonce d’AMD consacre moins un nouveau produit qu’une intégration verticale : architecture, compilateur, kernels, runtime, catalogue de modèles et API sont désormais pilotés plus directement par le même groupe.
XDNA2 ne fonctionne pas comme un petit GPU
Un GPU répartit des milliers de threads sur des unités programmables et s’appuie sur une hiérarchie de caches pour alimenter leur exécution. XDNA2 adopte une architecture de spatial dataflow. Le NPU est un tableau bidimensionnel de tuiles AI Engine. Chacune contient un processeur vectoriel SIMD/VLIW, un processeur scalaire RISC, une mémoire de programme et une mémoire de données locale. Des interconnexions et des moteurs DMA déplacent explicitement les blocs entre tuiles.
La différence est physique. Sur GPU, un scheduler lance un kernel sur un ensemble d’unités qui vont chercher leurs données dans la hiérarchie mémoire. Sur XDNA2, le compilateur réserve des tuiles à une opération, organise leurs buffers locaux et programme les transferts qui feront circuler le tenseur dans le maillage. Une multiplication de matrices n’est plus seulement une fonction appelée au bon moment : elle est affectée à une région du maillage, avec un placement et des communications planifiés à l’avance. Ce placement préplanifié réduit le coût de contrôle et certains accès répétés aux caches, mais il demande de connaître à l’avance la forme des opérations et de leurs données.
Voilà pourquoi porter un runtime GPU ne suffit pas. Le prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée, le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. Approfondir dans le glossaire traite beaucoup de tokens en parallèle et ressemble à une grande multiplication de matrices, terrain naturel pour le réseau de tuiles. Le decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse, le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. Approfondir dans le glossaire ne produit qu’un token par pas et relit les poids ainsi que le cache du contexte : les opérations rapetissent, la pression mémoire prend le dessus, et un découpage pensé pour le prefill peut laisser des tuiles sous-occupées. FastFlowLM annonce des chemins distincts adaptés à ces deux régimes. L’explication par l’occupation des tuiles est une lecture architecturale cohérente avec XDNA2, pas un audit de l’organisation interne de ses kernels binaires.
IRON, FastFlowLM, Lemonade : trois couches, trois rôles
Le nom des projets brouille facilement leur frontière. IRON est l’interface proche du matériel. Publié par AMD sous licence Apache 2.0 et construit sur MLIR-AIE, il expose en Python la composition d’opérateurs et les mouvements de données du NPU. Son dépôt contient des implémentations de GEMM, GEMV, attention MHA/GQA, RMSNorm, RoPE, activations et déquantification AWQ, ainsi que les descriptions ObjectFIFO qui font circuler leurs buffers entre tuiles. IRON ne fournit pas à lui seul l’expérience d’un Ollama : il donne aux auteurs de runtime les briques pour construire cette expérience sans redescendre à chaque fois dans le pilote.
FastFlowLM s’appuie sur IRON et MLIR-AIE pour produire ses kernels et assembler une boucle d’inférence. Il charge les poids depuis des artefacts destinés au runtime, notamment Q4NX, réserve le cache, choisit les chemins de prefill et de decode, applique la tokenisation, puis diffuse les tokens. Q4NX n’est pas présenté ici comme une quantification universelle : les fiches FastFlowLM mentionnent aussi Q4_1 ou Q4_KS selon les modèles. Son binaire d’environ 17 Mo expose un CLI et un serveur local. Lemonade se place encore au-dessus : catalogue, téléchargement, sélection du backend, gestion de modèles et API commune pour llama.cpp, ONNX Runtime, FastFlowLM ou ROCm.
Cette séparation explique aussi les deux sens du mot « ouvert » employés par AMD. IRON publie le code de son API, de ses opérateurs et de ses kernels sous Apache 2.0. Le dépôt FastFlowLM publie l’orchestration et les outils CLI sous MIT, mais distribue ses kernels accélérés sous forme de binaires propriétaires. Leurs conditions publiques se contredisent au 20 juillet 2026 : TERMS.md conserve un seuil commercial d’environ 9,2 millions d’euros de chiffre d’affaires annuel, tandis que le README annonce une utilisation gratuite sans limite, y compris commerciale. Le README demande par ailleurs un crédit « Powered by FastFlowLM », sans que TERMS.md le présente comme une obligation contractuelle. Vous pouvez inspecter la façon dont le runtime orchestre un modèle et développer avec IRON ; vous ne pouvez pas reconstruire depuis le même dépôt chaque binaire optimisé livré avec un modèle FastFlowLM. La pile est ouverte à ses deux extrémités, pas uniformément transparente au milieu.
NPU seul ou couple NPU et iGPU
Lemonade propose trois chemins NPU que leurs noms rendent trop proches. Le mode hybride OGA envoie le prompt au NPU, puis passe la génération à l’iGPU. Le NPU absorbe le prefill, phase parallèle et dense ; le GPU intégré prend le decode, phase séquentielle qui bénéficie de sa programmabilité et de son accès à la mémoire unifiée. Le mode ryzenai-llm garde l’inférence sur le NPU via la pile Ryzen AI. Le mode flm, lui, appelle FastFlowLM et ses kernels XDNA2 pour exécuter le modèle entier sur le NPU.
| Mode | Prefill | Decode | Moteur | Usage |
|---|---|---|---|---|
| Hybride OGA | NPU | iGPU | ONNX Runtime GenAI | partage selon la phase |
| Ryzen AI LLM | NPU | NPU | pile Ryzen AI | modèles NPU packagés |
| FastFlowLM | NPU | NPU | FLM / Q4NX | chemin XDNA2 spécialisé |
Ce découpage change la lecture d’un benchmark. « Sur Ryzen AI » peut désigner un modèle dont le prompt passe par le NPU et dont tous les tokens sortent de l’iGPU, ou un modèle maintenu sur le NPU de bout en bout. Comparer ces résultats sans nommer le backend revient à comparer des runtimes GPU en ne citant que la marque de la carte. Dans ce dossier, les chiffres FastFlowLM désignent le troisième chemin.
Ce que les mesures prouvent
FastFlowLM publie ses mesures par famille de modèles, avec le débit de prefill, le débit de decode et le contexte initial. Les bancs Llama et gpt-oss utilisent un Ryzen AI 7 350 avec 32 Go de RAM en mode « Performance ». Qwen 3.6 35B-A3B utilise le même processeur avec 96 Go. Chaque chiffre ci-dessous vient donc de l’éditeur du runtime, sur son propre logiciel. Aucune réplication indépendante exacte de cette matrice, avec le même matériel, les mêmes versions et les mêmes contextes, n’a été identifiée. Des essais menés par ITmedia et Notebookcheck confirment toutefois que FastFlowLM fonctionne réellement et atteint un débit interactif sur Ryzen AI, avec des protocoles différents de celui du tableau.
| Modèle | RAM | 1k | 32k | 64k | 128k |
|---|---|---|---|---|---|
| Llama 3.2 1B | 32 Go | 64,5 tok/s | 35,0 | 24,1 | 13,6 |
| Llama 3.2 3B | 32 Go | 26,3 tok/s | 13,6 | 9,0 | OOM |
| Llama 3.1 8B | 32 Go | 12,8 tok/s | 8,5 | OOM | OOM |
| gpt-oss-20b | 32 Go | 18,2 tok/s | 12,0 | 8,7 | 5,7 |
| Qwen 3.6 35B-A3B | 96 Go | 12,41 tok/s | 8,88 | non publié | non publié |
Le premier résultat est fonctionnel : un NPU de PC portable sait maintenir une boucle de génération complète, y compris pour un MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire de 20 ou 35 milliards de paramètres. Le nombre total de paramètres de Qwen 3.6 35B-A3B détermine la mémoire nécessaire pour garder ses experts ; ses quelque 3 milliards de paramètres actifs par token déterminent une part du calcul. Le MoE explique qu’un modèle de 35 milliards puisse produire une douzaine de tokens par seconde. Le banc Qwen utilise 96 Go, ce qui fournit de la marge au modèle, à son contexte et aux espaces de travail ; la source n’établit pas que 96 Go constituent le minimum requis.
Le deuxième résultat est la pente. Llama 3.2 1B perd près de 79 % de son débit entre 1k et 128k de contexte, de 64,5 à 13,6 tokens/s. Ses poids n’ont pas changé. Ce qui change est la quantité de clés et de valeurs que l’attention doit relire, ainsi que l’espace réservé aux buffers du contexte. À faible longueur, le NPU consacre une part élevée du pas de decode aux projections du modèle. À 128k, le parcours du cache et les mouvements de données prennent une fraction bien plus grande du temps. FastFlowLM repousse la limite fonctionnelle du contexte ; il n’annule pas son coût physique.
Le troisième résultat est l’OOM. FastFlowLM indique que moins de 50 % de la RAM système peut être accessible au NPU sur son banc de 32 Go et attribue cette limite à la pile AMD et Microsoft ; aucune documentation primaire de ces deux entreprises confirmant le plafond exact n’a été identifiée. gpt-oss-20b occupe environ 15,1 Go dans FLM, tout près d’une fenêtre annoncée autour de 15,6 Go : son démarrage peut réussir ou échouer selon la mémoire déjà occupée. Llama 3.1 8B tient à 32k puis échoue à 64k, parce que le modèle, son KV cache et les espaces de travail doivent entrer ensemble dans cette fenêtre. La mémoire est unifiée physiquement au niveau du PC, mais elle ne l’est pas sans limite du point de vue du pilote NPU.
Le chiffre énergétique qui manque encore
FastFlowLM affiche moins de 2 W pour le couple CPU et NPU, contre environ 25 W pour un chemin GPU, ainsi que des gains pouvant dépasser 67 fois l’énergie par token face à l’iGPU et 222 fois face au CPU. Ces valeurs sont plausibles dans leur direction : le maillage XDNA2 évite une partie du contrôle et des mouvements qu’un GPU généraliste paie, et son NPU a précisément été conçu pour rester actif dans une enveloppe de PC portable. Elles ne sont pas encore utilisables comme verdict comparatif.
Un ratio d’énergie par token intègre déjà la durée s’il est calculé correctement. L’absence d’une durée isolée ne réfute donc pas les facteurs annoncés. Le problème est l’impossibilité de les recalculer : les pages publiques ne donnent pas, pour chaque backend, la puissance moyenne, le débit exact, le même modèle et la même quantification, le périmètre électrique, le contexte, les séries brutes et les conditions thermiques. Le slogan « moins de 2 W contre environ 25 W » décrit une puissance instantanée ; il ne suffit pas à établir seul l’énergie totale d’une génération.
Deux essais extérieurs donnent un ordre de grandeur plus modeste. ITmedia observe FastFlowLM oscillant autour de 16 à 24 W sur son protocole, contre environ 30 à 45 W pour le chemin hybride ; son test de gpt-oss-20b estime 0,55 token/s/W pour FLM contre 0,41 pour LM Studio. Notebookcheck mesure environ 25 W au niveau du portable avec FastFlowLM et 65 W avec LM Studio sur Gemma 3 4B, les deux chemins dépassant 10 tokens/s. Ces essais soutiennent un avantage énergétique sur leurs machines ; ils ne valident pas les facteurs 67 et 223 publiés par FastFlowLM.
Notre conclusion est donc asymétrique. Le fonctionnement et le débit peuvent être retenus comme mesures éditeur réexécutables avec l’outil flm bench, pas comme une matrice indépendamment reproduite : le modèle précis du portable, le BIOS, le pilote, la fréquence mémoire, les conditions thermiques et les résultats bruts ne sont pas tous publiés. Les multiplicateurs énergétiques restent des affirmations constructeur à répliquer. C’est précisément le type de séparation entre fait mesuré et promesse que les TOPS avaient effacé au départ.
Ce qu’AMD gagne réellement
L’équipe apporte à AMD plus qu’un runtime de 17 Mo. Elle apporte une cadence de support modèle. La version 0.9.45, publiée six jours avant l’annonce, a ajouté Qwen 3.6 35B-A3B, deuxième MoE pris en charge sur le NPU, et un contrôle du KV cache lors des changements de backend. Le catalogue couvre Llama, Gemma, Qwen, DeepSeek-R1, gpt-oss, Whisper, des embeddings et plusieurs modèles multimodaux. Cette liste est une série de ports spécifiques : chaque nouvelle architecture exige de cartographier ses opérateurs, ses dispositions mémoire et ses quantifications vers des kernels XDNA2.
Pour AMD, internaliser l’équipe réduit la distance entre trois calendriers qui avançaient séparément : sortie d’un modèle, ajout des opérateurs dans IRON, livraison du modèle optimisé dans Lemonade. C’est ce que l’annonce appelle le « Day-0 enablement ». Notre lecture stratégique est qu’AMD cherche à réduire l’un des avantages cumulés par NVIDIA : la maturité de CUDA, de ses bibliothèques et de l’écosystème qui rend rapidement les nouveaux modèles exécutables. Sur PC, AMD tente la même opération à plus petite échelle : faire du NPU une cible que les développeurs peuvent choisir le jour où le modèle sort, pas six mois après.
La dépendance devient aussi plus visible. FastFlowLM prend en charge les puces Ryzen AI dotées de XDNA2, notamment les familles Strix, Strix Halo, Krackan et Gorgon. Les NPU XDNA de première génération restent hors du chemin annoncé. Les modèles sont distribués avec des artefacts et kernels optimisés, et une version minimale du pilote est requise. Le runtime simplifie l’usage après installation ; il ne transforme pas le NPU en cible portable indépendante du fournisseur.
Pour quel usage le NPU devient-il rationnel ?
Un assistant local qui attend une requête toute la journée est le cas le plus convaincant. Son débit cible est humain, une dizaine à quelques dizaines de tokens par seconde. Il valorise la confidentialité, la disponibilité hors ligne et une faible puissance au repos ou en génération. FastFlowLM expose une API locale standard, de sorte qu’un outil de RAG, un éditeur ou un agent n’a pas besoin de connaître XDNA2. Pour cette charge, libérer l’iGPU conserve aussi les ressources graphiques de la machine.
Le traitement d’arrière-plan suit la même logique : transcription, embeddings, indexation locale, résumé de documents et petits modèles multimodaux. Ces tâches ont une topologie connue, supportent une file d’attente et gagnent à occuper un accélérateur que l’interface graphique n’utilise pas. Le NPU ne remplace pas le GPU ; il évite de le réveiller pour une charge stable.
Le choix devient moins favorable quand le modèle change chaque semaine, quand vous devez charger un GGUF arbitraire, quand le contexte long est central ou quand plusieurs utilisateurs doivent être servis avec un batching continu Ordonnancement à l'itération : ajouter et retirer des requêtes du batch à chaque pas de génération, au lieu d'attendre qu'un batch entier se termine. Formalisé par Orca (OSDI 2022), popularisé par vLLM. Multiplie par 2 à 4 le débit d'un serveur d'inférence sous forte concurrence. Approfondir dans le glossaire agressif. Le catalogue FastFlowLM est large mais fini. Le GPU et llama.cpp acceptent davantage de formats et de modèles sans artefact XDNA2 préalable. Pour du serving à forte concurrence, vLLM et SGLang disposent d’ordonnanceurs, de caches paginés et d’un écosystème de kernels encore plus profond. Le NPU gagne une place dans la machine ; il ne récupère pas toutes celles du GPU.
La prochaine bataille est le modèle non prévu
FastFlowLM répond à la question qui bloquait les NPU de PC depuis leur arrivée : oui, un runtime spécialisé peut faire passer un LLM complet dans un maillage XDNA2 et restituer un débit interactif. L’intégration de l’équipe chez AMD donne à cette réponse une chance de survivre au prochain Qwen, au prochain Gemma et au prochain changement d’attention.
La question suivante sera plus exigeante. Un catalogue de modèles précompilés peut grandir vite ; il reste un catalogue. Le jour où un développeur pourra prendre un checkpoint arbitraire, compiler ses opérateurs manquants avec IRON et obtenir un résultat proche des kernels binaires sans attendre AMD, le NPU deviendra une plateforme. Jusqu’à ce jour, FastFlowLM est la meilleure preuve que le silicium n’était pas inutile. Il attendait son logiciel.
Sources et méthode
Date de gel rédactionnel : 20 juillet 2026. Étiquettes : fait vérifié (source primaire ou dépôt officiel), mesure éditeur (banc publié par FastFlowLM, non répliqué exactement ici), mesure extérieure (essai publié par un tiers avec un protocole différent), affirmation constructeur (comparaison dont le protocole public ne suffit pas à reproduire), jugement éditorial (recommandation explicitée). Le seuil de licence publié en dollars est converti au taux indicatif de 1 USD = 0,92 EUR.
Intégration de FastFlowLM chez AMD
- Fait vérifié : AMD, « FastFlowLM Joins AMD to Advance AI Inference », 17 juillet 2026. L’annonce dit que l’équipe « joined AMD », rejoint l’Artificial Intelligence Group et travaillera au support Day-0. Elle décrit FastFlowLM comme déjà construit avec IRON et étroitement aligné avec Lemonade ; elle ne qualifie pas la transaction d’acquisition et n’en publie pas les conditions.
Silicium XDNA2 et Ryzen AI 7 350
- Fait vérifié : AMD, architecture XDNA : tableau 2D de tuiles AI Engine, processeurs vectoriel et scalaire, mémoires locales, interconnexion et DMA. AMD, Ryzen AI 7 350 : jusqu’à 50 TOPS NPU, valeur maximale en conditions optimales.
- Fait vérifié : AMD, IRON, branche
develconsultée le 20 juillet 2026 : API Python MLIR-AIE sous Apache 2.0, opérateurs GEMM/GEMV/MHA/GQA/RMSNorm/RoPE, déquantification AWQ, ObjectFIFO, fusion et intégration XRT.
Runtime, ouverture et compatibilité
- Fait vérifié : dépôt FastFlowLM, consulté le 20 juillet 2026 : runtime C++ d’environ 17 Mo, support XDNA2, endpoints compatibles OpenAI, orchestration et CLI sous MIT, intégration à Lemonade datée du 1er octobre 2025. Les kernels NPU sont des binaires propriétaires. Les conditions publiques sont contradictoires :
TERMS.mdmaintient un seuil commercial d’environ 9,2 millions d’euros après conversion, tandis que le README annonce une utilisation commerciale gratuite sans limite et demande un crédit qui n’apparaît pas comme obligation dansTERMS.md. La version 0.9.45 du 11 juillet ajoute Qwen 3.6 35B-A3B et la gestion du KV cache entre backends. - Fait vérifié : AMD, guide Lemonade : mode hybride NPU-prefill/iGPU-decode, mode Ryzen AI LLM NPU et backend FastFlowLM ; prise en charge Ryzen AI 300/400/Max 300 et Z2 pour les chemins documentés.
Performances et mémoire
- Mesure éditeur : FastFlowLM, bancs Llama 3, gpt-oss et Qwen 3.6. Llama et gpt-oss : Ryzen AI 7 350, 32 Go, mode Performance, versions FLM 0.9.30/0.9.32. Qwen 3.6 35B-A3B : même processeur, 96 Go, FLM 0.9.45. Débits recopiés avec leur contexte ; aucune comparaison intermodèle n’en est déduite.
- Limite documentée par l’éditeur : model card gpt-oss-20b et instructions CLI : modèle autour de 15,1 Go, fenêtre NPU annoncée autour de 15,6 Go sur certains systèmes de 32 Go, moins de 50 % de la RAM accessible et OOM de Llama 3.1 8B au-delà de 32k dans le banc publié. FastFlowLM attribue la fenêtre à la pile AMD et Microsoft ; aucune source primaire de ces deux entreprises confirmant ce plafond exact n’a été identifiée.
Essais extérieurs
- Mesure extérieure : ITmedia AI+, 29 décembre 2025 : cinq répétitions par chemin sur Ryzen AI 7 PRO 350, puissance interne relevée par HWMonitorPro. FastFlowLM oscille autour de 16 à 24 W contre environ 30 à 45 W pour le chemin hybride ; sur gpt-oss-20b, l’auteur estime 0,55 token/s/W pour FLM et 0,41 pour LM Studio. Les modèles diffèrent dans une partie du comparatif, ce qui interdit d’en tirer un classement universel.
- Mesure extérieure : Notebookcheck, 28 novembre 2025 : environ 25 W mesurés au niveau du portable avec FastFlowLM contre 65 W avec LM Studio sur Gemma 3 4B, avec plus de 10 tokens/s dans les deux cas. Ce protocole ne reproduit pas la matrice officielle FastFlowLM.
Énergie
- Affirmation constructeur non retenue comme verdict : page des benchmarks FastFlowLM : moins de 2 W CPU+NPU, multiplicateurs de 67,2× face à l’iGPU et 222,9× face au CPU selon les cas présentés. Le périmètre public ne suffit pas à reconstruire chaque comparaison modèle pour modèle, contexte pour contexte et rail électrique pour rail électrique.
Note de méthode. Les tokens/s sont rapportés comme mesures de l’éditeur, pas comme un classement indépendant. Le dossier ne compare pas directement le débit de modèles de tailles ou d’architectures différentes. La baisse avec le contexte est interprétée à partir du mécanisme du KV cache et des OOM publiés ; l’ampleur exacte dépend du modèle, de la quantification, de la RAM disponible, du pilote et de la version FastFlowLM.
