Ryzen AI Embedded X100 et Kria pour la robotique : un test d'acceptation deterministe de l'IA en peripherie

Les decisions de robotique avec AMD Ryzen AI Embedded X100 devraient commencer par le delai de la boucle de controle, pas par le titre de l'accelerateur. Un robot a besoin de la reponse avant l'echeance de controle, avec un horodatage frais, un comportement stable sous la chaleur et la pression memoire, et une logique de securite capable de rejeter les commandes dangereuses.

C'est la facon utile d'aborder AMD Ryzen AI Embedded X100 et les modules Kria AI pour l'IA physique. Les supports d'AMD decrivent Ryzen AI Embedded X100 comme une famille de processeurs d'IA embarquee heterogenes avec des surfaces d'execution CPU, GPU et NPU. Les modules Kria AI restent un autre type de candidat, centre sur la logique FPGA, les E/S personnalisees, le streaming deterministe et le pretraitement borne. Les deux peuvent etre valables. Aucun des deux n'est accepte par une diapositive, une capture d'ecran de benchmark ou une demonstration en laboratoire avec le robot debranche.

Cet article transforme le contexte de sortie en test d'acceptation pour le placement des charges de travail. La decision n'est pas de savoir quelle puce est meilleure. La decision consiste a savoir quelle charge de travail est autorisee a vivre sur le CPU, le GPU, le NPU, le FPGA ou le chemin de controle en temps reel strict, et quelles preuves locales demontrent cette frontiere. Pour un contexte adjacent, consultez les tests d'acceptation du modele du monde NVIDIA Cosmos 3 Edge, le test d'acceptation de manipulation 3D RynnBrain 1.1, la liste de controle d'observabilite des builds TensorRT et le guide des proprietes de plateforme Search Console.

Pourquoi l'IA physique a besoin d'un test d'acceptation, pas d'une autre comparaison de puces

L'accelerateur est rarement le premier point de defaillance. La premiere defaillance est souvent une frontiere non prouvee. Un modele de perception influence le mouvement avant que la fraicheur de l'horodatage soit verifiee. Un executeur ROS 2 met des callbacks en file d'une maniere que personne n'a testee sous charge. Une enceinte thermique modifie la latence apres vingt minutes. Sur le robot, le materiel moderne peut quand meme manquer l'echeance.

Pour une equipe de robotique qui evalue un systeme de type X100, une conception basee sur Kria, un PC industriel avec accelerateur ou un autre module, l'acceptation commence par les echeances du robot. Quel est le budget de la camera a la commande ? Quelle boucle est en temps reel strict ? Quelle sortie est seulement consultative ? Que reste-t-il de valide si l'environnement d'execution de l'IA plante ?

Le dossier de preuves doit nommer la reference exacte de la carte ou du module, la revision du module, le firmware ou le BIOS, le noyau, la pile de pilotes, la version de ROCm ou du logiciel Ryzen AI lorsqu'ils sont utilises, le bitstream FPGA, la distribution ROS 2, la configuration de l'executeur, le hachage du modele, les fichiers de calibration, le digest de l'image conteneur, la configuration des capteurs, le profil d'alimentation, l'etat thermique et le comportement en cas de panne. Si un autre ingenieur ne peut pas recreer le test, la decision reste une opinion.

Les supports fournisseur comptent pour la decouverte. Les pages produit et les fiches produit officielles indiquent ce qu'il faut examiner. La documentation logicielle indique quels chemins peuvent etre pris en charge. Elles ne prouvent pas que le timing de votre camera, le chemin de quantification, les operateurs du modele, les copies memoire, les callbacks ROS 2, les contraintes thermiques de l'enceinte et la logique de repli respectent le delai sur le robot cible.

Protegez le chemin de controle en temps reel strict. Les composants appris peuvent aider la perception, la prediction, la comprehension de scene et la planification consultative. Ils ne doivent pas prendre silencieusement possession de l'arret d'urgence, des enveloppes de collision, du timing des servos ou de l'autorite finale sur les actionneurs. Si l'IA contribue au mouvement, des controles deterministes doivent avoir le pouvoir de rejeter les sorties obsoletes ou dangereuses.

Ce qui change avec Ryzen AI Embedded X100 et ou Kria reste pertinent

