GPU Container Job
What a GPU Container Job is, when to use one, and how you work with it.
A GPU Container Job runs your workload inside a KubeVirt virtual machine instance (VMI) with a GPU and shell access. You connect to it and work on it like a remote computer, installing what you need and running your code interactively.
When to use one
A GPU Container Job fits when you want direct, interactive shell access to a GPU. Use one to train and fine-tune models, run experiments, or process data.
If you only want to call a model over an API, a Managed Inference Job is the better fit. It serves the model for you, so you don't set up or run the environment yourself.
What you get
- Shell access — you install what you need and run commands directly.
- A dedicated GPU — one or more whole GPUs attached to your job.
- A root disk — holds your data across restarts, sized when you create the job.
- A clean environment — the job starts from a base OS image you choose at creation.
- VM-level isolation — each job runs in its own VMI.
How it works
A GPU Container Job moves through a short lifecycle.
- You create the job from the CLI or the web interface.
- CosmicAC schedules it on a GPU node in your cluster and provisions a VMI with the GPU attached.
- When the VMI is running, you connect and work on it.
Restarting the job replaces its VMI but keeps its storage and resources. Deleting the job removes its VMI, resources, and storage.
Deleting a job permanently removes its root disk. Copy anything you want to keep before you delete the job.
For how a job flows through the CosmicAC components, see Architecture.
How you connect
You connect to a running job in two ways.
- CLI shell — the CLI opens a shell on the container, and it behaves like any remote machine.
- SSH over Tailscale — set it up inside the container for longer-lived access from your local machine.
Either way, you run scripts, start processes, and inspect output directly.