Lo que realmente se necesita para ejecutar código en una supercomputadora de 200 millones de euros

• MareNostrum V de la Universitat Politècnica de Catalunya en Barcelona es una de las 15 supercomputadoras más potentes del mundo, una infraestructura pública de investigación valuada en €200 millones que realiza cómputo distribuido a lo largo de 8,000 nodos
• No es una sola computadora de alto rendimiento, sino un sistema distribuido de miles de computadoras independientes conectadas con una topología fat-tree InfiniBand NDR200, donde cualquier nodo puede comunicarse con la misma latencia mínima
• El envío de trabajos se hace mediante el gestor de cargas de trabajo SLURM, poniendo en cola tareas en el planificador con scripts por lotes que especifican solicitud de recursos, límite de tiempo y presupuesto del proyecto
• Opera en un entorno aislado (air gap) sin acceso a internet externo, por lo que hay que preparar con anticipación las librerías y datasets necesarios, y a veces extraer los resultados se vuelve más cuello de botella que el cómputo
• Es un recurso público gratuito para investigadores: las instituciones españolas pueden acceder por medio de RES, y en toda Europa mediante las convocatorias periódicas de la Empresa Común EuroHPC

---

Arquitectura: la red es la computadora

• El mayor malentendido sobre HPC es pensar que se renta una sola computadora ultrapotente, cuando en realidad la estructura consiste en distribuir trabajos entre miles de computadoras independientes
• Para evitar que las GPU queden inactivas esperando transferencias de datos en cómputo distribuido, MareNostrum V configura su fabric InfiniBand NDR200 en una topología fat-tree
  • En una red normal, cuando varias computadoras comparten el mismo switch se generan cuellos de botella de ancho de banda
  • La topología fat-tree incrementa el ancho de banda de los enlaces a medida que se sube en la jerarquía de red, garantizando ancho de banda no bloqueante (non-blocking)
  • Cualquiera de los 8,000 nodos puede comunicarse con la misma latencia mínima

Configuración de las particiones de cómputo

• Partición de propósito general (GPP): diseñada para trabajos de CPU altamente paralelos, con 6,408 nodos equipados cada uno con 112 núcleos Intel Sapphire Rapids, para un rendimiento pico combinado de 45.9 PFlops
• Partición acelerada (ACC): diseñada para usos especializados como entrenamiento de IA y dinámica molecular, con 1,120 nodos equipados cada uno con 4 GPU NVIDIA H100 SXM, para un rendimiento pico de 260 PFlops
  • Tomando como referencia un precio minorista de unos 25,000 dólares por cada H100, solo el costo de las GPU supera los 110 millones de dólares
• Nodos de login (Login Nodes): son el primer punto de entrada al conectarse por SSH y se usan solo para tareas ligeras como mover archivos, compilar código y enviar scripts de trabajo; no son para cómputo

Infraestructura cuántica

• MareNostrum 5 integra física y lógicamente la primera computadora cuántica de España
  • Incluye un sistema cuántico basado en compuertas digitales y el recocedor cuántico superconductor MareNostrum-Ona
• Las unidades de procesamiento cuántico (QPU) no reemplazan a la supercomputadora clásica, sino que funcionan como aceleradores especializados
• Al descargar en hardware cuántico problemas de optimización o simulaciones de química cuántica que incluso una GPU H100 procesa con dificultad, se construye una potencia de cómputo híbrido clásico-cuántico a gran escala

Air gap, cuotas y la realidad operativa del HPC

• Air gap: se puede acceder por SSH desde el exterior, pero los nodos de cómputo no tienen acceso a internet externo
  • No es posible usar pip install, wget ni conectarse a repositorios externos de HuggingFace
  • Todo lo necesario para los scripts debe descargarse y compilarse con anticipación, y dejarse listo en los directorios de almacenamiento
  • Los administradores proporcionan la mayoría de las librerías y el software mediante el sistema module
• Movimiento de datos: la entrada y salida de datos se hace por scp o rsync a través de los nodos de login
  • Como el cálculo real puede ser muy rápido, el proceso de extraer los resultados terminados a la máquina local a veces se convierte en el cuello de botella
• Restricciones y cuotas: a cada proyecto se le asigna un determinado presupuesto de tiempo de CPU, y existen límites estrictos sobre cuántos trabajos en ejecución o en espera puede tener un usuario al mismo tiempo
  • Es obligatorio especificar un límite de wall-time estricto para todos los trabajos
  • Si el tiempo solicitado se excede aunque sea por 1 segundo, el planificador termina el proceso de inmediato
