Servidores de computación GPGPU

Estos servidores están destinados a la computación con GPU (GPGPU), orientados a tareas de cálculo intensivo, aprendizaje automático, procesamiento de datos y simulación científica que requieran aceleración por hardware gráfico.

En estos servidores puede solicitar acceso cualquier investigador/a del centro. El acceso se concede previa solicitud y validación.

• Servidores en el clúster de computación HPC: Clúster de computación HPC
• Servidores en el CESGA: Solicitar acceso

En estos servidores el acceso está restringido a un grupo concreto, proyecto específico o bien está más controlado por cuestiones de gestión y planificación de recursos.

Es imprescindible comprobar la información actualizada en Xici en el momento de solicitar el servicio, donde se detalla la casuística particular de cada servidor (criterios de acceso, prioridades, condiciones de uso, etc.).

⚠️ Los servidores ctgpgpu15, ctgpgpu16, ctgpgpu17 y ctgpgpu18 tienen una instalación y asignaciones temporales, y su configuración y accesos podrían verse alterados alrededor de mayo de 2026.

(*) Por el momento, estos servidores utilizan únicamente ts (task-spooler) pero está prevista una migración pronto a un sistema basado en gpuctl con uso de tsp (task-spooler) opcional.

No todos los servidores están disponibles en todo momento para cualquier uso. Para acceder a los servidores, hay que solicitarlo previamente a través del formulario de incidencias. Los usuarios que no tengan permiso de acceso recibirán un mensaje de contraseña incorrecta.

Para conectarse a los servidores, debes hacerlo a través de SSH. El nombre y las direcciones IP de los servidores son las siguientes:

La conexión solo está disponible desde la red del centro. Para conectarse desde otras ubicaciones o desde la red de la RAI es preciso hacer uso de la VPN o de la puerta SSH.

En los servidores en los que hay un gestor de colas Slurm es obligatorio su uso para enviar trabajos y así evitar conflictos entre procesos, ya que no se deben ejecutar dos trabajos al mismo tiempo.

Para enviar un trabajo a la cola se utiliza el comando srun:

srun programa_cuda argumentos_programa_cuda

El proceso srun espera a que el trabajo se ejecute para devolver el control al usuario. Si no se quiere esperar, se pueden utilizar gestores de sesiones de consola como screen, y así poder dejar el trabajo en espera y desconectar la sesión sin preocuparse y recuperar la salida de consola más adelante.

Alternativamente, se puede utilizar nohup y pasar el trabajo a segundo plano con &. En este caso la salida se guarda en el archivo nohup.out:

nohup srun programa_cuda argumentos_programa_cuda &

Para ver el estado de la cola se utiliza el comando squeue. El comando muestra una salida similar a esta:

JOBID PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
9  servidore ca_water pablo.qu    PD       0:00      1 (Resources)
10 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
11 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
12 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
13 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
14 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
 8 servidore ca_water pablo.qu     R       0:11      1 ctgpgpu2

También puede obtenerse una vista interactiva, actualizada cada segundo, con el comando smap:

smap -i 1

En los servidores que emplean ts como gestor de trabajos, es obligatorio utilizarlo para ejecutar tareas que empleen GPU, con el fin de evitar conflictos y garantizar una asignación correcta de los recursos.

Para solicitar una GPU debe anteponerse la opción -G 1 (o el número de GPUs necesarias):

ts -G 1 programa_cuda argumentos_programa_cuda

Por ejemplo:

ts -G 1 python train.py --epochs 100

El sistema se encargará de poner el trabajo en cola y ejecutarlo cuando haya una GPU disponible.

Para consultar ejemplos más avanzados (múltiples GPUs, recursos adicionales, opciones específicas, etc.) se puede emplear el comando:

usage-overview

En los servidores que emplean gpuctl, es preciso utilizar el comando gpu para solicitar GPU y poder ejecutar trabajos en ellas.

El comando gpu no incorpora una cola de trabajos ni control de paralelismo. Puede emplearse de forma interactiva o desde scripts, pero para encolar varios trabajos o ejecutarlos en paralelo hay que usar herramientas externas, como task-spooler (comando tsp).

Hay dos flujos de trabajo principales:

Este método es el más adecuado si solo se quiere ejecutar un único comando. gpu exec actúa como un wrapper: se encarga de reclamar la GPU, preparar el entorno necesario para el comando y liberarla al finalizar.

gpu exec python ./train.py

Esta es la opción recomendada para ejecuciones simples, ya que evita tener que gestionar manualmente la reserva y la liberación de la GPU.

Este método es el más adecuado si se quiere mantener una reserva activa entre varios comandos, ya sea en una sesión interactiva o en un flujo de trabajo con varias ejecuciones consecutivas.

gpu claim
gpu exec python ./train.py
gpu release

O, de forma alternativa:

