On-Device or Cloud AI

Three places robot AI can run

Onboard compute sits inside the robot and answers fastest, but space, heat and battery limit its size. Edge or fog servers sit on the same site, perhaps in a comms room or a cabinet on the shop floor, and offer more power over short network hops. Cloud data centres host the largest models and make updates easy, at the cost of distance and dependence on the internet. Most real systems split the work between them. Researchers at UC Berkeley built FogROS2 to let robots running ROS 2 hand heavy jobs to cloud machines, and report that grasp planning fell from 14 seconds to 1.2 seconds and motion planning ran 45 times faster once offloaded.

How latency decides the split

Balance and joint control loops run far too fast to wait on a network, so they stay on the robot. Higher-level reasoning can tolerate more delay. Google DeepMind's Gemini Robotics shows one such split: a large vision-language-action backbone hosted in the cloud, paired with a local action decoder on the robot's onboard computer. The team reports cutting the backbone's query-to-response latency to under 160 ms, with end-to-end latency from raw observations to low-level action chunks of about 250 ms, and an effective control rate of 50 Hz because each response carries several actions. Ask any maker which control loops depend on the network and what delay they were designed to tolerate.

Privacy and connectivity trade-offs

Every frame sent off the robot is data leaving your site. If cameras and microphones stream to a cloud service, you need to know where that data is processed, how long it is kept and whether it trains the maker's models. Running perception on the robot or on a local server can keep raw images inside your building and send only summaries out. Connectivity is the other half of the question. Wi-Fi drops, mobile coverage varies and cloud services have outages, so decide what the robot should do when the link fails: finish the current step, stop safely where it is, or switch to a smaller onboard model with reduced abilities.

Power, heat and running costs

Onboard computing draws on the same battery as the motors, so a bigger processor shortens the working shift and adds heat that has to escape from a sealed body. Cloud computing turns that cost into a subscription or usage bill that continues for as long as the robot is in service. Edge servers sit between the two, with an up-front hardware purchase, local maintenance and no per-query fees. When comparing humanoids such as the Unitree G1 or Agibot X2, ask what processors are inside, which features need an account or subscription, and which functions keep working if that service ends. Those answers matter as much as the name of the model it runs.

Sources and further reading

• FogROS2: An Adaptive Platform for Cloud and Fog Robotics Using ROS 2 — UC Berkeley (arXiv).
  Open platform that offloads heavy robot computation to cloud servers, with measured speed-ups for grasp and motion planning.
• Gemini Robotics: Bringing AI into the Physical World — Google DeepMind (arXiv).
  Describes a VLA split between a cloud-hosted backbone and an on-robot action decoder, with measured latency figures.

Common questions

Can a humanoid robot work without internet?

Some can carry out basic movement and pre-trained skills offline, but features that rely on cloud-hosted models, such as open-ended voice commands, may stop working. Check the maker's documentation for an offline mode and test it on site before you depend on it.

Is on-device AI more private than cloud AI?

It can be, because raw camera and audio data need not leave the robot. Privacy also depends on the logs, crash reports and training uploads a robot sends later, so read the data settings rather than assuming that on-device means nothing is shared.