Oh. Basically, ZeroGPU quota is consumed on a reservation basis. Unless the author of that ZeroGPU Space explicitly sets another value in code, each call requests the default 60-second reservation. A failed generation, or one whose actual inference finishes much faster, does not retroactively change the size of that reservation. This follows from the core way ZeroGPU works and is one of the structural trade-offs behind making this class of GPU access affordable, so applying a purely mechanical refund to every failed attempt would be much harder than it sounds.
That said, I think your frustration is completely understandable from the user side.
You interact with an image/video generator, so it is natural to think that the quota is paying for a successfully generated image or video. If the page returns an error and gives you nothing, it feels as though no service was delivered.
The more accurate mental model is different:
You are not purchasing a successful output. You are booking a block of runtime on a shared GPU pool.
So, yes: a failed attempt can consume the reserved quota even when no usable result reaches you.
The current ZeroGPU documentation describes ZeroGPU as shared infrastructure that dynamically assigns and releases GPUs. A Space author marks the GPU portion of the application with @spaces.GPU
and may specify a duration
. If no duration is supplied, the default request is 60 seconds.
Hugging Face’s more detailed ZeroGPU implementation guide and its quota reference make the accounting model clearer:
@spaces.GPU
call requests the default 60 seconds;xlarge
requests count at twice the declared duration.This does not necessarily mean that a physical GPU is kept idle for the entire reserved 60 seconds. The GPU worker can finish and be released earlier. The quota reservation, the actual worker lifetime, and the delivery of the final image/video are three separate layers.
For a practical next step, I would avoid repeatedly retrying the same broken Space. Save the Space URL, the exact error text, and the approximate time of the attempt. So the basic behavior you observed is consistent with ZeroGPU’s reservation model, but your UX complaint is still valid: the reservation size, GPU acquisition stage, retry count, and exact failure point are not always visible to the visitor.
For a consistently broken generator, reporting the exact error to its author is more useful than spending another reservation on repeated attempts. For failures across several unrelated Spaces—or a repeated No GPU was available for you
sequence—the broader ZeroGPU Community is the better route.