Can it wait for a queue? The one test that sorts a workload
One question separates the jobs that belong on E31 Network from the work that must stay on your own machines: whether the work can wait for a queue.
· 4 min read
IN SHORT
A workload belongs on E31 Network if it can wait for a queue. Batch and asynchronous jobs such as training, batch inference, footage processing, and simulation sweeps can wait, so they are being designed to run on the network. Anything that must answer in the moment, such as robot control or live perception, stays on local infrastructure.
Every team that looks at rented compute eventually asks which of its work should go there. The answer usually arrives as a long document about latency budgets, data gravity, and risk. E31 Network is being designed around a shorter answer. The test is a single question: can the work wait for a queue.
If it can, it is a network job. If it must answer now, it stays with you. That is the whole test, and almost everything else about the network follows from it.
Why a queue is the right dividing line
The network is a pool of compute that teams rent by the hour for the duration of a job. Compute that is held for one job is not available to another, so a job that arrives when the pool is busy has to wait. Queues are not a failure mode in this design; they are part of it. A job that can sit in a queue until compute frees up is exactly the kind of job the pool is being built to run.
A queue also makes the economics work. The meter is being designed to start when compute is held for the job and stop when the job finishes. It does not run while the job is queued. A team that can tolerate waiting pays only for the hours the compute actually works, which is the point of renting rather than owning.
Work that cannot tolerate waiting breaks both of those properties. It would need compute held in reserve at all times, which is ownership by another name, and it would need to skip the queue, which takes compute from jobs that were already waiting. Neither fits a shared pool.
Applying the test to real work
Run the test on the jobs a team actually has. A model that needs to be retrained on this week's data can wait; it is a network job. A backlog of warehouse camera footage that nobody has processed yet can wait; it is a network job. A sweep of simulations whose results feed next month's design review can wait. A batch of inference over a dataset that was collected last quarter can wait.
Now the other side. A control loop that steers a moving machine cannot wait. A perception model that tells a robot what is in front of it right now cannot wait. A safety function cannot wait, and neither can an operator tool that has to respond while a person is standing at a console. An assistant that must answer a question in the moment cannot wait either, even if the same model could happily answer a backlog of questions overnight.
The pattern is that the same kind of computation can land on either side depending on when the answer is needed. Inference is not inherently real-time or batch. Inference that answers a live camera is real-time; inference over a stored archive of camera frames is batch. The test sorts by timing, not by the shape of the math.
Edge cases that look harder than they are
Some work seems to sit between the two. A nightly report that the morning shift depends on feels urgent, but it has a window of several hours, and a window that wide is a queue wait. It passes.
A dashboard that refreshes every few minutes feels like a batch job, but if people are watching it to make decisions, the useful window is short and the work belongs on your own systems. It fails.
A long training run that someone wants to watch feels interactive, but the training itself does not need the watcher. The run can wait to start and can run unattended once it does. It passes. Only the watching is real-time, and the watching is not the job.
When a case is genuinely unclear, ask what happens if the result arrives several hours later than hoped. If the answer is that nothing breaks and the work is still useful, it can wait for a queue. If the answer is that a machine stops, a person is blocked, or a decision was made without it, it cannot.
What the test does not decide
The test says where a workload runs. It does not say the network is ready to run it. E31 Network is a technical preview; no jobs can be submitted yet and no rates are published. The test is offered now so that teams can sort their work ahead of time and arrive with a clear picture of which jobs they would submit and which they would keep.
It also does not replace the local side. Real-time work still needs dedicated infrastructure, edge devices, or the customer's own systems, and the network is not being designed to replace any of those. Teams that want AI compute in their own rack for that work have Element 31's sibling product, Czar. The network is for the jobs that do not need to own compute. The pages on workloads and how it works walk through both halves.
Questions this raises
- Does a short job fail the test just because it is small?
- No. Size has nothing to do with the test. A job that takes a few minutes and can run at any point tonight passes; a job that needs an answer within the next heartbeat of a machine fails, however small it is.
- What happens to a job while it waits in the queue?
- It holds its place until compute is free. The design intent is that the meter does not run while a job is queued, so waiting costs nothing but time. Once compute is held for the job, the rent step begins and the meter starts.
- What if a workload is almost real-time but could tolerate a little delay?
- Ask whether the delay could stretch to a queue wait without harm. If a few hours of waiting would be acceptable, it is a batch job. If the useful window closes in seconds, treat it as real-time and keep it local.
KEEP READING