How a lab works under the hood

Everything you can and cannot do in a lab is explained by three ideas: a lab is a space with a budget, the GPU is split by memory, and resources are expressed in Kubernetes units. Read them once and the rest of the guide stops being a list of rules.

The architecture and why it is built this way

At a glance:

• Studio is the console. There you request a lab with a size, see its status, its usage chips, and who has access, and open it.
• Frida is Saptiva's control plane. It turns what you request in Studio into real resources on the Client's infrastructure: it reserves the capacity, creates the lab's isolated space, and maintains its budget for as long as the lab exists.
• The infrastructure is already yours: the GPUs, the CPU and memory nodes, and the storage (plus the corporate identity you use to sign in to Studio). Saptiva AI does not replace it; Frida distributes it among labs and models with clear rules.
• The lab panel is where you work. Everything you launch there (a notebook, a job, a volume) is charged to the budget Frida set.

Frida decides, the infrastructure enforces. Each thing you launch is compared with what remains of the lab's budget. If it fits, it starts; if not, it is rejected and Studio shows the reason on the lab's card.

Why it is designed this way:

• Real isolation. Each lab has its own space with network, permissions, and volumes. A lab does not see another lab's, and an error in one does not affect the others.
• Budget, not per-component reservation. You can split the size however you want (one large notebook or several small ones), but the total is never exceeded, even if the cluster is empty. That is what makes it possible to offer predictable capacity to many labs on few GPUs.
• A single source of truth. The budget you see in Studio's chips is the same one the cluster enforces. When Saptiva AI changes a size or a maximum, the change reaches the next start without reinstalling anything.
• Freedom within the budget. The platform sets the disk class, the cap, and the VRAM; the size of each notebook, the volume paths, and what to delete are in your hands. That freedom is what produces the cases in Advanced configuration.

How GPU memory (VRAM) is split

A physical card has a fixed amount of memory (for example 96 GB). The platform does not assign whole cards to labs: it assigns memory fractions.

How it works:

1. Hard memory ceiling. When a GPU process starts in your lab, it receives exactly your size's VRAM. Inside the process, nvidia-smi and torch.cuda.mem_get_info() show that amount, not the card's. If you request more, the allocation fails with a memory error (CUDA out of memory), the same as on a small card.
2. Shared compute. The card's compute time is not split into fractions: it is shared among whatever is running at that moment. That is why the same training can take a different amount of time depending on the neighbors' load. Memory is guaranteed; speed is not.
3. One GPU process per budget. The size's VRAM goes to the first process that requests it (usually your notebook). A second GPU process in the same lab (a training job) is rejected by quota until you release the first one. Hence the rule "stop the notebook before training".
4. Separate pools. The cards that serve InferNode models are different from the ones labs use. A lab never competes with an agent's chat, or the other way around.
5. Reserved from startup. The fraction is reserved when the process starts and released when it finishes or stops. A running, idle notebook reserves its VRAM the same as one that is working. This is what the infrastructure dashboard shows as reservada (reserved) versus en uso (in use).

What it means for you:

You want to	Do this
Train a model that does not fit in your size's VRAM	Create a lab with a larger size and mount the data volume there. Requesting 2 GPUs does not help: the quota is for memory, not cards.
Run a notebook and a training job at the same time	Not with a single size. Launch the training as a job and stop the notebook, or use two labs.
Know how much VRAM you have left	The lab's chips in Studio (VRAM usage / cap).
Get stable performance for a demo	Coordinate with the administrator: the Dashboard shows which labs share your card.

Kubernetes resources and their units

The lab forms, the Frida API, and the rejection messages use Kubernetes notation. Four resources and two families of units.

The four resources

Resource	What it is	Usual unit	Example
CPU	Processor time. 1 is a full core.	Cores or millicores (m)	500m = half a core; 4 = four cores
Memory (RAM)	Process memory. If the limit is exceeded, the process is terminated.	Binary (Mi, Gi)	16Gi = 16 gibibytes
Storage	Size of a persistent volume.	Binary (Gi)	50Gi
VRAM (GPU memory)	Fraction of the card's memory.	MiB without a suffix (in the API also Gi)	24576 = 24 GiB

Requests and limits

Each container declares two numbers per resource:

• request: what it needs guaranteed in order to start. The scheduler looks for a node with that much free room.
• limit: the most it can consume. When it goes over, CPU is throttled and memory terminates the process.

A lab's budget is counted on limits, not on requests, so nobody can exceed the size even if the cluster is empty. That is why the notebook form shows Minimum (request) and, under Advanced Options, Maximum (limit); if you only enter the minimum, the limit is set equal to it.

The units

You write	It means	Watch out
500m	0.5 CPU (500 millicores)	CPU only. 500m of memory is 0.5 bytes, a classic mistake.
2 (CPU)	2 cores
16Gi	16 × 1,024³ bytes = 17.18 decimal GB	It is what the form shows.
16G	16 × 1,000³ bytes = 14.9 Gi	7% less than 16Gi. Always use Gi.
24576 (VRAM)	24,576 MiB = 24 Gi	In the lab form, VRAM goes in MiB without a suffix.
6742763110400m (memory)	6.74 GB in millibytes	Valid but unreadable internal notation; it is the chips defect in 2.49.

Practical rules:

• CPU in m or whole numbers; memory and disk in Gi; VRAM in MiB. No other suffix is needed on this platform.
• A notebook costs more than what you enter. Each notebook gets a fixed overhead of about 200m of CPU and 256Mi of memory added, and the lab reserves about 400m and 1.25Gi for its own components. Details and diagram in Advanced configuration.
• Round down. If the maximum says 64Gi, the largest notebook that starts is 63Gi (why).

Reading a rejection message

pods "mi-notebook-0" is forbidden: exceeded quota: kf-resource-quota,
requested: limits.memory=65792Mi, requests.memory=65576Mi,
limited: limits.memory=64Gi, requests.memory=64Gi

Read it like this: the notebook requested 65792Mi as its memory limit (64 Gi for the notebook plus 256 Mi of overhead); the lab's budget is 64Gi (65,536 Mi); there are 256 Mi too many, so it is rejected. The fix is to lower the notebook to 63Gi. Studio shows this same rejection on the lab's card as "El notebook pedía más de lo que permite tu talla" (The notebook requested more than your size allows).

Next step

• Sizes and quota
• Advanced configuration