On-demand compute
GPU compute rented for the duration of one job and released when the job finishes, instead of owned, leased for a term, or left running between uses.
· 2 min read
IN SHORT
On-demand compute is GPU compute a team rents for one job and gives back when the job finishes. Nothing is bought and nothing runs between uses; the team pays for the hours the compute is held. E31 Network is being designed as a marketplace for exactly this, for batch and asynchronous AI workloads, with rates to be published when access opens.
On-demand compute is GPU compute that a team rents for the duration of one job and gives back when the job finishes. It is the opposite of owned or term-leased capacity: nothing is bought, nothing is kept running between uses, and the team pays only for the hours the compute is held.
Why it matters
Most teams do not need heavy compute all the time. They need it for a retraining run this week, a backlog of footage next month, a sweep of simulations before a review, and very little in between. Owning enough hardware for the peak means paying for that hardware at the trough, when it sits idle.
Renting by the job changes the shape of the cost. Spend follows the work rather than the calendar. A team can size each request to the job in front of it instead of to the largest job it expects to see in a year.
The trade is that on-demand compute is shared. A job may wait for capacity to come free, and a job that cannot wait is not a good fit. That boundary is what separates on-demand compute from dedicated infrastructure, and it is why the model suits batch and asynchronous work rather than anything that must answer in the moment.
How it works on E31 Network
E31 Network is being designed as a marketplace where companies rent AI compute by the hour for batch and asynchronous workloads. The one-line version: rent compute when you need it, run the job, get the output, release the compute.
A team would describe a job, including the work, the data, the request, and the output it expects back. Compute would be held for that job and the meter would start. The job runs unattended, isolated from other jobs. When it finishes, the output is returned, the compute goes back to the pool, and the meter stops. The team pays for the hours the compute was held and nothing afterwards.
This is a technical preview. No jobs can be submitted yet, and no rates are published; the design intent is that rates appear when access opens. For teams that want compute in their own rack instead, Element 31 also builds Czar, a sealed appliance on its own subscription. The network is for the jobs that do not need to own compute. See how it works for the life of a job in full.
Related terms
Questions this raises
- How is on-demand compute different from a cloud instance left running?
- The difference is the unit. An instance is rented as a machine and keeps costing money until someone turns it off. On-demand compute as E31 Network defines it is held for a job and released when the job finishes, so there is nothing to remember to shut down.
- What kinds of work suit on-demand compute?
- Work that can wait for a queue and run unattended: training, fine-tuning, retraining, batch inference, footage and image processing, simulation, rendering, evaluation, and dataset processing. Anything that must answer in the moment stays on the team's own systems.
- Is on-demand compute cheaper than owning hardware?
- It depends on how even the demand is. A team that runs heavy jobs all day is usually better off owning. A team whose demand is bursty pays for idle hardware at the trough when it owns, and avoids that when it rents by the job. No rates are published yet, so the comparison cannot be made in figures today.
KEEP READING