Advanced configuration: what the platform does not protect
The lab panel lets you choose almost everything: size and path of each volume, how many notebooks to open with the budget, what to delete. The platform sets only three things: the disk class, the size's resource cap, and the VRAM each process sees. Everything else is your decision, and some decisions give no warning when they go wrong. This page collects the cases seen in real installations. The reason for each one is in How a lab works under the hood: budget counted on limits, VRAM split by memory, and Kubernetes units.
1. The mount path of the working volume
What you can do: when you create the notebook, change where the Workspace Volume is mounted (/home/jovyan by default).
What happens: the environment always opens and saves in /home/jovyan. If the volume is on another path, your work goes to the container's temporary disk. It looks normal for days and is lost entirely on the first restart (stop, maintenance, node failure). There is no recovery.
What to do: keep the default path. A folder with your name goes inside: /home/jovyan/mi-nombre. Details in The notebook lost its files on restart.
2. Spending the whole budget on a single notebook
What you can do: the size is a divisible budget: one large notebook or several small ones, up to the cap.
What happens: each notebook costs a bit more than what you request (about 0.2 CPU and 0.25 GB of overhead per notebook), and the lab needs to reserve about 0.4 CPU and 1.25 GB for its own components, mainly the Volumes file browser. If your notebook takes everything, the browser never opens (it stays at 0/1 with no message) and a second notebook is rejected. If you request custom resources at exactly the maximum, the notebook itself does not start.
This is how the budget of a size M is split:
What to do: with size S, a notebook of 1 CPU and 4 GB; with M, up to 4 CPU and 16 GB; with L, up to 8 CPU and 32 GB. With custom resources, stay at least 0.5 CPU and 1.5 GB below the Máximo (Maximum) the form shows.
| Size | Recommended notebook | Total lab budget | VRAM |
|---|---|---|---|
| S | 1 CPU / 4 GB | 2 CPU / 6 GB | 2 GB |
| M | 4 CPU / 16 GB | 5 CPU / 18 GB | 12 GB |
| L | 8 CPU / 32 GB | 9 CPU / 34 GB | 24 GB |
The values are those of the reference installation; yours appear in the lab's chips and in GET /workbenches/v1/plan.
2b. The form maximum is not the maximum for a notebook
What you can do: create the lab with Recursos personalizados (Custom resources) by entering exactly the value that Máximo shows (for example, Memoria (Memory) 64Gi) and then a notebook with those same 64 GB.
What happens: the form maximum is the budget of the entire lab. A notebook can never take all of it, because its own container carries a fixed overhead (about 0.25 GB of memory and 0.2 CPU) that is also charged to the budget. The notebook stays at 0/1 and the lab shows "El notebook pedía más de lo que permite tu talla" (The notebook requested more than your size allows), even if the sum looks exact.
Real case from August 2026, with a lab created at the 64 GB cap. The immediate fix was to lower the notebook to 63 GB; the underlying fix, for Saptiva AI to adjust the Client's maximum so it includes the overhead (Lab quotas).
What to do: if you need the maximum, request it for the lab and create the notebook 1 GB and 0.5 CPU below it. If the work truly requires the 64 GB in a single process, the administrator must ask Saptiva AI for a higher ceiling.
3. The GPU you see is not the whole card
What you can do: request 1 GPU in a notebook, a training job, or an experiment.
What happens: the platform caps GPU memory at your size's VRAM. nvidia-smi and torch.cuda.mem_get_info() show 12 GB on a size M even if the card has 96. Compute, on the other hand, is shared with other labs on the same card: performance varies depending on who else is running. A second GPU process in the same lab is rejected by quota while the first one holds the GPU.
If you created the lab with Recursos personalizados and left VRAM empty, the lab has no GPU: any notebook or job that requests one is rejected, even if there are free cards in the Client.
What to do: size the model and the batch_size to your size's VRAM, not the card's. To train with more memory, raise the lab's VRAM with Redimensionar (Resize); and if the work spreads load across cards, request several: the GPU budget is a rectangle of N cards by M of VRAM each, and a two-card notebook sees two distinct physical cards (Multiple GPU cards). A lab still runs only one GPU notebook at a time.
4. Disk classes other than the allowed one
What you can do: choose the storage class when you create a volume (from the notebook form, from Volumes, or from a file applied by hand).
What happens: any class other than the allowed one is rejected silently: the volume is never created and the notebook stays at 0/1. Only the lab's card in Studio shows the reason.
What to do: do not touch the class. The size is yours to choose.
5. Deleting
- Deleting a lab destroys its volumes immediately. There is no trash, retention, or prior backup.
- Deleting a notebook offers to delete its volume too. Uncheck it if you want to keep the data.
- A volume in use by a notebook cannot be deleted; stop or delete the notebook first.
- A volume that outlives its notebook keeps counting against the lab's disk, and the disk is the only axis that cannot be reduced. Creating and deleting several notebooks without checking the option to delete the volume leaves occupied space that you do not recover even by lowering the size.
6. Files uploaded through the Volumes browser
Files uploaded with the browser (magnifying glass icon) before August 20, 2026 ended up with an owner different from the notebook's: they can be read but not deleted or renamed from the notebook. Move them with the same browser or work with a copy. Files uploaded later do not have this problem.
7. Packages and state
pip install outside /home/jovyan, variables, kernels, and background processes are lost on restart. Install on the volume (pip install --user with HOME=/home/jovyan or a virtual environment inside the volume) and keep a requirements.txt there. A long training goes as a lab job, not as a cell (Training).
8. Sharing is done from Studio
The lab panel does not offer Manage Contributors: Studio manages access (Share a lab). What is shared with the whole Client are the pipelines uploaded in the Shared tab and the names, parameters, and metrics of any pipeline (Pipelines).
9. Scaling down with stopped notebooks
What you can do: scale down the lab while it has stopped notebooks.
What happens: the check compares what is running with the target; a stopped notebook uses nothing, so its declared size is invisible and the scale-down passes. When you resume it, it no longer fits and stays at 0/1 without anything having warned you. Nothing is lost: the notebook and its volume are still there.
What to do: before scaling down, check the size of the stopped notebooks you plan to resume. If it already happened, scale the lab back up and start the notebook (Resize a lab).
The UI numbers and what they measure
Four screens show lab resources and they do not measure the same thing. Reading them as if they were interchangeable is the origin of most "the UI says X but I can't use X" reports.
| Where | What it measures | Common trap |
|---|---|---|
| Máximo in the Nuevo laboratorio (New lab) form | Budget ceiling per resource, defined by Saptiva AI for the Client. | It is not the maximum for a notebook (case 2b). |
| Lab chips in Studio | Committed usage / cap, adding up notebooks, jobs, and lab components. | VRAM appears full (24576 / 24576) as soon as a GPU notebook starts, even if it runs nothing: it is a reservation, not usage. In 2.49 the memory in use appears unnormalized. |
| Infrastructure Panel (Dashboard; administrators) | Reserved vs. in use vs. available on the Client's GPUs. | A running lab reserves its size's VRAM even if its GPU is idle; only deleting it or lowering its size gives it back. |
| New notebook form | What that notebook requests. | It is charged with overhead (case 2). With no VRAM in the lab, any GPU requested is rejected (case 3). |
nvidia-smi in the notebook | VRAM the process sees, capped to the size. | Shows 12 GB on a size M even if the card has 96 (case 3). |
| Almacenamiento (Storage) in the chips | Volumes of the allowed class. | A volume in another class does not count and is not created either (case 4). |