ElectroTech · 7 November 2026

Ryzen AI Embedded X100 : Strix Halo passe au robot — 128 Go unifiés, 50 TOPS, et les vraies questions que personne ne pose

AMD a porté son APU Strix Halo dans le monde de l’embarqué avec le Ryzen AI Embedded X100 : jusqu’à 128 Go de mémoire unifiée, une NPU XDNA 2 taillée pour l’inférence locale et une plage thermique industrielle descendant à -40 °C. Une rupture d’architecture pour la robotique et le calcul edge — à condition de savoir où se trouve réellement la ligne de démarcation entre le saut générationnel et le pari d’intégration.

Strix Halo quitte le bureau : pourquoi AMD vise maintenant les robots

Il y a un moment où un composant cesse d’être un produit et devient une plateforme. Le Ryzen AI Max 300 — nom de code Strix Halo — a d’abord été un APU pour portables haut de gamme et mini-PC, avec une particularité qui a fait lever quelques sourcils : une mémoire unifiée qui peut grimper très haut, et une NPU XDNA 2 annoncée jusqu’à 50 TOPS. AMD en a tiré une plateforme développeur, la « Ryzen AI Halo », positionnée pour le développement IA local, avec 128 Go de mémoire unifiée et un support revendiqué de modèles jusqu’à 200 milliards de paramètres. La page produit officielle mentionne aussi une version « Coming Soon » équipée du Ryzen AI Max+ PRO 495 avec 192 Go de mémoire, et le Ryzen AI Max+ PRO 495 commence à apparaître dans des mini-PC, notamment chez Beelink selon Cowcotland.

Puis, en janvier 2026, AMD a dévoilé au CES la famille Ryzen AI Embedded X100 — six modèles : X199, X188, X168 et leurs variantes industrielles X199i, X188i, X168i. Cœurs Zen 5, NPU XDNA 2 jusqu’à 50 TOPS, TDP de 55 W. C’est la dérivation embarquée de Strix Halo, et le positionnement est explicite : la « physical AI », c’est-à-dire l’IA qui pilote des actionneurs, lit des caméras et tourne dans un châssis qui bouge. La page produit officielle AMD constitue désormais la référence à consulter pour les spécifications définitives — c’est elle qui fait foi, et non les tableaux relayés par la presse au moment de l’annonce.

Le contexte commercial compte autant que la fiche technique. AMD revendique 7 000 clients embarqués dans le monde — automobile, santé, broadcast, satellites — selon une déclaration de Lee Hee-man d’AMD rapportée par TechTimes. Ce chiffre provient d’un seul média et d’un dirigeant de la marque : il faut le prendre comme un indicateur d’ambition, pas comme un audit. Mais il dit quelque chose de réel : AMD a une base installée embarquée, et il veut y faire monter en gamme le calcul IA. Le X100 est l’instrument de cette montée.

La promesse, en une phrase : mettre dans un robot ce qui tenait jusqu’ici dans un poste de développement, sans changer de modèle mental de programmation. C’est séduisant. C’est aussi exactement le genre de promesse qu’il faut démonter pièce par pièce avant de la croire.

Sous le capot : Zen 5, RDNA 3.5 et XDNA 2 dans un seul die

Le X100 est un APU au sens plein : CPU, GPU et NPU sur la même puce, avec un contrôleur mémoire partagé. La répartition, telle que documentée par les tableaux de spécifications relayés par cnx-software et raspberryme, donne ceci :

Le suffixe « i » n’est pas cosmétique : c’est la différence entre un composant qui supporte la température ambiante d’une armoire électrique et un composant qui survit au démarrage à froid d’un engin extérieur en hiver. Pour un robot mobile, un système de vision en extérieur ou un équipement de chantier, c’est souvent le critère qui tranche avant même de parler de TOPS. À noter que cette contrainte thermique rejoint directement les préoccupations de nos dossiers sur les PMIC intelligents 2026 : à 55 W dans un châssis fermé et soumis au froid, le séquencement d’alimentation et la télémétrie de puissance ne sont plus des options de confort.

Côté mémoire, le point clé : LPDDR5x jusqu’à 8 canaux, avec Link-ECC. La fréquence citée dans les extraits est de 8000 MT/s. Sur un bus 256 bits, cela donne un ordre de grandeur théorique d’environ 256 Go/s — mais attention, ce chiffre est un calcul dérivé, pas une donnée publiée par AMD pour le X100 spécifiquement. Il faut le traiter comme un ordre de grandeur à vérifier au banc, pas comme une spec.

