If you want to rent A100 USA capacity for training or batch jobs, Cloudj gives you a direct path: open the GPU deploy page with the A100 selected, type US into the Country field, and compare the independent host machines that are listed right now. You will see two A100 variants, PCIe and SXM4, in single and multi-GPU machines. This article explains the practical difference between them, when a multi-GPU listing is worth it, and how to estimate the full cost of a job, including the part people forget: storage while the instance is stopped.
If you have not yet decided on the US as a location, the GPU cloud in the USA guide covers the US search in general.
A100 on Cloudj in one paragraph
The A100 is a datacenter GPU, listed on Cloudj in its 40 GB version. It needs a higher account level than a new account has; if you try too early, the console says the GPU class is not available at your account level, and you can contact Cloudj support from there. It runs in a container with your chosen template (Ubuntu 22.04 + CUDA, PyTorch + JupyterLab, or your own public Docker image at a higher account level), reached over SSH with a key.
PCIe vs SXM4: the practical difference
Both variants have the same GPU chip and the same 40 GB of memory in the listed version. The difference is how the card connects to the machine and to other GPUs.
| A100 PCIe | A100 SXM4 | |
|---|---|---|
| Form factor | Standard PCIe card | Module on a dedicated board |
| GPU-to-GPU links | Over PCIe, or bridges in some machines | Usually high-bandwidth NVLink between GPUs |
| Power and clocks | Lower power limit | Higher power limit, can sustain higher clocks |
| Best fit | Single-GPU training, inference, batch jobs | Multi-GPU training with heavy communication |
For a single-GPU job, the gap is modest and price often decides. For multi-GPU training where GPUs exchange gradients every step, SXM4 machines usually scale better because of the faster links. Check the model pages for the specifications Cloudj prints, and do not rely on general benchmark claims.
Running the US search
- Open the deploy page with the A100 PCIe, or switch to SXM4.
- Enter
USin the Country field. - Choose the GPU count: 1x, 2x, 4x or 8x. All GPUs are in the same machine.
- Set the disk size you need. It cannot be changed after deploy, and list prices include it.
- Set a minimum reliability and, if you will move a lot of data, a maximum bandwidth price.
- Compare rows on reliability, max duration, download speed and bandwidth price.
Stock changes during the day. If nothing is listed, try the other variant, change the GPU count, add CA, or check later. For batch work, European codes are fine too.
When a multi-GPU listing is worth it
Renting 4x or 8x A100 only pays off if your code actually uses all of them. Ask three questions:
- Does the model fit on one GPU? If yes, data parallelism across several GPUs can shorten training time, but only if your batch is large enough to split.
- Does it not fit? Then you need model or tensor parallelism, and fast GPU-to-GPU links matter. Prefer SXM4.
- Is the job many small independent runs? Then several single-GPU instances may be simpler than one multi-GPU machine.
Before a long run, verify that every GPU is busy:
nvidia-smi --query-gpu=index,utilization.gpu,memory.used --format=csv -l 5If one GPU is busy and the others idle, fix the launch command before paying for more hours. The A100 vs H100 comparison helps if you are unsure whether a newer card would finish faster.
Estimating the cost of a job, including stopped time
Prices change every few minutes, so we do not quote numbers. Instead, use the rates the console shows you before you deploy, which are then locked for that instance. A full estimate has four parts:
- Running cost = running price (GPU + disk) x hours the instance runs.
- Stopped cost = stopped price (storage only) x hours the instance sits stopped.
- Bandwidth = GB downloaded x download rate + GB uploaded x upload rate.
- Deposit = held from your balance at deploy, not a cost. The unused part returns after you destroy the instance, possibly up to 72 hours later.
The second line is the one that surprises people. Stopping keeps your disk and charges storage only, which is cheaper than running but not free. A large disk left stopped for weeks adds up. Stopping also releases the GPU; starting again may wait until that GPU is free. If you will not need the data, destroy the instance.
Billing is per minute, so a run that ends early costs less. The GPU cost estimate guide has a worked template you can copy.
A100 for inference?
The A100 can serve models well, especially those that need more than 24 GB or benefit from large batches. For many inference jobs, though, a consumer card is enough and does not need a higher account level. The RTX 4090 vs A100 for inference comparison walks through that decision.
Protect long runs
- Check the "available until" date; the instance and its disk are removed when it arrives.
- Copy checkpoints off the machine regularly. Hosts are independent with no hardware SLA, and there is no automatic move if one goes offline.
- Keep the dataset somewhere you can re-download quickly.
FAQ
Is the A100 on Cloudj 40 GB or 80 GB?
The A100 PCIe and SXM4 are listed in the 40 GB version.
Can I add GPUs to a running instance?
No. The GPU count is chosen at deploy. Deploy a new machine with a different count if you need it.
Why does a stopped instance still cost money?
Stopped instances keep their disk, so storage is charged. Destroy the instance when you no longer need the data.
Where can I see A100 prices?
Live on the A100 PCIe page, the A100 SXM4 page and GPU cloud.
Next step
Open the deploy page with the A100 PCIe, enter US, and compare single and multi-GPU rows. Estimate running, stopped and bandwidth costs before you start, and copy checkpoints out as you go.