Qué corre de verdad en nuestro clúster, leído desde los propios scripts

El histórico de trabajos de un clúster suele ser un muro de identificadores de seis cifras y nombres crípticos —mcpfw_cc, eval_dynamic_pid, boltz2— que lo dicen todo a quien los lanzó y nada a los demás. Pero si guardas los scripts, el muro se convierte en un documento: la gente escribe por qué hace las cosas, sobre todo cuando una tanda cuesta dinero y una noche de espera.

Hemos repasado cuatro meses del clúster de cómputo del grupo ANTS, del Departamento de Ingeniería de la Información y las Comunicaciones de la Facultad de Informática de la Universidad de Murcia —en torno a 7.700 trabajos de 19 usuarios, reconstruidos desde los propios ficheros sbatch— y lo contamos de forma anonimizada: sin nombres, sin rutas internas, mirando patrones y no personas. Así es, por dentro, un clúster de investigación pequeño.

Dos medidores, dos historias #

Si hubiera que resumirlo en una frase: el clúster va hoy, sobre todo, de modelos de lenguaje, y sobre todo de probarlos, no de entrenarlos desde cero. De las siete líneas de trabajo que conviven en la máquina, la mayoría tocan LLMs: ajuste fino de seguridad, benchmarks de código y de llamada a funciones, ataque automático, un modelo para móvil y servicio de inferencia. De preentrenamiento serio, nada; lo más parecido son fine-tunes con LoRA y muchísima evaluación. Así es un clúster GPU universitario en 2026: no un horno de entrenamiento, sino un laboratorio de medida para modelos entrenados en otra parte.

Pero los contadores cuentan dos historias según cuál mires:

• Horas de GPU (~3.000): las domina el benchmarking de modelos cuantizados (~37 %); después, proteínas (~15 %), auto-alineamiento, bosques y ataque (entre el 10 y el 12 % cada uno) y el modelo para móvil (~9 %). Las GPU son de los LLMs, pero sobre todo de medirlos.
• Horas de CPU (~30.000): se reparten de otra manera: bosques LiDAR (~27 %) y benchmarking (~25 %) delante, seguidos del clasificador para móvil (~19 %) y el ataque (~12 %). Quien más GPU reserva no es quien más CPU pide.

Las GPU: defender y atacar el mismo modelo #

El lado GPU es, en sí mismo, casi un debate completo sobre seguridad de LLMs, con distintos usuarios en distintos papeles.

La defensa. Un estudio de SFT + LoRA sobre “auto-alineamiento”, evaluando cada checkpoint con HarmBench, el benchmark estándar de comportamientos dañinos. Todo encadenado como un grafo de dependencias: entrena, y al terminar dispara un array de evaluaciones con --dependency=afterok, guardando las salidas aparte para poder volver a juzgarlas después sin reentrenar.

El ataque. Mucho más pequeño, pero llamativo: un sistema de jailbreak automático y multiagente que ataca un modelo abierto de 120B en decenas de objetivos y turnos, con el clasificador oficial de HarmBench como juez. Todo el conjunto —objetivo, agentes y juez— se apila en una sola H200 de 141 GB, porque cada nodo GPU tiene exactamente una tarjeta.

La medida. Servir modelos GGUF cuantizados con llama.cpp y puntuarlos en BFCL (llamada a funciones), BigCodeBench y RULER (contexto largo). Cliente y servidor en el mismo nodo, tras descartar los túneles SSH porque no paraban de fallar. Parte de los resultados se publica en Yardstick .

Así que un usuario afina modelos para que sean más seguros y los puntúa con HarmBench; otro ataca automáticamente un modelo grande y puntúa los ataques con el mismo clasificador de HarmBench. Las dos mitades de la misma pregunta, en los mismos nodos.

Proteínas, árboles, dientes y lagunas #

El resto de líneas son más pequeñas, pero cada una es un inquilino limpio y monotema:

• Plegado de proteínas: Boltz-2 , un modelo de difusión de la familia AlphaFold, sobre ~2.500 pares de proteínas. Solo un puñado de trabajos, pero enormes y reanudables: una reserva de cinco días que salta los pares ya hechos.
• Bosques desde nubes de puntos: estimación de biomasa aérea a partir de LiDAR con Pointcept (PTv3, OACNN), segmentando árboles individuales.
• Imágenes médicas: segmentación con UNet++, DeepLabV3+ y SegFormer, incluido un array de 100 semillas para medir la varianza entre ejecuciones.
• Modelo para móvil: un clasificador de riesgo en conversaciones de menores, un LLM pequeño exportado a LiteRT-LM int4/int8 para teléfonos, más un modelo “principal” en H100. Código en GitHub .
• Y, por los bordes, GNN espaciotemporales que predicen clorofila en una laguna desde imágenes de satélite, un piloto de AutoML para detección de intrusiones, y genómica de célula única.

Lo que los scripts enseñan sobre convivir en una máquina compartida #

Más allá de qué se computa, los scripts son una guía discreta de cómo ser buen inquilino. Varios patrones se repiten en usuarios que no tienen nada que ver entre sí:

• Pedir menos, arrancar antes. Un comentario fechado el día en que alguien lo descubrió: bajar la petición de 4 CPU / 8 GB a 1 CPU / 2 GB hizo que un trabajo pasara de “esperar días” a “arrancar en segundos”, porque el pequeño encajó en un hueco de backfill de un nodo con 28 de 30 núcleos ocupados.
• Preparar en scratch local y sincronizar con el home al final, dentro de un trap de limpieza, para no machacar el NFS durante la tanda y para que, si el trabajo muere, la limpieza se haga igual.
• Sin desalojar a nadie: la gente usa --nice alto y walltimes honestos. Como resume un script, lo que de verdad libera una GPU para el vecino no es la prioridad, es terminar pronto.
• Avisos por ntfy y correo: se encola y uno se olvida.

Y mi favorito, una decisión de seguridad escondida en un script de benchmarking. El equipo que mide modelos de código necesita que el modelo escriba código; sus scripts son tajantes: el clúster solo genera texto, nunca ejecuta el código que escribe el modelo. La corrección —que sí ejecutaría ese código— va después, en un contenedor aislado en una máquina local. Un comentario incluso corrige a otro comentario anterior que había dado por buena la vía insegura, y avisa de que leerlo mal “habría puesto el aislamiento en el sitio equivocado”. Pensar con claridad dónde se permite ejecutar código que no es de fiar, en una máquina compartida, es justo el reflejo que hay que tener.

Conclusión #

El histórico de trabajos de un clúster, leído con calma, es un retrato de lo que preocupa a una comunidad. El del grupo ANTS, a mediados de 2026, se preocupa por los modelos de lenguaje —hacerlos más seguros, romperlos a propósito, medir lo que pueden y encogerlos hasta un móvil—, y proteínas, bosques y dientes por los bordes.

Nada de eso se ve en los nombres de los trabajos. Está en los scripts. Guardad los scripts.

Cifras reconstruidas a partir de la contabilidad de Slurm y de los sbatch recuperados; las horas de GPU/CPU reflejan capacidad reservada (elapsed × asignado), no uso medido, y la intención de cada trabajo se infiere de los cuerpos de los scripts y sus comentarios. Se excluye un registro huérfano que figuraba como RUNNING desde mayo y que inflaba la GPU en unas 2.500 horas, y en cinco trabajos que quedaron colgados unas 18 horas más allá de su límite (Slurm los cerró a la vez al día siguiente) la reserva se cuenta hasta el límite pedido, no hasta el cierre. A petición de una de las personas del grupo, su línea de trabajo y todos sus trabajos se han retirado de esta entrada, de las cifras y de los gráficos. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables.