Capital de Tokens
Durante años, gran parte de la inteligencia artificial se construyó alrededor de una arquitectura relativamente cómoda:
datos
↓
cloud
↓
modelo
↓
respuestaEse patrón funciona bastante bien cuando una respuesta tarda unos cientos de milisegundos, cuando Internet está disponible y cuando un error termina en una pantalla.
El mundo físico cambia las reglas.
Un brazo robótico, un vehículo autónomo, una máquina industrial o un sistema de inspección no pueden asumir que habrá una conexión perfecta con un datacenter. Tampoco pueden esperar indefinidamente a que un modelo remoto decida qué hacer mientras el entorno continúa moviéndose.
Ahí aparece la Physical AI: sistemas de inteligencia artificial capaces de percibir, decidir y actuar sobre el mundo real.
Un artículo reciente de TechRadar Pro, “How to deploy physical AI effectively”, resume tres requisitos que parecen simples pero cambian por completo la arquitectura:
- latencia muy baja;
- operación offline-first;
- cómputo y almacenamiento eficientes cerca del punto de acción.
La conclusión de fondo es importante:
la Physical AI no es cloud AI metida dentro de un robot.
Necesita otra distribución de responsabilidades entre edge, cloud, simulación, entrenamiento, datos, evaluación y despliegue.
Y uno de los repositorios más interesantes para estudiar cómo empieza a materializarse ese stack es microsoft/physical-ai-toolchain, un proyecto open source que conecta Azure con varias piezas del ecosistema de NVIDIA y herramientas de robótica como ROS 2 y LeRobot.
No es un SDK para mover un servo.
Es algo más ambicioso: un intento de convertir el ciclo completo de aprendizaje de un robot en una plataforma reproducible.
Physical AI son dos loops, no uno
Una buena forma de entender el problema es separar dos ciclos que operan a velocidades completamente distintas.
El primero es el loop de control físico.
sensores
↓
percepción / estado
↓
policy / inferencia
↓
control
↓
actuadores
↓
mundo físico
└──────────────→ nuevos sensoresEse ciclo tiene restricciones duras.
Puede ejecutarse decenas o cientos de veces por segundo. Si la red desaparece, el robot no puede quedarse congelado esperando una API. Si una cámara produce un frame nuevo, el sistema necesita procesarlo dentro de un presupuesto temporal conocido.
Por eso la inferencia que afecta al movimiento suele vivir en el edge, cerca de los sensores y actuadores.
Pero existe un segundo ciclo mucho más lento: el learning loop.
robot
↓ captura experiencias
ROS 2 bags / datasets
↓
curación y validación
↓
entrenamiento
↓
evaluación
↓
registro del modelo
↓
paquetizado
↓
despliegue
↓
robotEse segundo loop sí puede aprovechar GPUs remotas, almacenamiento cloud, simuladores, experiment tracking y sistemas de orquestación.
Esta separación explica por qué una arquitectura seria de Physical AI no puede resumirse como “poner un LLM en un Jetson”.
El problema real es construir la fábrica que produce, valida y distribuye las policies que luego ejecutan localmente.
Eso es precisamente lo que intenta estructurar Microsoft Physical AI Toolchain.
Qué es realmente microsoft/physical-ai-toolchain
El README lo describe como un framework abierto orientado a producción que integra servicios de Microsoft Azure con el stack de Physical AI de NVIDIA.
La arquitectura cubre ocho dominios:
Infrastructure
Data Pipeline
Data Management
Synthetic Data
Training
Evaluation
Fleet Delivery
Fleet IntelligenceLo importante es que el repositorio ya no presenta todos esos componentes como un requisito monolítico.
Microsoft reorganizó el proyecto alrededor de una escalera de adopción T0 → T5.
T0 Dev
│ 1 robot + laptop
│ zero cloud / zero Kubernetes
│
T1 Lab
│ pocos robots + storage compartido
│
T2 Pilot
│ Azure ML / OSMO / registry / MLflow
│ recomendado para producción
│
T3 Production
│ k3s + FluxCD en un sitio
│
T4 Scale
│ varios sitios + Azure Arc + GitOps + gating
│
T5 Operate
fleet intelligence / drift / retraining
roadmapEsta decisión arquitectónica es probablemente una de las mejores ideas del repo.
El proyecto reconoce explícitamente que obligar a un equipo a desplegar Azure Arc, AKS, Flux, IoT Operations y toda la infraestructura cloud antes de conseguir que un robot aprenda una tarea sería una mala experiencia.
En T0 el loop completo puede cerrarse con un robot y una laptop.
Sin Kubernetes.
Sin Azure.
Sin Arc.
Eso permite empezar por el problema de robótica y añadir infraestructura solamente cuando aparece una necesidad real de escala.
T0 demuestra qué piezas son realmente esenciales
El Tier 0 es especialmente educativo porque desnuda el sistema hasta sus componentes mínimos.
El flujo recomendado es aproximadamente:
1. capturar demostraciones con ROS 2
2. copiar los datos al laptop
3. inspeccionar / curar el dataset
4. entrenar una policy LeRobot
5. evaluar localmente
6. ejecutar la policy nuevamente en el robotPara capturar datos, el repo utiliza ROS 2 bags.
Un ejemplo mínimo de la documentación es:
ros2 bag record -o demos/insertion-task /observations /actionsEn configuraciones más reales, el sistema puede registrar topics como:
/joint_states
/camera/color/image_raw
/imu/dataLa configuración de captura permite establecer frecuencia y compresión por topic. La documentación usa, por ejemplo, lz4 para telemetría numérica de alta frecuencia y zstd para imágenes donde interesa una mayor compresión.
Ese detalle importa mucho más de lo que parece.
Un robot puede producir cantidades enormes de información. Cámaras a 30 FPS, articulaciones a 100 Hz, IMUs a 200 Hz y otros sensores empiezan a competir por I/O, almacenamiento y ancho de banda mucho antes de hablar de entrenamiento.
Physical AI empieza siendo también ingeniería de datos en tiempo real.
Del ROS bag al dataset que entiende el modelo
Capturar datos no significa que ya podamos entrenar.
El repo utiliza LeRobot, el proyecto de Hugging Face para aprendizaje robótico, como una de sus representaciones principales para imitation learning.
La arquitectura de almacenamiento distingue entre los datos crudos y los datasets convertidos.
Conceptualmente:
ROS 2 / MCAP
↓
conversión
↓
LeRobot dataset
├── meta/info.json
├── meta/stats.json
├── data/*.parquet
└── videos/*.mp4En el diseño de Azure Storage, los bags originales viven bajo rutas como:
datasets/raw/{device-id}/{date}/episode.mcapy las versiones procesadas pasan a algo parecido a:
datasets/converted/{dataset-id}/Esto introduce una propiedad fundamental para sistemas físicos: el modelo debe poder rastrearse hasta los datos que lo produjeron.
Si una policy nueva empieza a comportarse mal, necesitamos saber:
- qué episodios entraron en el dataset;
- con qué versión fueron convertidos;
- qué estadísticas de normalización se utilizaron;
- qué código entrenó el modelo;
- qué checkpoint terminó desplegado.
En un chatbot, una regresión puede producir una respuesta peor.
En un robot, una regresión puede producir movimiento físico.
La trazabilidad deja de ser comodidad y se convierte en una parte de la safety story.
Tres familias de entrenamiento: RL, IL y VLA
El dominio training/ del repo separa tres enfoques:
training/
├── rl/ reinforcement learning
├── il/ imitation learning
└── vla/ vision-language-actionReinforcement Learning
La ruta de RL se apoya principalmente en NVIDIA Isaac Lab.
Aquí el robot aprende políticas mediante interacción con entornos simulados y funciones de recompensa. En vez de recopilar únicamente demostraciones humanas, podemos ejecutar miles o millones de episodios en simulación.
Imitation Learning
La ruta de IL utiliza LeRobot y datasets de demostraciones.
La idea es directa:
humano ejecuta tarea
↓
robot observa estado + acción
↓
dataset
↓
policy aprende a imitarEl repositorio incluye pipelines para entrenar policies como ACT — Action Chunking with Transformers.
Vision-Language-Action
La tercera ruta es VLA: modelos que conectan percepción visual, instrucciones lingüísticas y acciones robóticas.
Los workflows del proyecto incluyen soporte para fine-tuning de modelos NVIDIA GR00T además de los pipelines tradicionales de Isaac Lab y LeRobot.
Esto muestra hacia dónde se mueve la industria.
No queremos únicamente un modelo que aprenda una trayectoria concreta.
Queremos robots capaces de recibir una intención más general y convertirla en secuencias de acciones.
OSMO convierte el entrenamiento en un workload distribuido
Cuando una laptop deja de ser suficiente aparece NVIDIA OSMO.
OSMO funciona como capa de orquestación de workloads de simulación y entrenamiento. El repo incluye templates para lanzar trabajos como:
train.yaml → Isaac Lab RL
lerobot-train.yaml → LeRobot imitation learning
groot-train.yaml → GR00T VLA fine-tuningEn T2, Azure ML y OSMO permiten mover el trabajo hacia clusters GPU, ejecutar entrenamiento distribuido, guardar checkpoints y conectar las corridas con MLflow.
Aquí aparece otra diferencia importante respecto a una aplicación de IA convencional.
Un training job de robótica no produce simplemente un archivo final.
Produce una cadena de artefactos:
dataset versionado
↓
configuración
↓
run / experiment
↓
checkpoints
↓
métricas
↓
modelo registradoEl repositorio incluso exige que los Azure ML data assets se referencien mediante versiones explícitas —por ejemplo azureml:nombre:3— y rechaza shortcuts como @latest para preservar reproducibilidad.
Es una decisión pequeña con una filosofía correcta:
un robot no debería cambiar de comportamiento porque “latest” significaba otra cosa esta mañana.
Simulación: fabricar experiencias antes de arriesgar hardware
Una de las piezas más poderosas de Physical AI es que gran parte del aprendizaje puede ocurrir antes de tocar el mundo real.
El toolchain integra Isaac Sim / Isaac Lab y además tiene un dominio específico para synthetic data basado en NVIDIA Cosmos.
La pipeline descrita por Microsoft encadena tres capacidades:
simulación
↓
Cosmos Transfer 2.5
↓ fotorealismo
Cosmos Predict 2.5
↓ futuros plausibles
Cosmos Reason 2
↓ evaluación / curación
training dataLa idea de fondo es resolver uno de los mayores problemas de robótica: conseguir suficientes experiencias representativas.
En el mundo real, recopilar una nueva situación puede exigir horas de operación, personal, hardware y riesgo físico.
En simulación podemos variar:
- iluminación;
- posición de objetos;
- texturas;
- cámaras;
- fricción;
- geometrías;
- fallos;
- escenarios raros.
El objetivo no es que la simulación sea perfectamente idéntica al mundo.
Es generar suficiente diversidad para que la policy aprenda invariantes útiles y luego medir cuánto de ese comportamiento sobrevive al salto sim-to-real.
La evaluación es una fase independiente, no un if loss < x
Entrenar no significa que una policy sea segura para controlar hardware.
El repo separa explícitamente el dominio de evaluation y contempla varias superficies:
Local evaluation
Software-in-the-Loop (SiL)
Hardware-in-the-Loop (HiL)
OSMO-managed evaluationLa documentación de LeRobot muestra un ejemplo particularmente concreto: una policy ACT controlando un UR10E mediante ROS 2.
El nodo de inferencia consume:
/joint_states
/camera/color/image_rawy puede publicar comandos sobre:
/lerobot/joint_commandsEl loop tiene un valor de referencia de 30 Hz.
Pero el parámetro más importante probablemente sea otro:
enable_control=falseLa documentación recomienda ejecutar primero la policy sin enviar comandos al robot y observar sus predicciones en /lerobot/status. Solo después se activa el control real.
Esa separación entre inferir y actuar es una idea que debería aparecer en cualquier sistema agentic que toque el mundo físico.
Antes de permitir acción irreversible:
observe
→ predict
→ evaluate
→ authorize
→ actNo:
model says yes
→ motor movesONNX y TensorRT: el modelo entrenado todavía no es el producto
Una vez validada la policy, el siguiente problema es ejecutarla con suficiente eficiencia en el edge.
El toolchain contempla exportar y empaquetar modelos en formatos como ONNX y TensorRT.
Ese paso es crítico porque entrenamiento e inferencia viven bajo restricciones distintas.
En training queremos flexibilidad:
PyTorch
GPUs grandes
batching
instrumentación
checkpointsEn el robot queremos algo más parecido a:
latencia predecible
memoria limitada
consumo controlado
runtime estable
aceleración de hardwarePor eso el flujo completo es realmente:
modelo de investigación
↓
modelo evaluado
↓
modelo optimizado
↓
artifact versionado
↓
container / runtime edgeEl edge no debería recibir el checkpoint simplemente porque fue el último que terminó de entrenar.
Debe recibir un artefacto promovido después de evaluación.
GitOps para robots: el despliegue también necesita rollback
Cuando tenemos un robot, actualizar una policy manualmente puede ser aceptable.
Cuando tenemos veinte, cien o robots distribuidos en varias plantas, aparece otro problema: version skew.
¿Qué robot ejecuta qué policy?
¿Qué versión debería ejecutar?
¿Cómo hacemos rollback?
En T3 y T4 Microsoft introduce FluxCD y un modelo GitOps.
Git
↓ desired state
FluxCD
↓ reconcile
sitio / cluster
↓
robot runtimeGit se convierte en fuente declarativa de la versión deseada.
Un rollback deja de ser “entrar por SSH al robot y recordar qué comando corrimos”.
Puede convertirse en revertir el estado declarado.
Pero el repo añade una precisión muy importante: antes de que una policy se cambie sobre hardware físico debe existir un deployment gate.
Esto distingue dos conceptos que a menudo se mezclan:
fleet delivery no es lo mismo que fleet intelligence.
T4 resuelve principalmente entrega, conectividad, identidad y gating en múltiples sitios.
T5 —todavía roadmap— pretende añadir drift detection, retraining y analítica agregada de la flota.
La distinción es saludable.
Distribuir software a cien robots ya es un problema difícil.
Cerrar automáticamente el loop telemetría → drift → retraining → deploy es otro problema todavía más peligroso.
La propia documentación del Tier Model advierte contra el retraining completamente autónomo con datos de producción: una distribución degradada podría terminar reforzando precisamente el comportamiento que queremos corregir.
Los agentes aparecen arriba del pipeline, no dentro del control loop
Aquí el repositorio conecta Physical AI con otra tendencia: agentic engineering.
El README deja claro que los agentes son opcionales. Las etapas pueden ejecutarse manualmente mediante CLI y APIs.
Eso es importante.
La IA agéntica se coloca como una capa de orquestación sobre sistemas determinísticos existentes:
instrucción humana
↓
agente
↓
selecciona pipeline
↓
CLI / APIs / workflows
↓
OSMO / Azure ML / storage / evaluationNo debería reemplazar los mecanismos verificables debajo.
El repo contiene agentes de Copilot específicos. Uno de los más interesantes es OSMO Training Manager, diseñado para manejar conversaciones multi-turn alrededor de jobs de imitation learning.
Puede:
- validar prerequisitos;
- preparar una corrida;
- pedir confirmación antes de lanzar workloads GPU;
- enviar el job a OSMO;
- seguir logs;
- analizar loss y checkpoints;
- consultar métricas en Azure ML / MLflow;
- ejecutar evaluación posterior.
Su configuración incluye defaults explícitos para ACT, training steps, batch size, learning rate y frecuencia de checkpoints.
Esto ilustra una arquitectura que probablemente veremos mucho más:
agente probabilístico
↓
controla herramientas determinísticas
↓
workflows reproducibles
↓
artifacts versionados
↓
gates verificablesEl agente reduce complejidad operacional.
Pero el pipeline sigue existiendo aunque quitemos al agente.
Ese diseño es mucho más robusto que construir todo el sistema como una conversación gigante con un LLM.
Edge-first no significa cloudless
Volvamos al artículo de TechRadar.
Puede ser tentador leer “Physical AI necesita edge” y concluir que el cloud deja de importar.
Ocurre exactamente lo contrario.
El cloud sigue siendo extremadamente útil para:
- almacenar grandes datasets;
- entrenar con múltiples GPUs;
- mantener un model registry;
- comparar experimentos;
- ejecutar simulación masiva;
- distribuir artifacts;
- observar múltiples sitios;
- coordinar identidad y acceso.
Lo que cambia es qué responsabilidad puede tolerar la distancia del cloud.
Podemos verlo así:
EDGE — tiempo crítico
────────────────────────
sensores
state estimation
inferencia
safety local
control
actuadores
CLOUD — tiempo elástico
────────────────────────
datasets
simulación
training
experiment tracking
model registry
analytics
fleet delivery control-planeLa arquitectura madura no elige entre cloud o edge.
Decide qué debe seguir funcionando cuando el enlace entre ambos desaparece.
El repo también muestra por qué “production-ready” necesita matices
Aquí conviene separar la ambición del proyecto de su estado real.
El README utiliza el término production-ready, pero la propia documentación es mucho más prudente.
T5 continúa siendo roadmap.
Varias piezas de T3/T4 se presentan todavía como recetas avanzadas o documentación en evolución.
Y, más importante, el proyecto publica un threat model STRIDE bastante honesto.
Ese análisis identifica 19 amenazas, incluyendo riesgos críticos y altos todavía abiertos.
Entre ellos aparecen ejemplos como:
- Terraform state almacenado localmente con secretos en texto claro como riesgo crítico;
- autenticación de la API de OSMO deshabilitada en determinada configuración como riesgo alto;
- una Model Encryption Key almacenada en ConfigMap en vez de Secret como riesgo alto.
Eso no invalida el proyecto.
Al contrario: es una señal de madurez que el repositorio publique sus propios límites.
Pero sí significa que “production-ready” no debería interpretarse como:
clona el repo, ejecuta Terraform y conecta inmediatamente un brazo industrial crítico.
Debería interpretarse más como:
existe una arquitectura seria, código ejecutable, automatización y un camino explícito hacia producción, pero cada despliegue tiene que completar su propio hardening, threat model, safety case y validación.
En Physical AI, esa diferencia importa muchísimo.
La gran idea: el producto es el lifecycle, no el modelo
La lección más interesante del repositorio no es Azure Arc.
No es OSMO.
No es LeRobot.
Ni siquiera es Isaac Lab.
Es la forma en que todas esas piezas se conectan.
CAPTURE
ROS 2
↓
DATA
MCAP / LeRobot
↓
CURATE
validate / inspect
↓
LEARN
RL / IL / VLA
↓
SIMULATE
Isaac / Cosmos
↓
EVALUATE
local / SiL / HiL
↓
OPTIMIZE
ONNX / TensorRT
↓
REGISTER
versioned artifact
↓
DELIVER
GitOps / Flux / Arc
↓
RUN
edge inference
↓
OBSERVE
telemetry / outcomesEse ciclo es el verdadero sistema de Physical AI.
El modelo es una pieza reemplazable dentro del lifecycle.
Y eso conecta con algo que también está ocurriendo en agentes de software: el valor se desplaza desde el modelo aislado hacia el harness que lo convierte en una capacidad operacional.
En Physical AI, podríamos expresar una idea similar:
Physical AI
=
Model
+ Sensors
+ Data Pipeline
+ Simulation
+ Training
+ Evaluation
+ Edge Runtime
+ Safety Gates
+ Deployment
+ ObservabilityQuitar cualquiera de esas capas puede funcionar en una demo.
Escalar sin ellas es otra historia.
De la IA que responde a la IA que participa en el mundo
Los chatbots hicieron natural la idea de conversar con una máquina.
Los agentes están haciendo natural la idea de delegarle trabajo digital.
Physical AI añade el siguiente salto:
la inteligencia empieza a participar directamente en procesos físicos.
Eso eleva el estándar de ingeniería.
Un hallucination en una conversación puede ser molesto.
Un error de una policy que controla hardware puede tener consecuencias económicas o físicas.
Por eso el futuro de Physical AI probablemente no se definirá únicamente por quién tenga el mejor foundation model.
Se definirá también por quién construya el mejor sistema para:
- recoger experiencias;
- convertirlas en datos confiables;
- entrenar de forma reproducible;
- simular casos difíciles;
- evaluar antes de actuar;
- optimizar para edge;
- desplegar con rollback;
- observar el comportamiento real;
- impedir que una mala actualización se propague.
El repositorio de Microsoft es interesante precisamente porque intenta convertir esa lista en software.
Todavía está evolucionando y varias de sus capas avanzadas no están terminadas.
Pero ofrece una vista bastante concreta de hacia dónde puede ir la ingeniería de Physical AI:
no un robot conectado a una API, sino una cadena completa de aprendizaje, validación y operación donde el edge actúa y el cloud mejora lo que actuará después.
Fuentes
- TechRadar Pro — How to deploy physical AI effectively
- Microsoft — physical-ai-toolchain, repositorio oficial
- Physical AI Toolchain — Repository Architecture
- Physical AI Toolchain — Tier Model
- Physical AI Toolchain — T0 Dev local training lifecycle
- Physical AI Toolchain — Configuring Edge Data Recording
- Physical AI Toolchain — Azure Storage Architecture
- Physical AI Toolchain — LeRobot Training
- Physical AI Toolchain — OSMO Training Workflows
- Physical AI Toolchain — Synthetic Data / NVIDIA Cosmos
- Physical AI Toolchain — Evaluation Guide
- Physical AI Toolchain — LeRobot ACT Policy Inference
- Physical AI Toolchain — Fleet Deployment
- Physical AI Toolchain — Threat Model
- Microsoft repo — OSMO Training Manager agent