Sized before the render starts.
Working memory is planned from the render’s resolution, frame count and step count and reused every step, so it is a property of the job rather than of the prompt.
3 · Interruption and resume
A stop costs the step in flight, not the render.
Sampler state is committed after every step, so a stop loses at most the step that was running.
5
Interruptions
2 were host crashes
40/40
Steps, each computed once
Quality-mode render
0bytes
Difference, resumed vs never stopped
Ultrafast-mode run only
| Attempt | Steps computed | How it ended |
|---|---|---|
| 1 | Steps 0–16 | Host crash |
| 2 | — | Stopped before its first step |
| 3 | Steps 17–18 | Host crash |
| 4 | — | Stopped before its first step |
| 5 | Steps 19–39, then decode and encode | Finished |
The same command was used each time, with --resume after a stop; --checkpoint-every N writes a .vzckpt every N steps. In a separate ultrafast-mode run, a render resumed from its step-4 checkpoint and the same render run straight through produced byte-identical final latents (SHA-256 b7e65f28… in both), with two machine reboots between the runs. The five-interruption quality render was not re-run uninterrupted, so for it the result is a record of resuming from a saved state, not a hash comparison.
Resident mode: urgent work first.
On one resident server a long render pauses at the next step boundary, writes a .vzckpt checkpoint and frees the GPU; an urgent render sent with priority runs; the long render then resumes from its checkpoint. The model stays loaded between jobs. The source describes this as shipping in the current NVIDIA release. The hash evidence above covers stop-and-resume; no separate hash comparison is shown for preemption, and no urgent-job latency is published: not measured for this configuration.
