Paying for the peak at the trough

A team that owns its compute has to size it for the busiest week it expects. Every other week, the same hardware is partly idle, and the bill for it does not shrink. The cost of the peak is paid at the trough, month after month, whether or not a job is running.

E31 Network is being designed around the opposite arrangement. Compute is rented by the hour for the job in front of you, and released when the job finishes. The peak is paid for when it happens, and the trough costs nothing.

The shape of the problem

Most AI workloads in a working team are not steady. A model needs retraining when the data changes, not every day. A backlog of footage builds up and then has to be cleared. A sweep of simulations runs before a design review and not again until the next one. The demand curve is a series of spikes with long flat stretches between them.

Owned hardware cannot follow that curve. It is a fixed quantity, bought or leased for a term, and it costs the same on the quiet days as on the busy ones. If the team sizes it for the spikes, most of it waits most of the time. If the team sizes it for the flat stretches, the spikes take far longer than they should, and the work that depends on them slips.

Neither choice is wrong. Both are expensive in a way that is easy to miss, because the expense shows up as either idle hardware or late work rather than as a line item.

What owning the peak actually costs

The visible cost is the hardware and the power it draws. The less visible costs sit around it: the rack space, the cooling, the person who keeps it patched, the time spent deciding whose job runs first when two teams want the same machines in the same week. Each of these scales with the peak, not with the average.

There is also the cost of being wrong about the peak. A team that buys for this year's largest job will find that next year's largest job is larger. The hardware that was sized correctly becomes the bottleneck, and the cycle starts again with a bigger purchase. The team is either over-provisioned or behind, and rarely neither.

What renting the peak would look like

On the network, a job would declare the work, the data, the request, and the output. The request names how much compute the job needs and for how long, or until it is done. When compute is free, it is held for the job and the meter starts. The job runs, the output comes back, the compute goes back into the pool, and the meter stops.

The team pays for the hours the compute was held. There is no hardware to own, nothing to keep warm between jobs, and no purchase to justify against a forecast that will be wrong. The peak is a bill for that week, and the trough is not a bill at all.

The one thing the team gives up is immediacy. A job on the network can wait in a queue until compute is free, and the meter does not run while it waits. That is what makes the arrangement work, and it is also what rules out anything that cannot wait. The design test is simple: if the job can run tonight, it can run here. If it must answer now, it stays on the team's own systems.

Where the line falls

Renting the peak is not the right answer for every team. A team whose compute is busy most of the time is not paying for a trough, because there is no trough. For them, owning the hardware is the cheaper arrangement, and Element 31 builds Czar for exactly that case: a sealed appliance for a team that wants compute in its own rack.

The network is for the other case, where the need is heavy some of the time and light most of the time. The retraining this week, the footage backlog, the simulation sweep, the dataset that needs processing once. For those jobs, paying at the peak and not at the trough is the whole point.

Rates have not been published, and the program will not publish them until access opens. What can be said now is the shape of the arrangement: by the hour, for the hours held, with the meter stopped when the job is done. See how it works for the life of a job, and when owning compute makes sense for the other side of the line.