Microsoft measures a 383% mapping slowdown when robot inference stays onboard

A 383% slowdown is a ratio. If a mapping and planning pass takes one second on the A100, the same pass takes up to 4.83 seconds on a smaller GPU that has the memory to hold the stack ^[12]. Microsoft puts the specific test hardware in a separate technical report ^[11].

The three headline numbers describe three different failures. Mapping and planning lost throughput against the A100 ^[4]. Navigation missed deadlines, with a 30% drop in the timely detection of obstacles on lighter GPUs ^[6]. Manipulation is the case where speed and accuracy came apart: the vision-language-action models did not slow down dramatically on the smaller GPUs, and their accuracy still fell by half ^[7].

Some of the smaller GPUs could not run the mobile manipulation stack at all ^[5]. Whether the stack fits is the first question, and the chosen task matters. Checking a kitchen for rubbish and binning it means planning a path, perceiving the scene, navigating, picking the object up and returning to the bin, so the stage that fails sets what the robot can do ^[2][15].

Every number in the post compares one GPU against another. A deployed fleet also depends on the link. Offloading swaps the small onboard card for a remote one plus a wireless connection, so the quantity that decides whether an offloaded grasp arrives in time is round-trip latency under the plant's own radio conditions, including the tail. Microsoft says offloading improved response time and accuracy along with battery lifetime and cost across the configurations it tested ^[16], and that it raised task success rates and allowed larger models ^[8].

On power, the company says replacing power-hungry onboard compute with lightweight onboard hardware and remote inference can substantially improve battery life ^[9]. The trade-off is the GPU's draw against the radio's. The post also argues the onboard GPU costs weight and money and limits which generation of model can run ^[14].

Microsoft describes wiring a GPU to the robot as the prevailing approach, with higher-level planning sometimes done in the cloud while task execution stays on the machine, and says its work challenges that assumption ^[13][1]. Alongside the study it has added Kubernetes-based tooling to its Physical AI Toolchain for containerizing robotics inference and orchestrating it across robots, edge infrastructure and cloud ^[10]. The research claim is narrow and holds: a larger remote GPU beat a small onboard one on the same three workloads ^[4][6][7].