12. November 2026 · VRAMfarm-Team

Keine GPU im Leerlauf bezahlen: automatischer Stopp, tmux und Stopp per Code

Eine RTX 4090, die von 18 Uhr bis 9 Uhr morgens läuft, kostet 15 Stunden: 8,85 € für eine Nacht, in der nichts passiert. Mit dem automatischen Stopp bei Leerlauf kostet derselbe Fehler meist etwa drei Stunden, 1,77 €, und Ihr Ordner /workspace wird beim Beenden gespeichert. Der automatische Stopp ist aber nur das Sicherheitsnetz. Richtig sparen Sie mit ein paar Gewohnheiten: zwischen Sitzungen stoppen, Nachtjobs so starten, dass sie Sie nicht brauchen, und den Job den Server selbst stoppen lassen.

So funktioniert der automatische Stopp bei Leerlauf

Wird ein Server etwa zwei Stunden lang von niemandem genutzt, bekommen Sie eine Nachricht von uns: im Chat des Dashboards und, wenn Sie gerade nicht auf der Website sind, per E-Mail. Bleibt er eine weitere Stunde im Leerlauf und lässt sich sein Ordner speichern, speichert der Server /workspace und stoppt. Sie erhalten eine Benachrichtigung, dass er gestoppt wurde und Ihr Ordner auf den nächsten Server wartet. Lässt sich der Ordner nicht speichern (eigenes Docker-Image, siehe unten), bekommen Sie nur die Warnungen, und der Server läuft weiter, bis Sie ihn stoppen. Schlägt ein Upload fehl, läuft der Server ebenfalls weiter, und Sie werden darüber informiert.

Was als Nutzung zählt. Wir schauen auf drei Signale:

• eine offene Verbindung zum Server über unsere Adresse: SSH, Jupyter oder die App (ComfyUI, der Chat, vLLM);
• Daten, die in der letzten halben Stunde noch über diese Verbindungen geflossen sind;
• GPU-Last über ein paar Prozent.

Jedes einzelne davon genügt, damit der Server als beschäftigt gilt. Ein Training zählt als GPU-Last und wird deshalb nie gestoppt, solange es rechnet, auch wenn niemand verbunden ist. Die Zeiten in der Tabelle sind ungefähr. Die zwei Stunden zählen ab dem Moment, in dem der Server zuletzt genutzt wurde: Nach einem langen GPU-Job oder einer beendeten Sitzung kommt die Warnung also etwa zwei Stunden später, plus/minus zehn Minuten.

Was nach Leerlauf aussieht. Ein offener Jupyter-Kernel ohne Browser-Tab bei untätiger GPU. Ein Job, der nur auf der CPU läuft, etwa das Entpacken eines großen Archivs oder das Tokenisieren eines Datensatzes. Ein langer Download, der auf dem Server gestartet wurde, ohne dass etwas verbunden ist. Hat Ihre Arbeit solche ruhigen Phasen, klicken Sie auf Ich arbeite noch, wenn die Nachricht kommt, halten Sie eine Verbindung offen oder schalten Sie den automatischen Stopp für diese Zeit ab.

Wo er nicht greift. Der automatische Stopp beendet nur Server, deren Ordner sich speichern lässt, denn ein Stopp ohne Speichern würde Ihre Dateien löschen. Damit fallen Server mit Ihrem eigenen Docker-Image heraus: Ihr Ordner lässt sich noch nicht speichern, sie werden also nie automatisch gestoppt. Die Leerlaufnachricht bekommen Sie trotzdem, aber stoppen müssen Sie oder Ihr Skript; wie das geht, steht im API-Ratgeber für Batch-Jobs.

Abschalten, und warum Sie es meist lassen sollten

Die Option finden Sie unter Einstellungen: „Server im Leerlauf automatisch stoppen und Ordner speichern“. Ist sie aus, bekommen Sie weiterhin die Leerlaufnachrichten, höchstens alle sechs Stunden pro Server, aber nichts wird gestoppt.

