¿Puedes detener un notebook con GPU y retomar el mismo experimento?

Son las seis de la tarde. Un notebook por fin ha cargado un modelo y ha producido resultados que merece la pena examinar. Si detienes la sesión, quizá mañana tengas que dedicar un rato a reconstruir el entorno y cargar de nuevo el modelo. Si la dejas en marcha, un acelerador escaso puede pasar toda la noche sin uso.

Google anunció GKE Workspaces el 4 de noviembre. El entorno de desarrollo de código abierto funciona en el clúster de Google Kubernetes Engine del equipo. Un panel en el navegador permite lanzar JupyterLab o VS Code con los recursos configurados. El proyecto se basa en Kubeflow Workspaces y documenta cómo pausar y reanudar las sesiones compatibles. Para el equipo, la cuestión es qué estado necesita mañana y qué recursos deben seguir asignados para conservarlo.

Fotograma recortado de la demostración de notebooks reanudables de GKE Workspaces, Apache 2.0. Fuente de la imagen · Licencia.

Un archivo de notebook y una sesión activa conservan cosas distintas

Pausa de un notebook con GPU. Ilustración original de Telli.sh.

Guardar un notebook conserva las celdas escritas y los resultados que se hayan guardado. Un disco puede mantener los conjuntos de datos y los puntos de control disponibles para un proceso nuevo. Nada de eso captura automáticamente todo lo que contiene una sesión en marcha. Un experimento puede tener variables inicializadas, un modelo en un acelerador y un estado intermedio que lleve tiempo recrear.

Google describe el uso de GKE Pod Snapshots para conservar el estado activo de los espacios compatibles mientras se liberan recursos de cómputo. Los archivos del espacio de trabajo permanecen en el almacenamiento persistente. Para reanudar hacen falta la instantánea y capacidad compatible. Pausar se parece así a retomar el experimento, con las limitaciones propias del entorno, más que a abrir de nuevo un archivo guardado.

La reproducibilidad y la comodidad mejoran partes distintas del flujo. Una instantánea ayuda a quien quiere retomar pronto una sesión. Un notebook reproducible y un punto de control de la aplicación permiten que otra persona repita el trabajo o lo traslade a otro entorno. Si el experimento importa, conserva las dos cosas.

Un equipo de investigación puede pausar una sesión de GPU entre reuniones y guardar a la vez el código en el repositorio y los artefactos del modelo en una ubicación duradera. Si más adelante falla la restauración de la instantánea, tiene una alternativa clara. Un entrenamiento largo también puede guardar puntos de control con regularidad aunque el espacio desde el que se inició admita pausas.

Un espacio detenido todavía puede tener un coste

Cálculo de la factura real. Ilustración original de Telli.sh.

La ventaja económica inmediata consiste en evitar el consumo de cómputo mientras nadie trabaja. La factura depende de lo que haga el clúster después de detener la sesión. Un nodo puede seguir en marcha porque lo usen otros pods. Una reserva puede conservar un coste o un compromiso. Los discos persistentes y las instantáneas guardadas siguen formando parte del sistema.

Imagina un caso hipotético. Si una investigadora deja asignado durante doce horas un acelerador que nadie más usa, la pausa puede liberar esas doce horas. Es una oportunidad de recuperar capacidad. El efecto económico depende de cómo se asignen y facturen el nodo y el acelerador. Si otro trabajo necesita que el nodo siga en línea, la pausa puede ayudar más a la planificación que a la factura inmediata.

Una comparación equilibrada tiene en cuenta el tiempo. Guardar una instantánea consume recursos, restaurar un estado grande tarda y el acelerador deseado puede no estar disponible enseguida. En un clúster con mucha demanda, ceder el dispositivo a otra persona puede ser importante aunque el equipo ya se haya comprometido a pagar por ese conjunto de recursos.

Registra cuándo termina el trabajo activo, cuándo se detiene el espacio y cuándo vuelve a estar disponible el nodo. Mide luego cuándo puede ejecutar la siguiente celda alguien que reanuda el espacio. Así el equipo de plataforma puede comprobar si la regla devuelve capacidad útil sin que la jornada siguiente empiece con una cola.

El equipo de plataforma sigue definiendo las condiciones del espacio

