The challenges of renting cheap GPUs

GPU compute can be expensive, and finding the right hardware at an affordable price is not always straightforward. Platforms such as Vast.ai and RunPod expand the options available to individual developers and small teams, making GPU capacity accessible without a large upfront investment.

There are plenty of reasons to use that capacity:

• Run a temporary workload. Evaluate a model, process a batch of requests, or run a short experiment, then release the GPU when the work is done.
• Serve an open model on a dedicated endpoint. Choose a model that fits your application, including models with fewer built-in content restrictions, and reserve GPU capacity for your own use.
• Compare GPU types for local LLM inference. Try your intended model on different GPUs to understand memory requirements and inference performance before deciding what hardware to use locally.
• Access more capacity when you need it. Run a model that exceeds your local GPU’s memory, or keep another experiment moving while your own hardware is busy.

A low hourly price makes these uses more accessible. But getting useful work out of an inexpensive GPU still takes more than choosing a listing.

The instance needs to start. Model files need to reach it over the network. Drivers, CUDA, and the application runtime need to work together. If something fails, someone has to diagnose the problem, release the instance, and try another machine.

That work can become a substantial part of an otherwise simple task. A quick model evaluation turns into an afternoon of infrastructure troubleshooting. A dedicated endpoint takes repeated launch attempts to bring online.

Dorbit can take care of these checks, startup retries, and cleanup, making affordable GPU capacity easier to use.

In October 2026, we evaluated Vast machines using offers priced at $1 per hour or less, focusing on NVIDIA GPU architectures supported by Dorbit: Ampere, Ada, Hopper, and Blackwell.

Our checks covered container startup, SSH access, uploading and downloading a 500 MiB test file through S3, and GPU operation. We required S3 upload throughput of at least 100 Mbps and verified the transferred file sizes. On every allocated GPU, we checked CUDA initialization and computation, along with communication and CUDA Graph operations. Each probe had a 20-minute time limit.

Using the final recorded result for each machine, 306 machines met our eligibility criteria, while 78 did not.

These results describe this evaluation and our requirements. They show how much needs to happen between finding an inexpensive listing and having an environment ready to use.

Now imagine doing those checks by hand, one rental at a time.

You wait for a container to start, try to connect over SSH, test transfer speeds, and investigate software errors. If an attempt fails, you release the instance, find another listing, and repeat the process. Meanwhile, the workload you wanted to run is still waiting.

Troubleshooting can also add to the bill. Vast, for example, charges for instances in its active/connected state, with separate storage and bandwidth charges. A running instance can therefore incur costs while you are still getting your application ready. Vast billing documentation

Dorbit validates candidates, records the results, and manages startup retries and cleanup. If a machine cannot bring your endpoint online, Dorbit attempts to find another machine matching your GPU specifications and retry the launch. Your quoted price stays the same, even if the replacement capacity costs Dorbit more.

Runtime charges begin only after Dorbit verifies that your endpoint can serve inference requests. If Dorbit ultimately cannot find compatible capacity or get your endpoint ready, it reports a startup error and releases the reserved credits in full. If your endpoint never becomes ready, you pay no serving charge.