02.Workloads
Train, infer and render on one substrate
Reading time: 16 min
The three workload classes subsidise each other. That is the whole architectural bet.
58%
of network hours are inference
up from 31% in 2025
3.4x
median utilisation vs. single-tenant
mixed workloads fill each other's troughs
12s
median cold start to first token
down from 94s at launch
A network of borrowed hardware has an unforgiving economics problem: operators need consistent revenue, and any single class of work is spiky. Training arrives in enormous bursts and then stops for weeks. Inference is steady but collapses overnight in its home timezone. Rendering is seasonal to the point of absurdity.
Running all three on one substrate is not a product decision so much as a load-balancing one. Inference holds the floor. Training buys the peaks. Rendering absorbs whatever is left at whatever price clears, which is why a render queue is the most valuable thing on the network at four in the morning.
What follows is how each class is actually scheduled, and where the abstraction leaks.
Including the workloads we tell people to run somewhere else.
The three shapes
1. Inference is now the majority of the network by hours
Two years ago this network was a training network with some rendering attached. That has inverted. Inference is now 58% of billable hours, and the shift changed what the scheduler optimises for — from raw throughput toward warm capacity and tail latency.
Rendering has grown in absolute terms while shrinking as a share, which is exactly the behaviour you want from ballast.
Inference
Training and fine-tuning
Rendering and simulation
Batch and ETL
Source: ROBO billing records, Q1 2026 vs Q1 2025
Overnight troughs are filled almost entirely by render and batch queues.
00:00–04:00
04:00–08:00
08:00–12:00
12:00–16:00
16:00–20:00
20:00–24:00
Source: ROBO network telemetry, trailing 30 days
Training
2. Training works here when the job tolerates a node vanishing
Distributed training is the hardest thing to run on hardware you do not own, because it is the workload least tolerant of a single node disappearing. A 400-way data-parallel run with a synchronous all-reduce is only as available as its worst participant.
ROBO handles this by refusing to pretend the problem away. Training placements are contiguous where possible — a single operator's rack rather than a scattered set — and the framework integration checkpoints on a cadence derived from that specific operator's measured departure rate. Runs that cannot tolerate elastic membership are told so at submission time rather than at hour nine.
Single-operator contiguous rack
Two operators, same metro
Elastic, membership may change
Geo-distributed, async
Source: ROBO scheduler, trailing 90 days
Source: ROBO benchmark suite, 7B-class dense models
“The honest version is that we lost two runs before we understood checkpoint cadence. Once the scheduler started setting it from the operator's own history instead of our guess, we stopped thinking about it entirely.”
Teodora Vance
Research Infrastructure Lead, LOOMCELL
Inference
3. Cold start is the entire inference product
Everything hard about serving inference on a borrowed network reduces to one number: how long between a request arriving at an endpoint with no warm capacity and the first token coming back. At launch that number was 94 seconds, which made scale-to-zero a theoretical feature nobody used.
Getting it to 12 seconds took three things — keeping model weights resident on nodes that have run them before, predicting demand from the endpoint's own traffic shape rather than reacting to it, and letting operators bid to hold weights warm for a small standing fee. The last one turned out to matter most.
Warm, weights resident
Warm pool, different node
Cold, weights cached in region
Cold, weights fetched
Source: ROBO benchmark suite, median of 10k requests
Source: ROBO network telemetry
Rendering
4. Rendering is the ballast that makes the rest affordable
Frame-parallel rendering is the easiest workload on the network and the most economically important. Frames are independent, restarts cost one frame, and the work is almost perfectly price-elastic — a queue that would be uneconomic at daytime rates becomes obviously worth running at four in the morning.
That elasticity is what lets operators attach hardware at all. Without a workload willing to consume every trough at whatever price clears, an operator's revenue would be as spiky as the training market, and most of them would not bother.
Submitted below a price ceiling
Submitted on a schedule
Submitted immediately, any price
Source: ROBO scheduler, trailing 90 days
“We set a ceiling per frame and walk away. Some nights the whole sequence finishes by six, some nights it takes three days. For everything that is not a deadline shot, that trade is free money.”
Ruben Achterberg
Head of Pipeline, ORRERY
What does not belong
5. Four workloads we actively tell people not to run here
A network of independently operated hardware is genuinely worse than a single-tenant cloud for some work, and pretending otherwise produces unhappy customers who leave loudly. These are the cases where the honest answer is to run it somewhere else.
Further reading