💻 computer science

How Fast Can I Run My VLA? Demystifying VLA Inference Performance with VLA-Perf

Ce papier présente VLA-Perf, un modèle analytique permettant d'analyser les performances d'inférence des modèles Vision-Language-Action (VLA) afin d'éclairer leur conception et leur déploiement pour répondre aux contraintes temps réel de l'IA incarnée.

Auteurs originaux : Wenqi Jiang, Jason Clemons, Karu Sankaralingam, Christos Kozyrakis

Publié 2026-02-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Wenqi Jiang, Jason Clemons, Karu Sankaralingam, Christos Kozyrakis

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'enseigner à un robot comment faire du vélo. Pour que le robot ne tombe pas, il doit voir le chemin, comprendre les règles (comme "ne pas rouler sur les piétons"), et bouger ses jambes immédiatement. C'est ce qu'on appelle un modèle VLA (Vision-Language-Action).

Le problème ? Ces modèles sont comme des cerveaux de super-héros : ils sont intelligents, mais ils sont lents à réfléchir. Si le robot réfléchit trop longtemps, il se cogne contre un mur.

Les auteurs de cet article (de NVIDIA) se sont posé une question simple : « À quelle vitesse pouvons-nous faire tourner ces cerveaux de robots pour qu'ils ne trébuchent pas ? »

Pour répondre, ils ont créé un outil de simulation appelé VLA-Perf. Imaginez que c'est un simulateur de vol pour les robots. Au lieu de construire 100 robots réels pour tester 100 configurations différentes (ce qui coûterait une fortune), ce simulateur permet de prédire la vitesse de n'importe quelle combinaison de cerveau et de matériel.

Voici les 15 leçons principales, expliquées avec des analogies simples :

1. Le Matériel fait toute la différence (Le moteur)

Le constat : Un robot avec un petit ordinateur intégré (comme un téléphone puissant) est lent. Un robot connecté à un super-ordinateur dans un centre de données est rapide.
L'analogie : C'est comme comparer une voiture de ville (le robot seul) à un F1 (le robot connecté au cloud). La voiture de ville peut rouler, mais elle ne fera jamais 300 km/h. Pour des tâches rapides, il faut souvent un "moteur" externe puissant.

2. Plus le cerveau est gros, plus il est lent

Le constat : Si vous doublez la taille du modèle (le nombre de neurones), le temps de réflexion double aussi.
L'analogie : C'est comme demander à un élève de primaire de résoudre un problème de mathématiques. Si vous lui donnez un problème de niveau doctorat, il mettra beaucoup plus de temps. Pour aller vite, il faut parfois accepter un cerveau un peu plus "petit" mais plus rapide.

3. Se souvenir du passé coûte cher (Le contexte long)

Le constat : Si le robot essaie de se souvenir de tout ce qu'il a vu depuis 1 heure, il devient très lent.
L'analogie : Imaginez un serveur dans un restaurant. S'il doit se souvenir de la commande de chaque client depuis le début de la journée, il va oublier la commande du client actuel. Pour aller vite, le robot doit se concentrer sur l'instant présent ou un passé très récent.

4. La méthode de prédiction compte (Diffusion vs Autoregressif)

Le constat : Certains modèles construisent l'action pas à pas (comme écrire un mot lettre par lettre), d'autres le font d'un coup (comme un peintre qui voit l'image finale).
L'analogie :
- Méthode lente : Écrire un roman lettre par lettre.
- Méthode rapide (Diffusion) : Comme un sculpteur qui commence avec un bloc de pierre et enlève tout ce qui ne va pas jusqu'à ce que la statue apparaisse. C'est souvent beaucoup plus rapide pour les robots.

5. La taille du "paquet" d'actions

Le constat : Demander au robot de prédire 50 mouvements à l'avance (un gros paquet) ne le ralentit presque pas.
L'analogie : C'est comme commander un repas. Commander 1 plat prend le même temps que commander 50 plats au serveur. Une fois que le serveur (le robot) a commencé à réfléchir, il peut préparer tout le menu d'un coup sans perdre de temps.

6. Où placer le cerveau ? (Sur le robot ou dans le cloud ?)

Le constat : Faire tourner le cerveau sur le robot est rapide si le réseau est mauvais. Faire tourner le cerveau dans le cloud est rapide si le réseau est excellent.
L'analogie :
- Sur le robot : C'est comme cuisiner dans votre propre cuisine. C'est rapide, mais vous avez peu d'ustensiles.
- Dans le cloud : C'est comme envoyer votre commande à un chef étoilé. Si le livreur (internet) est rapide, vous avez un plat incroyable en 2 secondes. Si le livreur est bloqué dans les embouteillages (4G lent), vous attendez 10 minutes et votre plat est froid.

