Asynchronous workload
Compute work whose result is not needed at the moment it is requested. The requester submits it, moves on, and collects the output later.
· 2 min read
IN SHORT
An asynchronous workload is compute work whose result is not needed the moment it is requested. The requester submits it and collects the output later, whether minutes or a night later. E31 Network is being designed around this property: a job may wait in a queue until compute is free, runs unattended, and returns its output, with the meter running only while compute is held.
An asynchronous workload is compute work whose result is not needed at the moment it is requested. The requester submits it, moves on, and collects the output later. The gap between asking and receiving can be minutes or a night, and the work is still correct either way.
Why it matters
Asynchrony is the property that makes a shared compute pool workable. If every requester needed an answer immediately, the pool would have to hold enough capacity for every requester's peak at once, which is the same economics as everyone owning their own hardware. When requests can wait, the pool can be smaller than the sum of the peaks and still finish everyone's work.
For a team, asynchrony is also a design choice about where work runs. Splitting a system into the part that must answer now and the part that can answer later is usually the first step toward running the second part somewhere cheaper. The live part stays close to the machine or the user; the asynchronous part becomes a job.
How it works on E31 Network
E31 Network is being designed around asynchronous work. The question the design asks of every candidate workload is whether it can wait for a queue. If it can, it fits. If it must answer now, it stays on the team's own infrastructure, on an edge device, or on the machine itself.
In practice, an asynchronous workload on the network would be submitted as a job and may sit in a queue until compute is free. The meter does not run during that wait. When compute is held, the job runs unattended and isolated, the output is returned to the submitter, and the compute is released. The team is not expected to be present for any of it.
Large-model inference is a useful example of the distinction. The same model can be run asynchronously, where a batch of prompts is submitted and the completions come back as a file, or interactively, where a person is waiting on each reply. The first is a network workload. The second is not, and the design does not intend it to be. Retraining, evaluation runs, footage processing, and simulation sweeps all fall on the asynchronous side by nature; see how it works for how a job moves through the system.
Related terms
Questions this raises
- How long can an asynchronous job wait before it runs?
- As long as its deadline allows. The request a job declares includes when it must be finished, and that is what bounds the wait. The meter does not run while the job is queued, so waiting costs nothing; how jobs of different sizes are ordered fairly is still an open problem the program lists.
- Is asynchronous the same as batch?
- They overlap but describe different things. Batch describes the shape of the work: submitted whole, run unattended, finished with a result. Asynchronous describes the timing: the result is not needed now. Nearly every batch workload is asynchronous, and E31 Network is being built for work that is both.
- What about inference that must be fast but not instant?
- If a person or a machine is waiting on the reply, it is real-time and stays on the team's own infrastructure. If the replies can be collected after the fact, it is asynchronous and can be a job. The design does not offer a middle tier, and no latency figures are published.
KEEP READING