GPU Environment

Some hubs offer a GPU profile alongside the standard CPU one, for courses whose work actually needs one — computer vision, deep learning, and similar. This page covers what it is, who it’s for, how to get it, and what’s expected of you once you do.

Who it’s for¶

The GPU profile exists for coursework that genuinely needs GPU compute — training or running models that are impractical on CPU alone. It is shared, limited, and more expensive to run than the CPU environment, so it isn’t the default choice for a course that doesn’t need it. If you’re not sure whether your course qualifies, ask when you request access.

Getting access¶

GPU access is arranged with CloudBank before your hub is set up — it isn’t something you turn on yourself from an existing CPU-only hub. If your course needs it:

• A new hub: mention the GPU requirement when you request the hub (see Getting Help).

• An existing hub: reach out asking to add the GPU profile (see Getting Help), and let us know your expected class times so we can plan capacity around them.

Once it’s set up, everyone with access to your hub can select the GPU profile — there’s no separate per-student approval step.

Choosing the GPU profile¶

At the spawn page, pick the GPU profile instead of CPU only. Each GPU is an NVIDIA T4 with 16GB of VRAM, shared between two people at a time.

The 16GB is not divided between you. Both sessions draw on the same pool, so a large model loaded by one person leaves less for the other — see Setting Up Inference.

Inside the GPU profile you choose an image:

• A small-models workshop image with PyTorch and common LLM tooling (transformers, langchain, a local llama-cpp-python build) already installed.

• A TensorFlow/JAX image.

• A plain PyTorch image, if you don’t need the extra LLM tooling and want a smaller environment.

If you don’t see the profile picker¶

The picker only appears when you have no server running. If you already have a session going — most often a CPU one you started earlier and haven’t shut down — logging back in drops you straight into it, with no picker and no chance to switch. It works the same way in reverse: a running GPU session sends you back to GPU rather than offering you CPU.

To get the picker back, stop the server you already have:

1. In JupyterLab, go to File > Hub Control Panel.

2. Select Stop My Server, and wait a few seconds for it to respond.

3. Select Start My Server.

The picker appears on that second start.

Startup time: why it isn’t always instant¶

The GPU profile can start in under 30 seconds, or take several minutes. Both are normal, and the difference comes down to whether a GPU machine is already running:

• A machine that’s already up just needs to start your image, which is fast.

• A brand-new GPU machine needs its NVIDIA driver installed before it can run anything — that alone can take up to about 10 minutes on a fresh machine. The GPU image itself downloads onto the machine in parallel, and that part typically finishes in about 5 minutes, so the driver install is usually what you’re waiting on, not the image.

If you know in advance when your class needs GPUs — a specific lab session, a recurring class time — tell CloudBank ahead of time (see Getting Help). We can have a GPU machine already running and ready before your class starts, which is what gets you the under-30-second case instead of the cold-start one.

Cost and capacity¶

GPU machines cost more than CPU ones

A class of 20 students all using the GPU profile at once needs about 10 GPU machines running simultaneously. It’s worth sharing this with your students so they have a sense of what they’re using — asking them to stop their server when they’re done, rather than leaving it idle, directly reduces how many GPU machines need to stay up.

Shutting down when you’re done¶

A GPU machine you leave running keeps that GPU unavailable to anyone else, even if you’re not actively using it. When you’re finished with a session:

1. In JupyterLab, go to File > Hub Control Panel.

2. Select Stop My Server.

This is worth building into your course’s routine — asking students to stop their server at the end of a lab, not just close the browser tab, is one of the simplest ways to keep GPU capacity available for everyone sharing it.

You don’t have to rely on remembering, though: a session shuts down on its own after one hour with no activity, and after 12 hours total, even if it’s in the middle of a long-running process. Save your work accordingly — a training run or job that needs longer than 12 hours straight won’t be able to finish in one session.

Packages¶

The GPU image’s installed packages are listed in its environment.yml. The CPU image’s are in its own environment.yml.

To request something be added, see Requesting Packages — GPU and CPU requests go to different repos (the GPU image’s own issue tracker, separate from the CPU image’s).

If something in the GPU environment isn’t behaving the way you expect, Getting Help covers where to ask.