Schalten Sie sie nur mit gutem Grund ab: ein Job mit stundenlanger CPU-Arbeit zwischen den GPU-Schritten oder ein Server, den Sie als Test-Endpunkt behalten, der ab und zu aufgerufen wird. Eine einmalige ruhige Phase lösen Sie besser mit Ich arbeite noch, dann bleibt das Sicherheitsnetz fürs nächste Mal bestehen.

Ohne automatischen Stopp läuft ein vergessener Server, bis Sie ihn stoppen oder Ihr Guthaben aufgebraucht ist. Ein Stopp bei Guthaben null speichert nichts: Die Festplatte wird mit allem gelöscht, was darauf lag. Was bei null genau passiert, steht im Ratgeber zur Abrechnung.

Das umgekehrte Problem: Verbindungen, die einen Server beschäftigt halten

Weil offene Verbindungen als Nutzung zählen, kann ein vergessenes Fenster einen Server genauso die ganze Nacht laufen lassen wie ein vergessener Server. Die üblichen Verdächtigen:

• ein PowerShell- oder Terminal-Fenster mit einer SSH-Sitzung, die Sie nie geschlossen haben;
• ein Jupyter- oder ComfyUI-Tab, der im Browser offen geblieben ist;
• ein VS-Code- oder Cursor-Fenster, das noch über Remote SSH verbunden ist.

Aus Sicht des Servers sieht jedes davon so aus, als würde jemand arbeiten. Schließen Sie also nach getaner Arbeit die Tabs und die Sitzung, oder besser: Stoppen Sie den Server sofort. Warten Sie nicht darauf, dass der automatische Stopp das drei Stunden später erledigt.

Gewohnheiten, die Leerlauf reduzieren

Zwischen Sitzungen stoppen. Die Vorbereitung eines Servers dauert 2–5 Minuten und wird nicht berechnet. Ein neuer Start kostet mindestens 15 Minuten, und eine fertige App lädt ihre Modelle erneut herunter, was berechnet wird. Ab wann sich das Stoppen lohnt, hängt also davon ab, was Sie betreiben:

Eine Mittagspause auf einer RTX 4090 kostet 0,59 € pro Stunde, wenn Sie sie laufen lassen. Auf einer H100 zu 3,90 € pro Stunde oder auf einer Maschine mit mehreren GPUs tut dieselbe Stunde deutlich mehr weh.

„Speichern und stoppen“ statt „Stoppen“, wenn Sie wiederkommen. Ihre LoRAs, Ergebnisse, Notebooks und Skripte sind auf dem nächsten Server wieder da, auch auf einer anderen Karte. Der Speicher kostet 0,03 € pro GB und Monat. Was aufbewahrt wird und was nicht, steht unter was mit Ihren Dateien passiert, wenn Sie eine GPU stoppen.

Dort vorbereiten, wo es günstig ist. Code schreiben, Imports reparieren und einen Datensatz herunterladen brauchen keine H100. Erledigen Sie das auf Ihrem eigenen Computer oder auf einer kleinen Karte wie der RTX 3060 zu 0,12 € pro Stunde, speichern Sie den Ordner und starten Sie die große Karte erst, wenn der Job startklar ist.

Mit einem Ausschnitt der Daten testen. Fünf Minuten mit 1 % des Datensatzes zeigen den Absturz, der sonst erst eine Stunde nach Beginn des vollen Laufs käme, während die teure Karte wartet.

Den Stopp in den Job einbauen. Am sichersten zahlen Sie nicht für einen fertigen Job, wenn der Job den Server selbst stoppt. Darum geht es im letzten Abschnitt unten.

Nachtjobs mit tmux

Starten Sie einen Job in einer normalen SSH-Sitzung und die Verbindung bricht ab (Laptop zugeklappt, WLAN, VPN), stirbt der Job meist mit. tmux hält ihn auf dem Server am Laufen, unabhängig von Ihrer Verbindung. Im Jupyter-Terminal funktioniert das genauso.

Ob es installiert ist, prüfen Sie mit tmux -V. Falls nicht, installieren Sie es; es landet außerhalb von /workspace, wiederholen Sie das also auf jedem neuen Server:

apt-get update && apt-get install -y tmux

Dann:

tmux new -s train          # Sitzung mit dem Namen „train“ öffnen
python train.py            # den Job darin starten
# Strg+B drücken, dann D, um die Sitzung zu verlassen; der Job läuft weiter
tmux ls                    # Sitzungen später auflisten
tmux attach -t train       # zur Sitzung zurückkehren

Ohne tmux erledigt nohup das Wesentliche und schreibt die Ausgabe in eine Logdatei, die Sie verfolgen können:

nohup python train.py > /workspace/train.log 2>&1 &
tail -f /workspace/train.log     # Strg+C beendet nur das Mitlesen, nicht den Job

Für alles, was läuft, während Sie schlafen, gelten zwei Regeln. Schreiben Sie alle 15–30 Minuten Checkpoints nach /workspace, damit ein Fehler ein Intervall kostet und nicht die ganze Nacht. Und laden Sie vor dem Start auf: Ein Guthaben, das um 3 Uhr nachts ausgeht, stoppt den Server ohne Speichern.

Solange der Job rechnet, lässt ihn der automatische Stopp in Ruhe. Ist er fertig, wird die GPU ruhig: Etwa zwei Stunden später kommt die Warnung, eine Stunde danach speichert der Server seinen Ordner und stoppt. Das ist das Sicherheitsnetz. Der nächste Abschnitt erspart Ihnen diese Leerlaufstunden.

Den Server per Code stoppen, wenn der Job endet

Jeder Server lässt sich über die API stoppen. Erstellen Sie einen Token unter Einstellungen → API-Tokens; er beginnt mit gf_live_ und wird nur einmal angezeigt. Notieren Sie die Nummer Ihres Servers aus Meine Server (die #1234 auf der Karte). Auf dem Server:

export GF_TOKEN=gf_live_xxxxxxxxxxxxxxxx
export GF_ID=1234

python train.py; curl -s https://vramfarm.com/api/instances/stop \
  -H "Authorization: Bearer $GF_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"id\": $GF_ID, \"save\": true}"

Das ; ist wichtig: Der Stopp läuft, egal ob das Training gelingt oder abstürzt. Mit && stattdessen würde ein Absturz den Server weiterlaufen lassen. "save": true lädt zuerst /workspace hoch und stoppt dann; die Abrechnung läuft die paar Minuten des Uploads weiter, und schlägt der Upload fehl, läuft der Server weiter. Lassen Sie es weg, stoppt der Server sofort und die Festplatte wird gelöscht. Auf einem Server mit Ihrem eigenen Docker-Image hat save keine Wirkung, der Server stoppt einfach. Führen Sie die ganze Zeile in tmux aus, damit der Stopp auch dann passiert, wenn Ihre Verbindung abbricht.

In Python dieselbe Idee mit try/finally:

import os, requests

def stop_server(save=True):
    requests.post("https://vramfarm.com/api/instances/stop",
                  headers={"Authorization": f"Bearer {os.environ['GF_TOKEN']}"},
                  json={"id": int(os.environ["GF_ID"]), "save": save}, timeout=30)

try:
    train()                       # Ihre Trainingsschleife
finally:
    stop_server()

Ein Wort zum Token. Er liegt auf einer Maschine, die einem Anbieter gehört, behandeln Sie ihn also als offengelegt: Erstellen Sie dafür einen eigenen Token mit einem Namen wie „self-stop“ und widerrufen Sie ihn, wenn das Projekt endet. Ein Token kann Server starten, auflisten und stoppen, aber weder Ihr Passwort noch Ihren SSH-Schlüssel ändern oder neue Tokens erstellen. Die Spalte Zuletzt genutzt in den Einstellungen zeigt, ob ein Token benutzt wird, wenn er es nicht sollte.

Wollen Sie den Token ganz vom Server fernhalten, führen Sie den Stopp von Ihrem eigenen Computer oder aus Ihrer CI aus. Ein Skript dort startet den Server, wartet auf den Job, kopiert die Ergebnisse und stoppt ihn. Der Ratgeber GPU-API für Batch-Jobs zeigt diese Variante in curl und Python, mit eingebauter Ausgabengrenze.