LUPINE: GPUs aus dem Netzwerk an CPU-only-Maschinen anbinden
LUPINE ist eine GPU-over-IP-Brücke, die es ermöglicht, GPUs auf Remote-Maschinen mit reinen CPU-Maschinen zu verbinden.
Auf einen Blick
- Was ist das?
- LUPINE ist eine in C++ geschriebene GPU-over-IP-Brücke: Ein Server auf der GPU-Maschine stellt die Hardware über eine lange TCP-Verbindung als lokales CUDA-Gerät dar. Das Apache-2.0-Projekt liefert GHCR-Images, eine gehostete Demo und ein Multi-GPU-Setup.
- Für wen ist es gedacht?
- LUPINE passt für Entwickler und Labore, die eine vorhandene GPU-Maschine per Netzwerk an mehrere CPU-Rechner anbinden wollen, ohne Kupferkabel oder VM-Passthrough. Wer schnelle GPU-zu-GPU-Übertragungen über mehrere Server hinweg braucht, wird enttäuscht, denn direkte Server-zu-Server-Kopien sind laut README nicht implementiert.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 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 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
LUPINE: GPU-over-IP-Brücke zwischen Rechnern
Die Repository-Beschreibung nennt LUPINE eine GPU-over-IP-Brücke, die GPUs auf entfernten Maschinen an reine CPU-only-Maschinen anbindet. Architektonisch ist es ein Client-Server-System: Der Server läuft auf der Maschine, die die GPU besitzt, der Client auf der Maschine ohne GPU. Der Client stellt die entfernte Hardware als lokales CUDA-Gerät dar, sodass Programme unverändert bleiben.
Das Projekt ist in C++ verfasst und unter Apache-2.0 lizenziert; die Entwicklung läuft auf dem Hauptzweig main, zuletzt erschienen die Releases v1.0.0, v0.5.0 und v0.4.0 im Juli und August 2026. Die README liefert weder ein Architekturdiagramm auf hoher Ebene noch eine vollständige Liste unterstützter CUDA-Versionen über die Image-Tags hinaus. Wer Genaueres über die interne Kopplung wissen will, muss den Quellcode oder die Protokolldokumentation der Bibliothek selbst lesen.
Zwei Demos: gehostete T4 und Mac mit RTX 4090
Die README bietet zwei Einstiegswege. Die gehostete Demo verbindet sich mit demo.lupinemachines.com:14833 über ein gepinntes Client-Image und lässt nvidia-smi eine ferne Tesla T4 melden. Der README-Hinweis ist ehrlich: Wenn gerade keine GPU provisioniert ist, dauert der erste Anruf, spätere Antworten sollen schneller sein.
Die zweite Demo zeigt den Mac-Einsatz. Ein Python-Skript aus python/examples/tensor.py läuft per uv run und spricht mit einem Server auf einer Linux-Maschine mit RTX 4090; die Ausgabe meldet cuda available mit device lupine:0. Beide Demos nutzen dieselbe Umgebungsvariable LUPINE_SERVER, und beide basieren auf den veröffentlichten Container-Images. Andere Bereitstellungswege, etwa nativ ohne Docker, beschreibt die README nicht.
Schnellstart: gepinnte GHCR-Images für Server und Client
Die Quickstart-Sequenz verwendet zwei Images aus GHCR, deren Tags dem Muster cuda-<cuda-version>-ubuntu<ubuntu-version> folgen, im Beispiel cuda-13.3.1-ubuntu24.04. Der Server startet mit docker run --rm --gpus all -p 14833:14833 und öffnet Port 14833. Der Client setzt per -e LUPINE_SERVER=<server>:14833 die Zieladresse und ruft anschließend nvidia-smi oder ein eigenes CUDA-Programm auf.
Im Client-Container ist LD_LIBRARY_PATH=/opt/lupine/lib bereits gesetzt, sodass CUDA-Treiber die LUPINE-Simulierung libcuda.so.1 und NVML-Werkzeuge wie nvidia-smi die Simulierung libnvidia-ml.so.1 automatisch verwenden. Die Beispielausgabe im README zeigt eine reale Sitzung gegen eine entfernte RTX 4090; sie dokumentiert eine funktionierende Verbindung, ist aber kein Benchmark.
Verbindungsstabilität über LZ4 und Keepalive
Jede Client-Server-Verbindung ist ein einzelner langlebiger TCP-Stream. RPC-Request- und Response-Bodies verlangen das Kodierungsformat content-encoding: lz4, wobei pro HTTP/2-Body genau ein LZ4-Frame transparent komprimiert wird; ein Aushandeln von Alternativen findet nicht statt.
Weil Zwischengeräte wie Load Balancer oder Firewalls länger untätige Flüsse früher beenden als der Kernel-Timeout, aktiviert LUPINE auf jeder Verbindung TCP-Keepalive mit einem Leerlaufintervall von 60 Sekunden, 15 Sekunden zwischen den Proben und drei unbeantworteten Proben. Ein toter Partner wird damit nach ungefähr 105 Sekunden erkannt. Hinzu kommt ein Verbindungsversuch mit exponentiellem Backoff und einer Deadline pro Versuch, sodass ausgefilterte Ports schnell auffallen, statt im SYN-Retransmit-Fenster zu hängen.
Graceful Shutdown und optionale Checkpoint-Anbieter
Auf Linux stoppt SIGTERM die Annahme neuer Verbindungen, bittet die Verbindungs-Kindprozesse, laufende CUDA-Aufrufe zu beenden, und wartet auf deren Ende. Dieses Graceful Drain läuft im Open-Source-Server ohne zusätzliche Laufzeitabhängigkeit.
Ein Checkpoint-Anbieter wird unter liblupinecr.so.0 oder liblupinecr.so gesucht und verwendet die versionierte ABI aus checkpoint_provider.h. Fehlt der Anbieter oder ist er inkompatibel, bleibt das ein No-op, der Server beendet sich trotzdem ordentlich. Über LUPINE_SESSION lässt sich eine stabile Verbindungskennung setzen, die der Anbieter zur Wiederherstellung vor dem ersten CUDA-RPC und zum Checkpoint nach dem Drain erhält. Bei unverschlüsselten Verbindungen wird die Wiederherstellung übersprungen. Den Speicherort für Checkpoints wählt LUPINE nicht selbst; die Speicherkonfiguration liegt beim Anbieter, und LUPINE_CHECKPOINT_LIBRARY kann den Bibliothekspfad für private Installationen überschreiben.
Multi-GPU über mehrere Server und TLS hinter Proxy
Der Client akzeptiert in LUPINE_SERVER eine kommagetrennte Liste. Die Geräte erscheinen als eine lokale Ordinal-Liste in Serverreihenfolge: erst alle GPUs des ersten Servers, dann die des nächsten. Diese Anordnung ist vorhersagbar, man sollte sich aber vor Augen führen, dass die Nummerierung von der Konfigurationsreihenfolge abhängt.
Für Geräte-zu-Geräte-Kopien über Server hinweg stufen die Daten über den Client durch: Gerät-zu-Host auf dem einen Server, dann Host-zu-Gerät auf dem anderen. Direkte Server-zu-Server-Übertragungen, serverübergreifender Peer-Zugriff und cuMemcpy3DPeer sind laut README nicht implementiert. Für TLS wird ein Endpunkt mit https:// versehen, wenn der Server hinter einem TLS-terminierenden Proxy liegt; der Client prüft dessen Zertifikat gegen den System-Trust-Store. Klartext- und http://-Endpunkte nutzen als Vorgabe Port 14833. Eine eingebaute Authentifizierung auf Anwendungsebene gibt es nicht, nur den indirekten Weg über den Proxy.
Eigener Build: codegen.py und CMake
Wer aus dem Quellcode baut, muss zuerst einen Codegen-Schritt ausführen. Das Skript script/codegen.py liest CUDA-Headerdateien, darunter cuBLAS, cuDNN, NVML und die CUDA-Runtime-Header, und erzeugt daraus die RPC-Aufrufe. Die README weist an, die entsprechenden CUDA-Pakete zu installieren und danach cd codegen && python3 ./codegen.py zu starten.
Anschließend folgt der übliche CMake-Ablauf mit cmake -S . -B build und cmake --build build. Der Build erzeugt libcuda.so.1, libnvidia-ml.so.1 und lupine_driver_server. Für lokale Client-Ausführungen empfiehlt die README, den gebauten Shim per LD_PRELOAD=./build/libcuda.so.1 vorzuladen und LUPINE_SERVER zu setzen. Wer den Server lokal probieren will, findet zusätzlich ein Skript local.sh, das den Server startet oder Befehle ausführt.
Trace-Logging, Geräte-printf und Grenzen laut FAQ
LUPINE_TRACE steuert die Protokollierung auf Client, Server oder beiden. Der Wert 0 oder ein nicht gesetzter Wert deaktiviert das Tracing, 1 schreibt nach stdout, 2 nach stderr, jede andere nicht leere Zeichenkette wird als Dateipfad im Anfügemodus behandelt. Die alte Variable LUPINE_SERVER_TRACE ist laut README nicht mehr in Gebrauch.
Für Konsole-Ausgaben von CUDA-Geräten inspiziert LUPINE hochgeladene PTX- und Cubin-Daten auf vprintf. Bis ein Bild geladen ist, das Geräte-Standardausgabe nutzen könnte, vermeidet die Synchronisation die Umleitung des Prozess-Standardausgabe; danach erfasst die Synchronisation von Kontext, Stream und Events Server-fd 1 und reicht den begrenzten Puffer an die Standardausgabe des Clients weiter.
Der FAQ-Abschnitt benennt die Latenz als Hauptabwägung: Geräteübertragungen werden langsamer, weil eine PCIe-Verbindung über das Netzwerk zum Nadelöhr wird; für Training und Inferenz bleibt der Host-Gerät-Datenaustausch laut README klein. Das Projekt gibt an, teilweise KI-generiert zu sein, und ordnet sich selbst in eine Reihe früherer Arbeiten von Thunder Compute, Juice Labs und RCUDA ein.
Redaktionelles Fazit
LUPINE passt für Entwickler und Labore, die eine vorhandene GPU-Maschine per Netzwerk an mehrere CPU-Rechner anbinden wollen, ohne Kupferkabel oder VM-Passthrough. Wer schnelle GPU-zu-GPU-Übertragungen über mehrere Server hinweg braucht, wird enttäuscht, denn direkte Server-zu-Server-Kopien sind laut README nicht implementiert. Vor dem Einsatz lohnt der Test gegen demo.lupinemachines.com:14833 mit nvidia-smi -L, danach ein kleines Tensor-Skript über das gepinnte Client-Image, um Latenz und Treiber-Shim im eigenen Netz zu prüfen.
Community-Notizen