Three reasons robots will need many small AI models

September 22, 2026 · by Maxime Carriere

A humanoid has more than thirty joints, several cameras, an IMU, and force sensing at every contact point. The marketing photograph shows one brain. The schematic shows a federation: dozens of controllers, each closing its own loop, most of them talking to nothing but their own actuator.

The interesting design question is not how large the central model is. It is how many models there are, and what is allowed to travel between them.

Three reasons robots are likely to use multiple AI models or model components, each operating at the timescale its job demands:

• Time. The fastest control loops need an answer within one millisecond. A remote cloud round trip can easily consume tens of milliseconds, and substantially more depending on geography and network conditions, before inference begins.
• Energy. A model at a joint can be duty-cycled, or run on electronics already powered for the control loop. A central accelerator can also be clocked down or gated between requests, but keeping a large compute resource ready still carries a power cost.
• Privacy. A robot is a walking camera array, and data that never leaves the machine avoids exposure along an external data path.

The question is not how big the brain is. It is what is allowed to travel on the nerves.

One: time, and the answers that cannot wait for the centre

A robot runs on tiers, and the rates are published.

Each tier does one job, and its rate follows from that job.

• The current loop makes one motor push as hard as it was asked to. How hard a motor turns is called its torque, and torque comes from the current flowing in the motor’s coils, so the loop watches that current and corrects it. It is fast because a motor’s electrical dynamics are much quicker than the mechanical motion they eventually produce. The electrical time constant is inductance over resistance and so is specific to the motor, but current control commonly runs in the kilohertz to tens of kilohertz range: 10 to 20 kHz, once every 50 to 100 microseconds, is a typical figure.
• The servo loop holds one joint at the angle it was asked for. Servo loops commonly run around 1 kHz, once every millisecond, which gives substantially more feedback bandwidth than the mechanical motion they regulate. The rate a given joint needs follows from loop bandwidth, phase margin, actuator dynamics, sensing delay and how hard it has to reject disturbances, rather than from a single rule of thumb.
• The fieldbus carries those commands between the central computer and the joints, over a real-time bus such as EtherCAT or CAN FD. It has to deliver state and command updates fresh and deterministic enough for the servo architecture above it, which often puts it near the servo rate without requiring the two to be equal. A controller can interpolate, hold the last command or close its loop locally, and EtherCAT supports cycle times well under 100 microseconds where a design needs them.
• Whole-body control decides how the joints share a task, keeping balance while the hand goes where it was sent. It is slower because every tick solves for all the joints at once, and balance does not shift as fast as a coil current. 100 to 500 Hz, every 2 to 10 milliseconds.
• The learned tiers choose what to do at all. They can be slower still, because the loops underneath keep the robot standing while the answer is computed. Figure’s Helix splits an 80 million parameter policy at 200 Hz from a 7 billion parameter vision language model at 7 to 9 Hz, roughly 110 to 140 milliseconds per update, and Physical Intelligence’s pi-zero pairs a 3 billion parameter backbone with an action expert emitting at 50 Hz.

Does every tier need its own model? The bottom three are traditionally dominated by hand-written control code rather than learned models, though learned low-level controllers do exist. Above them, a tier’s rate is its compute budget: 200 Hz allows about 5 milliseconds per inference, 7 to 9 Hz roughly 110 to 140. A monolithic network could in principle do this too. What shipped systems do instead is split the learned stack into components running at different rates. The claim here is about practice, not impossibility.

A round trip to a remote server costs tens of milliseconds before inference begins, and measurements of cloud and edge round trip times put edge servers ahead for the great majority of users. The bottom rungs need an answer inside a millisecond, so a cloud path is too slow for the inner loop by one to two orders of magnitude. That does not mean the whole architecture has to be local: a slower tier can predict or hand down a set point while the inner loop runs locally.

There is a second requirement that a rate does not capture. A loop that answers in one millisecond nine times out of ten and in eight the tenth time is not a fast loop, it is a loop with a tail. Everything downstream assumes an alignment it is not getting, and the failure reads as bad perception rather than bad timing. A policy that misses one cycle in a thousand is not a reflex. It is a suggestion.

Two: energy, and how often the big model has to wake

Distributed small models can reduce total power by using controllers that are already powered and avoiding unnecessary wake-ups of a large accelerator. Per multiply-accumulate the large accelerator is the better machine, so the saving is never about small models being efficient. Whether it materialises depends on model size, idle power, duty cycle and data movement. What follows is the design argument, not a measurement of two robots against each other.

Three terms carry it.

• Marginal cost, not total. Most modern robots already place motor and drive electronics at or near the joint, powered and running to close the current loop, whatever the rest of the architecture looks like. Where a model is small enough to fit the part already there, it costs only the power of the extra work. Where it is not, the robot does gain a chip, and the budget further down is what decides whether the swap pays.
• Duty cycle. A small model can be duty-cycled or triggered selectively where the application permits. A camera model may instead run continuously, so the saving has to be designed rather than assumed. Central accelerators can also gate and sleep, and the comparison is between power management strategies, not between asleep and awake. A part kept ready still costs something: a third-party measurement puts one observed idle configuration at about 16 W.
• Transport. Moving a frame across a bus costs real energy in serialisers and physical layers, and computing where the data is born avoids it. How large that term is depends on payload size, interface, distance and compression. It can become a significant part of the energy budget when large sensor payloads have to cross high-speed interfaces, and nothing measured here establishes how it compares with the compute.

