HOW IT WORKS
Submit, rent, run, take the output, release. Described as design intent: the network is being built and no job can be submitted yet.
IN ACTIVE DEVELOPMENT — THIS PAGE DESCRIBES DESIGN INTENT, NOT A SHIPPED SERVICE
01 · THE LIFE OF A JOB
Five steps. You pay for two of them.
Compute is metered only while it is held and running. Queueing, output, and release are not billed time.
01
SUBMIT
the job, its data, and the compute it needs
02
RENT
GPUs are held for the request
03
RUN
batch, queued, unattended
04
OUTPUT
models, frames, results come back
05
RELEASE
the meter stops; the compute is freed
02 · WHAT A JOB IS
Work, data, a request, and what should come back.
A job is the unit of everything on the network: what is scheduled, what is isolated, what is billed.
- THE WORK
- A container or script: the training run, the processing pipeline, the simulation harness, the evaluation suite.
- THE DATA
- The dataset, footage, model weights, or inputs the job reads, staged for the job's duration.
- THE REQUEST
- How many GPUs, roughly how long, and any deadline: tonight, before the shift, by end of week.
- THE OUTPUT
- What should come back when it finishes: a model, processed frames, result files, metrics, logs.
03 · RENTING AND RUNNING
The meter runs while the compute is held, and not otherwise.
ONE JOB, START TO FINISH
ILLUSTRATIVE · NOT TO SCALE
- Billed by the hour
- Stops when the job finishes
- Nothing to own afterwards
Queued, then held
A job waits for capacity that matches its request, then a block of GPUs is held for it. The meter runs only from here.
Unattended
Jobs are meant to run without anyone watching: checkpoint, log, and finish on their own.
Released
When the job completes or is stopped, the compute returns to the pool and the charge ends with it.
04 · YOUR DATA AND OUTPUT
On the network for the job, and not longer.
Staged for the job
Inputs are being designed to live on the network only for the job that uses them, and to be removed afterwards.
Isolated while running
One job's compute, storage, and network are being designed to be separate from every other job's.
Accounted for
What ran, for how long, on what, and what came back is meant to be visible to the team that submitted it.
NO CERTIFICATIONS OR ACCREDITATIONS ARE HELD TODAY; NOTHING HERE SHOULD BE READ AS IMPLYING OTHERWISE
05 · WHAT IT IS NOT
Not a real-time system. Not in the loop.
Nothing a robot needs in the next millisecond should be submitted here. Control loops, navigation, safety systems, and live inference stay on the machine, the edge device, or the customer’s own infrastructure. The network takes the work that can wait for a queue.
06 · WHAT WE HAVEN’T SOLVED YET
Open problems, named.
A service like this earns trust by being specific about where it isn’t finished.
Getting large datasets to the compute
Forty hours of footage is easy to describe and slow to move. How inputs reach the network, and whether they should stay staged between related jobs, is active design work.
Mixed job sizes on shared capacity
Scheduling many small jobs beside a few very large ones, without the small ones waiting unreasonably, is not finished.
Where capacity comes from
How much compute is available at a given hour, and how that is communicated before a job is submitted, has not been settled.
What a job must say about itself
The minimum a submission needs to declare so it can be placed, run, and billed fairly is still being worked out with design partners.