• Logging: después de enviar un trabajo no hay salida en terminal en vivo; todo stdout y stderr se redirige automáticamente a archivos de log (por ejemplo, sim_12345.out, sim_12345.err)
  • Los resultados se revisan y el debugging se hace inspeccionando archivos de texto una vez que el trabajo termina o falla
  • El estado de los trabajos enviados puede monitorearse con squeue o tail -f

Gestor de cargas de trabajo SLURM

• Tras la aprobación de la asignación de investigación y el login por SSH, aparece un prompt de terminal Linux completamente normal
• Como miles de investigadores lo usan al mismo tiempo, si se ejecutan scripts pesados directamente desde la terminal se puede tumbar el nodo de login y terminar recibiendo un correo de advertencia del administrador del sistema
• SLURM (Simple Linux Utility for Resource Management): software open source de planificación de trabajos; al especificar en un script de Bash el hardware necesario, el entorno de software y el código a ejecutar, lo pone en cola, lo ejecuta cuando consigue el hardware y luego libera los nodos
• Principales directivas #SBATCH:
  • --nodes: número de máquinas físicas necesarias
  • --ntasks: número total de procesos MPI (tareas) que se crearán; SLURM se encarga de distribuirlos entre nodos
  • --time: límite estricto de tiempo de reloj, con terminación inmediata si se excede
  • --account: ID del proyecto al que se descontará el tiempo de CPU
  • --qos: Quality of Service o cola específica (por ejemplo, la cola debug ofrece acceso rápido pero con límite corto de ejecución)

Ejemplo práctico: orquestación de un barrido en OpenFOAM

• Para predecir downforce aerodinámico con un modelo sustituto de ML, se necesitaba ejecutar 50 simulaciones CFD (dinámica de fluidos computacional) de alta fidelidad sobre 50 mallas 3D distintas
• Ejemplo de script de trabajo SLURM para un solo caso CFD de OpenFOAM en la partición de propósito general:
  • Se definen recursos con opciones como --nodes=1, --ntasks=6, --time=00:30:00
  • Se carga el entorno con module load OpenFOAM/11-foss-2023a
  • Con srun --mpi=pmix se ejecutan en secuencia surfaceFeatureExtract, blockMesh, decomposePar, snappyHexMesh, potentialFoam, simpleFoam, reconstructPar
• En lugar de enviar las 50 manualmente, se usan dependencias de SLURM (dependency) para encadenar cada trabajo detrás del anterior
  • Con sbatch --dependency=afterany:$PREV_JOB_ID se registran 50 trabajos en la cola en cuestión de segundos
  • Para la mañana siguiente, las 50 evaluaciones aerodinámicas ya estaban procesadas y registradas, listas para convertirse en tensores para entrenamiento de ML

Límite de la paralelización: la ley de Amdahl

• La razón por la que, teniendo 112 núcleos por nodo, se pidieron solo 6 tareas para la simulación CFD es la ley de Amdahl
• Todo programa tiene una fracción serial que no puede paralelizarse, y la mejora teórica de velocidad queda estrictamente limitada por esa proporción
  • Fórmula: S = 1 / ((1−p) + p/N), donde S es la mejora total de velocidad, p es la proporción paralelizable y N es el número de núcleos de procesador
  • Aunque solo el 5% del código sea serial, incluso usando todos los núcleos de MareNostrum V la mejora teórica máxima sería de 20x
• Si se dividen las tareas entre demasiados núcleos, aumenta la sobrecarga de comunicación a través de la red InfiniBand
  • Si se gasta más tiempo transmitiendo condiciones de frontera entre núcleos que en el cálculo real, agregar hardware puede incluso volver más lento el proceso
• En simulaciones de sistemas pequeños (N=100), el runtime aumenta después de 16 hilos; solo en sistemas grandes (N=10k+) el hardware se vuelve totalmente productivo
• Escribir código para supercomputadoras es un ejercicio de gestionar la proporción entre cómputo y comunicación

Cómo acceder

• A pesar del costo del hardware, el acceso a MareNostrum V es gratuito para investigadores, y el tiempo de cómputo se considera un recurso científico financiado con dinero público
• Los investigadores de instituciones españolas pueden postular por medio de la Red Española de Supercomputación (RES)
• Los investigadores de toda Europa pueden postular mediante las convocatorias periódicas de acceso de la Empresa Común EuroHPC
  • La modalidad "Development Access" está diseñada para proyectos de portabilidad de código o benchmarking de modelos de ML, lo que la hace especialmente accesible para científicos de datos