How long can a job run?

It depends on the job, and there is no published ceiling. When a job is submitted, its request declares three things about time: how much compute it needs, for how long or until done, and when it must be finished. The design intent is that the job then runs unattended for that span, with the meter running while compute is held and stopping at release. A training run that takes most of a night and a processing pass that takes a few minutes are both jobs; one simply holds compute for longer.

What the design has not settled is how those two kinds of job share a pool fairly. That is on the published list of things the program has not solved, and it is the real answer underneath this question.

What the request declares

Of the four parts of a job, the request is the one about time. "For how long" can be a span: "I need eight GPUs for four hours to process this dataset" is a request with a duration built in. It can also be "until done", which suits a training run whose length is known only roughly. And it carries a deadline, "when it must be finished", which is different from duration: a job might need a few hours of compute but not be needed until next week.

That last distinction matters for the queue. A job with a distant deadline can wait longer for compute to be free, and the meter does not run while it waits. A job declared "until done" with a near deadline is harder to place. The how it works page walks through the request alongside the other three parts.

Long jobs and short jobs in one pool

The scheduling problem is easy to state. Imagine a job that needs eight GPUs for four hours arriving beside a job that needs a few minutes. If the long job goes first, the short one waits far longer than its own length. If short jobs always go first, a steady stream of them starves the long one. Any policy that favors one kind penalizes the other, and the program has not published which trade it would make.

Exactly what a job must declare to be scheduled well is itself on the unsolved list. The request as described above is a starting point, and it may not be enough. A job that could say "I can be split" or "I can start late but must finish by then" would be easier to place than one that only says "four hours".

What this means in practice

For now, assume that a job can be long, that the meter would run for the whole of it, and that nothing is owned when it ends. Do not assume a maximum, because none is published. And do not assume the scheduling has been worked out, because the program says it has not.

If you have a job whose length is hard to pin down, that is useful information. The design partners page describes the kind of team the program would want to work through such cases with, and notes that intake is not yet open. Whether a job that cannot wait at all belongs here is a different question, answered at what if my job cannot wait.