How a GPU run moves from submission to completion.
queued → provisioning → running → complete
↘ failed
↘ timeoutqueued
The run is accepted and validated. Your code is hashed. A cost estimate is calculated based on the timeout and GPU tier. The estimated amount is reserved from your Vault balance.
provisioning
A RunPod serverless worker is assigned. The container starts and any requested pip packages are installed. This typically takes 5-15 seconds for a warm worker, longer for cold starts.
running
Your code is executing on the GPU. stdout and stderr are streamed to R2 storage in real-time. The billing clock is ticking.
complete
Execution finished without error. Files in /output/ are uploaded to R2. The reserve is settled to the exact compute cost and any excess is released back to your Vault.
failed
An unhandled exception occurred. stderr contains the traceback. You are still billed for the time used before failure. The reserve is settled to actual usage.
timeout
Execution exceeded the timeout limit. The process is killed. You are billed for the full timeout duration. Any partial output written to /output/ before the kill is still available.
Volspan uses a three-phase billing model to ensure you always have sufficient balance without overcharging:
1. Reserve
When a run is queued, the maximum possible cost (timeout x GPU rate) is reserved from your Vault. This prevents overdraft if the run uses the full timeout.
2. Settle
When the run completes (or fails/times out), the actual cost is calculated from the real execution time. This exact amount is deducted from the reserve.
3. Release
The difference between the reserve and the settled amount is released back to your available Vault balance immediately.
For long-running tasks, use get_gpu_run to check the current status:
get_gpu_run(run_id="run_8Kx2mPqR...")
// Returns:
{
"run_id": "run_8Kx2mPqR...",
"status": "running",
"gpu": "A100",
"elapsed_seconds": 34,
"timeout": 300
}Most MCP calls to run_on_gpu will block until completion and return the full result. You only need to poll manually if your client has a short request timeout.
When a run hits its timeout, the process receives SIGTERM followed by SIGKILL after 5 seconds. The run status is set to “timeout”. You are billed for the full timeout duration since the GPU was reserved for that period. To avoid unnecessary charges, set realistic timeouts for your workloads rather than using the maximum.
Need help? Reach out at [email protected]