Kann man ein GPU-Notebook stoppen und am selben Experiment weiterarbeiten?

Es ist 18 Uhr. Ein Notebook hat endlich ein Modell geladen und Ergebnisse geliefert, die eine genauere Betrachtung verdienen. Stoppen Sie die Sitzung, verbringen Sie morgen womöglich einen Teil des Tages damit, die Umgebung und das Modell erneut zu laden. Lassen Sie sie laufen, kann ein knapper Beschleuniger die ganze Nacht ungenutzt bleiben.

Google kündigte GKE Workspaces am 4. November an. Die Open-Source-Entwicklungsumgebung läuft im Google-Kubernetes-Engine-Cluster eines Teams. Über ein Browser-Dashboard lassen sich JupyterLab oder VS Code mit vorgegebenen Ressourcen starten. Das Projekt baut auf Kubeflow Workspaces auf und dokumentiert, wie sich unterstützte Sitzungen anhalten und fortsetzen lassen. Für Teams kommt es darauf an, welchen Zustand sie morgen brauchen und welche Ressourcen dafür belegt bleiben müssen.

Zugeschnittenes Standbild aus der Demo zur Wiederaufnahme von Notebooks mit GKE Workspaces, Apache 2.0. Bildquelle · Lizenz.

Eine Notebook-Datei und eine laufende Sitzung bewahren unterschiedliche Dinge

GPU-Notebook anhalten. Eigene Darstellung von Telli.sh.

Eine gespeicherte Notebook-Datei enthält die geschriebenen Zellen und alle mitgespeicherten Ausgaben. Auf einem Datenträger bleiben Datensätze und Checkpoints für einen neuen Prozess erreichbar. Beides sichert nicht automatisch alles, was eine laufende Sitzung enthält. Zu einem Experiment können initialisierte Variablen, ein Modell auf einem Beschleuniger und ein nur mit Aufwand wiederherstellbarer Zwischenzustand gehören.

Google beschreibt GKE Pod Snapshots als Möglichkeit, den laufenden Zustand unterstützter Arbeitsbereiche zu speichern und die Rechenressourcen freizugeben. Die Dateien des Arbeitsbereichs bleiben auf dauerhaftem Speicher. Für die Wiederaufnahme müssen passende Kapazität und der Snapshot verfügbar sein. Ein Anhalten kommt damit eher der Fortsetzung eines Experiments gleich als dem Öffnen einer gespeicherten Datei. Die Voraussetzungen der Umgebung bleiben relevant.

Reproduzierbarkeit und Komfort verbessern unterschiedliche Teile des Ablaufs. Ein Snapshot hilft, wenn jemand eine Sitzung bald wieder aufnehmen möchte. Ein reproduzierbares Notebook und ein Anwendungs-Checkpoint erleichtern anderen die Wiederholung oder den Wechsel der Umgebung. Bei wichtigen Experimenten lohnt es sich, beides aufzubewahren.

Ein Forschungsteam kann zwischen Besprechungen eine GPU-Sitzung anhalten und gleichzeitig den Code einchecken und Modellartefakte an einem dauerhaften Ort sichern. Wenn der Snapshot später nicht wiederhergestellt werden kann, bleibt ein klarer Ausweichweg. Auch eine lange Trainingsaufgabe kann regelmäßig Checkpoints speichern, selbst wenn der Arbeitsbereich bereits eine Pause unterstützt.

Auch ein gestoppter Arbeitsbereich kann Kosten verursachen

Tatsächliche Kosten ermitteln. Eigene Darstellung von Telli.sh.

Der unmittelbare wirtschaftliche Vorteil besteht darin, keine Rechenleistung zu nutzen, wenn niemand arbeitet. Was auf der Rechnung steht, hängt davon ab, was der Cluster nach dem Stopp tut. Ein Knoten kann weiterlaufen, weil andere Pods ihn benötigen. Eine Reservierung kann weiterhin Kosten oder eine Verpflichtung verursachen. Dauerhafte Datenträger und gespeicherte Snapshots bleiben Teil des Systems.

Nehmen wir einen hypothetischen Fall. Hält eine Forscherin einen ansonsten ungenutzten Beschleuniger nach Feierabend zwölf Stunden belegt, kann die Pause diese zwölf Accelerator-Stunden potenziell freigeben. Das ist eine Chance, Kapazität nutzbar zu machen. Der finanzielle Effekt hängt von Bereitstellung und Abrechnung von Knoten und Beschleuniger ab. Muss der Knoten für eine andere Aufgabe online bleiben, verbessert die Pause womöglich eher die Planung als die Rechnung.

Ein fairer Vergleich berücksichtigt auch Zeit. Ein Snapshot beansprucht Ressourcen, die Wiederherstellung eines großen Zustands dauert und der gewünschte Beschleuniger steht eventuell nicht sofort bereit. In einem stark genutzten Cluster kann schon die Weitergabe des Geräts an jemand anderen wertvoll sein, auch wenn das Team die Kapazität bereits verbindlich gebucht hat.

Erfassen Sie das Ende der aktiven Arbeit, den Stopp des Arbeitsbereichs und den Zeitpunkt, zu dem der Knoten wieder zur Verfügung steht. Messen Sie dann, wann nach dem Fortsetzen die nächste Zelle ausgeführt werden kann. Damit sieht das Plattformteam, ob eine Pausenregel nennenswert Kapazität zurückgibt, ohne den nächsten Arbeitsbeginn in eine Warteschlange zu verwandeln.

Das Plattformteam bestimmt weiterhin die Rahmenbedingungen

Selbstbedienung ändert, wer die Schaltfläche bedient. Administratoren legen weiterhin fest, welche Images gestartet werden dürfen, welche Beschleuniger verfügbar sind und wie der Cluster Kontingente und Isolation handhabt. Das Repository nennt Apache 2.0 als Lizenz und weist darauf hin, dass GKE Workspaces kein offiziell unterstütztes Google-Produkt ist. Bei der Bewertung für ein Team gehören Installation und Betrieb zur Verantwortung der Technik.

Ein ML-Entwickler braucht vielleicht eine vertraute IDE, ausreichend Arbeitsspeicher und Zugriff auf die Versuchsdaten. Die Plattformverantwortlichen denken außerdem an Standardidentitäten, Speicherrechte, das Stoppen von Arbeitslasten und aktualisierbare Images. Diese Anforderungen lassen sich vereinen, wenn die Arbeitsbereichstypen die Abwägungen sichtbar machen. Ein kleines CPU-Notebook und eine GPU-Sitzung für Experimente können unterschiedliche Voreinstellungen haben.

Die Ankündigung beschreibt außerdem Beschleunigeroptionen und Verbindungen für lokale Werkzeuge oder Agenten. Lesen Sie die Einrichtungshinweise für Ihren Cluster und Anwendungsfall, bevor Sie die Optionen als austauschbar behandeln. Hardwarespezifische Wiederherstellung, clusterübergreifender Zugriff und eine Verbindung zur lokalen Entwicklung haben jeweils eigene Voraussetzungen. Beginnen Sie mit einem einfachen Fall, in dem ein Teammitglied den Arbeitsbereich prüfen und seinen Cluster eindeutig erkennen kann.

Testen Sie das Anhalten und Wiederherstellen einmal vollständig

1. Lesen Sie die Installationsanleitung des Projekts und die aktuellen Anforderungen Ihrer GKE-Umgebung für Snapshots und Beschleuniger. Richten Sie einen Testarbeitsbereich mit Berechtigungen und Ressourcenlimits ein, die dem geplanten Ablauf entsprechen.
2. Starten Sie ein reproduzierbares Notebook. Speichern Sie dessen Eingabe, einen Zwischen-Checkpoint der Anwendung und eine kleine Ergebnisdatei. Erfassen Sie Zeit und Ressourcenzuteilung vor dem Anhalten.
3. Halten Sie den Arbeitsbereich an und prüfen Sie die Ressourcen im Cluster. Kontrollieren Sie, ob der Pod gestoppt wurde, ob der Beschleuniger neu eingeplant werden kann und welcher Speicher erhalten bleibt.
4. Setzen Sie den Arbeitsbereich fort. Prüfen Sie die erwarteten Dateien und den laufenden Zustand. Führen Sie eine Zelle aus, die das geladene Modell nutzt. Messen Sie die Zeit von der Anfrage bis zum nutzbaren Notebook.
5. Stellen Sie dieselbe Arbeit aus den gespeicherten Dateien und dem Anwendungs-Checkpoint wieder her. So haben Sie einen Ausweichweg und einen Vergleich, wenn die Wiederherstellung des Snapshots langsam oder nicht verfügbar ist.
6. Prüfen Sie die Inaktivitätsregeln im Team. Legen Sie fest, was als inaktiv gilt und ob lange laufende Aufgaben einen eigenen Arbeitsbereichstyp oder eine ausdrückliche Sonderbehandlung brauchen.

Testen Sie die Wiederherstellung auch bei knappem Kontingent oder einem ausgelasteten Cluster. Eine reibungslose Demo im leeren Cluster kann verbergen, wie schwer es ist, Kapazität zu bekommen, wenn viele Nutzer gleichzeitig zurückkehren. Der Test soll zeigen, wie sich das System verhält, wenn die Ressource knapp ist.

Rechnen Sie nach, wo die GPU-Zeit bleibt

Stellen Sie sich einen Entwicklerarbeitsplatz vor, der 40 Stunden pro Woche genutzt wird. Eine die ganze Woche belegte Maschine kommt auf 168 Stunden. Kann die Plattform den GPU-Knoten bei jeder Pause freigeben und nur während dieser 40 Stunden wieder bereitstellen, entfallen vor Berücksichtigung von Snapshot und Wiederherstellung 128 Stunden belegter Knotenzeit. Das ist ein Beispiel ohne unterstellten Cloud-Preis oder eine bestimmte Auslastung. Es ist eine Obergrenze für dieses Belegungsmuster, denn ein geteilter Knoten kann in dieser Zeit andere nützliche Arbeit erledigen.

Ein realistischerer Vergleich beginnt mit einem Ausgangswert aus dem eigenen GPU-Pool. Erfassen Sie pro Testzeitraum die Knotenstunden, die Belegung durch andere Aufgaben und den Umfang der gespeicherten Arbeitsbereichsdaten. Notieren Sie auch, wie lange es nach der Wiederaufnahme dauert, bis die nächste Zelle läuft. Bleibt der Knoten wegen einer zweiten Aufgabe aktiv, kann das pausierte Notebook Kapazität für diese Aufgabe schaffen, ohne die Rechnung zu senken. Auch das kann ein nützliches Ergebnis sein.

Die Dauer des Snapshots gehört in die Rechnung. Wenn das Anhalten lange dauert und der alte Pod dabei belegt bleibt, kann ein niedriger Inaktivitätsschwellenwert mehr Unterbrechungen ohne nennenswerte Einsparung verursachen. Dauert das Fortsetzen mehrere Minuten, weil die automatische Skalierung erst eine passende GPU bereitstellen muss, kann jemand nach einer kurzen Pause mehr Zeit verlieren, als die Regel spart. Messen Sie mehrere Pausendauern.

Legen Sie vor der ersten Pause fest, was erhalten bleiben muss

Das Repository von GKE Workspaces beschreibt einen zustandslosen VS-Code-Ablauf und ein separates zustandsbehaftetes JupyterLab-Beispiel. Letzteres zeigt die Wiederherstellung eines GPU-Notebooks, unter anderem mit einem Qwen2.5-Modell mit 3 Milliarden Parametern auf einer T4. Kubernetes-Pod-Snapshots und das Beispiel haben konkrete Kompatibilitätsanforderungen. Die GKE-Dokumentation erläutert die Rolle der GKE Sandbox sowie kompatible Knoten- und Image-Konfigurationen. Prüfen Sie beim GPU-Beispiel vorab, dass der neue Knoten dasselbe unterstützte GPU-Modell und eine kompatible Umgebung bietet.

Klären Sie, was Ihre Nutzer von einer Pausentaste erwarten. Manche erwarten Dateien, Ausgaben und den Zustand des Editors. Andere wollen, dass die nächste Python-Zelle ein bereits im RAM liegendes Objekt oder ein Modell im VRAM nutzen kann. Ein geteilter Datensatz kann im externen Objektspeicher liegen und außerhalb des Snapshots bleiben. Halten Sie fest, welche Zustände sich wiederherstellen lassen, wo normale Dateien dauerhaft gespeichert werden und was bei einer fehlgeschlagenen Wiederherstellung zu tun ist.

