[TRIBUNE de Salil Raje, AMD] Le passage de l’IA dans le cloud à l’IA physique contraint les entreprises à revoir leurs conceptions de la performance. Les indicateurs conçus pour l’entraînement et l’inférence ne reflètent qu’une partie de la réalité lorsque l’IA doit percevoir, raisonner et contrôler des machines évoluant aux côtés des humains. Dans ces systèmes, la performance devient un enjeu global. Elle transforme la manière dont les robots sont évalués et conçus, et, par extension, détermine les architectures informatiques qui les propulseront. Salil Raje Vice-président senior et directeur général du groupe “Adaptive and Embedded Computing” d’AMD détaille ici cette évolution (*)

Les systèmes d’IA physique ne se contentent plus de fournir des réponses : ils passent à l’action et cela change la donne. Ce qui compte désormais, c’est la réactivité, la prévisibilité, la puissance, la sécurité et la capacité à fonctionner de manière fiable dans des conditions réelles.

La gestion du temps est au cœur de cette évolution. Une décision de contrôle qui arrive trop tard ne relève pas d’un simple problème de performance. Il s’agit d’une défaillance critique pouvant entraîner des collisions, une instabilité ou des comportements dangereux.

C’est particulièrement évident dans le cas des robots humanoïdes. Ils sont déployés dans des environnements industriels plus tôt que prévu et travaillent, de plus en plus, à proximité des humains.

Dans mes échanges avec les fabricants d’équipements robotiques (OEM), l’exigence qui revient le plus souvent n’est plus la puissance de calcul maximale. Il s’agit plutôt de la capacité à exécuter des modèles d’IA avancés parallèlement à un contrôle déterministe en temps réel.

Autrement dit, il s'agit d'allier intelligence et réponse prévisible, contrainte par le temps, à l’échelle du système.

Dans le monde physique, rater une fenêtre temporelle n’est pas un simple retard : c’est une situation dangereuse. Or, l’industrie me semble t’il continue d’optimiser les mauvais paramètres.

Faire évoluer les métriques d’évaluation

Le TOPS (trillions d'opérations par seconde) est une métrique incomplète pour l'IA physique. Il indique la capacité de calcul disponible, mais ne précise pas si un système est capable de détecter un événement, de prendre une décision et d'exécuter l'action appropriée dans un laps de temps imparti.

Cette manière de voir nécessite que les moteurs de calcul, la mémoire, le réseau, les capteurs et les logiciels fonctionnent comme un système parfaitement orchestré, avec une bande passante mémoire suffisante pour acheminer les données là où elles sont nécessaires, au moment opportun.

Or, un modèle performant sur un processeur donné ne garantit pas un système rapide si le transfert de données, la planification des tâches ou toute autre étape entraîne un dépassement des délais impartis.

C'est pourquoi l'IA physique doit être évaluée de bout en bout, depuis la réception des données des capteurs jusqu'à l'action physique.

La latence moyenne ne suffit pas et la latence extrême (ou latence de queue, tail latency) et la gigue (instabilité temporelle) sont cruciales, car un seul pic de latence peut déstabiliser une boucle de contrôle. Les tests de performance (benchmarks) des modèles présentent la même limite.

On peut élaborer le meilleur plan possible, mais si le robot manque le créneau temporel pour agir, la qualité de ce plan devient sans importance.

In fine, ce qui compromet généralement le respect des contraintes temporelles, ce n'est pas le modèle lui-même, mais tout ce qui se passe entre les différentes étapes : la mise en file d'attente, la planification, les copies en mémoire et le transfert de données.

Une machine, des charges de travail variées

L'IA physique ne se résume pas à une charge de travail unique. La perception et le raisonnement, axés sur le débit de traitement, sont bien adaptés aux processeurs graphiques (GPU) et aux processeurs neuronaux (NPU).

Le contrôle en temps réel, soumis à des contraintes temporelles strictes, exige une exécution déterministe, un domaine où excellent plutôt les FPGA et les SoC adaptatifs. Les processeurs généralistes (CPU) quant à eux, assurent la coordination globale du système, garantissant la synchronisation de l'ensemble.

Du “corps” au “cerveau” d’un robot, ces différentes charges de travail s'exécutent simultanément, mais elles répondent à des problématiques fondamentalement distinctes qui nécessitent des architectures de calcul adaptées.

Car, faire transiter tous les flux de capteurs et toutes les décisions de contrôle par un processeur unique crée des goulots d'étranglement en termes de bande passante, de consommation énergétique et de latence.Il s'agit là de limites propres au système dans son ensemble.

Concevoir un robot comme un "corps" 

Dans la conception d’un robot il convient d'allouer les ressources de calcul appropriées à chaque charge de travail, au plus près des données et de l'action. En pratique, cela revient à concevoir un robot en s'inspirant du corps humain : un cerveau qui perçoit, raisonne et planifie ; une colonne vertébrale qui assure la transmission des communications critiques en termes de temps à travers tout le système ; des articulations qui exécutent les mouvements de manière déterministe ; des mains capables d'une grande dextérité ; et des capteurs répartis en périphérie.

Le résultat est un système distribué en temps réel, composé de nœuds coordonnés plutôt que d’une unité de traitement unique. A ce niveau, la puissance de calcul maximale est importante, mais elle ne donne qu’une vision partielle des choses.

Les développeurs qui optimisent le système dans son ensemble et associent chaque charge de travail au moteur de calcul approprié concevront des robots capables de fonctionner de manière fiable là où cela compte vraiment.

La puissance de calcul maximale peut permettre de réaliser une démonstration impressionnante ; c’est toutefois la performance au niveau du système qui transforme cette démonstration en un véritable produit.

(*) Cette tribune est une adaptation en français d’un blog publié sur le site d’AMD, consultable dans son entièreté ici.