Convierte la VRAM en swap en Linux

Si tu máquina se queda corta de RAM cuando levantas modelos locales, compilas proyectos grandes o abres demasiados contenedores, seguramente ya viste el síntoma clásico: el sistema empieza a intercambiar memoria al disco y todo se vuelve más lento. En ese contexto aparece una idea rara pero útil para conversar: usar la VRAM de tu GPU Nvidia como espacio de swap en Linux.

No estamos hablando de magia ni de convertir una tarjeta gráfica en RAM real. La propuesta del proyecto nbd-vram, publicado en GitHub, es más bien una forma de exprimir memoria que normalmente queda reservada para cargas gráficas o de cómputo. Eso abre una conversación interesante sobre rendimiento, límites físicos y qué tanto puedes estirar un equipo para desarrollo o IA local antes de comprar más hardware.

Qué problema intenta resolver esta idea

La memoria RAM se llena rápido cuando trabajas con Docker, navegadores pesados, IDEs, bases de datos locales y modelos de IA. Cuando eso pasa, Linux recurre al swap para mover páginas de memoria menos usadas a otro medio más lento. El problema es simple: si tu swap está en un SSD, ya pagas una penalización de latencia y ancho de banda. Si además el sistema entra en presión fuerte de memoria, el equipo se siente torpe incluso para tareas básicas.

La VRAM, por otro lado, suele estar infrautilizada en muchos equipos de desarrollo. Una GPU con 8 GB, 12 GB o 24 GB puede tener memoria libre mientras la RAM principal está al límite. La idea de nbd-vram intenta aprovechar ese espacio como una especie de respaldo temporal para páginas de memoria, de modo que el sistema tenga una alternativa antes de caer al disco o al OOM killer.

Eso no significa que la VRAM sea un reemplazo de la RAM. La VRAM está pensada para alimentar a la GPU con datos de alto rendimiento, no para comportarse como memoria general del sistema. Aun así, para ciertos escenarios puede servir como una capa intermedia útil, especialmente si tu flujo de trabajo tolera latencias algo mayores y si prefieres evitar que el SSD sea el primer destino del swap.

Cuándo sí tiene sentido

Hay casos donde esta idea puede ser interesante:

• Equipos de desarrollo con GPU Nvidia y RAM limitada, por ejemplo 16 GB o 32 GB.
• Laboratorios caseros para IA local donde cargas modelos grandes, embeddings o varias herramientas a la vez.
• Máquinas donde quieres amortiguar picos de memoria sin escribir tanto al SSD.
• Entornos de prueba donde te interesa experimentar con políticas de memoria, no reemplazar infraestructura seria.

Cuándo no vale la pena

También hay escenarios donde no compensa:

• Si no tienes GPU Nvidia compatible, el proyecto no te ayuda.
• Si tu GPU ya está al tope por entrenamiento o inferencia, usar su VRAM como swap puede empeorar el rendimiento.
• Si tu objetivo es estabilidad máxima, el swap en VRAM es más una prueba técnica que una solución de producción.
• Si tu equipo ya tiene suficiente RAM, probablemente te conviene más ajustar swappiness o agregar memoria física.

Cómo funciona nbd-vram por dentro

El repositorio nbd-vram propone usar NBD, Network Block Device, para exponer la VRAM como si fuera un dispositivo de bloque. Desde la perspectiva de Linux, eso permite montar un backend que el sistema puede usar como swap. La idea no es nueva en el mundo de Linux, pero sí es bastante específica en cómo aprovecha la memoria de la GPU.

En términos prácticos, el flujo es este: una parte del sistema reserva VRAM, se presenta como un recurso accesible vía NBD y luego se habilita como swap. Linux puede enviar páginas menos activas a ese espacio antes de recurrir al disco. El resultado esperado es que, en algunos casos, la presión sobre la RAM principal baje sin castigar tanto al SSD.

La documentación del proyecto está en el repositorio oficial de GitHub: https://github.com/c0dejedi/nbd-vram. Si quieres revisar el enfoque técnico, el código y los requisitos exactos, conviene leerlo ahí antes de intentar nada en tu equipo.

La diferencia con el swap tradicional

El swap tradicional vive en una partición o archivo en disco. Su ventaja es que es simple, estable y no depende de una GPU específica. Su desventaja es que, incluso en un SSD NVMe rápido, sigue siendo bastante más lento que la RAM.

Con VRAM como swap cambias el medio de respaldo. No ganas la misma latencia de la RAM, pero sí puedes mover el cuello de botella a un componente que, en tu caso, quizá estaba ocioso. Eso puede ser útil en cargas donde el sistema solo necesita un colchón temporal y no un almacenamiento permanente de páginas frías.

Qué limita esta aproximación

La primera limitación es obvia: la VRAM no es infinita. Una GPU de 8 GB puede perder buena parte de ese espacio en uso gráfico o de cómputo. La segunda limitación es el acceso. Aunque la GPU tenga mucho ancho de banda interno, la forma en que Linux interactúa con ese recurso no es la misma que con la RAM normal.

La tercera limitación es operativa. Si tu sesión gráfica, tu entorno de IA y tu swap comparten la misma GPU, puedes terminar compitiendo por el mismo recurso. En otras palabras: el sistema puede sentirse mejor en un momento y peor en otro, según la carga real.

Qué necesitas antes de probarlo

Antes de tocar nada, conviene validar tres cosas: hardware, drivers y objetivo de uso. Si te faltan esas bases, puedes terminar con una sesión inestable o con un sistema que intercambia memoria a un recurso que luego necesitas para otra tarea.

