Ausgangslage und Anforderungen

HPC-Zentren wie die GWDG setzen in der Regel Batch-Scheduling-Systeme ein, die sich gut für wissenschaftliche Anwendungsfälle wie die Genomsequenzierung oder das Training von KI-Modellen eignen. Mit dem Aufkommen von Large Language Models (LLMs) werden die wertvollen GPU-Ressourcen in HPC-Zentren jedoch zunehmend auch für das Bereitstellen von KI-Modellen benötigt.

Das Bereitstellen von KI-Modellen erfordert ein anderes Paradigma: Service-Scheduling. Dieses weist Ressourcen dynamisch basierend auf der Nutzungsnachfrage zu und antwortet sofort, anstatt auf die Zuweisung von Ressourcen und das Laden von KI-Modellen in den GPU-Speicher zu warten. Zudem erwarten Nutzende, dass sie KI-Modelle über Webseiten und Programmierschnittstellen (APIs) nutzen können, was eine sichere Methode erfordert, HPC-Knoten über das Internet zugänglich zu machen.

Die Sicherheit der HPC-Umgebung hat oberste Priorität [1], da Angreifer sensible Forschungsdaten stehlen oder die Rechenknoten für Denial-of-Service-Angriffe sowie Crypto-Mining missbrauchen könnten. Wir haben verschiedene Ansätze untersucht, um dieses Problem zu lösen. Einer davon bildet unsere Scalable AI Accelerator (SAIA)-Plattform [2], auf der aktuell die KI-Dienste der GWDG betrieben werden (siehe https://www.mpg.de/24124791/gwdg_jb_2024?c=901669).

Bei der Entwicklung von SAIA mussten wir viele Funktionen neu implementieren, die in bestehenden Service-Scheduling-Plattformen bereits enthalten sind – etwa in Kubernetes, einem Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Da Kubernetes der De-facto-Standard zur Orchestrierung von Diensten in Cloud-Umgebungen ist, haben wir zwei Ansätze untersucht, um die Nutzung von Kubernetes in HPC-Umgebungen zu ermöglichen, ohne den Zugriff auf Ressourcen für Batch-Scheduling-Arbeitslasten zu beeinträchtigen.

Ephemeral Kubernetes

Der erste Ansatz wird Ephemeral Kubernetes [3] genannt. Er nutzt Warewulf, um HPC-Knoten über Knotenbilder zu starten, die die Softwarepakete für Kubernetes-Worker- oder Kontrollknoten enthalten. Warewulf ist ein häufig in HPC-Umgebungen eingesetztes Knotenverwaltungssystem. Es stellt das Betriebssystem der Knoten über das Netzwerk bereit und ermöglicht so eine zentrale Steuerung der Softwarepakete und Konfigurationen aller Knoten in einem Cluster.

Durch das Bereitstellen separater Knotenbilder über Warewulf können alle Softwarepakete bei Bedarf ausgetauscht werden, was die Angriffsfläche minimiert. Zudem bleibt Ephemeral Kubernetes selbst dann betriebsbereit, wenn einzelne Knoten entfernt werden – beispielsweise um sie über einen Batch-Scheduler wieder in ihren regulären Betrieb zurückzuführen.

Rootloses Kubernetes

Unser zweiter Ansatz verwendet rootloses Kubernetes innerhalb von Slurm-Jobs [4]. Der Batch-Scheduler Slurm, der auf den HPC-Plattformen der GWDG eingesetzt wird, ermöglicht uns das Betreiben von Kubernetes-Clustern mit regulären Benutzerberechtigungen. Während bestehende Lösungen oft versuchen, Kubernetes und Slurm zu kombinieren [5], bietet unser Ansatz ein voll funktionsfähiges, rootloses Kubernetes.

Besonders hervorzuheben ist, dass wir unsere Lösung seit der Erstveröffentlichung [4] kontinuierlich weiterentwickelt haben, um offene Herausforderungen wie Einschränkungen bei der Netzwerkleistung und die Unterstützung mehrerer Knoten zu beheben. Wir planen, diese Verbesserungen in Q4/2025 oder Q1/2026 zu veröffentlichen.

HPC-Koexistenz

Basierend auf diesen beiden Ansätzen möchten wir einen möglichen alternativen Entwurf für SAIA diskutieren, den wir intern unter dem Namen Scalable Kubernetes Inference Platform (SKIP) führen. Obwohl SKIP viele weitere Details umfasst, konzentrieren wir uns hier auf die HPC-Umgebung, welche die Backend-Infrastruktur der Inferenzplattform bildet.

Wenn entweder Ephemeral Kubernetes oder rootloses Kubernetes eingesetzt wird, ist ein Meta-Scheduler erforderlich, um die Ressourcenverhandlung zwischen den Kubernetes- und Slurm-Controllern zu steuern. Wir gehen von einem Anwendungsfall aus, der unserer Chat AI-Plattform (https://chat-ai.academiccloud.de/) ähnelt: Diese benötigt einen über Kubernetes betriebenen Backend-Bereich mit Zugriff auf GPU-Knoten. Wie in Abbildung 1 unter „Login“ dargestellt, dienen Nicht-GPU-Knoten als Einstiegsstellen für Slurm-Nutzende oder für Anfragen aus einer Frontend-Umgebung. Weitere Nicht-GPU-Knoten stellen die jeweiligen Kontrollplattformen für Slurm bzw. Kubernetes bereit. Schließlich gibt es einen Pool von GPU-Worker-Knoten, die flexibel entweder dem Kubernetes-Cluster (zur Bereitstellung von KI-Modellen) oder dem Slurm-Cluster (zur Verarbeitung von Batch-Jobs) zugewiesen werden.

Je nach gewähltem Ansatz steuert der Meta-Scheduler entweder Warewulf, um Knoten einem Ephemeral-Kubernetes-Cluster hinzuzufügen oder zu entziehen, oder er steuert Slurm, um Jobs zu übermitteln, die Kubernetes-Worker bereitstellen. Der vom Meta-Scheduler genutzte Algorithmus zur Knotenverteilung kann auf einem statischen Zeitplan basieren oder als dynamischer Scheduler die aktuelle Auslastung beider Cluster berücksichtigen.

Bei einem Cluster mit 20 GPU-Knoten könnten beispielsweise zehn Knoten basierend auf einem Zeitplan dynamisch zwischen dem Kubernetes- und dem Slurm-Scheduler wechseln, während jeweils fünf Knoten dauerhaft fest zugewiesen bleiben. Da bei einer KI-Dienstplattform die meisten Anfragen tagsüber eingehen, ließen sich die zehn flexiblen Knoten tagsüber der Inferenzplattform und nachts dem Slurm-Scheduler zuteilen, um anstehende Batch-Jobs abzuarbeiten.

Die in diesem Artikel vorgestellte Forschung zeigt, wie wir Innovationen entwickeln, um HPC-Ressourcen optimal für neue Anwendungsfälle zu nutzen. Zudem legen wir Wert darauf, unsere Entwicklungen direkt in den Produktivbetrieb zu überführen – wie etwa als Teil der Chat AI-Plattform. So kann rootloses Kubernetes beispielsweise im Scientific Compute Cluster (SCC) der GWDG genutzt werden, um Forschung auf Basis von Kubernetes zu ermöglichen.

Literaturhinweise