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 13.900 trabajos de 20 usuarios, reconstruidos desde los propios ficheros sbatch— y lo contamos de forma anonimizada: sin nombres, sin rutas internas, mirando patrones y no personas. Esto es lo que parece un clúster de investigación pequeño cuando lo lees hacia atrás.

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 ocho 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 (~6.500): las dominan el ajuste fino de seguridad de LLM (~43 %) y la evaluación de modelos (~18 %). Las GPU son de los LLMs.
• Horas de CPU (~113.000): unos dos tercios pertenecen a una sola línea de fuzzing de firmware, buena parte de ella rebañada de núcleos ociosos en los nodos GPU.

Ese segundo número es lo más interesante de todo el archivo, así que empecemos por ahí.

El trabajo más interesante no es de IA #

Una de las líneas —casi la mitad de todos los trabajos del periodo— hace fuzzing de banda base. Los scripts ejecutan FirmWire , un emulador de sistema completo para procesadores de banda base celular, contra la imagen de un módem Shannon de Samsung, fuzzeando los manejadores de protocolo de capa 3 de GSM/GPRS: control de llamada, SMS, gestión de sesión, SNDCP… Es decir, las partes del módem de un teléfono que parsean mensajes que llegan por el aire, históricamente una fuente rica de fallos disparables en remoto.

Dos detalles la convierten en ingeniería, no solo en cómputo:

Va orquestada por un servidor MCP. Los trabajos más pequeños y numerosos —miles— son tareas de “verificación” de un CPU y veinte minutos, lanzadas por un servidor MCP (Model Context Protocol). Cuando el fuzzer encuentra un candidato a crash, la herramienta descarga al clúster un trabajo de replay para confirmarlo, con cuidado: lo repite varias veces y mata cualquier replay que pase de cinco minutos, porque una banda base emulada puede meterse en un bucle infinito y colgar la herramienta. Es una herramienta de seguridad usando un clúster HPC como una aplicación web usa una cola de trabajos: capacidad elástica en ráfaga, un crash cada vez.

Rebaña núcleos ociosos. Una campaña aparte despliega un array de 150 instancias de AFL y las fija a los nodos GPU pidiendo --gres=gpu:0: es decir, pide las CPU de los nodos GPU sin tocar las tarjetas. En una máquina donde los trabajos de GPU dejan la mayoría de los núcleos libres, esto los reclama para tandas de ocho horas —que “expiran” por diseño al llegar al walltime—. Luego, otros arrays cosechan los crashes, los deduplican por SHA-256 y re-triagean los únicos best-of-5. Un uso ingenioso de una máquina compartida: la carga de seguridad es hambrienta de CPU e infinitamente paralela, así que encaja justo en los huecos que dejan los trabajos de deep learning.

Las GPU: defender y atacar el mismo modelo #

El lado GPU es casi un debate autocontenido sobre seguridad de LLMs, con distintos usuarios en distintos papeles.

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

El ataque. Mucho más pequeño, pero llamativo: un marco de jailbreak automático y multi-agente que ataca un modelo abierto de 120B a lo largo de 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.

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.

La cola larga: proteínas, árboles, dientes y módems #

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 LLM pequeño exportado a LiteRT-LM int4/int8 para teléfonos, más un modelo “principal” en H100.
• Y, por los bordes, detección de intrusiones con AutoML y GNN, 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 llevó un trabajo 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 a casa al final, dentro de un trap de limpieza, para no machacar el NFS durante la tanda y que un trabajo muerto recoja igualmente.
• Sin expropiación: 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 no confiable, en una máquina compartida, es exactamente el instinto correcto.

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— con una gran operación de fuzzing de seguridad corriendo en las rendijas, 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. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables.