====== Servidores de computación GPGPU ====== ===== Descripción del servicio ===== 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. ==== Servidores de acceso libre ==== En estos servidores puede solicitar acceso cualquier investigador/a del centro. El acceso se concede previa solicitud y validación. ^ Nodo ^ Servidor ^ CPU ^ RAM ^ GPUs ^ Sistema Operativo ^ Gestión de trabajos ^ | ''ctgpgpu4'' | PowerEdge R730 | 2 × [[https://ark.intel.com/products/92980/Intel-Xeon-Processor-E5-2623-v4-10M-Cache-2_60-GHz|Intel Xeon E5-2623 v4]] | 128 GB | 2 × Nvidia GP102GL 24GB (Tesla P40, 2016) | AlmaLinux 9.1 \\ • CUDA 12.0 | **Slurm (uso obligatorio)** | * Servidores en el clúster de computación HPC: [[ centro:servizos:hpc | Clúster de computación HPC ]] * Servidores en el CESGA: [[ centro:servizos:cesga | Solicitar acceso ]] ==== Servidores de acceso restringido ==== 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.). ^ Nodo ^ Servidor ^ CPU ^ RAM ^ GPUs ^ Sistema Operativo ^ Gestión de trabajos ^ | ''ctgpgpu5'' | PowerEdge R730 | 2 × [[https://ark.intel.com/products/92980/Intel-Xeon-Processor-E5-2623-v4-10M-Cache-2_60-GHz|Intel Xeon E5-2623 v4]] | 128 GB | 2 × Nvidia GP102GL (Tesla P40) | Ubuntu 22.04 \\ • Driver Nvidia 590 \\ • CUDA Toolkit 12.5 y 13.1 (por defecto) | n/a | | ''ctgpgpu6'' | SIE LADON 4214 | 2 × [[https://ark.intel.com/content/www/us/en/ark/products/193385/intel-xeon-silver-4214-processor-16-5m-cache-2-20-ghz.html|Intel Xeon Silver 4214]] | 192 GB | Nvidia Quadro P6000 24GB (2018) \\ Nvidia Quadro RTX8000 48GB (2019) \\ 2 × Nvidia A30 24GB (2020) | CentOS 7.9 \\ • Driver Nvidia 535.86.10 (CUDA 12.2) | n/a | | ''ctgpgpu9'' | Dell PowerEdge R750 | 2 × [[https://ark.intel.com/content/www/es/es/ark/products/215274/intel-xeon-gold-6326-processor-24m-cache-2-90-ghz.html|Intel Xeon Gold 6326]] | 128 GB | 2 × NVIDIA Ampere A100 80GB | AlmaLinux 8.6 \\ • Driver NVIDIA 515.48.07 (CUDA 11.7) | n/a | | ''ctgpgpu11'' | Gigabyte G482-Z54 | 2 × [[https://www.amd.com/es/products/cpu/amd-epyc-7413|AMD EPYC 7413 @2.65 GHz (24c)]] | 256 GB | 5 × NVIDIA Ampere A100 80GB | AlmaLinux 9.1 \\ • Driver NVIDIA 520.61.05 (CUDA 11.8) | n/a | | ''ctgpgpu12'' | Dell PowerEdge R760 | 2 × [[https://ark.intel.com/content/www/xl/es/ark/products/232376.html|Intel Xeon Silver 4410Y]] | 384 GB | 2 × NVIDIA Hopper H100 80GB | AlmaLinux 9.2 \\ • Driver NVIDIA 555.42.06 (CUDA 12.5) | n/a | | ''ctgpgpu15'' ⚠️ | SIE LADON (Gigabyte) | 2x AMD EPYC 9474F (48c) | 768 GB | 4 × NVIDIA H200 NVL | AlmaLinux 9.6 | gpuctl* | | ''ctgpgpu16'' ⚠️ | SIE LADON (Gigabyte) | 2x AMD EPYC 9474F (48c) | 768 GB | 4 × NVIDIA H200 NVL | AlmaLinux 9.7 | gpuctl* | | ''ctgpgpu17'' ⚠️ | SIE LADON (Gigabyte) | 2x AMD EPYC 9474F (48c) | 768 GB | 4 × NVIDIA H200 NVL | AlmaLinux 9.7 | gpuctl* | | ''ctgpgpu18'' ⚠️ | SIE LADON (MegaRAC SP-X) | 2x AMD EPYC 9335 (24c) | 1536 GB | 4 × NVIDIA H200 | Ubuntu 22.04 | gpuctl | ⚠️ 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. ===== Alta en el servicio ===== 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 [[https://citius.usc.es/uxitic/incidencias/add|formulario de incidencias]]. Los usuarios que no tengan permiso de acceso recibirán un mensaje de contraseña incorrecta. ===== Manual de usuario ===== ==== Conexión con los servidores ==== Para conectarse a los servidores, debes hacerlo a través de SSH. El nombre y las direcciones IP de los servidores son las siguientes: ^ Nodo ^ FQDN ^ IP ^ | ''ctgpgpu4'' | ctgpgpu4.inv.usc.es | 172.16.242.201 | | ''ctgpgpu5'' | ctgpgpu5.inv.usc.es | 172.16.242.202 | | ''ctgpgpu6'' | ctgpgpu6.inv.usc.es | 172.16.242.205 | | ''ctgpgpu9'' | ctgpgpu9.inv.usc.es | 172.16.242.94 | | ''ctgpgpu11'' | ctgpgpu11.inv.usc.es | 172.16.242.96 | | ''ctgpgpu12'' | ctgpgpu12.inv.usc.es | 172.16.242.97 | | ''ctgpgpu15'' | ctgpgpu15.inv.usc.es | 172.16.242.207 | | ''ctgpgpu16'' | ctgpgpu16.inv.usc.es | 172.16.242.212 | | ''ctgpgpu17'' | ctgpgpu17.inv.usc.es | 172.16.242.213 | | ''ctgpgpu18'' | ctgpgpu18.inv.usc.es | 172.16.242.208 | 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 [[:es:centro:servizos:vpn:start|VPN]] o de la [[:es:centro:servizos:pasarela_ssh|puerta SSH]]. ==== Gestión de los trabajos con SLURM ==== 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 ==== Gestión de los trabajos con TS ==== 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 ==== Gestión de las reservas y trabajos con gpuctl ==== 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: === 1. Reserva de GPU automática === 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. === 2. Reserva de GPU manual === 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. === Vida de las reservas === 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 === Comprobación del estado de la reserva === 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. === Reserva de una segunda GPU oportunista === 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. === Uso de task-spooler (tsp) === 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''. == Ejecutar varios trabajos en serie con la misma reserva == 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''. == Ejecutar varios trabajos en paralelo == 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. === Uso de tmux === 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 === Partición de una GPU con perfiles MIG === ''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. === Notificaciones por correo === ''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. == Ver la configuración actual == gpu notify == Activar o desactivar las notificaciones == 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. == Configurar un correo personalizado == 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 == Emparejar cuenta de Telegram == 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 == Envío de notificaciones personalizadas == 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. === Reportes de uso === 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 === Recomendaciones prácticas === * 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.