Physical Intelligence saca su API beta para modelos de robots

Physical Intelligence abrió su Pi API beta, que le deja a developers externos entrenar y correr los modelos de robot foundation de la empresa, de la línea π0 y π0.5, sin tener que bancarse la infraestructura de ML. Es el primer paso grande para sacar estos modelos de los propios despliegues de la compañía, y el pitch es directo: subís datos, lanzás el fine-tuning en compute que gestiona Pi, y accedés al modelo fine-tuneado por un gateway hosted.

Cómo funciona la API

El workflow tiene tres partes. Subís tus datos de demostración. Pi corre el fine-tuning en su propio compute e infraestructura. Después la inferencia pasa por un gateway hosted, así que el modelo vive en la nube de Pi, no en tu hardware.

La empresa dice que el último modelo disponible por la API fine-tunea con menos datos y mejora sobre lo que sus partners estaban corriendo, y que planea seguir reemplazando los modelos por versiones nuevas a medida que los saca. Son claims de vendor, todavía no hay números publicados, pero el punto estructural se mantiene: la alternativa a esta API es armar vos mismo el data pipeline, el compute de entrenamiento y el stack de serving.

Quiénes ya la están usando

Pi le dio acceso temprano a un grupo chico de empresas para probar si podían mejorar la autonomía por su cuenta, y el blog muestra los resultados. Actor corre una wheel loader autónoma en un despliegue comercial en Utah, sin operador adentro de la máquina. El robot de doble brazo Axol de Almond le quita rebabas a piezas que se usan en su propio armado, con un modelo al que el equipo llegó después de cuatro días de iteración con la API. Otros nombres de la lista: CloudChef, AgRobotics, Chef Robotics, Formic Robotics, Foundry, Frontier Machines y Ultra.

La mayoría de los despliegues mostrados, desde Japón hasta Suiza hasta sitios en todo EE. UU., corría con inferencia cloud-hosted por la API. La empresa también marca dónde falló: la conectividad de red fue un problema real para algunos.

El loop de iteración sobre el que se armó la API

El post sostiene que los failure modes cambian según la tarea, una prenda que sale del revés, un ingrediente que no se queda en la cuchara, una pieza que aterriza en el lugar equivocado, pero el proceso de mejora es el mismo en todos lados: colectar demostraciones, entrenar, probar en el robot, y dejar que los fallos decidan qué datos colectar después. La API existe para que el developer corra ese loop solo sobre los últimos modelos de Pi, en vez de rearmar el stack cada vez que mejora un modelo.

Qué significa para vos

Si corrés robots, la pregunta práctica es la gravedad de los datos. La inferencia cloud-hosted significa que tus datos de demostración y los pesos del modelo viven en la infraestructura de Pi, y algunos de los partners early ya se tropezaron con límites de conectividad. El beta no es sign-up abierto: le contás a la empresa qué querés armar, y ella decide. Si tu caso de uso necesita que los modelos se queden on site, o en la máquina, este beta todavía no es para vos. Si no, te saca el trozo más grande del stack de self-hosting, y le das una mirada.