Reaver GPUReaver GPU
API Launch App

Network

Renting Compute

Submit a containerized workload, choose a GPU class and region, and pay only for the seconds you actually use. Escrow protects both sides until the job settles.

The workload spec

A job is described by a small spec. The only required fields are an image and a GPU class; everything else has sensible defaults.

json
{
  "image": "docker.io/myorg/trainer:1.4",
  "gpu": "a100",
  "region": "eu",
  "maxMinutes": 120,
  "env": { "DATASET": "s3://bucket/shards" },
  "command": ["python", "train.py", "--epochs", "3"]
}

GPU classes

Request a class, not a card. The scheduler guarantees the requested class or better, so a job tagged rtx4090 may also run on an A100 if that yields a faster match — never on weaker hardware.

ClassVRAM floorBest for
rtx409024 GBRendering, batch inference, small fine-tunes
a10040 GBTraining, large batches, multi-GPU jobs
h10080 GBFrontier training, throughput-critical work

Per-second pricing

You pay for metered GPU-seconds, billed continuously from the moment the container reports healthy until it exits. There is no minimum block and no idle charge — stop the job and billing stops.

The displayed rate is a live market price set by available supply at your requested class and region. When you submit, the network escrows rate × maxMinutes; anything unused is refunded to your wallet at settlement.

Cost control: set maxMinutes as a hard ceiling and --max-rate to refuse matches above a price you choose. The job will queue rather than overpay.

Estimate before you run

bash
reaver quote --gpu a100 --region eu --minutes 120

# → est. 0.41 SOL  (rate 0.0000057 SOL/GPU-sec, 12 nodes available)

Regions

Pin a workload to a geography for data-residency or latency reasons, or leave it open for the cheapest global match.

TagCoverage
naNorth America
euEurope
apacAsia-Pacific
anyCheapest available worldwide

Data and results

Workloads pull inputs and push outputs to your own storage (S3-compatible buckets, IPFS, or a signed URL). Reaver GPU never holds your data at rest — the node fetches inputs at start, runs in an ephemeral sandbox, and the scratch volume is wiped when the job ends.

Job lifecycle

  1. queued — submitted, awaiting a matching node.
  2. scheduled — assigned; image is being pulled.
  3. running — container healthy, metering active.
  4. completed / failed — escrow settles, refund returns.

See the API Reference for the full set of job commands and status fields.