L’inventaire I/O, tel que relayé : encodage/décodage vidéo matériel jusqu’à 4K@60 Hz, HDMI 2.1, DisplayPort 2.0, eDP 1.4, DVI, USB4 (deux ports), deux USB 3.2, sortie jusqu’à 8K@60. C’est un profil d’I/O de plateforme client, ce qui est logique : le X100 descend du silicium Strix Halo. Ce qui reste à confirmer pour la variante Embedded, ce sont les interfaces spécifiquement industrielles — PCIe en configuration exacte, MIPI CSI pour les capteurs caméra, Ethernet industriel, et le support des protocoles temps réel type TSN. Aucune de ces données n’apparaît dans les extraits disponibles. C’est une lacune importante : pour un design robotique, MIPI et Ethernet déterministe pèsent souvent plus lourd que le nombre de CU. Et c’est précisément là que les capteurs MEMS de nouvelle génération — IMU à traitement embarqué, micro-miroirs, acoustique — doivent trouver leur place dans la chaîne : un APU capable d’avaler 128 Go de modèles ne sert à rien si le flux caméra n’arrive pas par un lien déterministe. Voir notre état des lieux MEMS 2026.

Enfin, la NPU. AMD annonce « jusqu’à 50 TOPS NPU4 » — mais ce chiffre provient de la page Ryzen AI Halo, qui décrit le Ryzen AI Max+ 395, pas explicitement la variante X100 Embedded. La concordance est forte, la confirmation formelle manque. Quant aux précisions supportées (INT8, INT4, FP16), elles ne sont pas documentées dans les extraits. On sait que XDNA 2 est une architecture NPU conçue pour l’inférence quantifiée, mais affirmer des chiffres INT4 précis serait inventer.

128 Go unifiés : la vraie rupture, et ses limites physiques

C’est ici que se joue l’essentiel. La mémoire unifiée n’est pas une nouveauté en soi — les Jetson la pratiquent depuis des années, les Apple Silicon aussi. Ce qui change avec le X100, c’est l’échelle : jusqu’à 128 Go dans un seul pool adressable par le CPU, le GPU et la NPU, sans copie explicite entre des mémoires séparées.

Concrètement, qu’est-ce que cela permet ? Un modèle de langage de 70 milliards de paramètres en quantification 4 bits pèse environ 35 Go de poids. En 8 bits, environ 70 Go. En FP16, environ 140 Go — hors de portée. Donc avec 128 Go, on peut charger un 70B en INT8, ou un 70B en INT4 avec une marge confortable pour le contexte et le cache KV. Un modèle de 200B paramètres en INT4 pèse environ 100 Go : il rentre, mais il ne laisse presque plus rien pour le contexte, les activations et le reste du système. C’est là que la revendication « jusqu’à 200B paramètres » doit être lue avec précision : c’est un maximum théorique de chargement, pas une promesse de confort d’usage.

La deuxième contrainte est la bande passante. Un LLM en inférence générative est memory-bound : chaque token généré nécessite de lire l’intégralité des poids actifs. Avec 256 Go/s théoriques, un modèle de 35 Go de poids implique un plafond absolu d’environ 7 tokens par seconde, avant même de compter l’efficacité réelle du moteur d’inférence, qui est typiquement de 50 à 70 % de la bande passante théorique. Donc plutôt 3 à 5 tokens/s en pratique pour un 70B INT4. C’est utilisable pour un agent qui réfléchit, pas pour une boucle de dialogue fluide.

Pour un modèle plus petit — 8B en INT4, soit environ 4 Go — le même calcul donne un plafond théorique de l’ordre de 60 tokens/s, et probablement 20 à 40 tokens/s réels. C’est là que le X100 devient intéressant pour l’embarqué : faire tourner un VLM de taille moyenne (analyse d’image + langage) à une cadence compatible avec une supervision robotique.

Il faut aussi comprendre la partition mémoire. La mémoire unifiée est un pool, mais elle n’est pas infiniment flexible : le firmware alloue des zones au GPU (mémoire graphique), à la NPU, au CPU. La taille de ces zones est configurable, mais pas à la volée sans coût. Un design qui veut alterner entre un gros modèle résident et un pipeline de vision temps réel doit penser cette partition en amont, pas la découvrir en production. C’est le même réflexe de co-design que celui décrit dans notre dossier sur les PMIC intelligents : la ressource se planifie, elle ne s’improvise pas.

Tokens par seconde : ce qu’AMD annonce, ce qu’on peut réellement attendre

Soyons directs : aucun débit mesuré, aucun tokens/s publié sur un modèle nommé, aucune mesure indépendante n’apparaît dans la matière disponible. AMD revendique un « Leadership LLM Tok/Sec per $ » et compare la plateforme Ryzen AI Max / Halo à l’Apple M4 Pro et au NVIDIA DGX Spark — mais sans publier de valeurs numériques dans les extraits fournis. C’est une affirmation comparative marketing, non recoupée.

