Redimensionar un laboratorio
Un laboratorio no se queda con la talla con la que nació. Desde Studio 2.58, el propietario puede subirlo, bajarlo o darle una combinación de recursos a medida sin crear otro ni mover datos. Los archivos, los notebooks y los volúmenes se quedan donde están.
La regla que gobierna todo es una sola, y no es "subir o bajar": es si lo que ya está corriendo cabe en el destino. De ahí sale todo lo demás.
Antes de empezar
- Ser el propietario del laboratorio. Un editor puede usarlo, pero no cambiarle el tamaño.
- El laboratorio en estado Listo. Uno que se está creando o eliminando no se puede redimensionar todavía.
- Saber qué corre dentro. El diálogo te lo dice, pero conviene entrar sabiendo si vas a interrumpir el trabajo de alguien (Compartir).
Los cinco ejes
Un laboratorio es un presupuesto con cinco ejes. Cuatro suben y bajan; el disco solo sube.
| Eje | En el diálogo | Sube | Baja | Qué mide |
|---|---|---|---|---|
| CPU | CPU | Sí | Sí | Núcleos que pueden usar todos tus procesos a la vez. |
| Memoria | Memoria | Sí | Sí | Memoria RAM total del laboratorio. |
| Tarjetas | Tarjetas | Sí | Sí | Cuántas tarjetas de GPU puede tener un notebook a la vez. |
| VRAM | VRAM por tarjeta | Sí | Sí | Memoria de GPU que ve cada proceso, por tarjeta. |
| Disco | Disco | Sí | No | Espacio total de los volúmenes del laboratorio. |
Los cuatro primeros son contabilidad: la cuota se cobra cuando arranca cada proceso, así que un tope nuevo aplica al siguiente notebook que lances. El disco es distinto porque un volumen no se encoge y nadie devuelve espacio: bajar el tope solo dejaría un laboratorio que ya no puede crear ni ampliar volúmenes. Por eso el disco es un trinquete: si pides menos, se conserva el valor vigente y la respuesta te lo avisa.
La regla
Lo que decide si un cambio es seguro no es la dirección. Bajar de L a M con un notebook pequeño no interrumpe a nadie. Subir la CPU y bajar la memoria a la vez parece una ampliación y puede obligar a detener el notebook, porque en el eje de memoria ya no cabe. Studio mide lo que está en uso, lo compara con el destino eje por eje, y solo pide detener cuando de verdad hace falta.
Nada se detiene por su cuenta. Si el cambio no cabe, la petición falla y te nombra el estorbo; para que se aplique tienes que confirmarlo tú, en el diálogo, viendo qué notebook es y de quién.
Las dos cuentas
Antes de aplicar nada, la plataforma hace dos preguntas distintas, y las dos tienen que dar que sí. Confundirlas es la causa de casi todas las sorpresas.
¿Cabe el PRESUPUESTO? Σ(cuotas de todos los laboratorios) + delta ≤ (capacidad − cargas que no son laboratorio) × factor
¿Cabrá el PROCESO? alguna máquina con CPU y memoria libres para el notebook + N tarjetas con M de VRAM libre cada una
Primera cuenta: ¿cabe el presupuesto? No pregunta si hay sitio ahora mismo, sino si la instalación puede respaldar la promesa. Se suma lo que ya está prometido a todos los laboratorios (sus cuotas, estén corriendo o no), se le añade lo que esta petición pide de más, y se comprueba que el total quepa en lo que la instalación tiene una vez descontado lo que no es un laboratorio (Studio, la identidad, el servicio de modelos).
Ese "lo que pide de más" es el delta: la diferencia entre lo que el laboratorio tiene hoy y lo que tendría después. Se usa la diferencia y no el total porque el laboratorio ya ocupa su parte de la suma; contarlo entero lo cobraría dos veces.
| Cambio | Delta | Consecuencia |
|---|---|---|
| Subir de 2 a 5 CPU | +3 | Se comprueba capacidad para 3 CPU más. |
| Bajar de 5 a 2 CPU | −3 | Bajar nunca se rechaza por capacidad: libera, no pide. |
| Crear un laboratorio desde cero | el laboratorio entero | Es el único caso en que el delta es el total. |
El factor es el permiso explícito para sobrevender. En CPU y memoria se puede: un laboratorio rara vez usa todo lo que tiene, y pasarse solo deja un proceso esperando, que se resuelve cuando algo libera sitio. Hoy vale 1 (sin sobreventa) mientras no haya datos de cuánto del presupuesto concedido se usa a la vez. En VRAM y disco no existe factor: pasarse ahí no se recupera.
Segunda cuenta: ¿cabrá el proceso? Que el presupuesto quepa en la suma no significa que exista una máquina capaz de alojarlo. Una instalación con 40 CPU libres repartidas entre diez máquinas no puede correr un notebook de 9 CPU. Así que además se comprueba que alguna máquina concreta pueda alojar el notebook y, si pide GPU, que haya N tarjetas distintas con M de VRAM libre cada una, no N×M sueltos: la VRAM no se suma entre tarjetas, un proceso vive en la que le toca.
Cada eje se compara contra un denominador distinto, con una política distinta:
| Eje | Se compara contra | Política | Por qué |
|---|---|---|---|
| CPU y memoria | Capacidad menos las cargas que no son laboratorio | Factor configurable | Sobrevender solo produce un proceso en espera, y eso se recupera. |
| Tarjetas | Nada a nivel de instalación | Techo por laboratorio, más el encaje por tarjeta | Varios laboratorios comparten cada tarjeta por diseño; sumar tarjetas concedidas modelaría asignación exclusiva, que no es como funciona. |
| VRAM | La VRAM física de las tarjetas asignadas a laboratorios | Estricta | No se recupera, y el usuario se queda sin salida. |
| Disco | El tamaño declarado del almacenamiento compartido | Estricta | Un almacenamiento lleno rompe las escrituras de todos los laboratorios a la vez, no solo del que se pasó. |
Un ejemplo con cifras ilustrativas. Un laboratorio quiere pasar de talla S a M; en CPU eso es de 2 a 5, así que el delta es +3. Cada renglón es un término de la primera cuenta, en el mismo orden:
ya prometido a los laboratorios 40 CPU
delta de esta petición + 3
───────
total a respaldar 43 CPU
capacidad de la instalación 96 CPU
menos lo que no es un laboratorio − 16 Studio, identidad, servicio de modelos
───────
disponible para laboratorios 80 CPU
factor de sobreventa × 1 sin sobreventa
───────
techo 80 CPU 43 ≤ 80 cabe
Y la segunda cuenta sobre el mismo caso: ¿hay una máquina con 5 CPU y 18 GB libres para el notebook? Si además pidiera 2 tarjetas de 12 GB, ¿hay dos tarjetas distintas con 12 GB libres cada una? Las dos tienen que dar que sí.
El orden en que se aplica
El orden no es estético: los dos fallos posibles no son simétricos, y se elige por cuál es recuperable.
- Leer el laboratorio (su cuota y su uso vivo).
- Comprobar que nadie lo cambió desde que lo leíste; si sí, se rechaza y vuelves a empezar.
- Resolver el destino contra el plan del Cliente; si un eje supera el techo, se rechaza con el eje y el límite.
- Aplicar el trinquete a los ejes que no bajan (el disco): destino efectivo, con aviso.
- Si el destino es igual al actual, no se hace nada.
- Regla de admisión,
uso ≤ destino: si falla y no diste consentimiento, se rechaza nombrando el estorbo. - Capacidad de la instalación, solo en los ejes que suben: liberar recursos no puede requerir permiso.
- Detener notebooks, solo si hace falta.
- Aplicar la cuota nueva.
- Releer y devolver el resultado.
Comprobar y aplicar (pasos 6 a 9) ocurren como una sola operación para toda la instalación, no por laboratorio, porque el denominador es compartido: dos peticiones a la vez no pueden colarse en el mismo hueco.
Detener antes de aplicar. Si se aplicara la cuota primero y luego fallara el detener, el laboratorio quedaría con menos presupuesto del que usa y notebooks vivos: el peor estado, y sin nada que lo repare solo. Si se detiene primero y falla el aplicar, perdiste una sesión pero el laboratorio queda sano y relanzable.
| Dónde falla | Qué queda | Quién lo repara |
|---|---|---|
| Al detener | Nada aplicado, laboratorio intacto | Reintentar |
| Tras detener, al aplicar | Notebooks detenidos, cuota anterior | Tú reintentas, y la respuesta te lo dice; entra en caliente porque el uso ya bajó |
| La cuota tarda en converger | Redimensionando con antigüedad visible | Espera; si persiste, soporte |
| Tras aplicar, al arrancar un proceso | Aparece en los rechazos de la tarjeta | Tú, con el motivo a la vista |
Pasos
- En Laboratorio, en la tarjeta del laboratorio, pulsa Redimensionar.
- Elige una talla nueva o ajusta los recursos. La tabla del diálogo compara Actual, Nuevo y En uso por cada eje, y la columna Aviso marca lo que ese cambio implica: Requiere detener notebooks en ejecución o El disco no se puede reducir; se mantiene el valor actual.
- Pulsa Aplicar. Si algún eje no cabe, el botón dice Detener y aplicar y antes se abre la confirmación Se detendrán notebooks en ejecución, con la lista Se detendrá: (nombre del notebook y dueño). Los datos del laboratorio permanecen en el volumen; no se pierden.
- El laboratorio pasa a Redimensionando con el aviso "Aplicando el nuevo tamaño…" y vuelve a Listo en unos segundos. Si tarda más de lo normal verás "Esto está tardando más de lo esperado. El cambio sigue en curso": espera, y si no cambia, escribe a soporte.
Cuando hay que detener, Studio detiene primero y aplica después. Si algo falla a medio camino, el laboratorio queda sano y relanzable, con la cuota anterior; nunca queda con menos presupuesto del que ya usa.
Lo que un cambio hace y no hace
Subir no agranda un notebook que ya corre. El tamaño de un notebook se fija al arrancarlo. Al subir el laboratorio, el presupuesto nuevo queda disponible, pero el notebook vivo sigue con su tamaño de siempre. Para aprovecharlo, detén el notebook y relánzalo con una talla mayor, o abre un segundo notebook.
Bajar el disco no falla, pero tampoco baja. El resto de los ejes se aplican, el disco se queda donde estaba y la respuesta trae el aviso. Como el laboratorio ya no coincide con ninguna talla, deja de mostrar el nombre de la talla y pasa a mostrar sus recursos en números. "Talla S" sigue significando exactamente los números del plan; un laboratorio con disco de más simplemente no es una S.
Un pipeline en ejecución bloquea la bajada. Studio solo detiene notebooks; no detiene ejecuciones de pipelines ni las piezas propias del laboratorio. Si eso es lo que ocupa el presupuesto, la respuesta lo dice con esas palabras y no te ofrece detener nada, porque detener los notebooks no bastaría. Cancela la ejecución y vuelve a intentarlo.
En un laboratorio compartido, el notebook que se detiene puede ser de otra persona. La confirmación lista cada notebook con su dueño para que lo veas antes de confirmar. El editor no recibe ningún aviso del producto: si vas a detener el trabajo de alguien, avísale tú.
La definición de una talla puede cambiar. Si tu laboratorio se creó cuando la talla L tenía 9 CPU y hoy la L son 8, un cambio "a L" lo baja sin que lo hayas pedido. Por eso el diálogo muestra siempre el destino en números, no solo el nombre.
Casos, uno por uno
Todos sobre un laboratorio con un notebook corriendo que usa 1.2 CPU y 4.1 GB, con las tallas de la instalación de referencia (S 2 CPU / 6 GB / 50 GB, M 5 / 18 / 50, L 9 / 34 / 100).
| Cambio | Qué pasa | Por qué |
|---|---|---|
| Subir de S a M | En caliente | Todo lo que corre cabe de sobra. El notebook sigue con su tamaño. |
| Bajar de L a M | En caliente | El notebook es pequeño y sigue cabiendo. Una política de "toda bajada detiene" lo interrumpiría sin motivo. |
| Bajar de M a S con un notebook de 4.2 CPU | Requiere detener | Falta CPU y memoria. Studio nombra el notebook; tú confirmas. |
| Más CPU y menos memoria | Requiere detener | Parece ampliación, pero en memoria queda por debajo del uso. Es el caso que justifica la regla. |
| Bajar el disco de 100 a 20 GB con 31 en uso | Se aplica el resto, el disco se conserva | Trinquete. Aviso en la respuesta; el laboratorio pasa a recursos en números. |
| Bajar con un pipeline corriendo | Bloqueado | Studio no puede detenerlo. La respuesta lo dice; cancela la ejecución primero. |
| Aplicar los mismos valores | No hace nada | Es idempotente: ni escribe ni detiene. |
| Dos pestañas editan a la vez | La segunda se rechaza | "El laboratorio cambió mientras lo editabas. Vuelve a abrir Redimensionar e inténtalo de nuevo." Nada de la segunda llega al laboratorio. |
Varias tarjetas de GPU
El presupuesto de GPU de un laboratorio es un rectángulo: N tarjetas × M de VRAM por tarjeta. Un laboratorio con 2 tarjetas y 12 GB por tarjeta puede correr un notebook de dos tarjetas que ve 12 GB en cada una, y cada una es una tarjeta física distinta. La VRAM no se suma entre tarjetas: un proceso vive en la tarjeta que le toca.
Así se registra y se reparte, con un laboratorio de 2 tarjetas y 8 GB por tarjeta:
plan gpumem = 8192 MiB por tarjeta lo que declara la talla
cuota gpus = 2 gpumem = 16384 el producto N × M, escrito por la plataforma
proceso gpus = 2 gpumem = 8192 16384 / 2, lo que recibe cada tarjeta
El plan declara la VRAM por tarjeta y la plataforma escribe el producto en la cuota; al admitir un proceso lo divide de vuelta. Por eso la división es siempre exacta: guardar un total y repartirlo obligaría a truncar (8192 / 3 = 2730.67) y a perder VRAM en silencio. El peor caso posible es exactamente N × M, y lo garantiza la cuota, no la confianza.
Dentro del notebook, nvidia-smi muestra las dos tarjetas con la VRAM de tu presupuesto, no la de la tarjeta entera. Así lo ve un notebook de dos tarjetas con 8 GB por tarjeta: dos dispositivos, cada uno con su VRAM asignada, y una copia entre ambos que funciona.

