EXAMPLES
Each one is a job with a beginning and an end: submit it, rent the compute, run it, take the output, release the compute.
ILLUSTRATIVE REQUESTS, NOT CUSTOMERS — E31 NETWORK HAS NOT SHIPPED
PROCESS A DATASET
“I need eight GPUs for four hours to process this dataset.”
A one-off run with a known shape.
A team has a large dataset to push through a model or a transformation. They know roughly what it needs and roughly how long it will take. They do not have eight idle GPUs, and buying them for one afternoon makes no sense.
THE JOB
- SUBMIT
- The processing container, the dataset, and a request for eight GPUs for about four hours.
- RENT
- Eight GPUs are held for the job once capacity matches the request. The meter starts.
- RUN
- The dataset is processed as one batch. Nobody watches it.
- OUTPUT
- The processed dataset and a log of what ran come back to the team.
STAYS ON YOUR OWN SYSTEMS
Whatever that dataset feeds in production stays on the team's own systems. The network only did the processing.
The job finishes. The eight GPUs return to the pool. The charge covers the hours they were held, and nothing after.
RETRAIN OVERNIGHT
“I need compute tonight to retrain my model.”
A deadline, not a schedule.
A robotics company has a week of new fleet data and a model that should learn from it before the next shift. The training run is heavy, it is needed once, and it is needed by morning.
THE JOB
- SUBMIT
- The training container, the new data, the current weights, and a request for compute tonight.
- RENT
- A block of GPUs sized to the run is held when the window opens.
- RUN
- Training runs through the night, checkpointing as it goes.
- OUTPUT
- A new model and its evaluation results are ready in the morning.
STAYS ON YOUR OWN SYSTEMS
The robots keep running their current model, their navigation, and their safety systems on their own compute the whole time. Nothing about the fleet depends on the network.
The run completes. The compute is released. The company deploys the new model through its own process, on its own schedule.
WORK THROUGH FOOTAGE
“I have forty hours of warehouse camera footage that needs processing.”
A backlog, not a stream.
A warehouse has a camera estate that records all day. The live feeds are handled on site. The backlog is a different problem: forty hours of footage to run through a vision model for review, labelling, or analysis.
THE JOB
- SUBMIT
- The vision pipeline, the footage, and a request for enough GPUs to get through it in a working day.
- RENT
- GPUs are held for the batch.
- RUN
- Forty hours of footage is processed in parallel, as one job, not forty.
- OUTPUT
- Detections, flagged segments, labels, or summaries come back to the operations team.
STAYS ON YOUR OWN SYSTEMS
Live monitoring, anything tied to a door or a conveyor, and any real-time detection stay on the site's own systems. The network never sees the live feed.
The batch finishes. The compute is released. Next week's backlog is next week's job.
RUN THE SIMULATIONS
“I need to run ten thousand simulations.”
Many small runs, one job.
An engineering team wants to test a layout change, a planner update, or a control policy across ten thousand scenarios before anything real moves. One workstation would take weeks.
THE JOB
- SUBMIT
- The simulation harness, the scenario set, and a request for enough compute to run them in parallel.
- RENT
- A block of GPUs is held for the sweep.
- RUN
- Ten thousand runs, fanned out across the block, each writing its result.
- OUTPUT
- Aggregated results, failures worth looking at, and the raw outputs for the ones that matter.
STAYS ON YOUR OWN SYSTEMS
The real machines are not involved. Whatever the team decides to change afterwards is deployed through their own systems.
The sweep completes. The compute is released. The team paid for a sweep, not for a cluster.