Oluwadi
Investigating the Overlooked
Region
What
Who For
Analysis
Oluwadi
Investigating the Overlooked
Sunday Robotics built Memo, its home robot, to run its AI model's inference in the cloud -- then spent two days testing it inside real houses and ripped the cloud out of the critical path entirely. Boston Dynamics built the opposite architecture on purpose: on its humanoid Atlas, the moment-to-moment motor control runs onboard a Jetson Thor chip, but the higher-level reasoning that decides what Atlas should do next on an unfamiliar factory task runs off the robot, reached over a wireless network every single time.[1][7] Both companies are solving the identical problem -- where should a robot's AI model actually run, on the machine or in a datacenter reached over the air -- and they reached opposite answers. Both are defensible.
Every large language model company scales the same direction: build a bigger model, then rent more datacenter GPUs to run it. Robotics inverts that. A robot's onboard chip, its power draw, and its weight budget are fixed by the machine itself -- a humanoid carries roughly 2 kWh of battery and draws a few hundred watts in normal motion, so its onboard compute is a 40-to-130-watt chip like NVIDIA's Jetson Thor, not a rack of GPUs.[1] The model has to be built to fit that hardware, not the other way around, and two separate constraints force the tradeoff: a robot's control loop can't miss a deadline the way a slow chatbot reply can just be tolerated, and every robot needs its own dedicated compute, paid for on every unit shipped, unlike a cloud LLM serving millions of users off one shared cluster.[1]
Those figures come from SemiAnalysis's own reporting and from each model's own technical documentation: Physical Intelligence's π0.7,[2] ByteDance's GR-3 technical report,[3] and NVIDIA's own DreamZero project page.[4] Generalist AI, a separate startup, trains its GEN-0 and GEN-1.5 models at roughly 10 billion parameters on more than 270,000 hours of real-world manipulation data.[6] On the small end, NVIDIA's own research lab answered the same size constraint from a different direction: RoboTTT is a 3-billion-parameter policy that updates its own weights during test-time training, giving it minutes of usable memory without growing past what a robot can actually carry onboard.[5] Every frontier LLM lab is racing toward more parameters. Every frontier robotics lab, DreamZero aside, is racing to stay under a ceiling.
A robot's control stack runs at more than one frequency at once, and the gap between them decides what can actually leave the machine. Servo and safety loops run at 100-plus Hz -- a 100 Hz loop has to produce its next output every 10 milliseconds, and a wireless round trip alone typically costs 10 to 50 milliseconds, which eats the entire budget before a model has done any thinking. That layer can never leave the robot.[1] The planning and reasoning layer runs far slower, roughly 5 to 20 Hz, so a 5 Hz planner gets about 200 milliseconds per decision -- enough headroom that the same 10-to-50-millisecond network round trip fits comfortably, with margin left over.[1] Average latency isn't actually the hard part at that layer, though -- jitter is. Irregular, unpredictable delay, where a robot never knows exactly when the next instruction will land, is what breaks a task that a low but steady latency would never touch.[1]
NVIDIA's own numbers show why onboard compute is structurally disadvantaged before any cost math even runs. Its datacenter GPUs -- Blackwell, B300 -- carry gross margins in the mid-to-high 70s percent; Jetson, the robot-class chip, runs in the mid-60s.[1] That gap would matter less if Jetson silicon lived on its own manufacturing node, insulated from the fight over advanced-node capacity. It doesn't, not anymore: Jetson Orin was built on Samsung's SF8 process, genuinely separate from the datacenter roadmap, but Jetson Thor moved onto TSMC's N4 -- the same leading-edge node datacenter accelerators use -- and NVIDIA's own next Thor successor is expected to move to N3 and then N2, the identical nodes Rubin and Feynman, its future datacenter chips, are fighting the rest of the industry for.[1] Low-volume, lower-margin robot chips now queue for the same scarce wafer capacity as the highest-margin product NVIDIA makes -- even though, by SemiAnalysis's own estimate, a million Jetson-class chips a year by 2030 would still add up to only about ten thousand wafers, a rounding error against datacenter demand.[1]
SemiAnalysis modeled what offloading actually costs against running everything onboard -- this is SemiAnalysis's own analysis, not an independently verifiable industry benchmark, and it's presented here as their modeled scenario, not settled fact. Comparing a B300 datacenter server, an RTX 6000 Pro datacenter server, and Jetson Thor onboard compute, all serving a 96-robot fleet, their model found that once realistic utilization is factored in -- roughly 40% for the onboard chip against 90% for a shared datacenter GPU -- offloading to a shared B300 reaches only about 46% of the on-robot cost per FLOP for a standard industrial deployment, and roughly 12% for a home deployment, where an individual robot's onboard chip sits idle even more of the time.[1] By that same model, the crossover point where sharing a GPU becomes cheaper than running onboard lands at roughly 5 robots per GPU by DRAM capacity, or about 7 robots per GPU by wafer and silicon efficiency.[1] Below that fleet density, onboard can still win; above it, the shared GPU pulls ahead -- a fleet-size and utilization argument, not a universal one.
Boston Dynamics splits its stack in half on purpose. On Atlas, System 1 -- the visuomotor policy that actually drives the motors -- runs onboard a Jetson Thor chip, the same real-time layer nothing can offload. System 2, the higher-level reasoning that decides what Atlas should do next on an unfamiliar factory task, runs off the robot entirely, served through the company's Orbit fleet software on Google's TPUs, built on Google DeepMind's Gemini Robotics-ER reasoning models.[7][8] The company's own reasoning: a reasoning model general enough to handle real factory-floor variation is too large to fit on any robot chip available today, so it has to live in a datacenter -- and running it there also lets Boston Dynamics improve every deployed robot's inspection accuracy at once, without shipping firmware updates machine by machine.[7]
Agility Robotics made the opposite bet with Digit, its bipedal warehouse robot now doing paid commercial work at GXO, Amazon, Toyota Motor Manufacturing Canada, Schaeffler, and Mercado Libre. Every inference step Digit runs -- perception, whole-body control, manipulation -- fits onboard its Jetson-class chip; nothing about how it decides what to do next leaves the robot.[9] Agility still uses the network for things that aren't real-time decisions -- fleet orchestration, workflow assignment, and over-the-air updates all run through its Arc cloud software -- but the AI inference that actually controls the robot in the moment stays local, because factory wireless is unreliable in exactly the way a safety-critical decision can't tolerate, and a robot working alongside people can't depend on a network link for a call that has to be right the instant it's made.[9][10]
Sunday Robotics reversed itself on the same question inside of 48 hours. Memo, its home robot, was originally designed to run its ACT-2 model's inference in the cloud. Two days into testing it inside real houses, the company pulled the cloud out of the critical path and moved inference fully onboard. The reason wasn't latency -- it was jitter. Home WiFi, the company found, is a mess of dead zones, neighbor interference, badly configured mesh routers, and asymmetric links; a robot trying to hold a high success rate over hours can't shrug off an irregular stall the way a video call can, because it never knows in advance when the next command update will actually land.[1][11]
Weave Robotics, building Isaac, a laundry-folding home robot, runs a hybrid of both answers rather than choosing one. Isaac's own policy model -- a few billion parameters, the same size class as Physical Intelligence's and ByteDance's models above -- runs onboard. But the company still depends on the network for two things it decided didn't need to be instant: uploading training data back to Weave, and a human teleoperator who can take over the robot's arms remotely for a five-to-ten-second correction when Isaac hits a fold it can't finish alone -- pants, undergarments, pillowcases -- before handing control back.[1][12]
Why does this matter? Four real companies, solving adjacent versions of the identical problem at the identical moment, reached four different architectures -- and none of them is wrong given what each company is actually optimizing for. Boston Dynamics needs a generality no robot-sized chip can hold yet, and can tolerate occasional cloud dependency on a factory floor with managed wireless. Agility can't tolerate that dependency at all, because a warehouse safety decision has to be right the instant it's made, network or no network. Sunday learned the hard way that a home's wireless is worse than a factory's, not better, and reversed a real architecture decision after two days of evidence instead of defending the plan on paper. Weave decided the honest middle path was to keep the model onboard and reserve the network only for the parts of the job that were never going to be instant anyway. This isn't a solved question with one right answer waiting to be adopted industry-wide. It's an active, live tradeoff, and the companies actually shipping robots right now are still finding out, deployment by deployment, which side of it they're on.
Part of the same thread: "GXO Put an Autonomous Forklift on a Live Warehouse Floor"[13] named the chip a robot computes on as one of three physical-AI stack layers; this piece is about what decides whether that chip runs the whole job alone. "Fei-Fei Li's World Labs Raised $1.2 Billion"[14] covers the world-model layer these same robots increasingly train against.