All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Free P2P GPU sharing — what would stop you using this over Vast/RunPod?
Not an offer, nothing to sell — this is free and there's no platform. I genuinely want the objections.
The idea: one script on a box with Docker and a GPU prints a link. Whoever opens it lands in a terminal on that machine, right in their browser. No account for either side, no listings, no fees, no middleman.
It's not trying to beat Vast or RunPod at renting from strangers — they're great at that. It covers the case they structurally can't: getting a specific person onto a specific machine, right now. A marketplace needs liquidity; this works with two people and one box.
https://runsnack.com — install scripts are on GitHub (Apache 2.0), so you can read the docker run flags before running anything. The agent inside the container is closed source.
What I'm asking: you've all got idle hardware and strong opinions about isolation. What kills this for you? Docker not being a VM? No escrow? Closed agent? Something I haven't thought of?
Genuinely want the harsh version. Thanks!
Comments
Plenty of research showing that direct access to a GPU allows you to takeover anything else running on that GPU. No isolation without vGPU.
nah docker aint even the main issue for me, closed source agent is the actual dealbreaker. i can read the install script all day but the thing actually executing inside the container when some stranger sends commands is a black box, cant verify its not doing anything sketchy beyond the terminal session, no syscall filtering i can check, nothing. @forest already mentioned the problem. raw gpu passthrough with no mig/vgpu partitioning means shared gpu memory space, theres actual research on reading leftover vram from other processes after context switches. cuda isolation aint some hardware enforced thing like sr-iov, its basically just hoping nobody goes digging through stale memory. docker sharing the host kernel is its own thing too, one kernel cve or a misconfigured cap and its not container access anymore its host access. vast/runpod at minimum give you a real vm with its own kernel. would need gvisor or kata instead of raw docker, mig based gpu partitioning instead of
--gpus all, and the agent actually open sourced so ppl can see whats running not just the wrapper script around it.yeah no mig/vgpu means shared gpu memory space and cuda doesnt actually enforce isolation the way ppl assume, its basically relying on processes not going out of their way to read stale vram instead of real hardware separation like sr-iov gives u on nics. op should just say straight up if this is bare
--gpusall passthrough with no mig config, cuz if so thats a data leak risk even with zero escape happening, just from sharing gpu context with some random strangers workloadEDIT
that cuda memory isolation issue is an nvidia thing specifically. if op's stack is nvidia gpus the whole no-mig shared vram context leak risk applies straight up, cuda doesnt hardware enforce isolation without mig/vgpu. if its amd tho, different stack entirely, rocm/hip instead of cuda, and amd's got their own equivalent problem, sr-iov based gpu virtualization exists on some instinct cards (mi series) but consumer/prosumer amd gpus dont really have a mig equivalent at all, so raw passthrough on amd without proper sr-iov partitioning is arguably even less isolated since theres no partitioning option to fall back on in the first place. op should just clarify which gpu vendor this is actually targeting cuz the isolation story is completely different depending on nvidia vs amd, and if its meant to be vendor agnostic that just doubles the isolation gaps since youd need to solve both separately
if apple silicon is in scope thats a different mess, metal doesnt even have a mig/sr-iov equivalent, gpu passthrough to containers on mac is basically not a real thing since docker runs through a linux vm under the hood anyway. igpus (intel/amd) are honestly worse for this ngl, shared memory with the cpu means ur not just sharing vram context ur potentially sharing system memory the igpu touches directly. va-api/quicksync passthrough has zero mig equivalent either.
if somethings wrong here let me know, im not that big of a nerd on this stuff
I think Nvidia and AMD are equally vulnerable when not using SR-IOV-based isolation, so it's not unique to Nvidia (besides CUDA itself being an Nvidia product). No GPU has any kind of native isolation between running kernels.