GPU Instances · Browse offers
Docs / GPU Instances

Browse offers

Filter the GPU catalog screen in the console — it spans the whole network and defaults to your account region.

Before you launch anything, use the GPU catalog screen to find an offer that matches your requirements.

The catalog screen

The catalog shows a single ranked list of GPU offers across the network, sorted by price and availability. Your account region is applied automatically, so you only need to set the filters you actually care about.

Set filters
GPU, count, budget
Catalog searches network
region-aware
Pick a ranked offer
ready to launch
FilterWhat it does
GPU modelMatch a specific card, e.g. H100, A100, RTX 4090.
GPU countNumber of GPUs required on the host.
Max priceOnly show offers at or under a per-hour price (USD).
GPU catalog with model, count, and max price filters above a ranked list of offers
Set your filters, then scan the ranked list — price and availability, together.
Tip
Whichever offer you pick here is the one you launch from — see Launch an instance. Prices shown are live — see Pricing.

Sizing for training vs. inference

The right filters depend heavily on what you're about to run:

  • Inference (serving a model) — VRAM is the binding constraint: it has to hold the model weights plus room for the request batch. A single higher-VRAM GPU (count of 1) is usually enough for small-to-mid-size models; larger models need either a bigger single GPU or multiple GPUs working together.
  • Training / fine-tuning — needs headroom for weights, gradients, optimizer state, and activations, which adds up to several times the model's inference footprint. Multi-GPU counts are common so the job can shard across devices, and fast interconnect between them matters more than it does for inference.
  • Batch / data jobs — often more about raw throughput than VRAM ceiling; a wider price filter across more modest GPUs can be more cost-effective than chasing the top-end card.
Note
Not sure a raw instance is even what you want? See GPU instance, model server, fine-tuning, or hosted inference? for how these pieces fit together.

Say you need a single mid-size GPU for inference and want to keep the hourly cost down. A typical pass through the catalog looks like this:

  1. 1
    Set the GPU model filter
    Choose the specific card family you need — e.g. A100 — instead of leaving it open to every hardware type.
  2. 2
    Set count to 1
    Most single-model inference workloads need exactly one GPU; only raise this if the model genuinely won't fit on one card.
  3. 3
    Leave max price generous at first
    A loose price filter on the first pass shows the full spread of offers, rather than an artificially short list.
  4. 4
    Scan the ranked list
    Offers are sorted by price and availability — the top rows are your best combination of low cost and readiness right now.
  5. 5
    Tighten the price filter
    Once you know the going rate for that GPU class from the first pass, narrow max price to rule out anything above it.

Reading the ranked results

Each row in the catalog is one offer, ranked primarily by price with availability as a tiebreaker. A lower position in the list usually means either a higher price or hardware that's currently harder to secure. If the top few rows cluster around a similar price, that's a good signal of the going rate for that GPU class right now — worth noting before you set a tighter max price filter.