Les supports Ryzen AI Embedded X100 d'AMD reunissent l'execution CPU, l'acceleration graphique et l'inference NPU dans une meme famille embarquee en peripherie. Pour la robotique, la question pratique n'est pas de savoir s'il faut tout deplacer vers la puce. Elle est de savoir si la consolidation reduit la charge d'integration sans creer d'operateurs non pris en charge, de contention de memoire partagee, de gigue ou de risque de mise a jour.

Les modules Kria AI repondent a une question differente. La logique FPGA est interessante lorsque le robot a besoin d'une entree capteur deterministe, d'une gestion de protocoles personnalises, de transformations au debit ligne ou d'un pretraitement borne avant l'inference. L'alignement des cameras, les ponts de capteurs et la reduction de donnees cadencee sont des endroits raisonnables pour evaluer Kria. Le cout tient aux competences de conception materielle, a la gestion du cycle de vie des bitstreams, a l'iteration plus lente et aux regles de rollback qui traitent les bitstreams comme des artefacts deployables.

Lisez la documentation ROCm et Ryzen AI comme des contraintes, pas comme des promesses. Verifiez la prise en charge des appareils, les versions d'OS et de noyau, la compatibilite de l'environnement d'execution, le chemin de compilation, les conteneurs, la couverture des operateurs, les outils de quantification, l'acces au profiler et les limites connues. Un resultat dans un notebook n'est pas accepte. Le modele deploye doit s'executer avec l'environnement cible, a la cadence des capteurs du robot, pendant que le reste du robot est actif.

Le test d'acceptation deterministe Optijara pour la robotique en peripherie

ODER-AT, le test d'acceptation deterministe Optijara pour la robotique en peripherie, comporte cinq portes. Chaque porte produit des preuves, pas des hypotheses.

Porte 1 : verification des artefacts, des references et de l'environnement d'execution

Commencez par prouver que l'appareil de test est l'appareil deployable. Capturez la reference, la revision du module, le firmware, le BIOS, le noyau, le pilote, ROCm ou l'environnement Ryzen AI, le bitstream FPGA, la distribution ROS 2, les reglages de l'executeur, le digest du conteneur, le hachage du modele, les fichiers de calibration, le firmware de la camera et le profil d'alimentation. Conservez la page produit officielle d'AMD, la fiche produit, la documentation et les fichiers du fournisseur de carte avec les notes. Si la reference change, le test recommence.

Porte 2 : repartition des charges de travail entre CPU, GPU, NPU, FPGA et controle

Cartographiez chaque fonction robotique vers une surface de calcul avant le benchmarking. Le CPU possede souvent l'orchestration ROS 2, les noeuds de cycle de vie, les machines d'etat de securite, la supervision par watchdog, le comportement de repli, les diagnostics et la logique non acceleree. Le GPU convient a la perception parallele lorsque la prise en charge du framework, la bande passante memoire, le comportement de batching et la variance de latence respectent le delai. Le NPU convient a l'inference neuronale uniquement lorsque le modele exact, les operateurs, la precision, le chemin de quantification et le comportement de l'environnement d'execution sont verifies. Le FPGA convient aux E/S deterministes, au pretraitement capteur, aux pipelines de streaming et aux transformations bornees. Le chemin de controle en temps reel strict possede l'autorite finale sur les actionneurs, l'arret d'urgence, les enveloppes de collision et le timing des servos.

Porte 3 : budget de latence de la perception au controle

Instrumentez l'ingestion camera, la fin de l'inference, la generation du plan, l'emission de commande et l'acceptation par l'actionneur. Repetez sous contention, avec la journalisation activee, le reseau actif, les diagnostics en cours, les controles de mise a jour presents, une pression memoire introduite, un trempage thermique en cours et tous les capteurs attendus connectes. Les echeances manquees, images obsoletes, profondeurs de file, distributions de gigue, marqueurs de throttling et evenements watchdog constituent le resultat.

Porte 4 : frontiere entre temps reel strict et temps reel souple

