Partager temporairement une GPU implique souvent de préparer des utilisateurs, des clés SSH, des règles d’accès et des permissions, ce qui peut décourager toute personne voulant exécuter une simple ligne de code. RunSnack propose de simplifier cette démarche en permettant d’exécuter un script et de partager un lien qui ouvre dans le navigateur une terminale dans un conteneur Docker, avec accès direct à la GPU de la machine hôte. Développé par Manuel Herrador Muñoz, ce projet vise à partager du matériel directement avec une personne précise, sans créer un nouveau marché de GPU.

Les points clés de RunSnack en 20 secondes

• L’hôte exécute un script et reçoit un lien pouvant être partagé avec une autre personne.
• L’accès se fait dans une terminale à l’intérieur d’un conteneur Docker, et non directement sur la machine hôte.
• Il ne nécessite pas de comptes ni ne prélève de commission sur les sessions.
• Compatible avec GPU NVIDIA supportées, y compris Jetson et matériels de centres de données.
• Docker limite l’isolation : le projet déconseille son utilisation avec des inconnus.

Le concept est simple car il élimine une grande partie des démarches classiques pour partager une capacité de calcul : pas besoin d’un catalogue GPU, de configurer un compte fournisseur ou un système de facturation. RunSnack connecte simplement celui qui dispose du matériel et celui qui souhaite l’utiliser, en laissant de côté tout accord commercial entre eux.

Sa documentation donne des exemples concrets sortant de l’usage traditionnel de location d’infrastructures : un étudiant qui a besoin de la GPU d’un laboratoire pour quelques heures, un développeur qui doit reproduire un problème sur une Jetson physique ou un collaborateur qui exécute du code sur une machine spécifique.

C’est précisément dans ces cas que la proposition se différencie des services cherchant à fournir de la capacité de calcul disponible sur Internet.

De l’exécution d’un script à une terminale accessible depuis le navigateur

La procédure proposée par RunSnack comprend peu d’étapes.

Sur Linux ou macOS, il suffit d’exécuter l’installateur :

chmod +x snackup.sh
./snackup.sh

Sous Windows, un script équivalent pour PowerShell est disponible.

L’installateur vérifie la disponibilité de Docker, demande combien de cœurs CPU et de mémoire RAM peuvent être utilisés, et propose éventuellement de définir un horaire d’accès. Ensuite, il télécharge l’image nécessaire, lance le conteneur et affiche un lien.

La personne recevant ce lien peut l’ouvrir dans un navigateur pour accéder à une terminale de session. RunSnack indique qu’aucun logiciel supplémentaire n’a besoin d’être installé sur la machine distante, ni de créer un compte à l’avance.

La première utilisation implique de télécharger une image d’environ 1,4 Go. Les sessions suivantes peuvent être lancées sans refaire cette étape.

Ce mode change considérablement l’expérience comparée à une configuration SSH classique.

Pour donner un accès temporaire via SSH, il faut souvent créer des comptes, distribuer des clés, vérifier des permissions, déporter ou rendre accessible le service, puis retirer ces accès. Rien de difficile pour un administrateur, mais excessif lorsqu’on souhaite simplement faire fonctionner une GPU pendant quelques heures.

RunSnack propose une autre interface : un lien temporaire et une terminale web.

Le dépôt public permet aussi de vérifier les scripts snackup.sh et snackup.ps1 avant exécution. Cela permet notamment de voir comment est lancé le conteneur et quelles mesures de sécurité sont adoptées.

Une distinction importante concerne le code source : les scripts d’installation sont publics sous licence Apache 2.0, mais l’agent opérant dans l’image Docker pour gérer la connexion n’est pas open source. La documentation précise que la logique assurant l’établissement et la gestion de la session est intégrée dans une image Docker fermée, distribuée via Docker Hub.

Ce point est essentiel pour des organisations souhaitant auditer complètement le logiciel utilisé sur leurs serveurs.

Un conteneur avec permissions restreintes, mais pas une machine virtuelle

La sécurité constitue probablement le point le plus critique de RunSnack.

