Was auf unserem Cluster wirklich läuft, gelesen aus den Skripten selbst

Die Job-Historie eines Clusters ist meist eine Wand aus sechsstelligen Kennungen und kryptischen Namen – mcpfw_cc, eval_dynamic_pid, boltz2 –, die demjenigen alles sagen, der sie gestartet hat, und allen anderen nichts. Bewahrt man aber die Skripte auf, wird aus der Wand ein Dokument: Die Leute schreiben auf, warum sie etwas tun, vor allem dann, wenn ein Durchlauf Geld und eine Nacht Wartezeit kostet.

Wir haben vier Monate des Rechenclusters der ANTS-Gruppe am Fachbereich für Informations- und Kommunikationstechnik der Fakultät für Informatik der Universität Murcia durchgesehen – rund 7.700 Jobs von 19 Nutzern, rekonstruiert aus den sbatch-Dateien selbst – und erzählen es anonymisiert: ohne Namen, ohne interne Pfade, mit Blick auf Muster statt auf Personen. So sieht ein kleiner Forschungscluster aus, wenn man ihn rückwärts liest.

Zwei Zähler, zwei Geschichten #

Müsste man es in einem Satz zusammenfassen: Auf dem Cluster geht es heute vor allem um Sprachmodelle, und vor allem darum, sie zu prüfen, nicht darum, sie von Null an zu trainieren. Von den sieben Arbeitslinien, die sich die Maschine teilen, haben die meisten mit LLMs zu tun: Sicherheits-Fine-Tuning, Benchmarks für Code und Funktionsaufrufe, automatisierte Angriffe, ein Modell fürs Smartphone und Inferenzdienste. Ernsthaftes Pretraining: keines; das Nächstliegende sind Fine-Tunes mit LoRA und sehr, sehr viel Evaluation. So sieht ein universitärer GPU-Cluster im Jahr 2026 aus: kein Trainingsofen, sondern ein Messlabor für Modelle, die anderswo trainiert wurden.

Die Zähler erzählen aber zwei Geschichten, je nachdem, welchen man anschaut:

• GPU-Stunden (~3.000): dominiert vom Benchmarking quantisierter Modelle (~37 %); dann Proteine (~15 %), Self-Alignment, Wälder und Angriffe (jeweils 10 bis 12 %) und das Modell fürs Smartphone (~9 %). Die GPUs gehören den LLMs, vor allem aber dem Messen.
• CPU-Stunden (~30.000): anders verteilt: LiDAR-Wälder (~27 %) und Benchmarking (~25 %) vorn, gefolgt vom mobilen Klassifikator (~19 %) und den Angriffen (~12 %). Wer die meiste GPU reserviert, fordert nicht die meiste CPU an.

Die GPUs: dasselbe Modell verteidigen und angreifen #

Die GPU-Seite ist fast eine in sich geschlossene Debatte über LLM-Sicherheit, mit verschiedenen Nutzern in verschiedenen Rollen.

Die Verteidigung. Eine SFT+LoRA-Studie zu „Self-Alignment“, bei der jeder Checkpoint mit HarmBench evaluiert wird, dem Standard-Benchmark für schädliches Verhalten. Alles als Abhängigkeitsgraph verdrahtet: trainieren, und nach Abschluss ein Array von Evaluationen mit --dependency=afterok auslösen, wobei die Ausgaben getrennt gespeichert werden, um sie später ohne erneutes Training neu beurteilen zu können.

Der Angriff. Viel kleiner, aber auffällig: ein automatisiertes Multi-Agenten-Jailbreak-Framework, das ein offenes 120B-Modell über Dutzende Ziele und Runden hinweg angreift, mit dem offiziellen HarmBench-Klassifikator als Richter. Das gesamte Ensemble – Ziel, Agenten und Richter – wird auf eine einzige H200 mit 141 GB gestapelt, weil jeder GPU-Knoten genau eine Karte hat.

Die Messung. Quantisierte GGUF-Modelle mit llama.cpp bereitstellen und sie auf BFCL (Funktionsaufrufe), BigCodeBench und RULER (langer Kontext) bewerten. Client und Server auf demselben Knoten, nachdem SSH-Tunnel verworfen wurden, weil sie ständig ausfielen.

Ein Nutzer justiert also Modelle, damit sie sicherer werden, und bewertet sie mit HarmBench; ein anderer greift automatisiert ein großes Modell an und bewertet die Angriffe mit demselben HarmBench-Klassifikator. Die zwei Hälften derselben Frage, auf denselben Knoten.

Der lange Schwanz: Proteine, Bäume, Zähne und Lagunen #

Die übrigen Linien sind kleiner, aber jede ist ein sauberer Mieter mit einem einzigen Thema:

• Proteinfaltung: Boltz-2 , ein Diffusionsmodell aus der AlphaFold-Familie, auf ~2.500 Proteinpaaren. Nur eine Handvoll Jobs, aber riesig und wiederaufnehmbar: eine Fünf-Tage-Reservierung, die bereits erledigte Paare überspringt.
• Wälder aus Punktwolken: Schätzung der oberirdischen Biomasse aus LiDAR mit Pointcept (PTv3, OACNN), mit Segmentierung einzelner Bäume.
• Medizinische Bilder: Segmentierung mit UNet++, DeepLabV3+ und SegFormer, darunter ein Array aus 100 Seeds zur Messung der Varianz zwischen Durchläufen.
• Modell fürs Smartphone: ein Risikoklassifikator für Gespräche Minderjähriger, ein kleines LLM, exportiert nach LiteRT-LM in int4/int8 für Telefone, plus ein „Haupt“-Modell auf der H100.
• Und an den Rändern raumzeitliche GNNs, die Chlorophyll in einer Lagune aus Satellitenbildern vorhersagen, ein Pilotprojekt zu AutoML für Intrusion Detection und Einzelzell-Genomik.

