gpu-hot: NVIDIA-Monitoring als selbst gehostetes Dashboard
🔥 Real-time NVIDIA GPU dashboard
Auf einen Blick
- Was ist das?
- gpu-hot liest NVML-Werte aus, liefert sie über Socket.IO an den Browser und lässt sich im Hub-Modus über mehrere GPU-Server bündeln. Wer die Umgebung kontrolliert und kein SaaS-Monitoring will, bekommt hier ein kleines Werkzeug mit klaren Grenzen.
- Für wen ist es gedacht?
- Sinnvoll ist gpu-hot für Teams, die eine überschaubare Zahl eigener NVIDIA-Knoten im eigenen Netz betreiben und keine externen Agenten installieren wollen. Wer Metriken langfristig speichern, Alarme auslösen oder Nicht-NVIDIA-Hardware überwachen muss, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 22 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke gpu-hot schließt
nvidia-smi liefert auf einem einzelnen Rechner alles, was man zur Momentaufnahme braucht. Sobald aber mehrere GPU-Server nebeneinander laufen, fehlt die gemeinsame Ansicht, und ein vollständiges Monitoring-System wie Prometheus mit Node-Exporter und Grafana bedeutet Konfigurationsaufwand, der für eine Handvoll Knoten oft nicht gerechtfertigt ist. gpu-hot setzt genau dort an: eine Web-Oberfläche, die laut README Echtzeitwerte im Subsekundenbereich zeigt, automatisch mehrere GPUs erkennt und sich über ein einzelnes Docker-Image sowohl auf einem Rechner als auch über mehrere Knoten betreiben lässt. Die Zielgruppe sind damit Betreiber kleiner bis mittlerer GPU-Installationen, etwa eine Workstation mit zwei Karten oder ein halbes Dutzend Ausbildungs- und Inferenzknoten. Der Verweis im README auf Skalierung von 1 bis über 100 GPUs ist eine Aussage des Projekts, kein belegter Messwert, und sollte als solche gelesen werden.
NVML, Socket.IO und der Hub als zweite Ebene
Im Kern liest core/monitor.py die Werte über NVML aus, also über dieselbe Schnittstelle, die auch der NVIDIA-Treiber bereitstellt. Ein Collector in core/metrics/ sammelt und normalisiert die Messpunkte, core/handlers.py verteilt sie über Socket.IO an verbundene Browser. Das Frontend ist kein Framework-Bauwerk: statische JavaScript-Dateien wie socket-handlers.js, chart-manager.js und gpu-cards.js rendern die Karten und Diagramme, wobei die Socket-Schicht laut Projektstruktur gebündelt rendert, statt für jeden eintreffenden Messwert sofort neu zu zeichnen. Für ältere Karten existiert mit core/nvidia_smi_fallback.py ein zweiter Pfad, der statt NVML das Kommandozeilenwerkzeug aufruft und dafür mit NVIDIA_SMI_INTERVAL ein eigenes, langsameres Intervall hat. Der Hub-Modus ergänzt eine zweite Ebene: core/hub.py und hub_handlers.py holen die Daten der konfigurierten Knoten ab und führen sie in einer Ansicht zusammen. Der Hub selbst braucht laut README keine GPU, was bedeutet, dass die Aggregation nicht auf einer der überwachten Maschinen laufen muss.
Ein Befehl bis zum Dashboard, danach die Umgebungsvariablen
Der Einstieg ist ein einzelner Docker-Aufruf: docker run -d --gpus all -p 1312:1312 ghcr.io/psalias2006/gpu-hot:latest, danach ist die Oberfläche unter http://localhost:1312 erreichbar. Voraussetzung sind Docker und das NVIDIA Container Toolkit. Für mehrere Maschinen startet man auf jedem GPU-Server denselben Befehl, ergänzt um -e NODE_NAME=$(hostname), und auf einem Hub-Rechner ohne GPU läuft das Image mit -e GPU_HOT_MODE=hub und -e NODE_URLS=http://server1:1312,http://server2:1312,http://server3:1312. Die Liste der Knoten-URLs ist im Hub-Modus Pflicht, nicht optional. Wer aus dem Quelltext bauen will, klont das Repository und ruft docker-compose up --build auf. Die übrigen Variablen greifen ins Verhalten ein: NVIDIA_VISIBLE_DEVICES=0,1 beschränkt die Überwachung auf einzelne Karten, UPDATE_INTERVAL=0.5 setzt das NVML-Abfrageintervall in Sekunden, NVIDIA_SMI=true erzwingt den Fallback-Pfad. Der Port selbst steht nicht in einer Umgebungsvariable, sondern als PORT = 1312 in core/config.py, wer ihn ändern will, muss also an den Quelltext oder an das Port-Mapping des Containers.
Prozessnamen kosten Zugriff auf den Host
Die Prozessüberwachung mit PID und Speicherverbrauch ist im README an eine Bedingung geknüpft: der Container braucht --init --pid=host. Damit teilt er den PID-Namensraum des Hosts und kann fremde Prozessinformationen einsehen. Das ist eine bewusste Erweiterung der Angriffsfläche, die man nicht nebenbei aktivieren sollte, und das README benennt sie auch selbst. Ohne diese Flags bleiben die Prozessnamen entsprechend leer. Ein zweiter Punkt betrifft die Last: Polling wird laut README automatisch pausiert, solange kein Client verbunden ist, sodass die Leerlauf-CPU-Last nahe null bleibt. Das hilft im Ruhezustand, nicht aber während einer laufenden Beobachtung. Bei vielen GPUs oder einem sehr kleinen UPDATE_INTERVAL trifft die Abfrage den Treiber häufiger; das README nennt als Gegenmaßnahme ausdrücklich das Erhöhen von UPDATE_INTERVAL, etwa mit -e UPDATE_INTERVAL=2.0.
In-Memory statt Historie
Die Diagramme zeigen Verläufe, aber nichts im Material deutet auf eine persistente Speicherung hin: die Daten fließen über Socket.IO an den Browser, es gibt einen JSON-Snapshot unter GET /api/gpu-data und eine Versionsabfrage unter GET /api/version, aber keine Zeitreihendatenbank. Wer nach einem Neustart oder einem Browserwechsel den Verlauf von gestern braucht, bekommt ihn nicht. Ebenso fehlt im README jede Erwähnung von Alarmierung, Schwellwerten oder Benachrichtigungen. Ein weiterer Fall, in dem gpu-hot das falsche Werkzeug ist: die Überwachung von AMD- oder Intel-GPUs, denn NVML und nvidia-smi sind NVIDIA-spezifisch. Und für Umgebungen, in denen die Prozesszuordnung zwingend ist, ohne den Host-PID-Namensraum freigeben zu dürfen, bleibt nur die reduzierte Ansicht ohne Prozessnamen.
Was Prometheus und Grafana anders machen
Der naheliegende Vergleich ist kein anderes Dashboard, sondern die Kombination aus dcGM-Exporter, Prometheus und Grafana. Deren Unterschied liegt nicht in der Oberfläche, sondern im Datenmodell: Prometheus schreibt Messwerte in eine Zeitreihendatenbank und behält sie über Neustarts hinweg, Grafana fragt diese Historie ab und kann daraus Alarme ableiten. gpu-hot hält die Werte im Speicher und liefert sie live an den Browser. Dafür braucht es keine Regelsprache, keine Abfragesprache und keinen zusätzlichen Exporter, und der Hub-Modus ist mit einer Umgebungsvariable erledigt statt mit Föderation und Service-Discovery. Die Wahl ist damit eine Frage des Zeithorizonts: Live-Blick gegen Nachvollziehbarkeit. Wer wissen will, ob eine Karte in diesem Moment drosselt, ist mit gpu-hot schneller; wer rekonstruieren will, warum sie es gestern um drei Uhr nachts tat, braucht die Zeitreihe.
Updates, Lizenz und Betriebsaufwand
Das Projekt steht unter MIT, der Quelltext darf also verwendet, verändert und weitergegeben werden, sofern der Lizenzhinweis erhalten bleibt. Das ist eine Einordnung, keine Rechtsberatung; wer das Image in einem Produkt weiterreicht, sollte die Lizenzbedingungen selbst prüfen. Für den Betrieb relevant ist die Update-Prüfung: app.js enthält laut Projektstruktur einen Versionscheck, und GET /api/version liefert Versions- und Update-Informationen. Die Release-Historie zeigt drei Veröffentlichungen zwischen Mai und Juli 2026 mit den Sprüngen v1.9.0, v1.9.1 und v1.9.2, wobei die letzten beiden am selben Tag erschienen sind. Das Muster deutet auf kurze Korrekturzyklen nach einem größeren Schritt hin. Für den Betrieb heißt das: ein festes Image-Tag statt latest ist bei diesem Tempo die ruhigere Wahl, und ein Upgrade ist ein Container-Neustart, sofern man die Konfiguration über Umgebungsvariablen hält und nicht im Image ändert.
Vor dem ersten Start prüfen
Die Fehlersuche im README ist kurz und lässt sich in drei Befehle übersetzen. Zuerst nvidia-smi auf dem Host, um zu sehen, ob der Treiber überhaupt Werte liefert. Dann docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi, um zu prüfen, ob der Container die GPUs durchgereicht bekommt. Im Hub-Modus zusätzlich curl http://node-ip:1312/api/gpu-data gegen jeden Knoten, denn wenn dieser Aufruf leer bleibt, hilft auch die Hub-Konfiguration nicht weiter; das README verweist in diesem Zusammenhang auf sudo ufw allow 1312/tcp. Bleiben die Metriken trotz funktionierender GPU-Anbindung aus, ist NVIDIA_SMI=true der nächste Versuch, gedacht für ältere Karten. Diese drei Prüfungen decken die wahrscheinlichsten Ausfälle ab und kosten weniger Zeit als die Fehlersuche im Dashboard.
Redaktionelles Fazit
Sinnvoll ist gpu-hot für Teams, die eine überschaubare Zahl eigener NVIDIA-Knoten im eigenen Netz betreiben und keine externen Agenten installieren wollen. Wer Metriken langfristig speichern, Alarme auslösen oder Nicht-NVIDIA-Hardware überwachen muss, ist hier falsch. Vor dem Rollout zuerst prüfen, ob der Container die GPUs sieht, ob die Prozessnamen sichtbar sind und ob der Hub die Knoten über Port 1312 erreicht.
Community-Notizen