El autoservicio cambia quién pulsa el botón. Los administradores aún deciden qué imágenes pueden iniciar las personas, qué aceleradores pueden pedir y cómo gestiona el clúster las cuotas y el aislamiento. El repositorio de GKE Workspaces indica que el código se publica bajo Apache 2.0 y que no es un producto con soporte oficial de Google. Al evaluarlo para un equipo, trata la instalación y la operación como responsabilidades técnicas propias.

Una ingeniera de aprendizaje automático puede necesitar un IDE familiar, memoria suficiente y acceso a un conjunto de datos. Quien administra la plataforma también debe pensar en las identidades predeterminadas, los permisos de almacenamiento, la detención de cargas y las imágenes que admiten actualizaciones. Los requisitos son compatibles si los tipos de espacio muestran las disyuntivas. Un notebook pequeño con CPU y una sesión de experimentación con GPU pueden partir de configuraciones distintas.

El anuncio también describe opciones de aceleradores y conexiones para herramientas locales o agentes. Revisa las instrucciones de tu clúster y caso de uso antes de dar por hecho que son intercambiables. La restauración ligada al hardware, el acceso entre clústeres y la conexión desde un entorno local tienen requisitos propios. Empieza con un caso sencillo en el que una persona pueda inspeccionar el espacio y confirmar qué clúster lo está ejecutando.

Prueba una pausa y una recuperación de principio a fin

1. Lee la guía de despliegue del proyecto y los requisitos vigentes de tu entorno GKE para instantáneas y aceleradores. Prepara un espacio de prueba con permisos y límites de recursos acordes con el flujo previsto.
2. Inicia un notebook reproducible. Guarda su entrada, un punto de control intermedio de la aplicación y un archivo pequeño de resultados. Anota el tiempo y la asignación de recursos antes de la pausa.
3. Pausa el espacio e inspecciona el estado de los recursos del clúster. Comprueba si se detuvo el pod, si el acelerador puede asignarse a otro trabajo y qué almacenamiento permanece.
4. Reanuda el espacio. Confirma los archivos y el estado activo esperados y ejecuta una celda que use el modelo cargado. Mide el tiempo entre la solicitud y el momento en que se pueda usar el notebook.
5. Intenta recuperar el mismo trabajo desde los archivos guardados y el punto de control de la aplicación. Tendrás una alternativa y una comparación si restaurar la instantánea es lento o imposible.
6. Revisa con el equipo los ajustes de inactividad. Decide qué se considera inactivo y si los trabajos largos necesitan un tipo de espacio aparte o un tratamiento explícito.

Haz también una prueba de restauración con la cuota cerca del límite o con el clúster ocupado. Una demostración impecable en un clúster vacío puede ocultar lo difícil que es obtener capacidad cuando varias personas vuelven a la vez. La prueba sirve para entender el comportamiento cuando escasean los recursos.

Calcula adónde van las horas de GPU

Imagina un puesto de desarrollo que se usa 40 horas a la semana. Una máquina asignada toda la semana suma 168 horas. Si la plataforma puede liberar el nodo de GPU cuando cesa el trabajo y devolverlo solo durante esas 40 horas, se evitan 128 horas de nodo asignado antes de contar la sobrecarga de las instantáneas y la restauración. Es un ejemplo que no presupone tarifas de nube ni patrones de utilización. Es un límite superior para esa asignación, porque un nodo compartido puede seguir haciendo trabajo útil durante el mismo periodo.

Para una comparación más realista, toma una referencia de tu propio grupo de GPU. Anota por intervalo las horas de nodo, si otro trabajo lo ocupó y cuántos datos del espacio quedaron guardados. Anota también el tiempo entre solicitar la reanudación y poder ejecutar la siguiente celda. Si el nodo sigue activo por otra carga, el notebook pausado puede dejarle capacidad sin reducir la factura. Sigue siendo un resultado útil.

El tiempo que tarda la instantánea cuenta. Si la pausa es larga y el pod anterior sigue asignado durante el proceso, un umbral de inactividad agresivo puede interrumpir más veces sin ahorrar apenas cómputo. Si reanudar tarda minutos mientras el ajuste automático busca una GPU compatible, una persona que vuelve de una pausa breve puede perder más tiempo del que ahorra la regla. Mide distintas duraciones de inactividad.

Decide qué conservar antes de activar la pausa