Le conteneur démarre avec un système de fichiers en lecture seule, supprime les capabilities Linux, utilise un utilisateur sans privilèges et active no-new-privileges. Selon la documentation, l’utilisateur distant obtient une terminale dans le conteneur, et non un shell direct sur la machine hôte.

Cela limite significativement la surface d’attaque comparée à une connexion root directe sur le serveur.

Mais RunSnack ne prétend pas que cet isolement soit totalement infaillible.

Les documents avertissent explicitement que Docker représente un sandbox, pas un hyperviseur. En effet, un conteneur partage le noyau avec la machine hôte, alors qu’une VM fonctionne souvent avec un noyau indépendant, via une couche de virtualisation.

Il est donc conseillé de réserver l’accès à un cercle de confiance, où l’on serait prêt à fournir une shell complète, même en mode confinement.

Il faut également faire attention à la gestion de la GPU : RunSnack donne au conteneur l’accès à l’intégralité du dispositif graphique. Il n’utilise pas des technologies comme NVIDIA Multi-Instance GPU (MIG), vGPU ou autres moyens de partitionnement.

L’équipe du projet signale que cette approche constitue une frontière d’isolation plus faible, et met en garde que la VRAM n’est pas nécessairement effacée entre sessions. Ainsi, des données pourraient rester accessibles entre différentes utilisations, même sans fuite de conteneur.

Pour limiter ce risque, RunSnack recommande d’éteindre complètement la machine pendant quelques secondes. Sur Linux, il est aussi suggéré d’arrêter le conteneur et d’utiliser la commande nvidia-smi --gpu-reset si le matériel le permet.

Ce genre d’avertissements précise bien pour quels scénarios le projet est adapté, et pour lesquels il ne l’est pas.

De la Jetson à la B200 : avec quelques nuances

RunSnack s’oriente principalement vers le matériel NVIDIA.

Son site indique qu’il fonctionne avec toute GPU NVIDIA compatible avec Docker et NVIDIA Container Toolkit, y compris les petits modèles comme Jetson et les accélérateurs de centres de données comme B200. Il peut aussi fonctionner sans GPU, bien que ce ne soit pas sa vocation principale.

L’installateur distingue en plus différentes architectures matérielles.

Pour x86_64, il utilise l’image standard ; une image spécifique est disponible pour Jetson (notamment liée à JetPack 6.1), ainsi qu’une autre pour DGX Spark basée sur Grace Blackwell.

Sur DGX Spark ou en x86, l’accès à la GPU utilise le paramètre classique --gpus all. La Jetson nécessite un traitement spécifique avec le runtime NVIDIA.

Ce large support matériel lui confère un argument face aux plateformes de capacité distribuée.

En effet, une marketplace doit prévoir une offre, une demande, cataloguer le hardware, fixer des prix, gérer des utilisateurs, et souvent jouer l’intermédiaire entre la capacité offerte et celle demandée.

RunSnack élimine quasiment tout cet écosystème.

Si deux personnes se connaissent déjà, que l’une possède exactement la machine dont l’autre a besoin, le problème ne se pose plus en termes de trouver une GPU, mais en comment fournir un accès temporaire avec un minimum d’effort.

C’est ici qu’émerge le concept de « réseau d’un », où il n’est pas nécessaire de bâtir un marché, car le fournisseur et l’utilisateur savent déjà à qui ils ont affaire.

RunSnack ne vise pas à remplacer un marketplace de GPU

La plateforme officielle compare RunSnack à des services de location ou à des réseaux distribués de GPU, mais ces comparaisons doivent être entreprises avec prudence, car elles sont faites par le propre projet, et l’écosystème évolue rapidement.

L’approche conceptuelle est claire :

Un marketplace cherche à mettre en relation un utilisateur avec un fournisseur de capacité qu’il ne connaît pas.

RunSnack part d’une situation inverse : les deux parties se connaissent déjà, et il suffit d’une façon simple de partager la machine.

Par conséquent, plusieurs fonctionnalités classiques d’une plateforme commerciale ne sont pas intégrées.

