LUPINE : pont GPU sur IP pour attacher des GPU distants à des machines sans GPU
LUPIN est un pont GPU sur IP permettant aux GPU de machines distantes d'être connectés à des machines équipées uniquement de CPU.
En bref
- De quoi s’agit-il ?
- Un projet C++ qui permet à des machines sans GPU d'utiliser des GPU sur des serveurs distants via un pont client-serveur, avec des images conteneur et des démos publiées.
- À qui s’adresse-t-il ?
- Le README ne fournit pas de benchmarks de performance, de garanties de sécurité ou d'engagements de support. La licence Apache-2.0 accorde des droits d'auteur et des brevets, mais ne traite pas des obligations de garantie ou de support.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement C++, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
GPU sur IP : l'idée centrale
LUPINE est un projet C++ qui agit comme un pont GPU sur IP. La description du dépôt indique qu'il permet d'attacher des GPU situés sur des machines distantes à des machines sans GPU. Le README explique qu'il s'agit d'un système client-serveur : un serveur s'exécute sur la machine qui possède le GPU, et un client s'exécute sur la machine sans GPU. Le client expose le GPU distant comme un périphérique local. Selon le fichier de licence, le projet est sous licence Apache-2.0. Le README ne fournit pas de diagramme d'architecture de haut niveau ni de liste des versions CUDA prises en charge au-delà des balises d'image.
Démo hébergée et démo Mac
Le README inclut deux démos. La première est une démo hébergée où les utilisateurs peuvent exécuter un client Docker contre demo.lupinemachines.com:14833 et voir un Tesla T4. La deuxième est une démo Mac qui exécute un script Python via `uv run` et montre une connexion à un RTX 4090. Les deux démos reposent sur les images conteneur publiées et la variable d'environnement `LUPINE_SERVER`. La démo hébergée est gratuite, mais le README prévient que le provisionnement d'un GPU peut prendre du temps. Ces démos sont les seuls exemples d'utilisation fournis ; aucun autre scénario de déploiement n'est décrit.
Démarrage rapide avec les images conteneur publiées
Le démarrage rapide utilise deux images GHCR : `lupine-server` et `lupine-client`, avec des balises suivant le modèle `cuda-<cuda-version>-ubuntu<ubuntu-version>`. L'exemple utilise CUDA 13.1.0 sur Ubuntu 24.04. Le serveur est exécuté avec `--gpus all` et publie le port 14833. Le client est exécuté avec `-e LUPINE_SERVER=<server>:14833` puis exécute une commande comme `nvidia-smi`. Dans le conteneur client, `LD_LIBRARY_PATH=/opt/lupine/lib` est défini, donc les shims CUDA driver et NVML sont utilisés automatiquement. Le README montre une sortie `nvidia-smi` d'un RTX 4090 distant, mais cette sortie est illustrative et non un benchmark.
Stabilité de connexion et arrêt gracieux du serveur
Le README décrit les fonctionnalités de stabilité de connexion. Chaque connexion client-serveur est un flux TCP unique de longue durée. Pour éviter que les connexions inactives soient récupérées par les middleboxes, LUPINE active le keepalive TCP avec un intervalle d'inactivité de 60 secondes, un intervalle de sonde de 15 secondes et 3 sondes sans réponse avant d'abandonner. Il implémente également une nouvelle tentative de connexion avec backoff exponentiel et des délais par tentative. Côté serveur, `SIGTERM` déclenche un drain gracieux : le serveur cesse d'accepter les connexions, demande à chaque processus enfant de connexion de terminer les appels CUDA en cours, et attend leur sortie. Un fournisseur de points de contrôle peut être chargé via `LUPINE_CHECKPOINT_LIBRARY` ou le chemin de recherche `liblupinecr.so`, mais un fournisseur manquant est un no-op. Le fournisseur utilise l'ABI versionnée dans `checkpoint_provider.h`.
Support multi-GPU et points de terminaison TLS
Le client peut s'attacher à plusieurs serveurs en définissant `LUPINE_SERVER` comme une liste séparée par des virgules. Les périphériques sont exposés dans l'ordre des serveurs : tous les GPU du premier serveur, puis tous ceux du suivant. Les copies de périphérique à périphérique entre serveurs sont prises en charge en transférant les données via le client : périphérique vers hôte sur un serveur, puis hôte vers périphérique sur l'autre. Les transferts directs de serveur à serveur, l'accès peer entre serveurs et `cuMemcpy3DPeer` ne sont pas implémentés. Pour TLS, un point de terminaison peut être préfixé avec `https://` lorsque le serveur est derrière un proxy de terminaison TLS ; le client vérifie le certificat du proxy par rapport au magasin de confiance du système. Les points de terminaison en clair et `http://` utilisent par défaut le port 14833.
Construction à partir des sources et exécution du client local
Construire LUPINE à partir des sources nécessite d'abord une étape de génération de code. Le script `codegen.py` lit les fichiers d'en-tête CUDA (y compris cuBLAS, cuDNN, NVML et les en-têtes du runtime CUDA) pour générer des appels RPC. Le README demande d'installer les paquets CUDA appropriés puis d'exécuter `cd codegen && python3 ./codegen.py`. Ensuite, CMake est utilisé : `cmake -S . -B build` et `cmake --build build`. La construction produit `libcuda.so.1`, `libnvidia-ml.so.1` et `lupine_driver_server`. Pour les exécutions client locales, le README suggère de précharger le shim construit avec `LD_PRELOAD=./build/libcuda.so.1` et de définir `LUPINE_SERVER`. Un script `local.sh` est également fourni pour démarrer le serveur ou exécuter des commandes.
Journalisation de trace, transfert printf du périphérique et FAQ
La journalisation de trace est contrôlée par `LUPINE_TRACE` sur le client, le serveur ou les deux. Les valeurs 0 ou non définies désactivent le traçage, 1 écrit sur stdout, 2 sur stderr, et toute autre chaîne non vide est traitée comme un chemin de fichier. Le README note que `LUPINE_SERVER_TRACE` n'est plus utilisé. LUPINE transfère également la sortie `printf` du périphérique en inspectant les données PTX et cubin téléchargées pour `vprintf`. La synchronisation est évitée jusqu'à ce qu'une image capable de sortie périphérique soit chargée ; après cela, la synchronisation de contexte, de flux et d'événements capture le fd 1 du serveur et transmet le tampon à stdout du client. La section FAQ aborde la latence (les transferts de périphériques deviennent plus lents car un lien PCIe est limité sur le réseau, mais le transfert de données hôte-périphérique est faible pour l'entraînement et l'inférence), l'authentification (indirectement via un proxy de terminaison TLS) et note que le projet a été en partie généré par IA. Le README liste également les travaux antérieurs de Thunder Compute, Juice Labs et RCUDA.
Conclusion éditoriale
Le README ne fournit pas de benchmarks de performance, de garanties de sécurité ou d'engagements de support. La licence Apache-2.0 accorde des droits d'auteur et des brevets, mais ne traite pas des obligations de garantie ou de support. Les métadonnées du dépôt montrent 2372 étoiles et 131 forks, mais le README lui-même ne spécifie pas de numéro de version ni d'historique de versions.
Notes de la communauté