Startseite > Infrastruktur > Container und Virtualisierung

Container und Virtualisierung im KI-Rechenzentrum

Ein KI-Modell braucht nicht nur Hardware, sondern einen ganzen Stapel Software in genau passenden Versionen. Container haben sich als Standard durchgesetzt, um diesen Stapel portabel zu machen, und werfen eigene Fragen auf, wenn sie zwischen Rechnern umziehen sollen.

Das Problem mit den Abhängigkeiten

Ein typisches Trainings- oder Inferenzprogramm hängt von einem Framework wie PyTorch ab, das eine bestimmte Version der GPU-Bibliotheken erwartet, die wiederum zu einem bestimmten Treiber passen muss. Dazu kommen Kommunikationsbibliotheken, Python-Pakete und eigene Werkzeuge. Weicht eine Version ab, läuft das Programm langsamer, liefert abweichende Ergebnisse oder startet gar nicht. Auf einem gemeinsam genutzten Rechner mit vielen Nutzern ist das kaum beherrschbar.

Container statt virtueller Maschinen

Eine virtuelle Maschine bildet einen kompletten Rechner nach, einschließlich eines eigenen Betriebssystems. Ein Container teilt sich dagegen den Betriebssystemkern mit dem Gastgeber und packt nur Programm und Bibliotheken ein. Er startet in Sekunden und kostet kaum Leistung. Mit Docker wurde das Prinzip ab 2013 massentauglich.

Im wissenschaftlichen Hochleistungsrechnen setzte sich eine Variante durch, die ohne dauerhaft laufenden Dienst mit Administratorrechten auskommt: Apptainer, früher Singularity. Nutzer können dort ihre eigene Umgebung mitbringen, ohne die Sicherheit des gemeinsamen Systems zu gefährden. Für den Zugriff auf GPUs reichen Werkzeuge wie das NVIDIA Container Toolkit den Treiber des Gastgebers in den Container durch.

Bunte Netzwerkkabel in einem offenen Serverschrank

Eine GPU, mehrere Nutzer

Nicht jede Aufgabe braucht einen ganzen Beschleuniger. Für kleine Modelle oder Tests wäre eine volle Rechenzentrums-GPU Verschwendung. Es gibt drei verbreitete Wege, sie zu teilen:

Zeitscheiben: Mehrere Container wechseln sich ab. Einfach, aber ohne Garantie für Speicher und Leistung.
Hardware-Partitionierung: Neuere Rechenzentrums-GPUs lassen sich in bis zu sieben feste Instanzen mit eigenem Speicher aufteilen (Multi-Instance GPU). Jede verhält sich wie eine kleine eigene Karte.
Virtualisierung: Eine virtuelle GPU wird einer virtuellen Maschine zugewiesen, verbreitet bei Cloud-Anbietern.

Orchestrierung

Bei Hunderten Containern auf Dutzenden Servern übernimmt eine Orchestrierung die Verteilung. Kubernetes startet Container, ersetzt abgestürzte, verteilt Anfragen und skaliert je nach Last. Für Inferenzdienste ist das heute der Normalfall. Für große Trainingsläufe wird es mit Batch-Schedulern kombiniert, die Gruppen von GPUs gemeinsam zuteilen, wie im Beitrag über Scheduling beschrieben.

Umziehen im laufenden Betrieb

Ein Container lässt sich leicht auf einem anderen Rechner neu starten. Schwieriger ist es, einen laufenden Prozess mitsamt seinem Zustand zu verschieben, etwa weil ein Server gewartet werden muss oder ein dringender Job Platz braucht. Für normale Prozesse gibt es dafür seit Jahren Werkzeuge wie CRIU (Checkpoint/Restore In Userspace), die den Speicher eines Prozesses einfrieren, übertragen und anderswo fortsetzen.

Bei GPU-Prozessen ist das komplizierter, weil ein großer Teil des Zustands im Grafikspeicher liegt, den das Betriebssystem nicht direkt sieht. Seit 2024 bietet NVIDIA ein Werkzeug an, mit dem sich der Zustand von CUDA-Prozessen sichern lässt, sodass er zusammen mit CRIU wiederhergestellt werden kann. In der Praxis setzen Trainingsläufe dennoch meist auf eigene, anwendungsseitige Checkpoints: Das Programm schreibt selbst in regelmäßigen Abständen Gewichte und Optimiererzustand auf ein Speichersystem und kann von dort auf beliebigen Rechnern weitermachen.

Reproduzierbarkeit

Für die Forschung haben Container einen Nebeneffekt, der fast wichtiger ist als die Bequemlichkeit: Ein veröffentlichtes Container-Abbild hält fest, mit welcher Software ein Ergebnis entstanden ist. Wer ein Experiment nachrechnen will, startet dieselbe Umgebung. Zusammen mit offenem Code und offenen Gewichten (siehe offene Modelle) wird KI-Forschung dadurch überprüfbarer.

Sicherheit

Container isolieren weniger stark als virtuelle Maschinen, weil sie sich den Kern teilen. Auf Systemen, auf denen fremde Nutzer eigenen Code ausführen, kombinieren Betreiber deshalb häufig beides oder setzen zusätzliche Schutzschichten ein. Abbilder aus unbekannten Quellen können Schadsoftware enthalten; seriöse Umgebungen prüfen und signieren die verwendeten Abbilder.

Hinzu kommt der Grafikspeicher: Wird eine GPU nacheinander von verschiedenen Kunden genutzt, muss sichergestellt sein, dass keine Reste von Daten oder Modellgewichten zurückbleiben. Hardware-Partitionierung trennt Speicherbereiche auch physisch, was ein Grund für ihre Beliebtheit bei Cloud-Anbietern ist.

Ein typischer Ablauf

Wie ein KI-Dienst mit Containern in Betrieb geht, folgt meist demselben Muster:

Eine Bauanleitung legt Basisabbild, Bibliotheken und Programmcode fest.
Daraus entsteht ein Abbild, das in einer Registry, einem Ablagesystem für Abbilder, gespeichert wird.
Die Modellgewichte werden meist getrennt abgelegt, weil sie viele Gigabyte groß sind und sich unabhängig vom Code ändern.
Die Orchestrierung startet Container auf Servern mit passenden GPUs und bindet die Gewichte ein.
Ein vorgeschalteter Router verteilt Anfragen und nimmt neue Versionen schrittweise in Betrieb, damit Fehler nur einen kleinen Teil der Nutzer treffen.

Der Vorteil dieses Vorgehens zeigt sich bei Problemen: Eine fehlerhafte Version lässt sich in Minuten durch die vorherige ersetzen, weil das alte Abbild unverändert in der Registry liegt.

Stand: November 2026, Redaktion fast project