GPU Container Job
What a GPU Container Job is, when to use one, and how you work with it.
A GPU Container Job gives you a KubeVirt virtual machine instance (VMI) with one or more whole GPUs. You open a shell in the VMI and use it like a remote machine. Install what you need and run your code.
When to use one
A GPU Container Job fits when you want shell access to a GPU. Common tasks include training and fine-tuning models, running experiments, and processing 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 the environment yourself.
What you get
- Shell access in the VMI: an interactive session for installing what you need and running your code.
- Dedicated GPUs: one or more whole GPUs passed through to your job.
- Root disk: persistent storage that holds your data across restarts. You set its size when you create the job.
- Clean environment: a base OS image that you choose at creation.
- VM-level isolation: a separate VMI for each job.
How it works
When you create a GPU Container Job, CosmicAC allocates the GPUs that the job needs and creates the job's VMI. The VMI boots on a node in your cluster and claims its GPUs through passthrough. After the VMI is running, you access it through a shell.
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. Before you delete a job, copy everything you want to keep.
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: a shell in the VMI that you open with the CLI.
- SSH over Tailscale: longer-lived access to the VMI from your local machine. You set up SSH and Tailscale in the VMI first.
Either way, you run scripts, start processes, and inspect output directly.