Ce qu’on a, en revanche, ce sont des revendications de performance relatives, également constructeur : jusqu’à 2,1× en multithread (CoreMark), 1,7× en graphique (OpenGL/GFXBench 5.0.0), 3,5× en débit de génération de jetons et 1,4× plus rapide au premier jeton face à l’Intel Core Ultra Series 3. Et face au NVIDIA Jetson Thor T5000, AMD revendique jusqu’à 3× en FP32 ; face à une RTX 4000 Ada, environ 1,7× sur des tâches d’ultrasons médicaux. Tous ces chiffres sont des revendications constructeur relayées par des tiers, non testées indépendamment.

Ce que l’ingénieur peut faire de tout ça, c’est raisonner par la physique plutôt que par le marketing :

• Un 8B INT4 devrait tenir une conversation à une cadence confortable sur GPU via ROCm ou llama.cpp. C’est le cas d’usage le plus crédible pour un robot qui doit « comprendre » une scène.
• Un 70B INT4 sera utilisable en mode agent asynchrone — une requête toutes les quelques secondes — pas en interaction temps réel.
• Un VLM type LLaVA ou Qwen-VL de taille moyenne est le sweet spot : l’image est traitée par le GPU, le raisonnement par le modèle, et la latence reste compatible avec une supervision à quelques hertz.

Les outils à tester, dans l’ordre : llama.cpp avec backend ROCm (le plus simple pour valider un débit brut), ONNX Runtime avec l’Execution Provider Ryzen AI pour exploiter la NPU, et la pile Ryzen AI Software d’AMD pour les modèles supportés officiellement. Le support ROCm est annoncé « Day 0 » — ce qui, dans l’écosystème AMD, veut dire que la pile est prête au lancement, mais pas nécessairement que tous les kernels sont optimisés pour cette puce précise. C’est un point à vérifier au banc, pas sur une page produit. Le portail Developer Central d’AMD centralise désormais outils, documentation et accès aux piles logicielles par gamme de produits : c’est le point d’entrée à surveiller pour savoir ce qui est réellement supporté sur X100, et ce qui ne l’est que sur Ryzen AI Max.

Jetson, Qualcomm, Intel : le X100 face à ses rivaux embarqués

La comparaison est le cœur du sujet, et c’est aussi là que les données manquent le plus. Voici ce qu’on peut dire honnêtement, avec les chiffres disponibles :

Ce tableau dit surtout une chose : la comparaison sérieuse n’est pas encore possible avec les données publiques. Les seuls chiffres fermes côté X100 sont les 50 TOPS (d’origine AMD, non confirmés pour la variante Embedded), les 55 W, et les 128 Go. Côté Jetson Orin, le chiffre de 275 TOPS circule largement mais n’apparaît pas dans nos extraits — je ne le cite donc qu’à titre indicatif, sans le présenter comme vérifié.

Là où le X100 gagne, structurellement : la capacité mémoire. 128 Go unifiés, c’est le double d’un Orin 64 Go, et cela change la classe de modèles qu’on peut charger. Pour un poste de calcul edge qui doit tenir un VLM résident plus un pipeline de vision, c’est un avantage réel, pas cosmétique.

Là où il reste un pari : l’écosystème. CUDA a quinze ans d’outils, de bibliothèques et de réponses Stack Overflow. ROCm progresse vite, mais l’écart se paie en semaines d’intégration. Et pour l’embarqué, la question n’est pas seulement « est-ce que ça marche », c’est « est-ce que ça marche sur Yocto, avec un kernel upstream, et est-ce que les drivers XDNA seront maintenus dans trois ans ». Aucune de ces réponses n’est dans la matière disponible. C’est un vrai angle mort.

Un point de méthode, enfin, sur la façon de lire les annonces : AMD publie ses pilotes et ses piles par produit sur son portail de téléchargement, avec des branches Windows et Linux distinctes. La disponibilité effective d’un pilote Linux pour la variante Embedded — et pas seulement pour les Ryzen AI Max de bureau — sera le premier signal concret de maturité. Tant que cette page ne liste pas explicitement les X100, considérez le support comme « annoncé », pas comme « livré ».

Ce que le X100 change vraiment pour un design embarqué

Au-delà des TOPS, la question qui intéresse un architecte est celle du budget énergétique et thermique global. Un APU à 55 W ne vit pas seul : il lui faut un étage d’alimentation capable de tenir les transitoires, un PMIC qui séquence correctement les rails, et une gestion de la chaleur compatible avec un boîtier scellé. C’est exactement le terrain de jeu des nouvelles familles de régulateurs intelligents — Infineon OPTIREG TLE9744QK, MaxLinear, Navitas — décrites dans notre dossier PMIC intelligents 2026. La télémétrie PMBus devient ici un outil de diagnostic : savoir quel rail a décroché au démarrage à -40 °C vaut mieux qu’un écran noir.

