Renting H100 cloud USA capacity is usually about one thing: finishing a training or fine-tuning run that is too slow or too large for consumer cards. That changes the questions you ask. Location matters less than whether the machine will last as long as the job, whether one card or eight is the right shape, and what happens to your checkpoints if the host disappears. This article is a planning guide for exactly that.
For US searches in general, see the GPU cloud USA guide.
Before you search: account level
H100s are datacenter GPUs. On Cloudj, what an account can rent depends on its account level, and new accounts start with consumer GPUs. If you select an H100 and the console says "This GPU class is not available at your account level", contact Cloudj support from the console before planning further.
Searching for H100s in the US and Canada
Open the H100 SXM deploy page and set the Country field. For North America:
US, CAThere are two main H100 variants on the list, each with 80 GB of VRAM:
- H100 SXM: the higher-power form factor. Its model page lists higher memory bandwidth than the PCIe card.
- H100 PCIe: a standard PCIe card with lower power and bandwidth.
Search both. Each result shows the country (no state or city), the GPU count, vCPU, RAM, download speed, reliability, max duration, bandwidth price and a Datacenter badge where relevant. If a machine is listed, you can deploy it; stock changes during the day, so check again if nothing fits. Live "from" prices per variant are on the model pages.
Location is a minor factor for training. If no US or Canadian H100 fits, removing the country filter is a perfectly reasonable choice, provided your data rules allow it.
1x or 8x: choosing the machine shape
The GPU count selector offers 1×, 2×, 4× and 8×, always in one machine. Listings with several H100s appear only when a host has them.
| Shape | Good for | Watch out for |
|---|---|---|
| 1× H100 | Fine-tuning up to mid-size models, LoRA on large models, experiments, debugging a training script | Full fine-tuning of large models will not fit in 80 GB |
| 2× or 4× H100 | Data-parallel training of mid-size models, faster turnaround | Your code must actually use all GPUs |
| 8× H100 | Large fine-tunes, sharded training of big models | Most expensive per hour; one fault stops the whole run |
A sensible pattern is to debug on 1× until the script runs cleanly end to end, then move to the larger shape for the real run. Do not debug on an 8× machine. The single vs multi-GPU cloud article explains when splitting across GPUs pays off and when it only adds overhead.
Match the machine's end date to your job
Every machine shows "available until" a date and a max duration in days. When that date arrives, the instance and its disk are removed. For a training run, this is the most important number on the row.
Work it out before deploying:
- Estimate the run length from a short benchmark on the same GPU type (for example, time 100 steps and multiply).
- Add generous margin for evaluation, restarts and data loading.
- Pick a machine whose "available until" date is comfortably later than your estimate.
If no machine lasts long enough, split the job: train in stages, save a checkpoint at the end of each, and resume on a new machine.
Keep checkpoints off the instance
Each machine is an independent host with no hardware SLA. If the host goes offline, billing pauses but nothing moves your job to another machine. Your disk lives on that host. So treat the local disk as scratch space and copy checkpoints elsewhere as you go.
A simple approach is to push each checkpoint to storage you control as soon as it is written:
rsync -avP -e "ssh -p 22" /workspace/checkpoints/ user@your-storage-host:/backups/run-01/Run this from a loop or a training callback. Keep at least the latest two checkpoints off the instance. The backup before a machine's end date article covers this in depth, including what to copy and when.
Estimating the cost
Cloudj does not publish fixed H100 prices; they change every few minutes. Use the console's live numbers and a simple formula:
total ≈ running price per hour × hours running
+ stopped price per hour × hours stopped
+ bandwidth down (GB) × price per GB
+ bandwidth up (GB) × price per GBThe running price includes GPU and disk. Billing is per minute from your prepaid balance, and the price shown at deploy is locked for that instance. Also budget the deposit held at deploy (roughly an hour of GPU plus storage and a bandwidth reserve); the unused part returns after you destroy the instance. The AI training GPU in the USA article has a fuller worked example of planning a run.
Practical tips
- Pick a disk large enough for datasets, base weights and several checkpoints. It cannot be resized later.
- Download base models and datasets on the host from their source rather than uploading from your laptop.
- Watch GPU utilisation on the instance page. A low number usually means your data loader is the bottleneck.
- Destroy the instance as soon as your final checkpoint is safely copied. Stopping keeps charging for storage and releases the GPU.
FAQ
Can I rent an H100 on a new account?
Probably not straight away. H100s need a higher account level. The console tells you, and you can contact support from there.
Is an 8× H100 machine always available?
No. Multi-GPU listings depend on what hosts are listed at the moment. Search and deploy if one fits.
What happens if the host fails during training?
Billing pauses while it is offline and there is no automatic move. Resume from your latest off-instance checkpoint on a new machine.
Does it matter whether the H100 is in the US or elsewhere?
For training, rarely. It matters if your data rules restrict countries or if you move very large datasets from a US source.
Plan your run
Open the H100 deploy page, set the Country to US, CA and compare machines by end date as well as price. All live prices are on GPU cloud.