Ein zweiter sinnvoller Versuch prüft einen Fehler vor der Wiederaufnahme. Machen Sie passende Kapazität in einem Test-Namespace vorübergehend unverfügbar. Prüfen Sie, ob der Arbeitsbereich einen klaren Status anzeigt, anstatt konkurrierende Wiederherstellungen zu starten. Prüfen Sie, ob die zuständige Person mit Dateien oder gespeicherten Ausgaben weiterarbeiten kann, wenn der Prozess im Arbeitsspeicher nicht zurückkehrt. Entfernen Sie danach den Test-Snapshot und prüfen Sie die Speicher- und Aufbewahrungsregeln.

Machen Sie die Kosten für das ganze Team verständlich

Forschende möchten ihre Arbeit fortsetzen. Das Plattformteam möchte knappe GPU-Kapazität an den Pool zurückgeben. Abrechnungsverantwortliche möchten wissen, ob eine Zuteilung tatsächlich verschwindet. Ein Test kann alle drei Fragen beantworten, wenn er Leerlaufzeit, Knotenzuweisung, Snapshot-Größe, erfolgreiche Wiederaufnahmen und Wiederherstellungszeit getrennt erfasst. Dokumentieren Sie Fehlerfälle für den Support und zeigen Sie den Nutzern, ob ihr Arbeitsbereich pausiert, auf Kapazität wartet oder bereit ist.

Wählen Sie auf dieser Grundlage eine Inaktivitätsregel je Arbeitslast. Eine lange Notebook-Sitzung mit einem Modell, das nur langsam lädt, kann vom Erhalt des Arbeitsspeichers zwischen zwei Schichten profitieren. Für ein kurzes Experiment auf Grundlage eines gespeicherten Skripts können dauerhafte Dateien und ein sauberer Neustart genügen. Beide können denselben Pool nutzen, ohne dieselbe Wiederherstellungszeit zu versprechen.

Ein Wiederaufnahmetest gehört auf die Freigabeliste

Eine Plattformaktualisierung kann das Start-Image oder den GPU-Knotenpool ändern. Legen Sie vor der Umstellung ein Test-Notebook mit der alten Konfiguration an und prüfen Sie es mit der neuen. Der Test sollte zwischen einer erfolgreichen Wiederherstellung und einer neuen Sitzung mit derselben geöffneten Notebook-Datei unterscheiden. Lesen Sie dafür einen Wert aus, der nur im laufenden Testprozess existiert, und prüfen Sie anschließend die von ihm verwendeten Dateien.

Macht ein Upgrade alte Snapshots ungültig, sollten Nutzer wichtige Ergebnisse vorher speichern können und den Ausweichweg kennen. Prüfen Sie die Bereinigung abgelaufener Snapshots gesondert. Ein Wiederherstellungstest zeigt, dass ein Arbeitsbereich zurückkehren kann. Ein Bereinigungstest zeigt, wie viel alter Zustand übrig bleibt, wenn er nicht mehr genutzt wird.

Bewahren Sie den Zustand, der am schwersten wiederherzustellen ist

Ein Arbeitsbereich wird nützlicher, wenn Menschen sich weniger um die Laufzeit der Maschine kümmern müssen und ihre Arbeit dennoch wiederfinden. Dafür müssen Dateien, Checkpoints, Snapshots und Kapazität getrennt behandelt werden. Bewahren Sie nur den Zustand auf, den Sie für einen sinnvollen Wiedereinstieg brauchen. Stellen Sie zugleich sicher, dass das Projekt ohne die ursprüngliche Sitzung reproduzierbar bleibt.

Wenn Ihr Team sagen kann, was auf dem Datenträger bleibt, was wiederhergestellt werden muss und wann die Rechenressourcen frei werden, kann es eine Pausenregel festlegen, die im Alltag funktioniert.

Quellen

• GKE-Dokumentation zu Pod-Snapshots und Kompatibilität

• Fortsetzbares Notebook-Beispiel in der Demo-Revision

• Ankündigung vom 4. November und Workspace-Demo im Google Open Source Blog

• GKE-Workspaces-Quellcode, Supportstatus und Installationsanleitung

---

Wenn Sie die Gespräche und Entscheidungen hinter Ihrer Arbeit durchsuchbar festhalten möchten, erstellen Sie ein Telli.sh-Konto.