Cómo funciona un laboratorio por dentro
Todo lo que puedes hacer y no hacer en un laboratorio se explica con tres ideas: un laboratorio es un espacio con presupuesto, la GPU se reparte por memoria, y los recursos se expresan en unidades de Kubernetes. Léelas una vez y el resto de la guía deja de ser una lista de reglas.
La arquitectura y por qué es así
A primera vista:
- Studio es la consola. Ahí pides un laboratorio con una talla, ves su estado, sus chips de uso y quién tiene acceso, y lo abres.
- Frida es el plano de control de Saptiva. Convierte lo que pides en Studio en recursos reales sobre la infraestructura del Cliente: reserva la capacidad, crea el espacio aislado del laboratorio y mantiene su presupuesto mientras exista.
- La infraestructura ya es tuya: las GPUs, los nodos de CPU y memoria y el almacenamiento (y la identidad corporativa, con la que entras a Studio). Saptiva no la sustituye; Frida la reparte entre laboratorios y modelos con reglas claras.
- El panel del laboratorio es donde trabajas. Todo lo que lanzas ahí (un notebook, un trabajo, un volumen) se cobra al presupuesto que Frida fijó.
Frida decide, la infraestructura hace cumplir. Cada cosa que lanzas se compara con lo que queda del presupuesto del laboratorio. Si cabe, arranca; si no, se rechaza y Studio muestra el motivo en la tarjeta del laboratorio.
Por qué está diseñado así:
- Aislamiento real. Cada laboratorio tiene su propio espacio con red, permisos y volúmenes. Un laboratorio no ve los de otro, y un error en uno no afecta a los demás.
- Presupuesto, no reserva por pieza. La talla se puede repartir como quieras (un notebook grande o varios pequeños), pero el total no se supera aunque el clúster esté vacío. Eso es lo que permite ofrecer capacidad predecible a muchos laboratorios sobre pocas GPUs.
- Una sola fuente de verdad. El presupuesto que ves en los chips de Studio es el mismo que aplica el clúster. Cuando Saptiva cambia una talla o un máximo, el cambio llega al siguiente arranque sin reinstalar nada.
- Libertad dentro del presupuesto. La plataforma fija la clase de disco, el tope y la VRAM; el tamaño de cada notebook, la ruta de los volúmenes y qué borrar quedan en tus manos. Esa libertad es la que produce los casos de Configuración avanzada.
Cómo se reparte la memoria de GPU (VRAM)
Una tarjeta física tiene una cantidad fija de memoria (por ejemplo 96 GB). La plataforma no asigna tarjetas enteras a laboratorios: asigna fracciones de memoria.
Cómo funciona:
- Techo duro de memoria. Cuando un proceso con GPU arranca en tu laboratorio, recibe exactamente la VRAM de tu talla. Dentro del proceso,
nvidia-smiytorch.cuda.mem_get_info()muestran esa cantidad, no la de la tarjeta. Si pides más, la asignación falla con un error de memoria (CUDA out of memory), igual que en una tarjeta pequeña. - Cómputo compartido. El tiempo de cálculo de la tarjeta no se fracciona: se reparte entre lo que esté ejecutando en ese momento. Por eso un mismo entrenamiento puede tardar distinto según la carga de los vecinos. La memoria sí está garantizada; la velocidad, no.
- Un proceso con GPU por presupuesto. La VRAM de la talla la toma el primer proceso que la pida (normalmente tu notebook). Un segundo proceso con GPU en el mismo laboratorio (un entrenamiento) se rechaza por cuota hasta que liberes el primero. De ahí la regla "detén el notebook antes de entrenar".
- Pools separados. Las tarjetas que sirven los modelos de InferNode son distintas de las que usan los laboratorios. Un laboratorio nunca compite con el chat de un agente, ni al revés.
- Reserva desde el arranque. La fracción se reserva cuando el proceso arranca y se libera cuando termina o se detiene. Un notebook encendido y ocioso reserva su VRAM igual que uno trabajando. Es lo que el Panel de infraestructura muestra como reservada frente a en uso.
Qué implica para ti:
| Quieres | Haz |
|---|---|
| Entrenar un modelo que no cabe en la VRAM de tu talla | Crea un laboratorio de talla mayor y monta el volumen de datos ahí. Pedir 2 GPUs no ayuda: la cuota es de memoria, no de tarjetas. |
| Ejecutar notebook y entrenamiento a la vez | No con una sola talla. Lanza el entrenamiento como trabajo y detén el notebook, o usa dos laboratorios. |
| Saber cuánta VRAM te queda | Los chips del laboratorio en Studio (VRAM uso / tope). |
| Rendimiento estable para una demostración | Coordina con el administrador: el Panel muestra qué laboratorios comparten tu tarjeta. |
Recursos de Kubernetes y sus unidades
Los formularios del laboratorio, la API de Frida y los mensajes de rechazo usan la notación de Kubernetes. Cuatro recursos y dos familias de unidades.
Los cuatro recursos
| Recurso | Qué es | Unidad habitual | Ejemplo |
|---|---|---|---|
| CPU | Tiempo de procesador. 1 es un núcleo completo. | Núcleos o milinúcleos (m) | 500m = medio núcleo; 4 = cuatro núcleos |
| Memoria (RAM) | Memoria del proceso. Si se supera el límite, el proceso se termina. | Binaria (Mi, Gi) | 16Gi = 16 gibibytes |
| Almacenamiento | Tamaño de un volumen persistente. | Binaria (Gi) | 50Gi |
| VRAM (memoria de GPU) | Fracción de memoria de la tarjeta. | MiB sin sufijo (en la API también Gi) | 24576 = 24 GiB |
Requests y limits
Cada contenedor declara dos números por recurso:
- request: lo que necesita garantizado para arrancar. El planificador busca un nodo con ese espacio libre.
- limit: lo máximo que puede consumir. Al superarlo, la CPU se ralentiza y la memoria termina el proceso.
El presupuesto de un laboratorio se cuenta sobre los límites, no sobre las peticiones, para que nadie pueda superar la talla aunque el clúster esté vacío. Por eso el formulario de notebook muestra Minimum (request) y, en Advanced Options, Maximum (limit); si solo escribes el mínimo, el límite se iguala a él.
Las unidades
| Escribes | Significa | Ojo |
|---|---|---|
500m | 0.5 CPU (500 milinúcleos) | Solo para CPU. 500m de memoria son 0.5 bytes, un error clásico. |
2 (CPU) | 2 núcleos | |
16Gi | 16 × 1 024³ bytes = 17.18 GB decimales | Es lo que muestra el formulario. |
16G | 16 × 1 000³ bytes = 14.9 Gi | Un 7 % menos que 16Gi. Usa siempre Gi. |
24576 (VRAM) | 24 576 MiB = 24 Gi | En el formulario de laboratorio, VRAM va en MiB sin sufijo. |
6742763110400m (memoria) | 6.74 GB en milibytes | Notación interna válida pero ilegible; es el defecto de los chips en 2.49. |
Reglas prácticas:
- CPU en
mo en enteros; memoria y disco enGi; VRAM en MiB. Ningún otro sufijo hace falta en esta plataforma. - Un notebook cuesta más de lo que escribes. A cada notebook se le suman unos
200mde CPU y256Mide memoria de sobrecarga fija, y el laboratorio reserva unos400my1.25Gipara sus piezas propias. Detalle y diagrama en Configuración avanzada. - Redondea hacia abajo. Si el máximo dice
64Gi, el notebook más grande que arranca es de63Gi(por qué).
Leer un mensaje de rechazo
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
Se lee así: el notebook pidió 65792Mi de límite de memoria (64 Gi del notebook más 256 Mi de sobrecarga); el presupuesto del laboratorio es 64Gi (65 536 Mi); sobran 256 Mi, así que se rechaza. La corrección es bajar el notebook a 63Gi. Studio muestra este mismo rechazo en la tarjeta del laboratorio como "El notebook pedía más de lo que permite tu talla".