gpu claim
eval "$(gpu env --shell)"
python ./train.py
gpu release

Si ya existe una reserva activa, gpu exec reutiliza y prepara automáticamente el entorno adecuado para el comando.

Es importante recordar que, después de crear o modificar una reserva, hay que ejecutar de nuevo eval "$(gpu env --shell)" si se van a lanzar los comandos directamente desde el shell. Como alternativa, se puede emplear gpu exec, que prepara el entorno en cada ejecución.

Las reservas se mantienen mientras se detecte actividad real de cómputo en la GPU.

Si una GPU permanece reservada sin actividad durante un tiempo prolongado, la reserva puede perderse automáticamente por inactividad. Por lo tanto, si después de eso se intenta ejecutar un trabajo asumiendo que la reserva sigue activa, el trabajo podrá fallar.

La reserva no se mantiene simplemente por tener una terminal abierta, sino por actividad real en la GPU.

Los tiempos de expiración sin actividad real en la GPU están configurados de la siguiente manera:

• Lunes a viernes, de 10:00 a 18:00 → 1 hora
• En otro momento → 2 horas
• Si la reserva parece abandonada (no hay ningún proceso del usuario en el sistema ni tampoco ninguna shell) → 10 minutos

Si estás trabajando con una reserva manual y quieres comprobar si aún sigue activa, puedes usar:

gpu mine

O bien, si quieres ver información general sobre todas las GPU, el momento en que se capturó un uso real de cada una y el tiempo configurado actual de expiración, puedes ejecutar:

gpu status

Esto es especialmente recomendable si ha pasado tiempo desde la última ejecución o si la GPU pudo quedar sin uso durante un período largo.

Además de la reserva principal, que se realiza con prioridad en la cola guaranteed, es posible reservar una segunda GPU en la cola burst_preemptible.

Esta segunda GPU podrá utilizarse siempre que esté libre, pero no está garantizada: puede perderse incluso en medio de un trabajo si otro usuario necesita esa GPU para su reserva principal.

Esto permite aprovechar capacidad libre adicional cuando haya, pero los trabajos que dependan de esta segunda GPU deben estar preparados para tolerar su pérdida.

Para solicitar esta segunda GPU, basta con ejecutar gpu claim una segunda vez:

gpu claim
gpu claim

También puede especificarse el número de GPU explícitamente:

gpu claim --numgpus 2

En este caso, el comando esperará hasta poder reservar el número de GPU solicitado.

Hay que tener en cuenta que estas dos formas no son exactamente equivalentes:

• con gpu claim seguido de otro gpu claim, la primera reserva se obtiene antes y la segunda se solicita después;
• con gpu claim ---numgpus 2, la petición se hace de forma conjunta y el comando esperará hasta poder reservar las dos GPU solicitadas.

Es importante recordar que, después de hacer cualquier reserva, hay que ejecutar de nuevo eval "$(gpu env --shell)" o hacer las ejecuciones con gpu exec.

Si la segunda GPU se pierde más adelante por ser preemptible, los trabajos que la estén usando podrían fallar o verse interrumpidos.

Por lo tanto:

• la primera GPU es la reserva prioritaria y garantizada;
• la segunda GPU es oportunista y solo estará disponible mientras no sea necesaria para otra reserva prioritaria;
• si alguna GPU no se puede reservar, el comando permanecerá a la espera y el usuario pasará a la cola correspondiente;
• al reservar dos GPU a la vez, el comando esperará hasta que se puedan reservar las dos a la vez.

Como gpu no incorpora una cola de trabajos ni control de paralelismo, una opción práctica para encolar ejecuciones es emplear task-spooler, con el comando tsp, combinado con gpu.

gpu claim
tsp gpu exec python ./train1.py
tsp gpu exec python ./train2.py
tsp gpu exec python ./train3.py
tsp gpu release

Este método permite reutilizar la misma reserva para varios trabajos consecutivos encolados en tsp.

Si se quieren ejecutar varios trabajos al mismo tiempo, se puede aumentar el número de slots de tsp:

gpu claim
tsp -S 2
tsp gpu exec python ./train1.py
tsp gpu exec python ./train2.py
tsp gpu exec python ./train3.py
tsp gpu exec python ./train4.py
tsp -w
tsp -S 1
gpu release

En este caso, hay que tener cuidado de no ejecutar gpu release antes de que terminen todos los trabajos. Primero hay que asegurarse de que la cola terminó, y solo después liberar la GPU.

Atención: ejecutar varios trabajos en paralelo no implica reservar varias GPU. Si solo hay una GPU reservada, todos los procesos compartirán esa misma GPU y competirán por sus recursos, como memoria y tiempo de cómputo.

Cabe recordar también que la reserva solo se mantiene mientras se detecte actividad real de cómputo en la GPU. Si los trabajos pasan demasiado tiempo sin usarla, la reserva puede caducar automáticamente por inactividad.