Il n’y a pas de service d’escrow pour sécuriser les paiements, ni de système de paiement, ni d’assurance de disponibilité, ni de modération des sessions ou d’accords SLA. Si le propriétaire demande une rémunération, RunSnack ne se charge pas de cette gestion.

Il n’y a pas davantage de collecte de données personnelles ni de suivi de l’activité des sessions. La connexion se fait directement entre les deux parties, et le service ne stocke ni n’observe le contenu des échanges.

Cela simplifie énormément l’utilisation, mais supprime aussi des protections que pourraient offrir une plateforme commerciale ou une infrastructure « prête à l’emploi ».

En cas de location d’une GPU par l’intermédiaire d’un marketplace à un inconnu, il est généralement attendu qu’un système de réputation, de garanties ou de résolution des litiges existe.

RunSnack n’a pas pour ambition d’aborder ces problématiques.

Un usage idéal dans les équipes, universités et laboratoires

Le contexte est plus clair dans des petites configurations.

Une équipe de recherche dispose d’une station de travail avec GPU, qu’un étudiant doit utiliser ponctuellement.

Un développeur maintient un logiciel pour une Jetson dans un laboratoire, et souhaite qu’un autre reproduise une erreur sur le même matériel.

Un groupe d’intelligence artificielle a une GPU de test libre quelques heures, et veut proposer un accès temporaire à un collaborateur externe, sans créer de compte permanent.

Dans ces cas, mettre en place un marketplace serait absurde.

Même une infrastructure formelle d’accès distant peut dépasser le temps nécessaire à la simple tâche à accomplir.

RunSnack vise justement à combler ce vide, entre « configurer l’accès » et « en faire un service cloud ».

De plus, cette approche a un intérêt particulier pour du matériel peu commun. Une plateforme de location peut offrir des centaines de GPU identiques, mais pas forcément une Jetson intégrée à un robot, une station expérimentale ou une machine avec un environnement spécifique.

Dans ces situations, la valeur ne réside pas uniquement en la puissance GPU, mais surtout dans le fait de pouvoir accéder à cette machine précise.

Ce qui en limite la portée peut aussi faire partie de son attrait.

Elle n’est pas conçue pour faire confiance à l’inconnu.

Elle ne propose pas un isolement équivalent à celui d’une VM ; la GPU est entièrement partagée. Aucun SLA, escrow ni gestion d’identité n’est proposée, et une partie du logiciel de gestion des connexions n’est pas en code source ouvert.

Tout cela la rapproche moins d’un service cloud GPU classique.

Mais pour des utilisateurs qui connaissent leur destinataire et veulent fournir un accès temporaire à une machine spécifique, cette absence de plateforme complète permet que le processus se limite à quelque chose ressemblant beaucoup à du partage d’écran : exécuter un script, copier un lien, et commencer à travailler.

Foire aux questions

Qu’est-ce que RunSnack ?

RunSnack est un outil permettant de partager temporairement une terminale avec accès aux ressources d’une machine, y compris sa GPU NVIDIA, via un lien accessible depuis un navigateur. La session fonctionne dans un conteneur Docker.

Faut-il configurer SSH pour utiliser RunSnack ?

En pratique, RunSnack ne requiert pas de fournir des clés SSH au utilisateur distant. L’hôte exécute le script, lance le conteneur, et partage le lien généré.

Est-il sûr de partager une GPU avec RunSnack ?

RunSnack impose plusieurs restrictions au conteneur, comme un système de fichiers en lecture seule, la suppression des capabilities, un utilisateur sans privilèges, et l’activation de no-new-privileges. Cependant, la documentation rappelle que Docker ne garantit pas un isolement total, et recommande d’utiliser cette solution avec des personnes de confiance.

RunSnack est-il entièrement open source ?

Pas complètement. Les scripts d’installation disponibles sur GitHub sont sous licence Apache 2.0, mais l’agent intégré dans l’image Docker, qui gère la connexion, n’est pas open source, selon la documentation du projet.

Sources :

• RunSnack, site officiel et documentation du projet.
• Référentiel officiel RunSnack sur GitHub, comprenant README, architecture, compatibilité et modèle de sécurité.