7. Le travail d'équipe (Collaboration Robot-Serveur)

Le constat : Diviser le travail (le cerveau sur le serveur, les muscles sur le robot) semble logique, mais c'est souvent plus lent.
L'analogie : C'est comme essayer de faire un puzzle à deux, mais l'un a les pièces et l'autre a l'image. Vous devez constamment passer les pièces par la fenêtre. Souvent, c'est plus simple que l'un des deux fasse tout le puzzle lui-même.

8. La magie de l'asynchronisme (Faire deux choses en même temps)

Le constat : Laisser le robot bouger pendant que le cerveau réfléchit à la prochaine étape aide énormément.
L'analogie : C'est comme un chef cuisinier. Pendant qu'il coupe les légumes (action), il peut déjà penser au plat suivant (réflexion). Il ne s'arrête pas de couper pour attendre d'avoir fini de penser. Cela permet de doubler ou tripler la vitesse.

9. Le "Système 1" et le "Système 2"

Le constat : Utiliser un petit cerveau rapide pour les réflexes immédiats et un gros cerveau lent pour la stratégie.
L'analogie : C'est comme conduire une voiture. Votre main sur le volant (Système 1) réagit instantanément si un chat traverse. Votre cerveau (Système 2) réfléchit lentement à l'itinéraire pour aller au travail. Mélanger les deux permet d'être à la fois réactif et intelligent.

10. Les objectifs de vitesse (10 Hz vs 100 Hz)

Le constat :
- 10 Hz (10 fois par seconde) : C'est le minimum vital. La plupart des robots modernes peuvent y arriver, même avec des petits ordinateurs.
- 100 Hz (100 fois par seconde) : C'est le niveau "super-héros". Pour y arriver, il faut soit des ordinateurs très puissants, soit des réseaux ultra-rapides (comme la 5G ou la fibre), soit des modèles simplifiés.

En résumé

Pour qu'un robot soit agile et ne trébuche pas, il ne suffit pas de lui donner un cerveau génial. Il faut trouver le bon équilibre entre :

