AWS présente pour Strands Robots une boucle de données en streaming qui relie l’enregistrement de démonstrations de robots, l’entraînement de politiques et leur déploiement. L’objectif est de conserver des données directement utilisables à chaque étape, sans imposer une conversion distincte entre l’enregistrement et l’entraînement.
Le fonctionnement est décrit dans un article publié par Hugging Face le 13 août 2026. Il s’adresse surtout aux équipes qui doivent faire circuler des volumes importants de données entre plusieurs étapes d’un même parcours.
Le format LeRobot sert de point de liaison
Strands Robots est présenté comme un SDK AWS open source distribué sous licence Apache 2.0. Son enregistreur stocke chaque exécution sous la forme d’un jeu de données au format LeRobot. Les outils compatibles peuvent donc lire directement le résultat, sans dépendre d’un format conçu pour une seule chaîne d’enregistrement.
AWS indique que LeRobot est déjà utilisé par plus de 90 000 jeux de données et modèles sur le Hub, provenant de plus de 8 000 éditeurs. Ce choix donne au SDK une compatibilité plus large avec l’écosystème existant, tout en évitant d’ajouter une étape de transformation propre à Strands Robots.
Les données de travail restent modifiables
La couche de stockage repose sur Hugging Face Storage Buckets, décrits comme des stockages d’objets mutables et non versionnés, soutenus par Xet. Les buckets partagent l’espace de noms hf:// avec les dépôts de jeux de données et sont accessibles depuis l’interface de ligne de commande hf.
La fonction sync_dataset_to_bucket écrit une exécution dans hf://buckets/{bucket}/{run_id}. Si aucun identifiant d’exécution n’est fourni, elle utilise par défaut le nom du répertoire du jeu de données. Le bucket devient ainsi l’espace des exécutions en cours, tandis que les données préparées pour publication suivent un autre parcours.
Pour publier ces données, push_to_hub() les envoie vers un dépôt de jeu de données versionné. La distinction est concrète : les expériences peuvent continuer à évoluer dans un stockage mutable, alors que la version destinée au partage dispose d’un historique séparé.
Xet limite les transferts répétés
Xet réduit les transferts inutiles grâce à la déduplication au niveau des octets et au découpage en blocs dépendant du contenu. Hugging Face rapporte que cette approche a réduit d’environ quatre fois le volume de données transférées lors de ses mesures sur le Hub.
Dans le benchmark cité, la modification de 1 %, 5 % ou 10 % d’un fichier original de 500 Mo a entraîné le transfert de 5,5 Mo, 27,5 Mo ou 55 Mo, respectivement. Avec les offres Enterprise, la facturation repose sur l’empreinte dédupliquée. Ces chiffres décrivent le comportement mesuré dans ce benchmark : ils ne constituent pas une estimation générale du volume transféré pour chaque projet robotique.
Le streaming réduit les données conservées en local
L’enregistreur divise les données en fragments Parquet et crée des fragments MP4 pour chaque caméra. Les seuils par défaut sont fixés à 100 Mo pour les données et à 200 Mo pour la vidéo.
La fonction stream_dataset expose ensuite un StreamingLeRobotDataset. Celui-ci décode les vidéos MP4 distantes à la demande et lit les données d’état et d’action dans les fragments Parquet. En local, le processus ne conserve que le petit répertoire meta/, qui contient le schéma, les statistiques et l’index des épisodes.
Ce fonctionnement n’est pas seulement une option de confort pour le mode bucket de l’entraîneur. Sa configuration attend dataset.streaming=true et refuse le mode bucket lorsque le streaming est désactivé. Le stockage et la lecture à distance deviennent donc une composante du parcours d’entraînement.
La simulation valide le parcours, pas la politique
Dans le parcours de simulation par défaut, la politique fictive produit un jeu de données structurellement valide, mais pas des données d’entraînement utiles. Une exécution minimale peut montrer que l’enregistrement, le stockage et le transfert vers l’entraînement fonctionnent ensemble. Elle ne permet pas de conclure qu’une politique robotique apprise sera performante.
Cette simulation minimale nécessite Python 3.12 ou une version ultérieure sous Linux ou macOS, avec une prise en charge d’Apple Silicon pour le backend MuJoCo. Pour les équipes qui évaluent le SDK, le bénéfice concret tient au chemin de données partagé, à la compatibilité avec LeRobot et à la réduction des téléversements répétés.
La qualité de la politique finale reste une question distincte. Elle dépend toujours des démonstrations disponibles et du processus d’entraînement : Strands Robots relie les étapes techniques, mais ne remplace ni la qualité des données ni l’évaluation du modèle obtenu.