• A Thor class module, the head or torso computer most of the humanoids named below carry: 40 to 130 W configurable, per NVIDIA. The roughly 16 W idle figure is a third-party measurement reported on NVIDIA’s developer forum rather than a vendor specification, and it is used here as an indication rather than a number to build on.
• An Orin class module: 10.2 W mean running YOLOv5s at 640 px, off our meter rather than a datasheet.
• A motor control microcontroller: an illustrative sub-watt budget, on for the life of the machine. Actual consumption varies by microcontroller, drive stage and workload, and no figure here is measured.

Thirty joints at an extra half watt is 15 W, more than the Orin drew running a detector. The arithmetic is the reason the energy case cannot be stated as a general law: a federation that adds half a watt per joint has already spent more than the central module it was meant to relieve. The case holds when each model stays small enough to fit the electronics already there, and every question answered locally is one the expensive module was never woken for.

Autonomy on a charge is the number a buyer compares, and it is driven by how often the robot has to wake its most expensive part, not by what that part can do. Many small models attack that number by reducing how often it has to wake, subject to each of them staying small enough to be nearly free.

Three: privacy, and what is allowed to travel

A humanoid in a home, a ward or on a factory floor is not a camera on wheels. It is a sensor platform that continuously derives a model of a private space: the frames, the audio near it, the map it builds in order to navigate, who is where and when, and the torque traces that describe how the work is actually done.

The design question is which parts of that model are allowed off the machine.

Images are the row everyone argues about. Three of the others are harder to defend.

• The map is a live floor plan of a private site, kept current by the machine that navigates with it.
• Occupancy and timing need no image at all. When a house is empty, how a ward is staffed at night, when the line runs slow. A stream of events is enough.
• The torque traces are the customer’s process. A factory that would never email its production data is asked to stream it continuously.

A model at the sensor replaces the raw stream with its output, a short vector in place of a frame. Biology reduces the same way before transmitting anything: about 126 million photoreceptors reach the brain through roughly 1.2 million optic nerve fibres, about a hundredfold compression inside the eye.

A latent is not private by construction. Images have been reconstructed from feature embeddings with substantial visual fidelity, and model inversion is an active literature rather than a theoretical worry. The engineering word for what a latent buys is data minimisation rather than anonymisation, which is a characterisation of the mechanism and not a legal determination about any particular deployment.

What the boundary buys is governability. A small, fixed, well defined thing crossing it can be logged, bounded and attested; a continuous stream cannot. A federation is a fleet of artifacts, so which model runs in which limb becomes an attestation question.

What the robot companies actually build

Nobody serious relies on one model for every control function, and even the systems marketed as one model sit on top of multiple control layers.

• Helix and pi-zero split the learned stack, in different ways. Figure’s Helix as published in 2025 separates a slow vision language system from a fast visuomotor policy, at 7 to 9 Hz and 200 Hz, on separate processes and GPUs. Physical Intelligence’s pi-zero is one architecture that augments a pretrained backbone with a separate action expert at up to 50 Hz. Two rates in both cases, reached by different routes.
• Figure’s own later work cuts the other way. It describes Helix 02, announced January 2026, as a single unified visuomotor neural network connecting every sensor to every actuator, and Helix 2.5 that September as its most advanced. The flagship example in this post has moved toward one learned model, and the control layers underneath it did not go anywhere.
• Skild, whose whole product is one general purpose brain, describes it as a hierarchy: a low frequency policy feeding a high frequency one that emits joint angles and torques. Hierarchical learned control inside one foundation model, which is not a model at every joint.
• The bottom tier already exists. Most modern robots use local motor and drive electronics, often on real-time buses such as EtherCAT or CAN. It is already distributed and already real time. What it runs today is hand-written control code rather than learned models, which is the gap this post is about.
• NVIDIA is becoming a major common platform for the top compute tier, but its Jetson Thor launch establishes an ecosystem, not market share. It names Agility, Amazon Robotics, Boston Dynamics, Caterpillar, Figure, Hexagon, Medtronic and Meta, with 1X, John Deere, OpenAI and Physical Intelligence evaluating. Being named an adopter is not a published architecture: Boston Dynamics describes Atlas as developed with Jetson Thor, and Agility uses IGX Thor in its safety architecture.
• Two exceptions worth naming. Tesla runs Optimus on its own FSD derived silicon, and XPeng’s IRON carries three in-house Turing chips. The consolidation argument, one layer up.
• The European parts are in the bottom tier, not the top. No European module among the head-row names, while ST, Infineon and NXP sell into the joint tier alongside TI. That reads one announcement rather than a market.

The industry is converging on multiple control timescales, but not on where the boundaries belong. Those timescales can live inside one model, one architecture with specialised components, or several independently deployed models. The argument here is that time, energy and data boundaries push toward more, smaller, separately deployable models.

What Kernwerk can help you with

A small model is not a large one with fewer parameters. Making one hold a deadline on the part already in the joint is its own engineering.

• Fast enough to be a reflex. We compress the model onto the part you chose, compile it for that silicon, and measure the tail rather than the mean, because one slow cycle in a thousand breaks a loop.
• Cheap enough to leave running. We size the model to the part instead of the part to the model, so the expensive module stays asleep.
• Quiet enough to keep the data where it was measured. A model at the sensor uses the frame and drops it, and only the answer travels.
• Sealed, so the model stays yours. We encrypt it, run it where the rest of the system cannot read it, and sign it so a device can prove which model it runs.

Two notes on evidence. No experiment of ours appears in this post: the control rates are published vendor claims, the anatomy is textbook, and the latent argument rests on citations. The only measurement of our own is the 10.2 W. And nothing here says large models do not matter, because deciding what to do next is their job.

If you are building the small models, the ones at the sensor and in the joint that decide what travels, that tier is the one we build for. Talk to us.