Compare the cost of a completed job, not just the posted hourly rate. Start with the exact GPU class you need, then check region, purchase model, quota, capacity, storage, network transfer, and interruption risk.
Start with a comparable unit
Cloud GPU SKUs are not interchangeable just because they use the same NVIDIA marketing name. Compare the same practical shape:
- GPU model and memory, such as H100 80 GB vs H100 NVL
- GPU count per VM
- CPU, RAM, local SSD, and network bandwidth
- Interconnect requirements for multi-node training
- Region and zone
- On-demand, spot, reserved, committed, or capacity-reserved price
- Operating system, driver, and container image requirements
AWS, Google Cloud, Azure, and specialist GPU clouds publish pricing in different formats. Decide what counts as an acceptable target before comparing any prices.
Why list price is not enough
The useful number is usually dollars per successful run. Hourly price is only one input.
Quota can block a launch even when the public price looks good. Regional capacity can make a GPU unavailable at the moment you need it. Spot instances can lower compute cost but increase restart risk. Storage and egress can matter when training data or model artifacts are large. Startup time matters when jobs are short or repeated many times.
- GPU-hour price: useful for budgeting and coarse provider comparison.
- Completed-job price: better for real decisions because it includes retries, failed launches, storage transfer, and idle setup time.
A practical comparison workflow
- Choose acceptable GPU classes, not one provider SKU. For example, decide whether an H100, H200, B200, A100, L40S, or A10G can run the workload.
- List allowed regions. Remove regions that violate latency, data residency, or team access requirements.
- Pull current on-demand and spot prices from each provider's public pricing page or pricing API.
- Check quota and launch permissions in each account.
- Run a small Docker-based smoke test in every candidate target.
- Track finished-job cost over time. Use the winner for similar jobs, but re-check prices and capacity before large runs.
Where anycloud fits
anycloud is useful when you already have multiple cloud accounts or credit pools and want one submit path. Instead of hard-coding one provider and region, you submit a Docker image or Python job and anycloud can pick the cheapest valid target across the cloud accounts you've connected when compute credentials and region are left unpinned.
That does not replace the fundamentals above: you still need usable credentials, quota, data placement, and a workload that can run portably. It does reduce the manual work of comparing targets and rerunning the same job flow across clouds.