Deuxième point : la hiérarchie de calcul. Le X100 n’a de sens que s’il est le cerveau « lourd » d’un système qui comporte aussi des nœuds frugaux. Un robot typique empile des microcontrôleurs ultra-basse consommation pour le réveil, la sécurité et les boucles de contrôle rapides, et un APU pour la perception et le raisonnement. Le match des architectures MCU 2026 — STM32U5/U0, BG2B, PIC32CM PL10, MSP430, avec la MRAM 5 nm de Samsung en embuscade — est le complément naturel de ce dossier : voir Microcontrôleurs ultra-basse consommation et IA en 2026. Un X100 qui tourne en permanence pour attendre un événement est un gaspillage de 55 W ; le réveil doit être confié à un MCU à quelques microampères.

Troisième point : l’alimentation de puissance. Si le X100 pilote des actionneurs, la chaîne de puissance (onduleur, étage moteur 48 V) est un sujet séparé mais adjacent. Les familles GaN qui couvrent désormais 40 à 1200 V — analysées dans notre article GaNrich 40–1200 V — sont précisément ce qui permet de tenir la densité de puissance dans le volume d’un châssis robotique. L’APU décide, le GaN exécute ; les deux doivent être pensés ensemble.

Quatrième point, plus prospectif : la mémoire comme ressource partagée rebat les cartes du co-design. Sur un SoC classique, on dimensionne la DRAM, puis on ajoute un accélérateur avec sa propre SRAM. Ici, tout le monde puise dans le même pool. Cela simplifie le BOM, mais cela déplace la complexité vers le logiciel : il faut un ordonnanceur qui sache réserver de la bande passante à la NPU pendant que le GPU traite une image. Aucune documentation publique ne décrit encore cet arbitrage pour le X100. C’est le genre de détail qui fait la différence entre une démo et un produit.

Le verdict provisoire : une plateforme crédible, une intégration à prouver

Résumons sans complaisance. Le Ryzen AI Embedded X100 apporte trois choses réelles : une capacité mémoire qu’aucun concurrent embarqué n’égale aujourd’hui (128 Go unifiés), une plage thermique industrielle crédible (-40 à 105 °C sur les variantes i), et un continuum logiciel avec l’écosystème Ryzen AI déjà installé sur bureau. Pour un laboratoire qui veut faire tourner un VLM de taille moyenne dans un robot, c’est la première plateforme x86 qui rend cela envisageable sans GPU discret.

Mais il apporte aussi trois incertitudes qu’aucune source disponible ne lève : le débit réel en tokens/s sur un modèle nommé, la disponibilité des interfaces industrielles (MIPI CSI, Ethernet TSN, configuration PCIe) sur la variante Embedded, et la pérennité du support logiciel au-delà du lancement. Tant que ces trois points ne sont pas documentés — idéalement par des mesures indépendantes et par la page produit officielle — le X100 reste une promesse d’architecture, pas une plateforme validée.

Le conseil pratique est simple : si votre projet robotique a besoin de 128 Go unifiés maintenant, le X100 est la seule option et il faut le prototyper. Si votre projet tient dans 32 ou 64 Go, un Jetson reste le choix rationnel, non pas parce qu’il est plus rapide, mais parce que l’écosystème vous fera gagner les semaines que ROCm vous coûtera. La vraie question n’est pas « quel est le meilleur APU », c’est « combien de temps d’intégration puis-je m’offrir ». Et sur ce terrain, la réponse dépend autant de votre équipe que du silicium.

Un dernier mot sur le calendrier. Les annonces de janvier 2026 sont désormais anciennes de plusieurs mois, et la page produit AMD est en ligne : c’est elle qu’il faut consulter pour les fréquences définitives, les configurations mémoire réellement proposées et les SKU commercialisés. Tout ce qui précède doit être relu à la lumière de cette page, et corrigé si elle contredit un tableau de presse. C’est la règle de base : la fiche officielle prime toujours sur l’article de lancement.

Sources

• AMD — Ryzen AI Embedded X100 Series Processors (page produit officielle)
• TechTimes — AMD Ryzen AI Embedded X100 Puts Strix Halo APU Into Robots With 128 GB Unified Memory
• AMD — Developer Central (outils et documentation IA)
• AMD — Drivers and Support for Processors and Graphics
• cnx-software et raspberryme — tableaux de spécifications relayés au lancement (X199, X188, X168 et variantes i)
• Cowcotland — mini-PC équipés du Ryzen AI Max+ PRO 495 (Beelink)
• Dossiers internes du magazine : PMIC intelligents 2026, MEMS 2026 : l’IA réveille le capteur, Microcontrôleurs ultra-basse consommation et IA en 2026, GaNrich 40–1200 V

Article recherché et rédigé automatiquement · Magazine Electrosens