La taille du cerveau (pas trop gros).
Le matériel (puissant).
La connexion (rapide).
La méthode (réfléchir en parallèle de l'action).

Les auteurs disent : « Ne devinez pas. Utilisez notre simulateur pour trouver la combinaison parfaite avant de construire le robot. » C'est comme vérifier la météo avant de partir en pique-nique : cela évite de se faire tremper !

Titre : Comment puis-je exécuter mon VLA rapidement ? Démystifier les performances d'inférence des VLA avec VLA-Perf

Auteurs : Wenqi Jiang, Jason Clemons, Karu Sankaralingam, Christos Kozyrakis (NVIDIA Research).

1. Problématique

Les modèles Vision-Language-Action (VLA) ont démontré des capacités impressionnantes pour les tâches d'IA incarnée (robots physiques). Cependant, leur déploiement sur des robots réels impose des contraintes d'inférence en temps réel strictes (généralement entre 10 Hz et 100 Hz pour suivre les taux d'ingestion vidéo).

Le paysage des performances d'inférence des VLA reste mal compris en raison de l'immense espace combinatoire des variables impliquées :

Architecture du modèle : Taille, choix de l'architecture (autoregressive vs diffusion), contexte long, nombre d'étapes de débruitage, taille des blocs d'actions (action chunking).
Système d'inférence : Capacité matérielle (GPU embarqué, serveur de bord, cloud), lieu d'exécution (on-device, edge, cloud), et performances du réseau (latence, bande passante).

L'absence d'une analyse systématique rend difficile la conception de futurs modèles et systèmes capables de garantir une inférence en temps réel.

2. Méthodologie : VLA-Perf

Pour répondre à cette lacune, les auteurs proposent VLA-Perf, un modèle de performance analytique basé sur le modèle Roofline.

Approche : Au lieu d'évaluer empiriquement chaque combinaison possible (ce qui serait prohibitif en temps et en coût), VLA-Perf prédit la latence et le débit optimaux pour n'importe quelle combinaison de modèle et de système.
Fonctionnement :
- Le modèle décompose l'inférence VLA en composants (encodeur de vision, backbone VLM, expert d'action) et en transferts de données (locaux ou réseau).
- Il calcule la latence totale ( $T_{total}$ ) comme la somme des latences d'inférence des composants et des latences de mouvement des données.
- Pour chaque opérateur, la latence est estimée par le modèle Roofline : $T = \max(\frac{FLOPS}{FLOPS/s}, \frac{Bytes}{MemBW})$ , tenant compte des limites de calcul et de bande passante mémoire du matériel.
- Le modèle prend en compte les configurations asynchrones, les pipelines à double système, et les contextes longs.
Validation : Le modèle a été validé contre des implémentations réelles (Triton sur RTX 4090) avec une fidélité de 73 % à 82 %, suffisante pour fournir des orientations de conception fiables.

3. Contributions Clés et Résultats (15 enseignements)

L'étude systématique menée avec VLA-Perf a permis de dégager 15 enseignements majeurs, regroupés ici par thématique :

A. Conception des Modèles et Échelle

Échelle des modèles : La latence d'inférence augmente de manière linéaire avec la taille du modèle. Les GPU de centre de données (ex: B100) peuvent supporter des modèles VLA plus de 30 fois plus grands que les modèles actuels tout en maintenant une inférence temps réel (>10 Hz), tandis que les GPU embarqués (Jetson Thor) peinent déjà avec les modèles actuels.
Contexte Long : Les GPU de centre de données peuvent gérer des contextes longs (jusqu'à 1000 timesteps) en temps réel, mais les GPU embarqués et grand public sont limités à environ 100 étapes.
Architecture (Diffusion vs Autoregressive) : Avec le chunking d'actions, l'inférence basée sur la diffusion est 1 à 2 ordres de grandeur plus rapide que l'approche autoregressive classique. L'approche autoregressive n'est compétitive que pour un très petit nombre de dimensions d'action ou avec un décodage parallèle.
Paramètres d'inférence : Le nombre d'étapes de débruitage a un impact linéaire et significatif sur la latence. En revanche, la taille du bloc d'actions (action chunk size) a un impact négligeable car l'inférence de l'expert d'action est limitée par la mémoire (memory-bound), pas par le calcul.

B. Déploiement et Architecture Système

Emplacement (On-Device vs Server) : L'inférence côté serveur (même avec des GPU grand public comme RTX 4090) surpasse largement l'inférence embarquée (Jetson Thor) dans la plupart des scénarios, sauf lorsque les conditions réseau sont extrêmement médiocres (ex: 4G lent ou cloud distant).
Collaboration Device-Server : Diviser la charge (VLM sur serveur, expert d'action sur robot) est généralement plus lent que l'inférence purement embarquée ou purement serveur, en raison de la latence de téléchargement du cache KV. Cette approche n'est avantageuse que sur des réseaux filaires très rapides.
Inférence Asynchrone : Pour l'inférence côté serveur, l'asynchronisme (recouvrement de l'inférence et de l'exécution du robot) peut améliorer le débit de 2,6x à 13,8x sur des réseaux sans fil lents (5G/4G), bien qu'il n'améliore pas la latence de bout en bout.
Pipelines à Double Système : L'utilisation d'un système rapide (System 1) et d'un système lent (System 2) peut améliorer les performances, mais le gain dépend fortement de la latence réseau. Sur des réseaux lents, le gain est minime car la latence de réseau domine le temps de cycle.

C. Objectifs de Performance (10 Hz vs 100 Hz)

Objectif 10 Hz : Atteignable sur des GPU embarqués avancés (Jetson Thor) pour des modèles standards, et sur des serveurs edge avec des GPU grand public même via des réseaux sans fil.
Objectif 100 Hz :
- Embarqué : Nécessite des optimisations au niveau du modèle (réduction de taille, quantification, moins d'étapes de débruitage).
- Edge/Cloud : Nécessite des GPU de centre de données (B100) et des réseaux rapides (Ethernet 10G ou WiFi 7).
- Cloud : L'inférence synchrone ne peut pas atteindre 100 Hz à cause de la latence réseau ; l'inférence asynchrone est indispensable pour atteindre des débits élevés (>300 Hz) en cloud.

4. Signification et Impact

Cet article constitue la première étude systématique du paysage des performances d'inférence VLA. Ses implications sont majeures pour la communauté de l'IA incarnée :

Guide de Conception : Il fournit des directives concrètes pour les ingénieurs : privilégier les architectures basées sur la diffusion, optimiser les étapes de débruitage, et comprendre que l'augmentation de la taille du modèle est possible mais coûteuse en latence.
Stratégie de Déploiement : Il démontre que le « edge computing » pur n'est pas toujours la solution optimale. Pour les robots mobiles, le déploiement sur des serveurs de bord (edge servers) avec des GPU puissants et une bonne connectivité est souvent supérieur aux solutions purement embarquées.
Outil de Modélisation : La mise à disposition de VLA-Perf (open source) permet aux chercheurs de simuler et d'optimiser leurs architectures VLA et leurs systèmes d'inférence sans avoir à déployer physiquement chaque combinaison, accélérant ainsi le cycle de développement.

En résumé, l'article établit que l'atteinte d'une inférence VLA en temps réel (surtout à haute fréquence >100 Hz) est un problème systémique qui ne peut être résolu uniquement par l'optimisation du modèle, mais nécessite une co-conception rigoureuse du modèle, du matériel et de l'architecture réseau.