Compute per robot, or compute per building
A facility can source intelligence one robot at a time, bolted to each machine or metered from each vendor's cloud, or hold one pool for the building. The two shapes cost, fail, and age differently.
· 4 min read
IN SHORT
Compute per robot puts a model on each machine or meters each robot against a vendor's cloud, so cost scales with the fleet and the big models never fit. Compute per building puts one pool in the facility's rack that every robot from any vendor draws from, with safety still on the machine. The building-wide pool is one subscription line that does not move as robots are added.
There are two ways to give a floor of robots the intelligence they need. The first is to attach it to each robot: a model on board, sized to what the machine can carry, and for anything larger, a metered connection to that robot vendor's cloud. The second is to hold one pool in the building and let every robot draw from it. Both are in use. They differ in what they can serve, what they cost as the floor changes, and where the evidence of what happened ends up.
What each shape can serve
A robot can carry a model large enough for reflexes and for the tasks it was commissioned for. It cannot carry the perception model for a floor that rearranges itself overnight, the decision model for items it has never seen, or the language model that lets a supervisor speak to it in plain terms. Those models are too large to ride on the machine.
Per-robot compute answers this by sending the request to the vendor's cloud. For some requests that is fine. For a mobile robot approaching an intersection or an arm choosing a grip, the round trip to a distant cloud is too long, and the robot falls back to its on-board model or waits. The large model exists, but the robot cannot use it when it matters.
A pool in the building sits on the facility's own network, close enough that the big models can answer inside each robot's latency budget. Substrate enforces that budget per robot. The robot still keeps its on-board model and still falls back to it when the pool is late, so the floor behaves safely either way. But the large models are reachable, which is the reason to have them at all. The Czar Grid page describes the pool itself.
How each shape is paid for
Per-robot compute scales with the fleet. Every machine added carries its own compute and its own metered share of the vendor's cloud. A decision to add a fleet is also a decision to add compute cost, request by request, and a decision to add a second vendor is a decision to add a second meter.
A building pool is paid for as one subscription for the configured Grid: hardware, platform license, and sustainment in one line, fixed for the term. More robots on the pool do not move it. The floor's compute becomes a cost of the building, like the rack and the network, and fleet decisions stop being compute decisions. The pricing page sets out that form.
How each shape handles a mixed floor
Most floors worth automating end up with robots from more than one vendor: mobile robots from one, pick arms from another, humanoids from a third. Under per-robot compute, each vendor's machines draw from that vendor's cloud and each vendor tunes its models on the captures its own robots collected. The floor has three pools it does not hold, three sets of adapted models it cannot see, and three records.
A building pool serves every robot in the building from any vendor, each under its own budget. Adaptation happens on the pool, on the site's captures, and the adapted weights serve the whole floor. The record of every decision and every task run is in one place, on the operator's hardware, read by the operator's named roles. The mixed-fleet use cases show what this looks like in a warehouse, a plant, and a terminal.
How each shape ages
Fleets turn over. A vendor is replaced, a pilot fleet gives way to a production fleet, a new kind of machine arrives. Per-robot compute leaves with the robots that carried it, and whatever the vendor's cloud had learned about the floor leaves with the vendor. The next fleet starts over.
A building pool stays. The departing fleet stops drawing from it. The adapted weights, the retrieval index over the site's documents, and the record all remain. The next fleet is connected under its own budget and benefits from a pool already shaped to the floor. Over the life of a building, that accumulated fit is worth more than any single fleet.
Where the evidence ends up
Under per-robot compute, the record of what each robot was told and why lives partly on the robot and partly in each vendor's cloud. After an incident, the safety officer reads what each vendor is willing to share. Under a building pool, every run of every site task is recorded and replayable in Agency Studio, and every decision the pool served is in the record, on site.
Both shapes keep safety on the robot. Both let the robot stop when it cannot get an answer. The difference is whether the intelligence above the reflexes belongs to the fleet or to the floor, and a floor outlasts every fleet that runs on it.
Questions this raises
- Does compute per building mean the robot carries nothing?
- No. Every robot keeps its own on-board model for reflexes and falls back to it when the pool cannot answer within its budget. The pool carries what the robot cannot, and the robot carries what it must.
- Is a building pool only worth it for large floors?
- One Czar is a pool for a small floor. Several joined are a Grid for a whole facility. The shape fits a single zone with one fleet as well as a terminal with vehicles, cranes, and inspection, and the subscription names whichever configuration the floor needs.
- What happens to per-robot compute when a vendor changes?
- It leaves with the vendor, along with any models tuned on the site's floor and any record held in the vendor's system. A building pool stays, keeps its adapted weights and its record, and serves the next vendor's robots under their own budgets.
KEEP READING