# GPU cloud cost calculator: estimate GPU, disk, bandwidth, deposit URL: https://cloudj.net/blog/estimate-gpu-cloud-cost Published: 2026-11-12 · Updated: 2026-11-12 > Build your own GPU cloud cost calculator: running and stopped prices, bandwidth per GB, the deposit and its return, plus a worksheet to fill from the console. GPU prices on Cloudj change every few minutes, so no fixed price list will tell you what a job costs. What you can do is build a small GPU cloud cost calculator of your own: a worksheet that takes the numbers the console shows for a specific machine and turns them into a total for your job. This article explains each part of the bill, gives you the worksheet, and shows the common mistakes that make real costs differ from estimates. For where these prices come from in the first place (a live list of machines filtered by country), see the [GPU cloud by location guide](https://cloudj.net/blog/gpu-cloud-by-location-guide). ## The parts of a GPU bill Every GPU instance on Cloudj is billed per minute from your prepaid account balance (in USD; customers in Vietnam can top up by VND bank transfer). The bill has four parts. **1. Running price.** While the instance runs, you pay the running price, which is the GPU price plus the disk price for the disk size you chose. The console shows it before you deploy, and it is locked for that instance. **2. Stopped price.** If you stop the instance, the GPU is released and you pay only for storage, the stopped price. This is much lower, but it is not zero. **3. Bandwidth.** Data downloaded into and uploaded out of the instance is charged per GB, at the bandwidth prices listed on that machine (shown per TB in the results). Different machines list different bandwidth prices. **4. Deposit.** Deploying holds a deposit from your balance: roughly an hour of GPU time, some hours of storage and a bandwidth reserve. It is not a charge. The unused part returns to your balance after you destroy the instance, though it can stay held for up to 72 hours while final bandwidth charges settle. There is no long-term commitment in this model. If a deployment fails to start, nothing is charged and the deposit is returned. ## The worksheet Fill these variables from the console for the machine you are considering: | Variable | Where it comes from | |---|---| | `R` running price per hour | Shown before deploy (GPU + disk) | | `S` stopped price per hour | Storage price for your disk size | | `D` price per GB downloaded | Machine's download bandwidth price (per TB ÷ 1000) | | `U` price per GB uploaded | Machine's upload bandwidth price (per TB ÷ 1000) | | `h_run` hours running | Your estimate, including setup and idle time | | `h_stop` hours stopped | Time you keep the disk while not computing | | `gb_in` GB into the instance | Models, datasets, packages | | `gb_out` GB out of the instance | Results, checkpoints, logs | Then: ```text total ≈ R × h_run + S × h_stop + D × gb_in + U × gb_out balance needed to deploy ≈ deposit + expected spend until your next top-up ``` Keep the worksheet in a spreadsheet; when you compare two machines, copy the row and change only the prices. ## Estimating h_run honestly The most common estimating error is counting only the "real work" hours. A GPU is billed from when it runs, not from when your job starts. Include: - **Setup:** installing packages, downloading models, debugging the first run. - **Data transfer while the GPU waits:** a slow upload with the instance already running is billed GPU time. - **Idle time:** an interactive session left open over lunch. - **Margin:** jobs rarely run exactly as planned. For training, time a short slice (for example 100 steps) on the same GPU model and scale up. For inference services, `h_run` is simply the hours the service is live. ## Stop, or destroy? Stopping looks cheaper than destroying when you plan to come back, but there are two catches. First, stopped time still costs `S` per hour. Second, stopping releases the GPU; someone else may rent it, and starting again waits until it is free. If you need a GPU right away later, you may end up deploying a new instance anyway. A simple rule: if you will be back within a few hours and can tolerate waiting, stop. If you are done for days, copy what you need and destroy. The [stop vs destroy](https://cloudj.net/blog/stop-vs-destroy-gpu-instance) article goes through the trade-off in detail. ## Reducing the total - **Download on the host.** Pulling public models from their source on the instance is faster than uploading and keeps your setup time short. - **Bring back less.** Final checkpoints and outputs, not caches. - **Compare bandwidth prices** for data-heavy jobs, not only `R`. - **Use the price sort.** Results are sorted by total price, lowest first, so for batch work widening the country filter shows more options. The [batch inference in the cheapest region](https://cloudj.net/blog/batch-inference-cheapest-region) article covers this. - **Pick the right card for the job.** A faster card at a higher `R` can lower the total if it cuts `h_run` enough. Compare cost per finished job. - **Destroy promptly** when everything is saved. ## GPU versus VPS billing If part of your system runs around the clock (an API, a database, a queue), it belongs on a VPS, which Cloudj offers with hourly or monthly billing. GPUs are billed per minute only. The [hourly vs monthly VPS](https://cloudj.net/blog/hourly-vs-monthly-vps) article helps you choose for that part; keep the GPU for the work that needs it. ## A worked example with variables A team fine-tunes a LoRA. They estimate 1 hour of setup, 5 hours of training and 30 minutes of evaluation, so `h_run` is 6.5. They download a base model of about 15 GB and upload 2 GB of training data, so `gb_in` is 17. They bring back a 0.5 GB adapter, so `gb_out` is 0.5. They destroy right after, so `h_stop` is 0. ```text total ≈ R × 6.5 + D × 17 + U × 0.5 ``` They plug in `R`, `D` and `U` for two candidate machines from the console and choose the lower total, checking that each machine's "available until" date leaves plenty of margin. Live "from" prices per model are on [GPU cloud](https://cloudj.net/gpu-cloud). ## FAQ ### Is the deposit a fee? No. It is held, not charged. The unused part returns after you destroy the instance, within up to 72 hours. ### Does the price change after I deploy? No. The price shown at deploy is locked for that instance. ### Why is my bill higher than my estimate? Usually setup time, idle time or bandwidth were left out. Track `h_run` and data volume on the next job. ### Am I charged while the host is offline? No. Billing pauses while the host is offline. ## Price your next job Open the [deploy page](https://app.cloudj.net/deploy/gpu), pick two candidate machines and fill in the worksheet for each. Compare live prices on [GPU cloud](https://cloudj.net/gpu-cloud).