A rented GPU that looked cheap on the hourly listing cost me more than expected: I left it running overnight after the first image finished. The model took minutes to load, but the idle machine kept billing for hours. This walkthrough covers choosing a GPU, setting up Stable Diffusion on Ubuntu, connecting securely, and avoiding that kind of surprise.
Choose a server that fits the model
For a first run, an NVIDIA GPU with 8 GB of VRAM is a reasonable target for Stable Diffusion 1.5. SDXL is more comfortable with 12 GB or more, though actual requirements depend on resolution, batch size, and optimizations. Check the GPU model and VRAM before renting; a listing’s “GPU memory” and its system RAM are different things.
Disk space matters too. I’d start with at least 50 GB of persistent storage for the operating system, Python dependencies, model checkpoints, and generated images. More is useful if you plan to keep multiple models.
Vast.ai is a good option I’ve used and tested for on-demand GPU rentals, with a range of hardware and prices. PowerVPS is another provider I’ve used and tested for VPS workloads; check its current offerings if you need a longer-lived server or supporting services, and confirm GPU availability before choosing a plan. In either case, compare the total cost, including storage and any charges that continue when the GPU is idle. The Server Rental Guide is a useful resource when comparing rental options and terms.
Start with a clean Ubuntu server
Choose an Ubuntu 22.04 image with NVIDIA drivers already installed if the provider offers one. That avoids spending your first session debugging driver setup. After connecting over SSH, confirm the GPU is visible:
nvidia-smi
You should see the GPU model, driver version, and memory. If the command is missing or reports no devices, check the provider’s GPU image and driver instructions before installing anything else. Driver installation varies by image and provider.
Install the basic tools:
sudo apt update
sudo apt install -y git python3 python3-venv python3-pip
For this example, use AUTOMATIC1111’s Stable Diffusion WebUI. Its first startup installs Python dependencies, so allow time for that, and keep the server’s disk persistent if you want to reuse the installation.
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui
You’ll need a model checkpoint that you’re allowed to use. Download it through the model host’s normal process, then copy it to the server or download it from the server if the host provides a direct link. Some model hosts require accepting a license or signing in. Put the .safetensors file in the WebUI’s model directory:
mkdir -p models/Stable-diffusion
# Copy your checkpoint into models/Stable-diffusion/
For example, from your local computer, copy a file with scp:
scp ./my-model.safetensors USER@HOST:stable-diffusion-webui/models/Stable-diffusion/
Replace USER and HOST with the SSH login details supplied by your provider. This command assumes the clone is in the remote user’s home directory.
Launch it without exposing the UI publicly
Start the WebUI so it listens on the server’s network interfaces:
./webui.sh --listen --port 7860
Keep this process running in your SSH session for the first test. The UI does not require you to open port 7860 to the internet. Instead, keep the provider firewall or security group closed to inbound traffic on that port and create a tunnel from your local machine:
ssh -L 7860:127.0.0.1:7860 USER@HOST
Then open http://127.0.0.1:7860 in your local browser. The tunnel forwards your local port to the WebUI on the server. If port 7860 is already in use locally, choose another local port, for example:
ssh -L 7861:127.0.0.1:7860 USER@HOST
In that case, open http://127.0.0.1:7861. Avoid exposing an unauthenticated image-generation UI directly to the public internet.
Generate a first image and check utilization
Select the checkpoint in the UI, enter a prompt, and start with a modest configuration: 512×512 resolution, one image, and around 20 steps. Once that works, try larger resolutions or other settings.
Watch GPU usage in a second SSH session:
nvidia-smi
A GPU that appears underutilized may be waiting on model loading, disk access, or a setting that sends work to the CPU. Don’t assume a higher step count is always better; it increases generation time, and the visual difference depends on the prompt and sampler.
Two rental habits that save trouble
Keep models on persistent storage. Many rental platforms distinguish between stopping a machine and deleting it. A stopped instance may retain its disk; deleting it may remove the model files too. Check the provider’s rules before you end a session, and copy anything important off the server.
Treat the hourly rate as only part of the cost. A GPU with more VRAM may finish a job faster, but the cheapest listing is not automatically the cheapest run. For a short task, compare estimated runtime as well as hourly price. Also check whether persistent disks are billed while the GPU is stopped. The details vary by provider and rental type.
Shut down when you’re done
Stop the WebUI with Ctrl+C in its SSH session. Then stop or release the rented instance using the provider’s controls. Don’t assume closing SSH stops the server. On some platforms, the machine keeps running—and billing—until you explicitly stop or terminate it.
If you expect to return later, choose the option that preserves the disk and confirm its storage charges. If you no longer need the files, back up the outputs and remove the instance according to the provider’s instructions.
Summary
A rented GPU makes Stable Diffusion accessible without buying hardware, but the setup is only half the job: model storage, network access, and shutdown behavior all affect the experience and the bill. Start with a preconfigured Ubuntu GPU image, verify it with nvidia-smi, use a model you’re licensed to run, and access the WebUI through an SSH tunnel. Most importantly, understand what happens to the server and its disk when you stop renting it.
Top comments (0)