Was die Skripte über das Zusammenleben auf einer gemeinsamen Maschine lehren #

Jenseits dessen, was berechnet wird, sind die Skripte ein diskreter Leitfaden dafür, wie man ein guter Mieter ist. Mehrere Muster wiederholen sich bei Nutzern, die nichts miteinander zu tun haben:

• Weniger anfordern, früher starten. Ein Kommentar, datiert auf den Tag, an dem jemand es herausfand: Die Anforderung von 4 CPUs / 8 GB auf 1 CPU / 2 GB zu senken, brachte einen Job von „tagelang warten“ zu „in Sekunden starten“, weil der kleine in eine backfill-Lücke eines Knotens passte, auf dem 28 von 30 Kernen belegt waren.
• Im lokalen scratch vorbereiten und am Ende nach Hause synchronisieren, innerhalb eines Aufräum-traps, um das NFS während des Durchlaufs nicht zu malträtieren und damit ein gestorbener Job trotzdem seine Ergebnisse einsammelt.
• Kein Verdrängen: Die Leute nutzen hohe --nice-Werte und ehrliche walltimes. Wie ein Skript zusammenfasst: Was eine GPU wirklich für den Nachbarn freigibt, ist nicht die Priorität, sondern früh fertig zu werden.
• Benachrichtigungen per ntfy und E-Mail: Man reiht ein und vergisst es.

Und mein Favorit: eine Sicherheitsentscheidung, versteckt in einem Benchmarking-Skript. Das Team, das Code-Modelle misst, braucht das Modell, um Code zu schreiben; seine Skripte sind kategorisch: Der Cluster erzeugt nur Text, er führt den vom Modell geschriebenen Code niemals aus. Die Korrektur – die diesen Code tatsächlich ausführen würde – kommt danach, in einem isolierten Container auf einer lokalen Maschine. Ein Kommentar korrigiert sogar einen früheren Kommentar, der den unsicheren Weg für gut befunden hatte, und warnt, ihn falsch zu lesen „hätte die Isolation an die falsche Stelle gesetzt“. Klar darüber nachzudenken, wo auf einer gemeinsam genutzten Maschine nicht vertrauenswürdiger Code ausgeführt werden darf, ist genau der richtige Instinkt.

Fazit #

Die Job-Historie eines Clusters, in Ruhe gelesen, ist ein Porträt dessen, was eine Gemeinschaft beschäftigt. Die der ANTS-Gruppe beschäftigt sich Mitte 2026 mit Sprachmodellen – sie sicherer machen, sie absichtlich brechen, messen, was sie können, und sie bis auf ein Smartphone schrumpfen –, und Proteinen, Wäldern und Zähnen an den Rändern.

Nichts davon sieht man in den Job-Namen. Es steht in den Skripten. Bewahrt die Skripte auf.

Die Serie, Linie für Linie #

1. Self-Alignment eines 3B-LLM mit LoRA und HarmBench : 2.600 Jobs, um Sicherheit zu justieren und zu messen.
2. Ein Rat kleiner Modelle gegen ein 120B-Modell : automatisches Jailbreaking auf einer einzigen H200.
3. Quantisierte LLMs messen : 300 GGUF, drei Benchmarks und eine Sicherheitsregel. Ein Teil der Ergebnisse wird auf Yardstick veröffentlicht.
4. 4.400 Proteinkomplexe mit Boltz-2 : fünfzehn Jobs und ein Faktor zehn.
5. Bäume einzeln aus LiDAR-Punktwolken : drei Architekturen, zehn Seeds und zwei Knoten.
6. Dentale Segmentierung und 100 Seeds : die Varianz messen, bevor man vergleicht.
7. Ein Risikoklassifikator für Minderjährige, der in ein Smartphone passt : synthetische Daten, LoRA und LiteRT-LM. Code auf GitHub .
8. GNNs für das Chlorophyll einer Lagune , und ein AutoML-Pilot.
9. Modelle bereitstellen und den Cluster pflegen : gemeinsame Inferenz, Burn-in und Sonden.

Zahlen rekonstruiert aus dem Slurm-Accounting und den wiedergefundenen sbatch-Dateien; die GPU-/CPU-Stunden spiegeln reservierte Kapazität wider (elapsed × zugewiesen), nicht gemessene Nutzung, und die Absicht jedes Jobs wird aus den Skriptkörpern und ihren Kommentaren erschlossen. Ausgeschlossen ist ein verwaister Eintrag, der seit Mai als RUNNING geführt wurde und die GPU-Zahlen um etwa 2.500 Stunden aufblähte; bei fünf Jobs, die rund 18 Stunden über ihr Limit hinaus hängen blieben (Slurm schloss sie am nächsten Tag gleichzeitig), wird die Reservierung nur bis zum angeforderten Limit gezählt, nicht bis zum Abschluss; die Zahlen der ersten Version dieses Beitrags enthielten beides. Auf Wunsch eines Gruppenmitglieds wurden dessen Arbeitslinie und alle seine Jobs aus diesem Beitrag, den Zahlen und den Grafiken entfernt. Anonymisierter Beitrag: ohne identifizierbare Nutzer, Pfade, E-Mails oder Projektnamen.