El repositorio de GKE Workspaces describe un flujo de VS Code sin estado y otro de JupyterLab que sí lo conserva. Este último muestra la restauración de un notebook con GPU, incluido un ejemplo con un modelo Qwen2.5 de 3.000 millones de parámetros en una T4. Las instantáneas de pods y el ejemplo tienen requisitos concretos de compatibilidad. La documentación de GKE explica el papel de GKE Sandbox y qué configuraciones de nodo e imagen son compatibles. En el ejemplo con GPU, comprueba que el nodo nuevo tenga el mismo modelo de GPU admitido y un entorno compatible antes de depender de la restauración.

Decide qué esperan las personas al ver un botón de pausa. Algunas esperan recuperar archivos, salidas y el estado del editor. Otras quieren que la siguiente celda de Python encuentre un objeto en la RAM o un modelo en la VRAM. Un conjunto de datos compartido puede estar en un almacenamiento de objetos externo y quedar fuera de la instantánea. Anota qué estados puede recuperar el espacio, dónde se conservan los archivos corrientes y qué hacer si falla la restauración.

Otra prueba útil es provocar un fallo antes de reanudar. Haz que la capacidad compatible no esté disponible temporalmente en un espacio de nombres de prueba. Comprueba que el espacio informa de un estado claro y no inicia varias restauraciones en paralelo. Comprueba si se puede continuar desde los archivos o las salidas guardadas cuando el proceso en memoria no se recupera. Elimina después la instantánea de prueba y verifica que las reglas de almacenamiento y retención se apliquen como se espera.

Comparte la información de costes con todo el equipo

Quien investiga quiere reanudar su trabajo. El equipo de plataforma quiere devolver capacidad al grupo de GPU. Quien gestiona la facturación quiere saber si desaparece una asignación. Una prueba puede responder las tres preguntas si registra por separado el tiempo inactivo, la asignación de nodos, el tamaño de las instantáneas, las reanudaciones correctas y el tiempo de recuperación. Documenta los fallos para soporte y muestra si el espacio está en pausa, en espera de capacidad o listo.

A partir de esa referencia, elige una regla de inactividad por tipo de carga. Una sesión larga con un modelo lento de cargar puede beneficiarse de conservar la memoria entre turnos. Un experimento corto que parte de un script guardado quizá solo necesite archivos persistentes y un inicio limpio. Ambos pueden compartir el mismo conjunto de recursos con distintos tiempos de recuperación.

Incluye una prueba de reanudación en la validación de cada actualización

Una actualización puede cambiar la imagen con la que arranca el espacio o el grupo de nodos que proporciona la GPU. Antes de activar el cambio para el equipo, crea un notebook de prueba con la configuración anterior y comprueba qué ocurre con la nueva. La prueba debe distinguir una restauración correcta de una sesión nueva con el mismo archivo abierto. Lee un valor que solo exista en el proceso activo de prueba y confirma después que sus archivos siguen presentes.

Si la actualización invalida instantáneas antiguas, avisa con tiempo para que las personas guarden los resultados importantes y explica la alternativa. Comprueba por separado la limpieza de instantáneas caducadas. La prueba de restauración demuestra que un espacio concreto puede regresar. La de limpieza muestra cuánto estado antiguo queda después de que se deje de usar.

Conserva el trabajo que más cuesta recrear

Un espacio es más útil cuando las personas pueden despreocuparse del ciclo de vida de la máquina y recuperar su trabajo. Para ello hay que separar archivos, puntos de control, instantáneas y capacidad. Elige el mínimo de estado que haga cómoda la reanudación y asegúrate de que el proyecto se pueda reproducir sin la sesión original.

Si el equipo sabe qué queda en el disco, qué debe restaurarse y cuándo se libera el cómputo, puede fijar una política de inactividad que la gente utilice en la práctica.

Fuentes

• Documentación de GKE sobre instantáneas de pods y compatibilidad

• Ejemplo de notebook reanudable en la revisión de la demostración

• Anuncio del 4 de noviembre y vídeo de GKE Workspaces en el blog de código abierto de Google

• Código, alcance del soporte y documentación de instalación de GKE Workspaces

---

Para conservar un registro en el que puedas buscar las conversaciones y decisiones de tu trabajo, crea una cuenta de Telli.sh.