--- title: "RunSnack convierte una GPU propia en un terminal compartido con un solo enlace" description: "Compartir temporalmente una GPU suele implicar preparar usuarios, claves SSH, reglas de acceso y permisos antes de que otra persona pueda ejecutar una sola línea de código. RunSnack propone reducir es..." url: https://revistacloud.com/runsnack-convierte-una-gpu-propia-en-un-terminal-compartido-con-un-solo-enlace/ date: 2026-09-04 modified: 2026-08-30 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/08/RunSnack-gpu-scaled.jpg categories: ["Guías y recursos"] tags: ["GPU", "RunSnack"] type: post lang: es --- # RunSnack convierte una GPU propia en un terminal compartido con un solo enlace [Compartir temporalmente](https://revistacloud.com/proxmate-convierte-un-cluster-proxmox-en-una-nube-privada-multiusuario/) una GPU suele implicar preparar usuarios, claves SSH, reglas de acceso y permisos antes de que otra persona pueda ejecutar una sola línea de código. **RunSnack propone reducir ese proceso a ejecutar un script y compartir un enlace que abre en el navegador una terminal dentro de un contenedor Docker con acceso a la GPU del equipo anfitrión**. El proyecto, desarrollado por Manuel Herrador Muñoz, está pensado para compartir hardware directamente con una persona concreta, no para crear otro marketplace de GPU. **Las claves de RunSnack en 20 segundos** - El anfitrión ejecuta un script y recibe un enlace que puede compartir con otra persona. - El acceso termina en una terminal dentro de un contenedor Docker, no directamente en el host. - No exige cuentas ni cobra comisión por las sesiones. - Funciona con [GPU NVIDIA compatibles](https://revistacloud.com/nebul-apuesta-por-una-nube-soberana-de-ia-con-infraestructura-gpu-en-europa/), incluida Jetson y hardware de centro de datos. - Docker limita el aislamiento: el propio proyecto desaconseja usarlo con desconocidos. La idea resulta sencilla precisamente porque elimina buena parte de lo que normalmente rodea al alquiler de capacidad de cálculo. No existe un catálogo de GPU que publicar, una cuenta de proveedor que configurar ni un sistema de facturación integrado. RunSnack conecta a quien tiene la máquina con quien necesita utilizarla y deja fuera del producto cualquier acuerdo económico entre ambos. Su propia documentación plantea ejemplos bastante alejados del alquiler tradicional de infraestructura: un estudiante que necesita utilizar durante unas horas la GPU de un laboratorio, un desarrollador que debe reproducir un problema en una NVIDIA Jetson física o un colaborador que necesita ejecutar código en una máquina concreta. Es precisamente ahí donde la propuesta se diferencia de servicios diseñados para encontrar capacidad de cálculo disponible en Internet. ## De ejecutar un script a tener una terminal en el navegador El procedimiento que describe RunSnack tiene pocos pasos. En Linux o macOS se ejecuta el instalador: ``` chmod +x snackup.sh ./snackup.sh ``` En Windows existe un script equivalente para PowerShell. El instalador comprueba que Docker esté disponible, pregunta cuántos núcleos de CPU y memoria RAM pueden utilizarse y permite establecer opcionalmente un horario de acceso. A continuación descarga la imagen correspondiente, inicia el contenedor y muestra un enlace. Quien recibe ese enlace puede abrirlo desde un navegador y acceder a la terminal de la sesión. RunSnack afirma que no es necesario instalar software en el equipo remoto ni crear una cuenta previamente. La primera ejecución requiere descargar una imagen de aproximadamente 1,4 GB, según el proyecto. Las siguientes sesiones pueden iniciarse sin tener que repetir esa descarga. Esto cambia bastante la experiencia frente a una configuración SSH convencional. Para prestar temporalmente acceso a una máquina mediante SSH puede ser necesario crear usuarios, distribuir claves, revisar permisos, exponer o hacer accesible el servicio y después retirar esas credenciales. Nada de eso es especialmente complicado para un administrador de sistemas, pero resulta desproporcionado cuando alguien necesita utilizar una GPU durante unas horas. RunSnack coloca otra interfaz delante: un enlace temporal y una terminal web. El repositorio público también permite revisar los scripts `snackup.sh` y `snackup.ps1` antes de ejecutarlos. Ahí puede comprobarse la forma en la que se inicia el contenedor y las opciones de seguridad utilizadas. Hay, no obstante, una distinción importante en el modelo de código abierto del proyecto. **Los scripts del instalador son públicos bajo licencia Apache 2.0, pero el agente que funciona dentro de la imagen Docker y gestiona la conexión no es open source**. La propia documentación indica expresamente que la lógica encargada de establecer y mantener la sesión está incluida en una imagen cerrada distribuida mediante Docker Hub. Es un detalle relevante para organizaciones que necesiten auditar íntegramente el software que ejecutan sobre sus servidores. ## Un contenedor con permisos reducidos, pero no una máquina virtual El apartado de seguridad probablemente sea la parte más importante de RunSnack. El contenedor se inicia con el sistema de archivos raíz en modo de solo lectura, elimina las Linux capabilities, utiliza un usuario sin privilegios y activa `no-new-privileges`. Según el proyecto, al usuario remoto se le entrega una terminal dentro de ese contenedor y no una shell directa sobre el sistema anfitrión. Esto reduce considerablemente la superficie expuesta frente a entregar directamente una cuenta del host. Pero RunSnack evita presentar ese aislamiento como absoluto. Su documentación advierte explícitamente de que **Docker es un sandbox, no un hipervisor**. El mensaje es especialmente importante porque un contenedor comparte kernel con el sistema anfitrión, mientras que una máquina virtual ejecuta normalmente un kernel separado sobre una capa de virtualización. Por eso el proyecto recomienda compartir sesiones únicamente con usuarios a los que el propietario estaría dispuesto a proporcionar una shell real, aunque estuviera contenida. Tampoco aconseja ejecutar el servicio en máquinas con información sensible sin estudiar previamente qué queda expuesto detrás de esa frontera. Hay además otra limitación más específica: la GPU. RunSnack entrega el dispositivo gráfico completo al contenedor. No utiliza NVIDIA Multi-Instance GPU (MIG), vGPU ni otra forma de particionamiento del acelerador. El propio proyecto considera esta parte una frontera de aislamiento más débil y advierte de que **la memoria VRAM no está necesariamente borrada entre contextos**, por lo que podría quedar información accesible entre sesiones incluso sin producirse un escape del contenedor. Para reducir ese riesgo al cambiar de usuario, RunSnack recomienda apagar completamente la máquina durante unos segundos. En sistemas Linux también propone detener el contenedor y utilizar `nvidia-smi --gpu-reset` cuando el hardware lo permita. Este tipo de advertencias define bastante bien para qué escenarios encaja el proyecto y para cuáles no. ## De una Jetson a una B200, con algunos matices RunSnack está orientado principalmente a hardware NVIDIA. La web afirma que puede trabajar con cualquier GPU NVIDIA que pueda utilizar Docker y NVIDIA Container Toolkit, incluyendo equipos pequeños como NVIDIA Jetson y aceleradores de centro de datos como B200. También puede ejecutarse sin GPU, aunque ese no sea su objetivo principal. El instalador distingue además diferentes arquitecturas. Para x86_64 utiliza la imagen convencional. Existe una imagen específica para NVIDIA Jetson, actualmente vinculada en la documentación a JetPack 6.1, y otra variante para DGX Spark basada en Grace Blackwell. En DGX Spark y sistemas x86 el acceso a la GPU utiliza el mecanismo estándar `--gpus all`. Jetson requiere un tratamiento específico mediante el runtime de NVIDIA. Esta amplitud de hardware es uno de sus argumentos frente a los mercados de capacidad distribuida. Un marketplace necesita disponer de oferta y demanda, catalogar hardware, establecer precios, gestionar usuarios y normalmente intermediar entre quien ofrece capacidad y quien la consume. RunSnack elimina prácticamente todo ese modelo. Si dos personas ya se conocen y una dispone exactamente de la máquina que necesita la otra, el problema deja de ser encontrar una GPU y pasa a ser **cómo proporcionar acceso temporal a esa GPU con el menor trabajo posible**. Ahí aparece el concepto que el proyecto denomina una «network of one»: no hace falta construir un mercado cuando el proveedor y el usuario ya saben quién está al otro lado. ## RunSnack no pretende sustituir a un marketplace de GPU La propia web compara RunSnack con servicios de alquiler y redes distribuidas de GPU, pero esas comparaciones deben interpretarse con prudencia porque han sido elaboradas por el propio proyecto y las características de las plataformas cambian con frecuencia. La diferencia conceptual sí resulta clara. Un marketplace busca que un usuario pueda encontrar capacidad perteneciente a un proveedor que probablemente no conoce. RunSnack parte de la situación contraria: **las dos partes ya se conocen y únicamente necesitan una forma sencilla de compartir el equipo**. Por eso deliberadamente no incluye varias funciones habituales en una plataforma comercial. No existe escrow para retener pagos. Tampoco hay sistema de pagos, garantías de disponibilidad, moderación de las sesiones o acuerdos de nivel de servicio (SLA). Si el propietario cobra por prestar la GPU, RunSnack deja esa relación completamente fuera del servicio. También afirma no almacenar información personal ni registrar la actividad de las sesiones. Según su política publicada, la conexión se produce directamente entre las partes y el servicio no monitoriza ni almacena el contenido de la sesión. Eso reduce componentes y simplifica el uso, pero también elimina las protecciones que una plataforma comercial puede proporcionar. Si alguien alquila una GPU a un desconocido mediante un marketplace, probablemente quiera mecanismos de reputación, cobro, resolución de disputas y garantías sobre la disponibilidad del recurso. RunSnack no intenta resolver ninguno de esos problemas. ## El caso interesante está dentro de equipos, universidades y laboratorios El planteamiento resulta más fácil de entender con situaciones pequeñas. Un equipo de investigación tiene una workstation con una GPU que necesita utilizar temporalmente un estudiante. Un desarrollador mantiene software para una Jetson situada en un laboratorio y necesita que otro desarrollador reproduzca un fallo sobre ese mismo hardware. Un equipo de inteligencia artificial dispone de una GPU de pruebas libre durante unas horas y quiere prestársela a un [colaborador remoto](https://revistacloud.com/teamviewer-logmein-anydesk-o-rustdesk-que-herramienta-de-acceso-remoto-elegir/) sin crearle una cuenta permanente en la infraestructura. En estos casos montar un marketplace sería absurdo. Incluso crear una infraestructura formal de acceso remoto puede terminar necesitando más tiempo que el propio trabajo que se pretende realizar. RunSnack intenta ocupar ese espacio intermedio entre **«sentarse delante de la máquina» y «convertirla en un servicio cloud»**. El enfoque tiene además una propiedad interesante para hardware poco habitual. Una plataforma de alquiler puede ofrecer cientos de GPU del mismo modelo, pero no necesariamente la Jetson conectada a un robot, una workstation experimental o una máquina que contiene exactamente el entorno que necesita reproducirse. En estos escenarios el valor no está exclusivamente en la potencia de la GPU. Está en acceder a **esa máquina concreta**. Por eso el mayor límite de RunSnack puede ser también parte de su propuesta. No está diseñado para confiar en desconocidos. No ofrece una frontera de aislamiento equivalente a una VM. La GPU se comparte completa. No existe SLA, escrow ni sistema de identidad. Parte del software que gestiona las conexiones tampoco está publicado como código abierto. Todo ello lo aleja de un servicio de GPU cloud convencional. Pero para usuarios que conocen al destinatario y necesitan proporcionar acceso temporal a una máquina concreta, precisamente esa ausencia de plataforma es lo que permite que el proceso termine reduciéndose a algo mucho más cercano a compartir pantalla: **ejecutar un script, copiar un enlace y empezar a trabajar**. ## Preguntas frecuentes ### ¿Qué es RunSnack? RunSnack es una herramienta para compartir temporalmente una terminal con acceso a los recursos de una máquina, incluida su GPU NVIDIA, mediante un enlace que se abre desde un navegador. La sesión se ejecuta dentro de un contenedor Docker. ### ¿Hace falta configurar SSH para utilizar RunSnack? El flujo normal de RunSnack no requiere entregar claves SSH al usuario remoto. El anfitrión ejecuta el instalador, inicia el contenedor y comparte el enlace generado. ### ¿Es seguro compartir una GPU con RunSnack? RunSnack aplica varias restricciones al contenedor, como root filesystem de solo lectura, eliminación de capabilities, usuario sin privilegios y `no-new-privileges`. Aun así, el propio proyecto advierte de que Docker no ofrece el mismo aislamiento que un hipervisor y recomienda utilizarlo con personas de confianza. ### ¿RunSnack es completamente open source? No. Los scripts de instalación disponibles en GitHub están publicados bajo Apache 2.0, pero el agente incluido en la imagen Docker que gestiona las conexiones es software cerrado según la documentación del proyecto. **Fuentes:** - RunSnack, web y documentación oficial del proyecto. - Repositorio oficial de [RunSnack en GitHub](https://github.com/PacifAIst/runsnack), README, arquitectura, compatibilidad y modelo de seguridad.