The first five minutes on a new GPU VM

The first five minutes on a new GPU VM have one job: prove that the machine you are paying for is the machine you ordered, before you copy a dataset onto it. Paid time starts when provisioning starts, so every check below is a few seconds of typing, and a check that fails is a reason to stop this instance and launch another one, not to debug for an hour.

Connect with the right user: ubuntu, Ubuntu or root

Copy the ssh command from the deployment in the dashboard, because the login user changes with the provider. These are the four VM providers:

This page assumes the template the dashboard labels Bare Metal. It is a plain GPU VM: the provider's Ubuntu image with NVIDIA drivers and Docker, reached over SSH. On the providers that log you in as ubuntu or Ubuntu, put sudo in front of anything that changes the system.

If the first connection is refused, wait a minute and try again. Hyperstack marks a VM ready as soon as it is active with a public IP, without checking that SSH answers. The SSH guide covers keys and ~/.ssh/config, and connection refused covers the cases that do not clear on their own.

Read nvidia-smi before anything else

nvidia-smi
nvidia-smi -L

nvidia-smi is NVIDIA's System Management Interface. Its documentation, checked 1 October 2026, describes the default output: a header with the driver version and a CUDA version, then one block per GPU with its memory use, utilization and ECC counters, then a table of processes. The -L option prints one line per GPU with its UUID, which is the quickest way to count the cards.

Three things to read in that output:

The CUDA Version is the part people misread. NVIDIA describes it as the latest CUDA version supported by the driver, so it is a ceiling and not an installed toolkit. Provider images ship different driver branches, so I read the version off the machine every time. It decides which PyTorch build and which CUDA container tag will work, and the PyTorch install guide uses it.

For a one-line summary you can paste into a support message, query the fields you need:

nvidia-smi --query-gpu=index,name,memory.total,driver_version --format=csv

The --format=csv flag is mandatory with --query-gpu, and nvidia-smi --help-query-gpu lists every field.

Check NVLink with nvidia-smi topo -m on 2, 4 or 8 GPUs

On a VM with 2, 4 or 8 GPUs, print the connection matrix:

nvidia-smi topo -m

NVIDIA's legend for the matrix: NV followed by a number is that many bonded NVLinks, PIX and PXB are paths through one or several PCIe switches, PHB goes through a PCIe host bridge, NODE crosses host bridges inside one NUMA node, and SYS crosses between NUMA nodes.

What is normal depends on the card. The H100 SXM, A100 SXM, H200 SXM and B200 are NVLink through NVSwitch, so expect NV entries between the GPUs. The H100 PCIe and A100 PCIe take 2-way NVLink bridges and the H200 NVL takes 2-way or 4-way bridges, so the matrix is how you find out what your offer has. The RTX PRO 6000, L40, L40S and RTX 6000 Ada have no NVLink at all, so a PCIe path between their GPUs is expected and not a defect. The live offer tables show an Interconnect column, and the multi-GPU page explains what the link means for training.

Check disk, memory and CPU with df, free and nproc

df -h /
lsblk
free -h
nproc

Compare the output with the offer. The line that bites later is df -h /: on QuantaCloud, Massed Compute and Hyperstack the disk is fixed by the offer, and models, Docker images and caches all share it. There is no resizing, so if it is too small, launch a different offer now, or use Verda, where you choose the size at launch.

lsblk also shows a volume if you attached one. Volumes exist on Verda and Hyperstack only, and you format and mount them yourself, as the stop guide shows. When the disk fills mid-job, No space left on device is the next page, and downloading models fast shows how to point the Hugging Face cache at the disk with room.

Test Docker GPU access with one command

sudo docker run --rm --gpus all ubuntu nvidia-smi

This is the sample workload from NVIDIA's Container Toolkit documentation, checked 1 October 2026, minus its --runtime=nvidia flag, since --gpus all alone is how DeployGPU's templates start containers. It runs nvidia-smi inside a stock ubuntu container, so the output should look like the host's. If it fails while the host command works, the NVIDIA Container Toolkit guide covers the fix.

When you later pull a CUDA image, choose a tag at or below the CUDA Version you wrote down. A container that asks for a newer CUDA than the driver supports will not start.

Run a PyTorch check that proves a kernel ran

If PyTorch is installed, this script confirms CUDA works end to end. The install guide covers the install and the Blackwell rules, and the Jupyter template ships it ready.

import torch

print("torch", torch.__version__, "built for CUDA", torch.version.cuda)
print("cuda available:", torch.cuda.is_available())
for i in range(torch.cuda.device_count()):
    print(i, torch.cuda.get_device_name(i))

x = torch.ones(1024, 1024, device="cuda")
print((x @ x).sum().item())

The last line should print 1073741824.0. A 1024 by 1024 matrix of ones times itself puts 1024 in each of its 1,048,576 cells, and the point is that the multiplication ran on the GPU. A True from is_available() only says the driver answered. If torch.version.cuda prints None, you have a CPU build, and Torch not compiled with CUDA enabled is the fix.

Watch GPU usage with nvidia-smi -l and nvtop

nvidia-smi prints one snapshot. To see usage move over time, loop it, log it, or open a monitor:

nvidia-smi -l 2
nvidia-smi dmon -s u
nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used --format=csv -l 5
sudo apt-get install -y nvtop
nvtop

The -l 2 option repeats the full display every 2 seconds, and dmon -s u prints one line per cycle with utilization percentages. Redirect the CSV query into a file when you want a record of a whole run. nvtop is an htop-style monitor for GPUs, and its README lists sudo apt install nvtop for Ubuntu 20.04 and newer.

Read GPU-Util with care. NVIDIA defines it as the percent of time over the sample period during which one or more kernels was executing, so 100 does not mean every core is busy. Low utilization with high memory use often points to the data loader or the CPU, and memory use at the card's total is the cue to read CUDA out of memory. I keep the monitor in a second tmux pane, as keeping jobs running after you disconnect explains.

Five failures and what to do about each

If you decide to give up on the machine, stop it from the dashboard or the API. Do not run shutdown inside it: on QuantaCloud and Massed Compute the health check treats a VM that the provider reports as powered off as lost and deletes it with its disk, and on Verda and Hyperstack a shutdown from inside is invisible to the provider and billing carries on.

Check Estimated time left before you start the job

The dashboard home shows Estimated time left: your balance divided by the combined hourly rate of your running instances. It assumes the same rates and leaves out storage, transfer and future top-ups. Compare it with the length of the job you are about to start. If the balance runs out mid-run the instance is stopped and its disk deleted, so top up on the billing page first, or turn on auto top-up.