Saltar al contenido principal

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:

  1. Techo duro de memoria. Cuando un proceso con GPU arranca en tu laboratorio, recibe exactamente la VRAM de tu talla. Dentro del proceso, nvidia-smi y torch.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.
  2. 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.
  3. 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".
  4. 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.
  5. 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:

QuieresHaz
Entrenar un modelo que no cabe en la VRAM de tu tallaCrea 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 vezNo con una sola talla. Lanza el entrenamiento como trabajo y detén el notebook, o usa dos laboratorios.
Saber cuánta VRAM te quedaLos chips del laboratorio en Studio (VRAM uso / tope).
Rendimiento estable para una demostraciónCoordina 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

RecursoQué esUnidad habitualEjemplo
CPUTiempo 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
AlmacenamientoTamañ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

EscribesSignificaOjo
500m0.5 CPU (500 milinúcleos)Solo para CPU. 500m de memoria son 0.5 bytes, un error clásico.
2 (CPU)2 núcleos
16Gi16 × 1 024³ bytes = 17.18 GB decimalesEs lo que muestra el formulario.
16G16 × 1 000³ bytes = 14.9 GiUn 7 % menos que 16Gi. Usa siempre Gi.
24576 (VRAM)24 576 MiB = 24 GiEn el formulario de laboratorio, VRAM va en MiB sin sufijo.
6742763110400m (memoria)6.74 GB en milibytesNotación interna válida pero ilegible; es el defecto de los chips en 2.49.

Reglas prácticas:

  • CPU en m o en enteros; memoria y disco en Gi; 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 200m de CPU y 256Mi de memoria de sobrecarga fija, y el laboratorio reserva unos 400m y 1.25Gi para 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 de 63Gi (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".

Siguiente paso