Primero, verifica que tienes una GPU Nvidia y que el driver está funcionando. Luego revisa cuánta VRAM libre tienes realmente cuando el sistema está en reposo y cuando cargas tus herramientas normales. Por último, define qué problema quieres atacar: picos de RAM, evitar swap en SSD, o simplemente experimentar.

La documentación oficial de Nvidia sobre drivers en Linux te sirve como punto de referencia para compatibilidad general: https://docs.nvidia.com/datacenter/tesla/driver-installation-guide/index.html. No necesitas seguir ese documento al pie de la letra para este caso, pero sí te ayuda a confirmar que tu stack de drivers está sano.

Datos que deberías mirar

Antes de intentar algo así, revisa estos números:

• RAM total instalada.
• VRAM total de la GPU.
• Swap actual en disco.
• Uso real de memoria con tus apps habituales.
• Si tu GPU se usa para display, cómputo o ambas cosas.

Una forma rápida de inspeccionar el estado del sistema es con comandos básicos:

free -h
nvidia-smi
swapon --show

Si quieres una foto más clara del comportamiento del sistema bajo carga, abre tus herramientas habituales, espera a que carguen y vuelve a ejecutar esos comandos. Así no te quedas con una medición en vacío que no representa tu día a día.

Cómo se probaría en un equipo de desarrollo

No hace falta convertir esto en un proyecto de fin de semana con 20 pasos. La lógica de prueba debería ser simple: medir antes, activar la solución, medir después y comparar. Si no ves mejora real, no insistas por deporte.

Un escenario razonable sería una workstation con 32 GB de RAM, una GPU Nvidia con 12 GB de VRAM y un SSD NVMe. Si abres varias pestañas, un IDE, contenedores y una sesión local de IA, puedes llegar a presión de memoria sin darte cuenta. En ese caso, el swap en VRAM podría actuar como amortiguador para evitar que el sistema empiece a escribir tanto al SSD.

Flujo de prueba recomendado

1. Registra el uso de RAM, swap y VRAM en reposo.
2. Abre tus cargas normales: editor, navegador, terminales, contenedores o modelo local.
3. Observa cuándo empieza a crecer el swap.
4. Repite la prueba con la solución activada.
5. Compara latencia percibida, uso de disco y estabilidad.

No te quedes solo con el número de memoria libre. Si el sistema responde mejor pero la GPU se satura, el resultado final puede ser peor para tu tarea real. En desarrollo local, la experiencia de uso importa más que un gráfico bonito.

Ejemplo de comparación práctica

Los números de la tabla son ilustrativos, no una promesa universal. Lo que sí te muestra es el tipo de comparación que deberías hacer: no solo mirar si el swap se usa menos, sino si el equipo responde mejor para tu flujo concreto.

Rendimiento, riesgos y límites reales

Aquí es donde conviene bajar las expectativas. Usar VRAM como swap no convierte a tu GPU en una extensión directa de la RAM. Sigue habiendo sobrecosto, coordinación entre componentes y posibles cuellos de botella. Si tu carga de trabajo necesita acceso constante y rápido a memoria, esto no te va a salvar.

También hay un riesgo de competir por recursos. Si estás entrenando o inferiendo modelos y al mismo tiempo el sistema usa la VRAM como swap, puedes provocar más latencia en la GPU. En ese caso, el beneficio de evitar el swap en disco puede quedar anulado por la pérdida de rendimiento en la carga principal.

Lo más sensato es pensar en esto como una herramienta de nicho. Puede servir para amortiguar picos, para pruebas y para ciertos escritorios de desarrollo. No deberías asumir que reemplaza una buena cantidad de RAM física, ni que es una receta estable para servidores de producción.

Señales de que no te conviene

Presta atención si ves alguno de estos síntomas:

• La GPU sube de uso aunque no estés haciendo cómputo intenso.
• El sistema empieza a cambiar ventanas con retraso.
• Los procesos de IA tardan más en responder al activar el swap en VRAM.
• El consumo de energía sube sin una mejora clara.

Si eso pasa, probablemente el coste de usar VRAM como swap supera el beneficio. En ese punto, te conviene volver a un swap tradicional en SSD y ajustar otras variables, como la cantidad de procesos concurrentes o la configuración de memoria de tus contenedores.

Qué aprender de esta idea aunque no la uses

Aunque nunca actives nbd-vram, la idea te deja una lección útil: la memoria no es un bloque único, sino una jerarquía de recursos con costos distintos. RAM, VRAM, SSD y swap resuelven problemas parecidos, pero con velocidades y propósitos diferentes. Entender esa diferencia te ayuda a diagnosticar mejor por qué tu equipo se siente lento.

Para quien trabaja con IA local en Latinoamérica, esto importa bastante. No siempre tienes acceso a una workstation ideal, y muchas veces toca sacar más provecho del hardware que ya tienes. Ahí es donde estas soluciones experimentales tienen valor: no porque sean definitivas, sino porque te obligan a pensar mejor la relación entre memoria, carga y costo.

También vale para equipos de desarrollo en Ecuador, México, Colombia, Perú o cualquier otro mercado donde comprar RAM extra o una GPU más grande no siempre es inmediato. Si puedes estirar un poco la vida útil de tu estación de trabajo con una prueba controlada, ya ganaste algo. Y si la prueba no da resultado, también aprendiste algo concreto sobre el límite de tu hardware.

Tabla resumen

Si quieres profundizar más, revisa la documentación del proyecto y compara su enfoque con tu uso real. La diferencia entre una idea interesante y una solución útil casi siempre está en la medición.