Classez chaque boucle. Les boucles en temps reel strict exigent un timing borne et un comportement de defaillance deterministe. Les boucles en temps reel souple peuvent tolerer des retards bornes ou une sortie degradee. Les sorties apprises consultatives ne peuvent influencer les decisions qu'au travers de contraintes, de controles de confiance, du rejet des sorties obsoletes et d'interverrouillages deterministes. Si la perception echoue, le robot doit deja savoir s'il doit ralentir, s'arreter, se degrader ou demander une intervention sans attendre qu'un accelerateur recupere.

Porte 5 : repetabilite, rollback et capture des preuves

L'acceptation exige des scripts reproductibles, des journaux, des seuils, des resultats d'injection de pannes et une preuve de rollback. Si un modele, un bitstream, un pilote ou un changement de conteneur modifie le comportement de timing, l'executeur de test doit le montrer. Si le rollback ne peut pas restaurer l'ensemble d'artefacts precedent avec des marqueurs d'audit clairs, l'aptitude au deploiement est incomplete.

{
  "framework": "ODER-AT",
  "hardware": ["Ryzen AI Embedded X100 class system", "Kria AI module", "alternative edge stack"],
  "workload_surfaces": ["CPU", "GPU", "NPU", "FPGA", "hard_real_time_control"],
  "evidence_required": ["SKU and firmware", "runtime versions", "model hashes", "ROS 2 executor config", "latency logs", "fault injection results", "rollback proof"],
  "reject_if": ["unsupported operators", "missed hard deadlines", "stale outputs cross safety boundary", "rollback cannot be proven"]
}

Guide de repartition des charges de travail pour CPU, GPU, NPU, FPGA et chemin de controle

Le CPU est generalement le centre banal du robot. C'est un compliment. Les noeuds ROS 2, la gestion du cycle de vie, les watchdogs, les machines d'etat de securite, la logique de repli, l'arbitrage des commandes et les diagnostics y ont souvent leur place parce qu'ils ont besoin de visibilite et d'une gestion previsible des defaillances.

Le placement sur GPU est interessant pour la perception parallele, mais il doit meriter cette place. Testez la bande passante memoire, les files, le comportement de batching, la maturite du framework et la variance de latence. Un noyau rapide peut quand meme perdre le budget si les images rebondissent en memoire dans un mauvais format.

Le placement sur NPU doit etre plus strict. Acceptez le NPU uniquement lorsque l'architecture exacte du modele, les operateurs, la precision, le chemin de quantification, le contrat de pretraitement et le comportement de l'environnement d'execution sont pris en charge et mesures. Si la quantification change la classe qui declenche une decision d'arret, c'est un probleme de conception de securite.

Le placement sur FPGA est le plus fort lorsque le timing et la structure comptent plus que la flexibilite. La capture synchronisee des capteurs, le pretraitement deterministe, la gestion de protocoles personnalises, les transformations au debit ligne et les chemins de donnees en streaming bornes sont de bons candidats. Le timing servo de bas niveau, l'arret d'urgence, les enveloppes de collision et l'autorite finale sur les actionneurs doivent rester bornes par le controle deterministe. Les sorties apprises peuvent conseiller, pas commander sans controle.

Integration temps reel ROS 2 : echeances, executeurs, capteurs et synchronisation

Les orientations officielles de ROS 2 sur les bases du temps reel, les executeurs et la programmation temps reel donnent un point simple : l'ordonnancement, l'allocation memoire, le comportement des callbacks et le comportement du systeme d'exploitation affectent le determinisme. Dans une pile heterogene en peripherie, le timing de l'accelerateur n'est qu'une partie du chemin.

La conception de l'executeur a besoin de son propre test. Verifiez les groupes de callbacks, les temporisateurs, la composition des noeuds, la profondeur de file, l'allocation memoire et l'inversion de priorite. Notez si la perception peut retarder la logique de securite, si les diagnostics rivalisent avec la generation de commandes et si les transitions de cycle de vie bloquent des callbacks critiques.

La synchronisation des capteurs merite la meme attention. L'alignement des cameras, les pertes d'images, la derive d'horloge, les sorties obsoletes, la contre-pression, la gigue de fusion et les commandes d'actionneur rejetees doivent etre journalises comme des evenements nommes. Ne les enterrez pas dans une moyenne. La queue peut manquer la seule echeance qui compte.