El uso de tmux permite mantener sesiones de terminal, desconectarse de ellas y recuperarlas más adelante, permitiendo de este modo mantener una sesión interactiva sin tener que mantener la conexión abierta. El hecho de desconectarse tampoco envía HUP a los procesos.

Para iniciar una sesión de tmux o reconectarse a ella si ya existe, se recomienda usar un nombre fijo:

tmux new -A -s main

Esto crea la sesión main si no existe, o reconecta a ella si ya estaba creada.

Una vez dentro de tmux, para desconectarse manteniendo la sesión activa hay que pulsar Control+b, soltar, y después pulsar d.

En este punto ya te puedes desconectar de la máquina sin interrumpir los procesos. Para volver a la misma sesión, basta con ejecutar de nuevo el comando anterior.

Si se quiere terminar la sesión completamente desde fuera:

tmux kill-session -t main

gpuctl permite particionar una GPU en varias instancias MIG para aislar recursos y ejecutar cargas más pequeñas en paralelo en una sola GPU física de forma más controlada.

Esta funcionalidad solo está disponible en GPUs compatibles; de lo contrario, no se podrá utilizar. Por el momento, solo las GPUs NVIDIA H200 tienen esta función activada.

Para reservar una GPU y activarla en modo MIG:

gpu claim --mig half
gpu claim --mig third
gpu claim --mig quarter

Esto partirá la GPU en dos, tres o cuatro particiones, eligiendo los perfiles MIG más indicados según la gráfica compatible. Ten en cuenta que este parámetro --mig solo se puede usar cuando se reclama exactamente una GPU.

Una vez creada la reserva MIG, gpu exec y gpu env ya preparan automáticamente CUDA_VISIBLE_DEVICES con los UUID MIG correspondientes.

gpuctl permite configurar el envío de notificaciones por correo electrónico relacionadas con el estado de las reservas y con el uso de las GPU.

gpu notify

gpu notify --mode off
gpu notify --mode email
gpu notify --mode telegram
gpu notify --mode both

Cuando las notificaciones están activadas, se envían correos o mensajes de Telegram en los siguientes casos:

• cuando una GPU es liberada automáticamente por permanecer sin uso;
• cuando el enforcer mata un proceso por usar GPU sin tener una reserva activa o perder una GPU oportunista;
• cuando una petición de reserva queda encolada;
• y posteriormente cuando esa reserva es concedida.

No se envían notificaciones en caso de que se haga una reserva y se conceda en el momento sin necesidad de esperar, o si la GPU es liberada de forma manual con release o al terminar un exec que hizo una reserva automática.

gpu notify --email tu.correo@dominio

Si no se configura un correo personalizado, se utilizará por defecto la dirección obtenida desde LDAP. Para volver al correo por defecto:

gpu notify --clear-email

Tras ejecutar el siguiente comando:

gpu notify --pair-telegram

Sigue las instrucciones para finalizar el proceso de emparejamiento. Para eliminar el emparejamiento:

gpu notify --unpair-telegram

El usuario puede enviar notificaciones personalizadas en distintos puntos de su flujo de trabajo mediante:

gpu notify --send "contenido del mensaje"

Esto puede resultar útil para recibir avisos propios al comienzo o al final de un experimento, tras completar una fase del procesamiento, o en cualquier otro punto relevante del flujo de trabajo.

Se utilizará el método de notificación preferido que esté configurado, o el correo electrónico en caso de que ninguno de los dos esté configurado.

Para consultar un resumen del histórico reciente de uso de la GPU por proceso, puede emplearse:

 gpu report 

Esto muestra los PID registrados, el número de muestras disponibles y métricas agregadas de uso de GPU, CPU y memoria.

Si se quieren ver los datos de un proceso concreto, con gráficas ASCII y la línea temporal de las muestras almacenadas, puede usarse:

 gpu report --pid PID 

Si hay muchas muestras, la salida puede aparecer resumida. Para ver la serie completa:

 gpu report --pid PID --all-samples 

• Para ejecutar un único comando, lo más sencillo suele ser gpu exec.
• Para mantener una reserva activa entre varios comandos, resulta más adecuado usar gpu claim + gpu exec + gpu release.
• Si se va a trabajar directamente desde el shell tras hacer una reserva manual, hay que ejecutar eval "$(gpu env --shell)" o anteponer gpu exec.
• Para dejar sesiones activas y recuperarlas más tarde, tmux suele ser la opción más cómoda.
• Para encolar varios trabajos, tsp es una alternativa práctica.
• Si se emplea tsp con paralelismo, hay que recordar que eso no reserva GPU adicionales: los procesos compartirán la GPU o GPUs visibles en ese momento.
• Si una reserva permanece demasiado tiempo sin actividad real de cómputo en la GPU, podrá perderse automáticamente por inactividad.