Running GPU jobs from the command line

Most GPU work does not need a dashboard. A job is an image, a command and a GPU type, and a terminal can start it, follow it and end it. The rent.dev CLI starts, lists and ends GPU pods: rent gpu create starts one from a container image on the GPU type you name, rent gpu ls lists them, and rent gpu kill terminates them. Following a pod's logs or running a command in it goes through the rent.dev API. The pods run on your own key at the GPU provider rent.dev connects to, which bills that key until the pod is terminated.

rent.dev: one API for the sandboxes and GPU pods an agent needs.

GPU types with stock reported, cheapest first

Rates as each vendor publishes them, normalised per GPU, from rent.dev's price board, generated 2026-11-14. Rows whose vendor gives no stock reading, or reads none in stock, are left out. See the whole board. Browse the full catalog.

Questions

How do I run GPU jobs from a CLI?

Install the rent CLI from npm (the package is rentdev), store your GPU provider key with rent byok add, then run rent gpu create --gpu-type <type> --image <image>. rent quote --gpu lists GPU types with their hourly rates. Pass environment variables with -e, expose a port with --port, for example 22/tcp for SSH when the image runs an SSH server, and end the pod with rent gpu kill <id> when the job is done. On rent.dev's price board, generated 2026-11-14, the cheapest GPU type rent quote --gpu lists with stock is the NVIDIA GeForce RTX 3070 at $0.13 per GPU hour (RunPod, community, low stock), read 2026-11-11.

How do I run GPU notebooks through an API?

Run the notebook headless instead of in a browser. Start a GPU pod from an image with Jupyter installed, fetch the notebook inside the pod from a repository or a URL, and execute it with jupyter nbconvert --to notebook --execute, or with papermill when you want to pass parameters. The executed notebook keeps every cell's output, so the agent reads results from the file. To work interactively instead, expose port 8888 and open the Jupyter server.

Which GPU runtimes bill per second?

Serverless GPU platforms generally meter per second while a container holds a GPU, and many pod and VM platforms meter per second or per minute for as long as the machine exists. What differs is what keeps the meter running: some count only active requests, others count warm idle time and cold starts. Read the billing terms of the runtime you pick, and terminate pods as soon as a job ends.

What image should a GPU job use?

One that already holds the CUDA version, framework and libraries the job needs, pinned by tag, so the pod starts working as soon as it boots. Installing a framework at start time adds minutes at GPU rates and can break when an upstream release changes.