Skip to content

Workbenches

A workbench is a Notebook object in your project: one pod running an IDE image - JupyterLab or code-server - with a PersistentVolumeClaim mounted at its home directory, reachable only by the person it belongs to.

It exists because the work that surrounds a model does not fit on a laptop and does not belong in a manifest. Preparing data, trying a prompt against an endpoint, checking what a model actually returns - all of it wants to run beside the models and the GPUs, on storage that survives the laptop closing, without a container build between each edit.

What it is not

A workbench is not where a model is served. It is a development environment with one user; a model deployment is a service with an endpoint, replicas and a lifecycle of its own. Code written in a workbench that becomes something other people call belongs in a deployment, not in the notebook that produced it.

What it costs while it is not being used

The pod holds its CPU, memory and any GPU for as long as it runs, whether or not anyone is connected. Closing the browser tab does not stop it.

Stop releases the compute and keeps the storage. That is the distinction to internalise:

Running Stopped Deleted
CPU, memory, GPU held released released
Home directory there kept, still billed removed with the volume
Time to get back to work none one start from scratch

A GPU workbench left running overnight costs the same as one serving traffic, and a GPU held by an idle workbench is a GPU no model deployment can schedule against.

The platform stops an idle workbench for you after four hours. Idleness is measured from the notebook's own activity, so a cell that runs for six hours counts as busy the whole time and is not interrupted - it is the workbench left open and untouched that gets stopped. Being stopped is the harmless column above: the home directory is kept and the workbench starts again from the same list. Treat it as a safety net rather than a reason not to press Stop, because until it fires the hardware is still held.

Getting a GPU

A workbench takes a GPU by being created on a hardware profile that has one - that is the entire mechanism. The profiles are the same ones model deployments use, so a workbench and a model server compete for the same cards and count against the same project quota.

That shared pool is worth keeping in mind when the two are used together: a notebook holding a card is a card the model you are about to deploy cannot have. The console walkthrough covers choosing the profile.

A CPU workbench does not become a GPU workbench by attaching a GPU

The image decides what can use the card. A CPU image ignores an attached GPU entirely, and a CUDA or ROCm image only works on the GPU generation it was built against - the same pairing that decides whether a model server starts. Pick the image and the profile together.

What is fixed after creation

Changeable
Hardware profile, and so the CPU, memory and GPU yes - takes a restart
Environment variables and attached connections yes - takes a restart
The workbench image yes, but see below
The storage attached at creation no - additional volumes can be attached, the first cannot be swapped

Changing the image keeps the home directory, so anything installed into the image is lost while anything written to the home directory survives. Packages a notebook depends on should be installed from the notebook, into the home directory, or they disappear at the next image change.