Y así lo ve el administrador en el Panel de infraestructura: el mismo notebook reservando 8 GB en dos tarjetas físicas distintas, junto a los notebooks de otros laboratorios que comparten esas mismas tarjetas.

Tres cosas que conviene saber:
- Un laboratorio corre un notebook con GPU a la vez, tenga las tarjetas que tenga. Es una limitación conocida de esta versión: un segundo notebook con GPU se rechaza por la cuota del propio laboratorio aunque el rectángulo tenga sitio.
- Una imagen de notebook solo CPU no usa las tarjetas que le diste.
nvidia-smilas ve, perotorch.cuda.is_available()devuelveFalseporque esa imagen trae una versión de PyTorch sin soporte de GPU. Desde Python parece que el laboratorio no te dio nada; no es así. Elige una imagen con GPU al crear el notebook. - Pedir más tarjetas que el máximo del plan se rechaza con el número exacto: "gpus 2 exceeds the plan ceiling of 1". El máximo lo fija tu Cliente y lo ves en los campos del diálogo.
Errores del diálogo
| Mensaje | Qué significa | Qué hacer |
|---|---|---|
| "El laboratorio cambió mientras lo editabas. Vuelve a abrir Redimensionar e inténtalo de nuevo." | Otra pestaña o persona aplicó un cambio antes que tú. No se aplicó nada tuyo. | Cierra el diálogo, ábrelo de nuevo y repite sobre el estado actual. |
| "Ese tamaño o combinación de recursos supera el máximo permitido para este laboratorio." | Un eje excede el techo del plan. El mensaje del servidor nombra el eje y el límite. | Baja ese eje o pide al administrador un techo mayor (Cuotas de laboratorios). |
| "No hay capacidad disponible ahora mismo para este cambio. Intenta con valores menores o vuelve a intentar más tarde." | La subida cabe en tu plan, pero no hay sitio en la instalación en este momento. Bajar nunca da este error. | Espera o pide menos. |
| "Ese tamaño o combinación de recursos no está permitido por la política del workspace." | La talla no existe en tu plan. | Elige una de las tallas ofrecidas. |
| "No pudimos confirmar la versión actual del laboratorio. Vuelve a intentarlo." | Studio no pudo leer el estado antes de enviar. | Reintenta; si persiste, recarga la página. |
Límites conocidos
Escritos aquí para que nadie los redescubra como un error.
- El disco nunca baja. Se libera borrando el laboratorio, no redimensionándolo.
- Solo el propietario. No hay forma de que un administrador o un editor redimensione el laboratorio de otra persona.
- Sin avisos a los editores. Quien tenía el notebook que se detuvo no se entera por el producto.
- Si falla después de detener, el notebook queda detenido con la cuota anterior; los datos siguen en el volumen. Vuelve a aplicar: como el uso ya bajó, la segunda vez entra en caliente.
- Bajar puede dejar un notebook detenido sin poder arrancar, y nadie avisa. La regla compara lo que corre con el destino, y un notebook detenido no usa nada: su tamaño declarado es invisible para la comprobación, así que una bajada por debajo de lo que necesita pasa sin objeción. No se pierde nada, pero ese notebook no arranca hasta que vuelvas a subir el laboratorio. Si al reanudar uno se queda en 0/1 después de una bajada, esta es la causa (El notebook no arranca).
- Borrar un notebook puede dejar su volumen atrás. Si al eliminarlo no marcas la opción de borrar también su volumen, el volumen sobrevive y sigue contando contra el disco. Combinado con que el disco no baja, es una calle de sentido único: quien experimenta un rato creando y borrando notebooks sin marcarla acaba con espacio que no puede recuperar ni reducir (Configuración avanzada).
Siguiente paso
- Tallas y cuota
- Configuración avanzada
- API de Laboratorios para hacerlo desde código