A machine, not a container.
Yours, down to the kernel.
Take root with sudo. Patch the kernel, load your own modules, mount what you like.
Your orchestrator, not ours.
Your own Docker daemon, or the box joined to your cluster as a GPU node.
1 to 8 GPUs on one box.
Same image, same command, more cards.
What is an on-demand GPU VM?
Most GPU clouds rent you a container. You get a process namespace on a host somebody else configured, with the kernel, the driver version and the container runtime already decided for you. That is fine right up to the moment your work needs something the host does not offer: a different driver, a custom kernel module, a privileged mount, your own container runtime, a kubelet.
An on-demand VM is the machine itself. You get root over one to eight dedicated NVIDIA GPUs, a full operating system you are free to replace, and a network you can reach on your own terms. Docker is something you install, not something you are handed. Kubernetes is something you join, not something you ask us to enable.
Billing does not change: per minute, no minimum rental period, and pausing stops the GPU charge.
One card, or eight of them.
Pick the GPU, then the count. Rates below are for the whole instance, on demand, billed by the minute.
| GPU | Total VRAM | vCPU | RAM | On demand |
|---|---|---|---|---|
| NVIDIA H200 SXM | 141 GB | 28 | 300 GB | $3.99/hr |
| NVIDIA H100 SXM | 80 GB | 16 | 200 GB | $2.69/hr |
| NVIDIA RTX Pro 6000 Blackwell | 96 GB | 28 | 160 GB | $1.89/hr |
| NVIDIA A100 80GB | 80 GB | 16 | 112 GB | $1.49/hr |
| NVIDIA A100 40GB | 40 GB | 16 | 112 GB | $0.89/hr |
| NVIDIA A30 | 24 GB | 16 | 112 GB | $0.41/hr |
| NVIDIA L4 | 24 GB | 32 | 124 GB | $0.44/hr |
vCPU and system RAM scale with the number of GPUs in the instance.
Instance storage is $0.00014/GB/hour. A paused instance is charged storage only.
Bring your own runtime.
The VM ships with GPU drivers and nothing you did not ask for. What runs on top is your call.
Docker
Install the daemon at the version your stack was built against. Pull from your own registry, including private ones. Use the NVIDIA container toolkit, or go around it.
Kubernetes
Join the instance to an existing cluster as a GPU node, or stand up a single-node cluster on the box. We do not run your control plane, which means we cannot break it.
Anything else
containerd, Podman, Apptainer, LXC, or no container at all. It is your kernel, so the list is as long as the kernel allows.
VMs or containers?
Same GPUs underneath, at the same hourly rate. The difference is how much of the stack you want to own, and how fast you want to be working.
| On-Demand VMThis page | Template (managed container) | |
|---|---|---|
| Access | Root on the machine | Root inside the container |
| Kernel and drivers | Yours to choose and patch | Fixed by the host |
| Docker | Install your own daemon | Not available inside |
| Kubernetes | Join or host a cluster | Not available |
| Time to first shell | about 90 seconds | 1.8 seconds |
| Pre-built stacks | You build the image | PyTorch, ComfyUI and more, ready |
| How you reach it | SSH | JupyterLab, VS Code in the browser, or SSH |
| GPUs per instance | 1 to 8 | 1 to 8 |
| Storage across stop and start | Persists | Persists |
| Billing | Per minute | Per minute |
| Pick this when | a container is not a machine | you want to start training right away |
Does the VM slow the GPU down?
Not in our tests. Internal 8× H200 runs put VM and container results within 1.2% of each other across tensor compute, HBM bandwidth, NCCL communication and training throughput. Five of the six were within 0.5%.
A virtual machine adds a hypervisor and a guest OS, and buyers reasonably assume the GPUs pay for it. They do not have to: the physical H200s are assigned to the VM through direct passthrough, CUDA executes on the card itself, and NVLink and NVSwitch still connect the eight GPUs. That is the architecture. Below is the measurement.
| What we measured | Container | VM | VM difference |
|---|---|---|---|
| BF16 matrix multiply, mean of 8 GPUs | 694.1 TFLOP/s | 695.9 TFLOP/s | +0.25% |
| FP16 matrix multiply, mean of 8 GPUs | 623.0 TFLOP/s | 630.3 TFLOP/s | +1.16% |
| HBM copy bandwidth, mean of 8 GPUs | 4.286 TB/s | 4.266 TB/s | -0.47% |
| NCCL all-reduce bus bandwidth, 1 GiB message | 468.2 GB/s | 467.4 GB/s | -0.17% |
| nanochat training, 1 GPU | 205,133 tok/s | 206,131 tok/s | +0.49% |
| nanochat training, 8 GPUs | 1,594,318 tok/s | 1,598,385 tok/s | +0.26% |
Differences in either direction at this scale are run-to-run variation: clocks, temperature and software builds move results by fractions of a percent. Read the table as parity, not as the VM winning four rows of six.
Internal JarvisLabs benchmark, June 2026, run on separate 8× NVIDIA H200 SXM allocations. A JarvisLabs GPU container compared with a KVM VM using direct GPU passthrough. Training was nanochat with FP8 and Flash Attention 3; probe software versions differed slightly between runs. These figures describe the tested systems and workloads, not a universal guarantee.
Four steps, then it is your box.
Pick a GPU, a count and a region
From the dashboard, or with one jl create.
SSH in and take root
About 90 seconds later. Drivers are loaded, sudo is yours, and the rest of the machine is empty.
Pause when you stop
GPU charges stop with it. You pay $0.00014/GB/hour for storage while it sits.
Resume onto the same disk
Your data, your images and your environment are where you left them.
What every VM sits on.
The same platform under every instance, whichever GPU you picked and however many of them.
Your GPUs are never shared. On VMs you control the kernel, drivers and OS. Your own isolated VPC with IP ranges you choose. One filesystem, attached to as many of your own instances as you need.
Admins manage members, allocate credits, and see team usage.
Choose where your data lives. India and Europe today, more regions coming soon.
What people run on them.
Workloads researchers actually run, and the card that handles each one.
| Workload | Runs well on | From |
|---|---|---|
| Training from scratch | NVIDIA H100 SXM | $2.69/hr |
| RL post-training and GRPO | NVIDIA A100-80GB | $1.49/hr |
| Long-running experiment sweeps | NVIDIA L4 | $0.44/hr |
| Fine-tuning open models | NVIDIA A100-80GB | $1.49/hr |
Every VM, from the terminal.
Create, connect, copy files and tear down without opening the dashboard. Your agents can drive it too.
Yes. SSH in and take root with sudo: install what you like, patch the kernel, load your own modules. It is a virtual machine, not a namespace on somebody else’s host.
Yes, your own daemon at your own version, pulling from your own registry. The NVIDIA container toolkit is yours to install or skip.
Yes. The VM behaves as a GPU node: install a kubelet and join an existing cluster, or run a single-node cluster on the box. We do not operate your control plane.
Not measurably, for the GPU paths we tested. In internal 8× H200 runs, VM and container results stayed within 1.2% of each other across tensor compute, HBM bandwidth, NCCL communication and nanochat training throughput, and five of the six results were within 0.5%. The GPUs reach the VM by direct passthrough, so CUDA runs on the card itself.
About 90 seconds to a root shell. If you want a working PyTorch environment in 1.8 seconds instead, that is what Templates are for.
GPU charges stop the moment you pause. You pay storage only, at $0.00014/GB/hour, and your disk is kept.
No. Your GPUs are dedicated to your instance for as long as it runs, and on a VM you control the kernel, the drivers and the OS on top of them.
Eight is the maximum in a single instance. For anything larger, talk to us.
Not every GPU is offered at every count. NVIDIA H200 SXM, NVIDIA H100 SXM, NVIDIA RTX Pro 6000 Blackwell, NVIDIA L4 run at 8 per instance. The rest are capped lower, and the configurations table shows exactly which.
A $10 minimum to add credit. Billing is per minute with no minimum rental period. There is no free trial.