Physical Intelligence ouvre un service bêta aux équipes qui souhaitent adapter ses modèles robotiques à leurs propres machines et tâches. L’annonce de Pi API, publiée le 13 octobre, indique qu’une équipe peut charger des données de robot, affiner un modèle sur l’infrastructure gérée par Pi et appeler le modèle obtenu par inférence hébergée. L’accès commence par une candidature et Pi indique intégrer les équipes par vagues.

Cela déplace une partie du travail d’ingénierie des modèles. Un développeur en robotique a toujours besoin d’une machine adaptée, d’une tâche qui mérite d’être automatisée, de démonstrations de cette tâche et d’un moyen de tester le modèle sur la machine. Pi propose d’exploiter la couche d’entraînement et de service du modèle qui relie ces éléments.

Le grand changement

  • Ce qui change : Pi propose à certaines équipes une adaptation hébergée de ses modèles robotiques. Son dépôt openpi public fournit déjà d’anciens points de contrôle et des exemples aux équipes prêtes à gérer leur propre pile d’entraînement ; la bêta ajoute une voie gérée pour l’affinage et l’inférence.
  • Pourquoi c’est important : Le transfert de l’infrastructure d’entraînement à Pi pourrait permettre à une équipe de robotique de consacrer plus d’efforts à collecter des démonstrations utiles et à évaluer le comportement sur son propre matériel. Le service ne fournit pas le robot, ne définit pas une tâche réussie et ne prouve pas que le client peut opérer en toute sécurité.
  • À surveiller : La valeur de la bêta dépendra de résultats reproductibles et de modalités d’intégration praticables. Pi a présenté des exemples de partenaires, mais les informations publiques de lancement ne précisent ni la version du modèle, ni le matériel pris en charge, ni les tarifs, le contrat d’API ou les conditions de sécurité.

Le travail confié à Pi

Pi décrit la séquence suivante : charger les données, lancer l’affinage sur ses ressources de calcul gérées, puis utiliser une passerelle hébergée pour l’inférence. Dans sa description du flux de travail, les données d’évaluation guident l’itération suivante. Le développeur recueille des démonstrations, entraîne le modèle, le teste sur un robot et étudie les échecs afin de décider quelles données collecter ensuite. L’API doit permettre au développeur de mener seul ce cycle tandis que Pi exploite l’infrastructure du modèle.

La base de code openpi de l’entreprise montre l’ancienne voie en autonomie. Elle comprend les points de contrôle π₀, π₀-FAST et π₀.₅ ainsi que des exemples de conversion d’un jeu de données, de configuration de l’affinage et de service d’une politique. Les besoins en GPU et les étapes de préparation des données expliquent pourquoi l’entraînement géré peut attirer une équipe experte en robotique mais disposant de peu d’infrastructure d’apprentissage automatique. L’annonce n’identifie pas la version du modèle bêta : les modèles ouverts ne doivent donc pas être confondus avec celui que l’API sert précisément.

Pi affirme que son dernier modèle d’API est plus performant et permet aux partenaires un affinage plus efficace en données. La publication de lancement ne fournit ni jeu de données comparatif, ni protocole de référence, ni taux de réussite des tâches pour quantifier cette affirmation. Elle indique aussi que la plupart des applications présentées utilisaient une inférence hébergée dans le cloud et que certaines ont rencontré des problèmes de réseau. Ce point compte pour une machine mobile dont la boucle de commande dépend d’un service distant, même si la publication ne précise aucun besoin de latence ou de fiabilité.

Ce qu’une équipe doit apporter

La candidature à la bêta demande qui, dans l’équipe, entraînerait la politique, quelle expérience existe avec les données robotiques et l’évaluation des politiques, quelle tâche précise est visée et quelle quantité de données de téléopération ou de simulation est disponible. Elle demande aussi le nombre et le type de robots, le lieu d’inférence souhaité et les critères de réussite. Ce sont des questions de candidature, pas des seuils d’admissibilité publiés ni une garantie d’inférence locale. Le formulaire propose cloud, local, les deux ou incertain ; le lancement décrit une inférence hébergée.

Ces questions révèlent ce que le service ne peut pas automatiser pour le client : définir le bon comportement sur un robot donné et le mesurer sur ce robot. Pi décrit des partenaires précoces qui répètent les démonstrations, les tests et les échecs. Ses exemples comprennent l’Axol d’Almond, un robot à deux bras montré en train d’ébavurer des entretoises utilisées dans un assemblage après quatre jours d’itérations avec l’API. Pi décrit aussi un chargeur sur roues Actor qui ramasse et charge du matériau lors d’un déploiement commercial. Ce sont des récits et des vidéos sélectionnés par Pi, pas des mesures indépendantes de fiabilité générale, de sécurité ou de performance sur différents matériels.

La voie publique actuelle consiste à demander l’accès à la bêta. Dans les documents examinés ici, Pi n’a publié ni contrat d’API ouvert, ni schéma des requêtes et réponses, ni nom du modèle bêta, ni matrice de compatibilité matérielle, ni tarifs, conditions de traitement des données ou accord de sécurité. Une équipe devrait obtenir ces conditions et effectuer ses propres essais répétés sur robot avant de juger si l’inférence hébergée convient à une vraie exploitation.

Articles connexes

BIG CHANGE avait déjà examiné la politique robotique de Runway entraînée sur vidéo et usine japonaise de données pour humanoïdes. Ces articles portent sur des travaux connexes de modèles et de données. L’annonce de Pi du 13 octobre est un événement distinct d’ouverture d’un service.

Sources et lectures complémentaires