Calculateur de VRAM embarquée et de matériel edge pour VLA & robotique

Comment estimer la mémoire et la bande passante d'un VLA embarqué

Contrairement aux LLM purement textuels, un modèle VLA embarqué sur un robot traite à chaque inférence les tokens visuels de plusieurs caméras et produit des commandes articulaires continues (chunks d'actions). La mémoire augmente donc non seulement avec les poids, mais aussi avec le nombre de caméras, la résolution et la longueur de l'historique, et la vitesse d'inférence est généralement limitée par la bande passante mémoire.

1. Formules

Le calculateur suppose un contrôle robotique en temps réel avec une taille de lot de 1 et utilise les équations suivantes.

Bytes_per_Param vaut 2,0 en FP16, 1,0 en FP8, environ 1,05 en W8A16, environ 0,62 en W4A16 avec tête d'action FP16 et environ 0,56 en NVFP4 (un facteur d'échelle FP8 pour 16 valeurs). Le tampon KV/activations est une estimation empirique proportionnelle au nombre de tokens visuels et à la taille du modèle.

2. Pourquoi la bande passante mémoire fixe la fréquence d'inférence

Avec une taille de lot de 1, l'inférence bute souvent sur la bande passante mémoire avant la puissance de calcul, car chaque inférence doit relire l'ensemble des poids depuis la DRAM. La fréquence d'inférence maximale d'un appareil s'estime donc par bande passante × taux d'utilisation ÷ mémoire lue par inférence, et la quantification des poids améliore à la fois la capacité mémoire et ce plafond de vitesse.

3. Chunks d'actions et double boucle de contrôle

Les modèles qui utilisent des chunks d'actions produisent plusieurs pas d'actions par inférence, que le contrôleur exécute à une fréquence plus élevée. Par exemple, à 30 Hz de contrôle avec 10 pas exécutés par chunk, le modèle n'a besoin de tourner qu'à 3 Hz. Les humanoïdes qui exigent un contrôle du corps entier à plusieurs centaines de hertz utilisent généralement une double boucle : le VLA produit des objectifs à basse fréquence, une petite politique envoie les commandes articulaires à haute fréquence. Prévoyez aussi une réserve système pour les files ROS 2 et les tampons caméra (ce calculateur suppose 3 Go) afin que le robot ne s'arrête pas faute de mémoire.

4. Caractéristiques des calculateurs edge et configurations suggérées

La plupart des calculateurs embarqués de robots utilisent une mémoire unifiée partagée entre CPU et GPU (LPDDR). La mémoire, la bande passante et la consommation proviennent des pages produit officielles de NVIDIA ; les configurations suggérées sont des repères fondés sur les réglages par défaut de ce calculateur.

5. Notes de dimensionnement par modèle

• Octo-Base (93M) et SmolVLA base (0.5B) : les poids pèsent environ 1 Go ou moins même en FP16. Ils tiennent sur une carte de 8 Go avec les réglages caméra par défaut et laissent une large marge de bande passante pour des fréquences de contrôle élevées.
• Isaac GR00T N1.7 (3B) et π0 (3.3B) : les poids FP16 représentent environ 6 à 7 Go. Le dépôt officiel de GR00T indique un GPU de la classe 16 Go pour l'inférence ; sur une carte de 16 Go, envisagez la quantification W4A16 avec les chunks d'actions.
• OpenVLA-7B : selon le dépôt officiel, l'inférence en bf16 demande environ 15 Go, ce qui ne tient pas sur une carte de 16 Go une fois le cache KV et la réserve ajoutés. Passez en W4A16 ou utilisez un AGX Orin 64GB ou plus. Comme le modèle produit ses actions sous forme de tokens, gardez un nombre d'actions par chunk proche de 1.
• Classe 14B à 32B : les poids FP16 occupent à eux seuls 28 à 64 Go. Un modèle de classe 32B en FP16 nécessite 128 Go (Jetson T5000) ; en W4A16, des cartes de 64 Go deviennent envisageables.
• Personnalisé : pour un modèle absent de la liste, saisissez son nombre de paramètres en incluant l'encodeur visuel et la tête d'action, afin de ne pas sous-estimer la mémoire.

6. Questions fréquentes