Microsoft Adds Remote AI Processing to Robot Toolchain After Performance Tests

Microsoft’s tests found gains in some robot tasks and battery life. The approach also puts network speed and remote GPU capacity into the operating equation.

By 3 min read
Microsoft Adds Remote AI Processing to Robot Toolchain After Performance Tests
Microsoft Adds Remote AI Processing to Robot Toolchain After Performance Tests

Listen to this story

The audio brief

About 1:27
0:001:27
Read transcript
Microsoft’s new Physical AI Toolchain lets developers move a robot’s AI work off the machine and onto a nearby or cloud GPU. In Microsoft’s tests, that shift improved results on some tasks and extended battery life—but it also made network performance part of the robot’s operating equation. The tool packages workloads in containers and uses Kubernetes-based software to manage where they run. Developers choose what to offload; the robot can still carry out its task while model inference happens elsewhere. That matters when onboard hardware is too limited: some smaller GPUs in the tests couldn’t run the full software stack. Among those that could, mapping and planning ran up to 383 percent slower than on an A100. Timely obstacle detection fell 30 percent on lighter GPUs, and slower vision-language-action models lost as much as half their accuracy. Those comparisons reflect different GPU capabilities, not distance alone. Microsoft also tested a Raspberry Pi 5 in place of an onboard GPU, sending data to a remote processor; the company says that setup extended battery life. Its examples cover SO-101 and UR10e robots, and a demonstration had the Rho model control a Mobile ALOHA robot with inference on a Jetson Thor GPU. The toolset also connects with LeRobot and ROS2. The practical question is whether a developer’s network latency, bandwidth, and access to remote GPUs can keep up with the demands of a real robot task.

Story brief

3 key points

Microsoft’s Physical AI Toolchain gives developers a Kubernetes-based way to package robot workloads and choose which run onboard, on edge GPUs, or in the cloud. In tests, smaller GPUs struggled: mapping and planning were up to 383% slower than on an A100, obstacle detection fell 30%, and slower vision-language-action models lost up to 50% accuracy. Offloading also extended battery life in a Raspberry Pi 5 setup,...

  1. 01

    The tool distributes containerized workloads across robot, edge, and cloud resources; developers choose what to offload, with Kubernetes-based tooling managing placement.

  2. 02

    Microsoft includes examples for SO-101 and UR10e robots and integrates the toolset with simulators, LeRobot, and ROS2.

  3. 03

    Microsoft demonstrated its Rho model controlling a Mobile ALOHA robot while inference ran on a Jetson Thor GPU.

Microsoft has added a way for developers to run robot AI workloads on nearby or cloud GPUs instead of keeping all that computing on the robot. Its research team found that offloading improved results in tested tasks and could extend battery life. The question for a working robot is whether those gains outweigh the demands of the connection to its remote processor.

Where the work goes

A robot running AI on an onboard graphics processor, or GPU, is limited by what that machine can carry and power. Microsoft’s approach moves inference—the step where a trained model produces an output—to a GPU at an edge site or in the cloud. The robot still receives instructions for the task, but the model no longer has to fit entirely on its onboard GPU.

Microsoft studied mobile manipulation: a robot navigating a space, locating an object and handling it. One example is finding rubbish in a kitchen and putting it in a bin. That job calls on mapping and planning, navigation, and manipulation, giving the researchers several kinds of AI work to test across onboard, edge and cloud computing setups.

The distinction matters for the results: these are comparisons across computing configurations, including GPUs with different capabilities. A faster result on a remote GPU does not mean distance itself makes a robot faster. It shows what stronger computing resources can offer when the robot can use them in time.

The measured limits of smaller GPUs

Some smaller GPUs in Microsoft’s tests could not run the full mobile-manipulation software stack. Among GPUs with enough memory, mapping and planning ran up to 383% slower than on an A100. That delay is consequential for a robot planning its route through a changing space, though the figure describes a tested comparison, not every robot or task.

The consequences differed by workload. On lighter GPUs, the navigation system showed a drop in timely obstacle detection. Slower vision-language-action models—models used to turn visual input and instructions into actions—also lost accuracy in Microsoft’s tests. In an object-handover task, the researchers found higher success rates with offloaded inference.

Battery savings meet a network constraint

The team also tested power use. It replaced an onboard GPU with a Raspberry Pi 5 board and sent the data to a remote GPU for inference. Microsoft says this increased robot battery life. That is a different benefit from improving task performance: moving power-hungry computing off the machine can let it operate longer between charges.

The tradeoff is not just GPU speed: remote inference also depends on network latency, bandwidth and available GPU resources. Those limits matter most when a task cannot wait for a delayed response. Microsoft presents offloading as a way to choose where work runs, rather than a finding that every part of a robot’s AI should always run remotely.

From research setup to developer tool

The new Physical AI Toolchain feature packages robot AI workloads into containers and distributes them across a robot, edge GPUs and cloud resources. Developers specify what to offload; Kubernetes-based tooling helps place and manage the resulting workloads. Microsoft says the toolset also integrates with robotic simulators, LeRobot and ROS2.

The release includes example offloading projects for SO-101 and UR10e robots. Microsoft also demonstrated its Rho model controlling a Mobile ALOHA robot while its inference ran on a Jetson Thor GPU. The examples make the feature concrete; the remaining test for developers is whether their own network and computing setup can deliver the responses their robot tasks require.

Sources

  1. microsoft.comWhat if robots didn't need all their AI onboard?

Loading discussion...

YOUR READING SPACE

Notifications