Het tijdelijk delen van een GPU betekent meestal dat je gebruikers, SSH-sleutels, toegangsregels en machtigingen moet voorbereiden voordat iemand anders één regel code kan uitvoeren. RunSnack biedt een oplossing door dat proces te verkorten tot het uitvoeren van een script en het delen van een link die in de browser een terminal opent binnen een Docker-container met toegang tot de GPU van de host. Het project, ontwikkeld door Manuel Herrador Muñoz, is bedoeld voor het direct delen van hardware met een specifieke persoon, niet voor het creëren van een nieuwe GPU-marktplaats.
Hoe RunSnack in 20 seconden werkt
- De host draait een script en ontvangt een link die gedeeld kan worden met anderen.
- De toegang wordt verleend via een terminal binnen een Docker-container, niet direct op de host.
- Het vereist geen accounts en rekent geen commissie voor sessies.
- Werkt met compatibele NVIDIA GPU’s, inclusief Jetson en datacenterhardware.
- Docker beperkt de isolatie: het project raadt aan om het niet met onbekenden te gebruiken.
Het idee is eenvoudig omdat het een groot deel wegneemt van wat normaal nodig is bij het verhuren van rekencapaciteit. Er is geen gpu-catalogus te publiceren, geen provideraccount in te stellen en geen geïntegreerd facturatiesysteem. RunSnack verbindt de eigenaar van de machine met degene die deze nodig heeft, en laat elke economische afspraak buiten het product om.
De documentatie geeft voorbeelden die een heel andere aanpak hebben dan traditionele infrastructuurverhuur: een student die enkele uren de GPU van een lab gebruikt, een ontwikkelaar die een probleem reproduceert op een fysieke NVIDIA Jetson, of een medewerker die code op een specifiek apparaat moet uitvoeren.
Hiermee onderscheidt het zich duidelijk van services die bedoeld zijn om beschikbare rekencapaciteit op internet te vinden.
Van script uitvoeren tot terminal in de browser
Het proces dat RunSnack beschrijft, bestaat uit slechts een paar stappen.
Op Linux of macOS voert de gebruiker het installatiescript uit:
chmod +x snackup.sh
./snackup.sh
Op Windows bestaat er een equivalent script voor PowerShell.
Het installatiescript controleert of Docker beschikbaar is, vraagt hoeveel CPU-kernen en RAM-geheugen gebruikt mogen worden, en biedt de mogelijkheid om een toegangstijdschema in te stellen. Vervolgens wordt de juiste image gedownload, de container gestart en verschijnt er een link.
Degene die de link ontvangt, kan deze openen in een browser en de terminalsessie gebruiken. RunSnack beweert dat er geen software op de remote machine geïnstalleerd hoeft te worden en dat er geen account vooraf aangemaakt moet worden.
De eerste keer duurt het ongeveer 1,4 GB om de image te downloaden, afhankelijk van het project. Bij daaropvolgende sessies kan dit worden overgeslagen.
Dit levert een veel andere ervaring op dan een traditionele SSH-configuratie.
Voor het tijdelijk bieden van SSH-toegang moet je meestal gebruikers aanmaken, sleutels uitdelen, machtigingen controleren, services blootstellen of toegankelijk maken, en daarna de credentials weer intrekken. Dit alles is niet moeilijk voor systeembeheerders, maar kan disproportioneel zijn als iemand slechts enkele uren een GPU nodig heeft.
RunSnack verlost je hiervan door een andere interface te bieden: een tijdelijke link en een webterminal.
De openbare repository maakt het ook mogelijk de scripts snackup.sh en snackup.ps1 te controleren voordat je ze uitvoert. Zo kun je zien hoe de container wordt gestart en welke beveiligingsopties worden gebruikt.
Er is echter een belangrijke nuance in het open source-model van het project. De installatiescripts zijn openbaar onder de Apache 2.0-licentie, maar de agent die binnen de Docker-image draait en de verbinding beheert, is gesloten bronsoftware. De documentatie vermeldt expliciet dat de logica die de sessie opzet en onderhoudt, verpakt zit in een gesloten image die via Docker Hub wordt verspreid.
Dit is een belangrijk punt voor organisaties die de software die op hun servers draait volledig willen auditen.
Een container met beperkte privileges, maar geen virtuele machine
Het veiligheidsaspect is waarschijnlijk het meest cruciale van RunSnack.
De container wordt opgestart met een readonly root filesystem, zonder Linux-capabilities, met een niet-bevoegde gebruiker en geactiveerd met no-new-privileges. Volgens de documentatie krijgt de remote gebruiker een terminal binnen die container, niet direct een shell op het hostsysteem.
Dit vermindert aanzienlijk het oppervlak dat blootgesteld wordt, vergeleken met directe toegang op de host.
Maar RunSnack presenteert die isolatie niet als volmaakt.
De documentatie waarschuwt dat Docker een sandbox is, geen hypervisor. Het is vooral belangrijk omdat een container het kernel deelt met de host, terwijl een virtuele machine meestal een apart kernel heeft dat op virtualisatieniveau draait.
Daarom raadt het project aan om sessies alleen te delen met gebruikers aan wie je een echte shell zou geven, zelfs als die binnen de container blijft.
Het wordt ook niet aanbevolen om deze diensten op machines met gevoelige informatie te gebruiken zonder eerst te onderzoeken wat er achter die grens wordt blootgesteld.
Daarnaast is er nog een andere specifieke beperking: de GPU.
RunSnack geeft het volledige GPU-apparaat aan de container door. Het gebruikt geen NVIDIA Multi-Instance GPU (MIG), vGPU of ander partitieermechanisme voor de GPU.
Volgens de projectdocumentatie wordt deze grens van isolatie als zwakker beschouwd, en wordt gewaarschuwd dat VRAM niet per se gewist wordt tussen sessies. Er kan dus informatie blijven hangen waar anderen toegang toe hebben, zelfs zonder dat de container uit de hand loopt.
Om dat risico te verkleinen bij gebruikerswissels, raadt RunSnack aan om de machine volledig uit en weer aan te zetten gedurende enkele seconden. Op Linux-systemen kan ook het stoppen van de container en het uitvoeren van nvidia-smi --gpu-reset nadat het hardware toestaat, helpen.
Deze waarschuwingen maken duidelijk voor welke scenario’s het project geschikt is en voor welke niet.
Van Jetson tot B200, met enkele nuances
RunSnack richt zich vooral op NVIDIA-hardware.
De website beweert dat het met elke NVIDIA GPU kan werken die Docker en NVIDIA Container Toolkit ondersteunt, waaronder kleine systemen zoals Jetson en datacenter-versnellers zoals de B200. Het kan ook zonder GPU draaien, hoewel dat niet de hoofdfocus is.
Het installatiescript onderscheidt verder verschillende architecturen.
Voor x86_64 gebruikt het de standaard image. Er is een speciale image voor NVIDIA Jetson, die momenteel volgens de documentatie gekoppeld is aan JetPack 6.1, en een variant voor DGX Spark gebaseerd op Grace Blackwell.
Voor DGX Spark en x86-systemen gebruikt de GPU-toegang de standaard --gpus all-optie. Jetson vereist een specifieke treatment via de NVIDIA-runtime.
Deze compatibiliteit met verschillende hardware is één van de argumenten van het project tegen marktsegmenten voor gedeelde capaciteit.
Een marktplek vereist aanbod en vraag, hardwarecatalogus, prijsstelling, gebruikersbeheer en meestal tussenkomst tussen aanbieder en consument.
RunSnack maakt dat bijna overbodig.
Als twee mensen elkaar al kennen en één heeft precies de machine die de ander nodig heeft, wordt het probleem kleiner: hoe tijdelijk toegang geven tot die GPU met zo min mogelijk werk.
Hier komt het concept van een “network of one” naar voren: je hoeft geen markt te bouwen als producer en consument al weten wie de ander is.
RunSnack wil geen vervanging zijn voor een GPU-marktplaats
De website vergelijkt RunSnack met verhuurdiensten en gedeelde GPU-netwerken, maar deze vergelijkingen moeten met voorzichtigheid geïnterpreteerd worden omdat ze door het project zelf gemaakt zijn en de platforms regelmatig veranderen.
Het conceptueel verschil is wel duidelijk.
Een marketplace stelt dat een gebruiker capaciteit kan vinden van een provider die hij niet kent.
RunSnack begint juist vanuit het tegenovergestelde: beide partijen kennen elkaar al en willen enkel een eenvoudige manier om de hardware te delen.
Daarom ontbreken veel functies die je op een commerciële platform zou verwachten, zoals escrow voor betalingen, betaalmodules, beschikbaarheidsgaranties, sessiebeheer en SLA’s. Als de eigenaar betaalt voor de GPU, valt dat buiten de service.
Ook wordt geen persoonlijke informatie opgeslagen of activiteit gelogd. Volgens het beleid worden de verbindingen direct tussen de deelnemers gemaakt, zonder dat de dienst de sessie inhoud monitoren of bewaren.
Dit vereenvoudigt het gebruik en verlaagt de drempel, maar verwijdert ook bescherming die een commerciële platform wel kan bieden.
Bij het huren van een GPU via een marketplace wil je vaak reputatiesystemen, betalingsafhandeling, geschillenregeling en garanties op de beschikbaarheid. RunSnack biedt dat niet en lost deze problemen niet op.
Het interessante geval: binnen teams, universiteiten en labs
Dit concept is vooral logisch bij kleine schaal.
Een onderzoeksafdeling met een workstation met een GPU die tijdelijk door een student gebruikt wordt.
Een ontwikkelaar die software voor een Jetson in een lab onderhoudt en een andere ontwikkelaar een fout wil laten reproduceren op datzelfde hardware.
Een AI-team dat een GPU enkele uren ter test beschikbaar wil stellen aan een externe collega, zonder dat die een permanent account krijgt.
In zulke gevallen zou een marktplek onnodig zijn.
Het opzetten van een formele remote-toegangsinfrastructuur kost vaak meer tijd dan het werk dat gedaan moet worden.
RunSnack vult de tussenruimte tussen “voor de machine zitten” en “de machine in de cloud zetten”.
Het heeft ook een voordeel bij hardware die niet standaard is: een verhuurplatform kan honderden GPU’s van hetzelfde model bieden, maar niet per se de Jetson verbonden aan een robot, een experimentele workstation, of een machine met precies het juiste software-beeld.
In dergelijke scenario’s is de waarde niet alleen de kracht van de GPU, maar ook toegang tot de specifieke machine.
Daarom kan een groot limiet van RunSnack ook een voordeel zijn, omdat het juist dat niet-vertrouwen weerspiegelt.
Het is niet ontworpen om met onbekenden te werken.
Het biedt geen soort VM-isolatie, de GPU wordt volledig gedeeld en er is geen SLA, escrow of identiteitssysteem. Ook de software die de verbindingen regelt, is niet volledig open source.
Dit betekent dat het verder wegstaat van een standaard GPU-clouddienst.
Maar voor haar gebruikers die de andere partij kennen en snel toegang tot een specifieke machine nodig hebben, maakt die ontlening juist dat mogelijk: het proces wordt simpelweg een kwestie van een script uitvoeren, een link kopiëren en aan de slag gaan.
Veelgestelde vragen
Wat is RunSnack?
RunSnack is een tool om tijdelijk een terminal te delen met toegang tot de resources van een machine, inclusief een NVIDIA GPU, via een link die je in een browser opent. De sessie draait binnen een Docker-container.
Moet ik SSH configureren om RunSnack te gebruiken?
De standaard workflow van RunSnack vereist geen SSH-sleutels of account aan de remote zijde. De host draait het installatiescript, start de container en deelt de gegenereerde link.
Is het veilig om een GPU te delen met RunSnack?
RunSnack past restricties toe zoals een readonly root filesystem, het verwijderen van capabilities, een niet-bevoegde gebruiker en no-new-privileges. Toch benadrukt het project dat Docker geen hypervisor is en beveelt het gebruik aan met vertrouwende personen.
Is RunSnack volledig open source?
Nee. De installatie-scripts op GitHub zijn onder Apache 2.0 gepubliceerd, maar de agent die in de Docker-image draait en de verbinding beheert, is gesloten bron volgens de documentatie.
Bronnen:
- Officiële website en documentatie van RunSnack.
- Officiële GitHub-repository van RunSnack, inclusief README, architectuur, compatibiliteit en beveiligingsmodel.