Les tests de contention doivent etre simples et repetables. Executez ensemble l'inference, la journalisation, le reseau, l'activite de mise a jour, les diagnostics et le fonctionnement normal du robot. Mesurez les echeances manquees, la pression memoire, la saturation de bande passante, le throttling thermique, les changements de mode d'alimentation, les evenements watchdog et la recuperation apres redemarrage. L'observabilite doit inclure des traces de timing, des compteurs materiels lorsqu'ils sont disponibles, la version du modele, les transitions d'etat de securite et les marqueurs de rollback sans ajouter trop de gigue.

Liste de controle de mise en oeuvre et plan de mesure pour un essai en laboratoire robotique

Le prevol doit valider la reference materielle, la nomenclature logicielle, la compatibilite du modele, l'acceptation de la quantification, le profil d'alimentation, la configuration thermique, le banc capteurs, la configuration ROS 2, les interverrouillages de securite, les watchdogs, la journalisation et le paquet de rollback. L'injection de pannes doit inclure les deconnexions camera, les images obsoletes, la defaillance de l'environnement NPU, la pression memoire GPU, l'incompatibilite de bitstream FPGA, la perte reseau, la baisse de confiance, la derive d'horloge, le rejet de commande d'actionneur et les fichiers de calibration corrompus.

Ne concevez pas cet essai pour flatter le materiel. Concevez-le pour trouver l'endroit ou la frontiere devient dangereuse, inobservable ou difficile a recuperer. C'est la que les decisions d'architecture deviennent concretes.

Erreurs courantes qui rendent les tests de robotique en peripherie plus beaux que le deploiement

La facon la plus rapide de se tromper est de benchmarker l'inference sans le robot. Le debit isole n'est pas le comportement du robot. Le timing des capteurs, l'ordonnancement ROS 2, les copies memoire, la conception de l'executeur, l'etat thermique et les echeances des actionneurs peuvent dominer l'acceptation.

La deuxieme erreur consiste a traiter la prise en charge de l'acceleration comme une preparation au deploiement. Un modele qui s'execute une fois sur un accelerateur ne prouve pas la couverture des operateurs, la precision quantifiee, le comportement thermique, la stabilite de l'environnement d'execution ou une degradation sure sous charge.

La troisieme erreur est d'ignorer le rollback, les watchdogs et les sorties obsoletes. Les fichiers de calibration non versionnes, les mises a jour de modele opaques et les tableaux de bord incapables d'expliquer quel artefact a produit une commande sont des risques de deploiement. La quatrieme consiste a laisser les composants appris franchir silencieusement la frontiere de securite. Si un modele neuronal peut influencer le mouvement, l'architecture a besoin de controles de fraicheur, de contraintes deterministes, d'une supervision watchdog et d'un mode de repli qui ne depend pas du meme composant defaillant.

Reserves, matrice de decision et quand choisir X100, Kria ou une autre pile en peripherie

Il existe de vraies reserves. La disponibilite materielle peut changer. La documentation fournisseur peut evoluer. La prise en charge de ROCm et Ryzen AI depend des appareils et versions logicielles exacts. La portabilite des modeles depend des operateurs, de la precision, du pretraitement et du comportement de quantification. Les enceintes thermiques peuvent invalider les resultats de laboratoire. La certification de securite peut exiger des preuves au-dela des benchmarks d'ingenierie.

Choisissez un systeme de type X100 lorsque la consolidation CPU, GPU et NPU convient a la pile logicielle et que les preuves locales demontrent une latence, un comportement thermique, un flux de mise a jour et un rollback acceptables. Choisissez des modules FPGA de type Kria lorsque les E/S de streaming deterministes, les pipelines capteurs personnalises et le pretraitement etroitement borne justifient l'effort de conception materielle. Choisissez une pile alternative lorsque les contraintes de certification, les operateurs non pris en charge, l'enveloppe d'alimentation, la thermique de l'enceinte, l'approvisionnement ou les exigences d'ecosysteme font echouer le test d'acceptation.

Un livrable de conseil pratique ici n'est pas une note d'achat. C'est un dossier de preuves avec cartographie des frontieres de charge de travail, benchmarks reproductibles, traces de timing ROS 2, scripts d'injection de pannes, preuve de rollback et matrice de decision avant que qui que ce soit ne s'engage sur Ryzen AI Embedded X100, Kria ou une autre architecture robotique en peripherie.