Written by the Cyfuture AI Infrastructure Team · Last updated 28 October 2026 · 9 min read

1. Introduction

Few things are more frustrating than paying for GPU time you can't use. You click launch, wait, and the instance either sits in a pending state, comes up but won't accept your SSH key, or boots fine and then reports that no GPU exists. The good news is that these failures fall into a small number of patterns, and most can be diagnosed in a few minutes without opening a ticket.

This guide is based on the issues our infrastructure team sees most often when customers start GPU instances on Cyfuture AI's GPU as a Service platform. It walks through them in the order we'd check them ourselves: cheapest and fastest checks first, deeper investigation later. Commands are for Linux instances; screen labels in the console may differ slightly from the wording used here, so treat the steps as a checklist rather than exact menu paths.

2. Two Kinds of "Fails to Start"

"Fails to start" can mean very different things, and the fix depends on which one you're looking at. Identify yours before changing anything.

3. First Five Minutes: Quick Checks

Before going deep, rule out the simple causes. In our experience these account for a large share of "my instance won't start" reports.

1. Read the status message. The console usually shows a reason next to an Error or Failed state. Copy it exactly; you'll need it later even if you fix the problem.
2. Check your account balance and quota. A depleted balance or a GPU quota limit can block a launch. This is the single most common cause for new accounts.
3. Confirm the instance size you requested. Multi-GPU sizes (2x, 4x, 8x) need more free capacity than a single GPU, so they are harder to schedule at busy times.
4. Wait and retry once. Capacity changes minute to minute. One clean retry after five to ten minutes costs nothing and often works.
5. Try a smaller size or another region. If a 8x instance won't schedule, a 4x or 2x may start immediately, and you can scale up later.

4. Instance Never Reaches Running

Insufficient capacity

The requested GPU type has no free hosts in that region right now. Symptoms: the instance stays in Pending for a long time, or fails with a capacity message. Fixes: retry later, choose a different instance size, or choose another region if your data allows it. If you need guaranteed availability for a project, a reserved term is the more dependable route than on-demand launches.

Quota or balance limits

Accounts have limits on how many GPUs can run at once. If you're launching a fourth GPU against a three-GPU limit, the request will be rejected no matter how much capacity exists. Check your current usage against your limit and request an increase before a planned launch, not during it.

Storage and network conflicts

An instance can fail to provision if the volume you're attaching is already attached elsewhere, sits in a different zone, or has been deleted. Likewise, a network or subnet that has run out of addresses will block the launch. Detach the volume from any other instance, confirm it's in the same location, and retry.

Bad image or startup script

Custom images and cloud-init or user-data scripts can stop an instance from finishing its boot. If you recently changed either, relaunch from the default image first. If that works, the fault is in your customisation, not the platform.

5. Instance Runs but You Can't Connect

When the console says Running but you can't get in, work from the outside in.

1. Check the network path. Confirm the instance has a public IP (or that you're on the right VPN or bastion), and that your firewall or security rules allow inbound SSH on port 22 from your address.
2. Check your key. Use the key pair selected at launch, set permissions correctly, and use the right username for the image.

   chmod 600 ~/.ssh/your-key.pem
   ssh -v -i ~/.ssh/your-key.pem ubuntu@<instance-ip>

   The -v flag shows whether the connection fails at the network, the handshake, or authentication, which tells you which of these three to fix.
3. Open the console or serial log. If the boot hangs on a file system check, a full disk or a failed mount, you will see it there. Don't reboot repeatedly before reading it; the log often shows the cause.
4. Check the disk. A root volume that is completely full can prevent services, including SSH, from starting. If you can get in by any route, run:

   df -h
   df -i

   df -i checks inode usage, which fills up with millions of small files (common with datasets and caches) even when df -h shows free space.

6. Instance Runs but the GPU Isn't Usable

This is the case where you're logged in but the whole point of the instance, the GPU, isn't working. Run these in order and stop at the first one that gives you a clue.

Step 1: Does the system see the GPU at all?

lspci | grep -i nvidia

If nothing is listed, the GPU isn't visible on the PCIe bus. That points to a platform or hardware issue, so skip to When to Contact Support. If the GPU is listed, the hardware is present and the problem is almost certainly software.

Step 2: Is the driver loaded?

nvidia-smi
lsmod | grep nvidia
modinfo nvidia | head

If nvidia-smi reports that it couldn't communicate with the driver, the kernel module isn't loaded or doesn't match the running kernel.

Step 3: Read the kernel messages

sudo dmesg | grep -i -E "nvrm|nvidia|xid"

NVRM lines tell you about driver load failures. Xid lines are error codes reported by the driver; NVIDIA publishes a reference for what each one means in its Xid errors documentation. Some Xids indicate application faults, others hardware problems, so look the number up before assuming the worst.

Step 4: Check the common software causes

• Kernel updated, driver not rebuilt. After an automatic kernel upgrade, the driver module may no longer match. Reboot into the previous kernel or rebuild the module (sudo dkms status shows whether it was built for the current kernel).
• Secure Boot blocking an unsigned module. Check with mokutil --sb-state. If Secure Boot is on and the module isn't signed, it won't load.
• Driver and CUDA version mismatch. The CUDA toolkit inside your container or environment needs a driver new enough to support it. nvidia-smi shows the highest CUDA version the installed driver supports; compare it to what your framework expects.
• Container can't see the GPU. For Docker, confirm the NVIDIA Container Toolkit is installed and that you start containers with GPU access, for example docker run --gpus all.
• Persistence mode off. On some setups the first GPU call after boot is slow or times out. Enabling persistence mode with sudo nvidia-smi -pm 1 can help.

7. Symptom-to-Fix Reference

8. Multi-GPU Instances: Extra Checks

Larger instances add a few failure modes that a single GPU doesn't have.

• Count the GPUs. Run nvidia-smi -L and confirm the number matches the instance you ordered. If you bought four and see three, note which index is missing and send that to support.
• Check each GPU, not just the first. A job that fails only when it touches GPU 5 is a different problem from one that fails everywhere.
• Remember the interconnect. Some instance types connect GPUs over PCIe rather than NVLink. That isn't a fault, but it does mean communication-heavy distributed training behaves differently, and a job that stalls at start-up may simply be waiting on slow inter-GPU synchronisation. For workloads that need NVLink and InfiniBand, see GPU Clusters.
• Check memory before blaming the instance. A model that doesn't fit in GPU memory fails with an out-of-memory error that can look like a start-up failure. nvidia-smi shows how much is already in use, including by leftover processes.

9. Preventing the Problem

If your workload is steady and you want capacity you can count on, comparing on-demand with reserved terms is worthwhile. Reserved capacity removes most of the launch-time uncertainty described in section 4.

10. When to Contact Support

Contact support if lspci doesn't list the GPU, if the GPU count is lower than ordered, if Xid errors keep recurring on a fresh image, or if an instance stays in Error with no cause you can find. Including the right details up front usually saves a round of back-and-forth. Please send:

• Instance ID, region and instance type
• Exact time (with time zone) of the failed start
• The status message shown in the console
• Output of nvidia-smi, lspci | grep -i nvidia and sudo dmesg | grep -i -E "nvrm|xid", if you could log in
• The image used and any startup script
• What you have already tried

11. FAQ

Related: RTX PRO 6000 Price & Specs Guide · RTX PRO 6000: Rent vs Buy · GPU Clusters · Fine-Tuning