====== Servidores de computación GPGPU ====== ===== Descrición do servizo ===== Estes servidores están destinados á computación con GPU (GPGPU), orientados a tarefas de cálculo intensivo, aprendizaxe automática, procesamento de datos e simulación científica que requiran aceleración por hardware gráfico. ==== Servidores de acceso libre ==== Nestes servidores pode solicitar acceso calquera investigador/a do centro. O acceso concédese previa solicitude e 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 no cluster de computación HPC: [[ centro:servizos:hpc | Cluster de computación HPC ]] * Servidores no CESGA: [[ centro:servizos:cesga | Solicitar acceso ]] ==== Servidores de acceso restrinxido ==== Nestes servidores o acceso está restrinxido a un grupo concreto, proxecto específico ou ben está máis controlado por cuestións de xestión e planificación de recursos. É imprescindible comprobar a información actualizada en Xici no momento de solicitar o servizo, onde se detalla a casuística particular de cada servidor (criterios de acceso, prioridades, condicións de uso, etc.). ^ Nodo ^ Servidor ^ CPU ^ RAM ^ GPUs ^ Sistema Operativo ^ Xestión de traballos ^ | ''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 | ⚠️ Os servidores ''ctgpgpu15'', ''ctgpgpu16'', ''ctgpgpu17'' e ''ctgpgpu18'' teñen unha instalación e asignacións temporais, e a súa configuración e accesos poderían verse alterados arredor de maio de 2026. (*) Polo momento, estes servidores utilizan unicamente ts (task-spooler) pero está prevista unha migración pronto a un sistema baseado en gpuctl con uso de tsp (task-spooler) opcional. ===== Alta no servizo ===== Non todos os servidores están dispoñibles en todo momento para calqueira uso. Para acceder aos servidores, hai que solicitalo previamente a través do [[https://citius.usc.es/uxitic/incidencias/add|formulario de incidencias]]. Os usuarios que non teñan permiso de acceso recibirán unha mensaxe de contrasinal incorrecto. ===== Manual de usuario ===== ==== Conexión cos servidores ==== Para conectarse ós servidores, debes facelo a través de SSH. O nome e as direccións IP dos servidores son as seguintes: ^ 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 | A conexión só está dispoñible dende a rede do centro. Para conectarse dende outras localizacións ou dende a rede da RAI é preciso facer uso da [[:centro:servizos:vpn:start|VPN]] ou da [[:centro:servizos:pasarela_ssh|parasela SSH]]. ==== Xestión dos traballos con SLURM ==== Nos servidores nos que hai un xestor de colas Slurm é obrigatorio o seu uso para enviar traballos e así evitar conflitos entre procesos, xa que non se deben executar dous traballos ó mesmo tempo. Para enviar un traballo á cola utilízase o comando ''srun'': srun programa_cuda argumentos_programa_cuda O proceso ''srun'' agarda a que o traballo se execute para devolver o control ó usuario. Se non se quere agardar, pódense utilizar xestores de sesións de consola coma ''screen'', e así poder deixar o traballo á espera e desconectar a sesión sen preocuparse e recuperar a saída de consola máis adiante. Alternativamente, pódese utilizar ''nohup'' e pasar o traballo a segundo plano con ''&''. Neste caso a saída gárdase no arquivo ''nohup.out'': nohup srun programa_cuda argumentos_programa_cuda & Para ver o estado da cola utilízase o comando ''squeue''. O comando mostra unha saída 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 Tamén pode obterse unha vista interactiva, actualizada cada segundo, co comando ''smap'': smap -i 1 ==== Xestión dos traballos con TS ==== Nos servidores que empregan ''ts'' como xestor de traballos, é obrigatorio utilizalo para executar tarefas que empreguen GPU, co fin de evitar conflitos e garantir unha asignación correcta dos recursos. Para solicitar unha GPU débese antepoñer a opción ''-G 1'' (ou o número de GPUs necesarias): ts -G 1 programa_cuda argumentos_programa_cuda Por exemplo: ts -G 1 python train.py --epochs 100 O sistema encargarase de poñer o traballo en cola e executalo cando haxa unha GPU dispoñible. Para consultar exemplos máis avanzados (múltiples GPUs, recursos adicionais, opcións específicas, etc.) pódese empregar o comando: usage-overview ==== Xestión das reservas e traballos con gpuctl ==== Nos servidores que empregan ''gpuctl'', é preciso utilizar o comando ''gpu'' para solicitar GPU e poder executar traballos nelas. O comando ''gpu'' non incorpora unha cola de traballos nin control de paralelismo. Pode empregarse de forma interactiva ou desde scripts, pero para encolar varios traballos ou executalos en paralelo cómpre usar ferramentas externas, como ''task-spooler'' (comando ''tsp''). Hai dous fluxos de traballo principais: === 1. Reserva de GPU automática === Este método é o máis axeitado se só se quere executar un único comando. ''gpu exec'' actúa como un //wrapper//: encárgase de reclamar a GPU, preparar o contorno necesario para o comando e liberala ao rematar. gpu exec python ./train.py Esta é a opción recomendada para execucións simples, xa que evita ter que xestionar manualmente a reserva e a liberación da GPU. === 2. Reserva de GPU manual === Este método é o máis axeitado se se quere manter unha reserva activa entre varios comandos, xa sexa nunha sesión interactiva ou nun fluxo de traballo con varias execucións consecutivas. gpu claim gpu exec python ./train.py gpu release Ou, de xeito alternativo: gpu claim eval "$(gpu env --shell)" python ./train.py gpu release Se xa existe unha reserva activa, ''gpu exec'' reutilízaa e prepara automaticamente o contorno axeitado para o comando. É importante lembrar que, despois de crear ou modificar unha reserva, hai que executar de novo ''eval "$(gpu env --shell)"'' se se van lanzar os comandos directamente desde o shell. Como alternativa, pode empregarse ''gpu exec'', que prepara o contorno en cada execución. === Vida das reservas === As reservas mantéñense mentres se detecte actividade real de cómputo na GPU. Se unha GPU permanece reservada sen actividade durante un tempo prolongado, a reserva pode perderse automaticamente por inactividade. Polo tanto, se despois diso se intenta executar un traballo asumindo que a reserva segue activa, o traballo poderá fallar. A reserva non se mantén simplemente por ter unha terminal aberta, senón por actividade real na GPU. Os tempos de expiración sen actividade real na GPU están configurados do seguinte xeito: * Luns a venres, de 10:00 a 18:00 → 1 hora * Noutro momento → 2 horas * Se a reserva parece abandonada (non hai ningún proceso do usuario no sistema nin tampouco ningunha shell) → 10 minutos === Comprobación do estado da reserva === Se estás a traballar cunha reserva manual e queres comprobar se aínda segue activa, podes usar: gpu mine Ou ben, se queres ver información xeral sobre todas as GPU, o momento en que se capturou un uso real de cada unha e o tempo configurado actual de expiración, podes executar: gpu status Isto é especialmente recomendable se pasou tempo desde a última execución ou se a GPU puido quedar sen uso durante un período longo. === Reserva dunha segunda GPU oportunista === Ademais da reserva principal, que se realiza con prioridade na cola ''guaranteed'', é posible reservar unha segunda GPU na cola ''burst_preemptible''. Esta segunda GPU poderá utilizarse sempre que estea libre, pero non está garantida: pode perderse mesmo no medio dun traballo se outro usuario necesita esa GPU para a súa reserva principal. Isto permite aproveitar capacidade libre adicional cando a haxa, pero os traballos que dependan desta segunda GPU deben estar preparados para tolerar a súa perda. Para solicitar esta segunda GPU, abonda con executar ''gpu claim'' unha segunda vez: gpu claim gpu claim Tamén pode especificarse o número de GPU explicitamente: gpu claim --numgpus 2 Neste caso, o comando agardará ata poder reservar o número de GPU solicitado. Hai que ter en conta que estas dúas formas non son exactamente equivalentes: * con ''gpu claim'' seguido doutro ''gpu claim'', a primeira reserva obtense antes e a segunda solicítase despois; * con ''gpu claim ---numgpus 2'', a petición faise de forma conxunta e o comando agardará ata poder reservar as dúas GPU solicitadas. É importante lembrar que, despois de facer calquera reserva, hai que executar de novo ''eval "$(gpu env --shell)"'' ou facer as execucións con ''gpu exec''. Se a segunda GPU se perde máis adiante por ser ''preemptible'', os traballos que a estean usando poderían fallar ou verse interrompidos. Por tanto: * a primeira GPU é a reserva prioritaria e garantida; * a segunda GPU é oportunista e só estará dispoñible mentres non sexa necesaria para outra reserva prioritaria; * se algunha GPU non se pode reservar, o comando permanecerá á espera e o usuario pasará á cola correspondente; * ao reservar dúas GPU a un tempo, o comando agardará ata que se poidan reservar as dúas á vez. === Uso de task-spooler (tsp) === Como ''gpu'' non incorpora unha cola de traballos nin control de paralelismo, unha opción práctica para encolar execucións é empregar ''task-spooler'', co comando ''tsp'', combinado con ''gpu''. == Executar varios traballos en serie coa mesma 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 a mesma reserva para varios traballos consecutivos encolados en ''tsp''. == Executar varios traballos en paralelo == Se se queren executar varios traballos ao mesmo tempo, pódese aumentar o 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 Neste caso, hai que ter coidado de non executar ''gpu release'' antes de que rematen todos os traballos. Primeiro hai que asegurarse de que a cola terminou, e só despois liberar a GPU. Atención: executar varios traballos en paralelo non implica reservar varias GPU. Se só hai unha GPU reservada, todos os procesos compartirán esa mesma GPU e competirán polos seus recursos, como memoria e tempo de cómputo. Cómpre lembrar tamén que a reserva só se mantén mentres se detecte actividade real de cómputo na GPU. Se os traballos pasan demasiado tempo sen usala, a reserva pode caducar automaticamente por inactividade. === Uso de tmux === O uso de ''tmux'' permite manter sesións de terminal, desconectarse delas e recuperalas máis adiante, permitindo deste xeito manter unha sesión interactiva sen ter que manter a conexión aberta. O feito de desconectarse tampouco envía ''HUP'' aos procesos. Para iniciar unha sesión de ''tmux'' ou reconectarse a ela se xa existe, recoméndase usar un nome fixo: tmux new -A -s main Isto crea a sesión ''main'' se non existe, ou reconecta a ela se xa estaba creada. Unha vez dentro de ''tmux'', para desconectarse mantendo a sesión activa hai que pulsar ''Control+b'', soltar, e despois pulsar ''d''. Neste punto xa te podes desconectar da máquina sen interromper os procesos. Para volver á mesma sesión, abonda con executar de novo o comando anterior. Se se quere terminar a sesión completamente desde fóra: tmux kill-session -t main === Partición dunha GPU con perfís MIG === ''gpuctl'' permite particionar unha GPU en varias instancias MIG para illar recursos e executar cargas máis pequenas en paralelo nunha soa GPU física de forma máis controlada. Esta funcionalidade só está dispoñible en GPU compatibles, en caso contrario non se poderá utilizar. Polo de agora, só as GPUs NVIDIA H200 teñen esta función activada. Para reservar unha GPU e activala en modo MIG: gpu claim --mig half gpu claim --mig third gpu claim --mig quarter Esto partirá a GPU en dous, tres ou catro particións, elexindo os perfís MIG máis indicados segundo a gráfica compatible. Ten en conta que este parámetro ''--mig'' só se pode usar cando se reclama exactamente unha GPU. Unha vez creada a reserva MIG, ''gpu exec'' e ''gpu env'' xa preparan automaticamente ''CUDA_VISIBLE_DEVICES'' cos UUID MIG correspondentes. === Notificacións por correo === ''gpuctl'' permite configurar o envío de notificacións por correo electrónico relacionadas co estado das reservas e co uso das GPU. == Ver a configuración actual == gpu notify == Activar ou desactivar as notificacións == gpu notify --mode off gpu notify --mode email gpu notify --mode telegram gpu notify --mode both Cando as notificacións están activadas, envíanse correos ou mensaxes de Telegram nos seguintes casos: * cando unha GPU é liberada automaticamente por permanecer sen uso; * cando o //enforcer// mata un proceso por usar GPU sen ter unha reserva activa ou perder unha GPU oportunista; * cando unha petición de reserva queda encolada; * e posteriormente cando esa reserva é concedida. Non se envían notificacións en caso de que se faga unha reserva e a reserva se conceda no momento sen necesidade de agarda, ou se a GPU é liberada de xeito manual con ''release'' ou ao rematar un ''exec'' que fixo unha reserva automática. == Configurar un correo personalizado == gpu notify --email tu.correo@dominio Se non se configura un correo personalizado, utilizarase por defecto o enderezo obtido desde LDAP. Para volver ao correo por defecto: gpu notify --clear-email == Emparexar conta de Telegram == Tras executar o seguinte comando: gpu notify --pair-telegram Segue as instrucións para rematar o proceso de emparellamento. Para eliminar o emparellamento: gpu notify --unpair-telegram == Envío de notificacións personalizadas == O usuario pode enviar notificacións personalizadas en distintos puntos do seu fluxo de traballo mediante: gpu notify --send "contido da mensaxe" Isto pode resultar útil para recibir avisos propios ao comezo ou ao final dun experimento, tras completar unha fase do procesado, ou en calquera outro punto relevante do fluxo de traballo. Utilizarase o método de notificación preferido que estea configurado, ou o correo electrónico en caso de que ningún dos dous estea configurado. === Reportes de uso === Para consultar un resumo do histórico recente de uso da GPU por proceso, pode empregarse: gpu report Isto mostra os PID rexistrados, o número de mostras dispoñibles e métricas agregadas de uso de GPU, CPU e memoria. Se se queren ver os datos dun proceso concreto, con gráficas ASCII e a liña temporal das mostras almacenadas, pode usarse: gpu report --pid PID Se hai moitas mostras, a saída pode aparecer resumida. Para ver a serie completa: gpu report --pid PID --all-samples === Recomendacións prácticas === * Para executar un único comando, o máis sinxelo adoita ser ''gpu exec''. * Para manter unha reserva activa entre varios comandos, resulta máis axeitado usar ''gpu claim'' + ''gpu exec'' + ''gpu release''. * Se se vai traballar directamente desde o shell tras facer unha reserva manual, hai que executar ''eval "$(gpu env --shell)"'' ou antepoñer ''gpu exec''. * Para deixar sesións activas e recuperalas máis tarde, ''tmux'' adoita ser a opción máis cómoda. * Para encolar varios traballos, ''tsp'' é unha alternativa práctica. * Se se emprega ''tsp'' con paralelismo, hai que lembrar que iso non reserva GPU adicionais: os procesos compartirán a GPU ou GPU visibles nese momento. * Se unha reserva permanece demasiado tempo sen actividade real de cómputo na GPU, poderá perderse automaticamente por inactividade.