One team, two kinds of compute

Look at the compute a working AI team actually uses over a quarter and a pattern appears. There is a flat line of steady load: the models answering on robots and edge devices, the operator tools, the live systems that have to be up during every shift. Then there are spikes that tower over the flat line: the week a model gets retrained, the days a backlog of footage finally gets processed, the sweep of simulations before a design review.

The flat line and the spikes are not the same kind of demand, and they should not be served by the same kind of compute. That observation is the reason E31 Network exists.

The first kind: compute that is there whenever it is needed

Real-time work has a simple requirement. The compute must be present, powered, and answering whenever the machine or the person needs it. It cannot wait for a queue, and it cannot depend on a network link that might not be there. The right way to meet that requirement is to own the hardware and put it next to the work: on the robot, on the edge device, in the team's own rack.

This kind of compute is sized for the steady load. It runs the perception model, closes the control loop, serves the operator console. It is busy in a predictable way. Buying it is sensible because it is used all the time, and keeping it local is necessary because the work cannot leave.

For teams that want more of this kind in their own rack, Element 31 builds Czar, a sealed appliance on its own subscription, which can be joined into a grid for a facility. That is the owned path. The network is not it.

The second kind: compute that shows up and leaves

Batch work has a different requirement. The compute must be large enough to finish the job in a reasonable window, and it must be available when the job is ready. Between jobs, it is not needed at all. A team retraining a model needs a lot of compute tonight and none of it tomorrow. A team with forty hours of warehouse camera footage needs compute until the footage is processed and then nothing until the next backlog.

Owning compute for this kind of demand means sizing for the peak. The peak comes a few times a quarter. The rest of the time, the hardware sits idle, depreciating, drawing power, waiting for the next spike. Owning enough for the peak means paying for it at the trough, and the trough is most of the year.

The design intent of E31 Network is to serve this kind of demand by the hour. A team describes the job, compute is held for it, the job runs, the output comes back, and the compute is released to the pool for someone else's spike. Nothing is owned. Nothing sits idle afterwards. The meter runs for the hours the compute was held and stops when the job finishes. Rates are not yet published; they will be when access opens.

Why one pool cannot do both

It is tempting to look for a single system that handles both kinds. The two requirements pull in opposite directions.

Compute that must be present cannot be shared, and compute that cannot be shared cannot be rented by the hour at a price that reflects shared use. Compute that shows up for a job must be shared to be affordable, which means jobs sometimes wait, which means it cannot carry work that must answer now. Any system that tries to be both ends up being an expensive version of one of them.

So the network does not try. It is being designed as the second kind only: hourly AI compute for training, inference, simulation, and processing jobs. The first kind stays with the team, on dedicated infrastructure, edge devices, robots, or its own systems. The sorting test between them is whether the work can wait for a queue.

What this looks like for a team

In practice a team ends up with a small, steady, owned footprint and a variable, rented one. The owned footprint is sized to the flat line and does not change much. The rented footprint is nothing most of the time and large for a few days when it matters.

The handoff between them is explicit. Data collected on the owned side is staged for a job. The output of the job is returned and the team deploys it on the owned side when it is ready. The handoff article covers that seam in detail.

E31 Network is a technical preview. No jobs can be submitted yet and design-partner intake is not yet open. But the shape of the two kinds of compute is visible now, and a team can start sorting its own work along that line. The workloads page is a good place to begin.