Se publicó un proyecto abierto NBD-VRAM, que permite utilizar parte de la memoria de video de la GPU NVIDIA como espacio de intercambio en Linux. El proyecto está dirigido principalmente a laptops con memoria RAM soldada, donde no se puede ampliar la RAM, pero hay una tarjeta gráfica NVIDIA RTX/GTX en el sistema con VRAM no utilizada. El código está escrito en C y shell, y se distribuye bajo la licencia MIT.
La idea de NBD-VRAM es simple: si el sistema ya comienza a utilizar el intercambio en un SSD, se puede colocar una capa intermedia delante del SSD: la memoria de video. El autor da un ejemplo con un portátil con RTX 3070 Laptop: de 8 GB de VRAM, se asignaron 7 GB como intercambio, y en total, sumando RAM, zram y el intercambio en SSD, el sistema obtuvo aproximadamente 46 GB de memoria direccionable. Se supone que el orden de llenado es el siguiente: primero se utiliza la RAM, luego la VRAM como una memoria de intercambio rápida, luego zram, y solo después de eso el SSD.
Técnicamente, NBD-VRAM no añade un nuevo controlador al núcleo. Un pequeño demonio asigna la memoria de la tarjeta gráfica a través de CUDA Driver API, y luego la entrega al núcleo de Linux como un dispositivo de bloque a través de NBD — Network Block Device — sobre un socket Unix. Después de conectarse, el cliente estándar nbd-client aparece en el sistema como /dev/nbdX, que se puede asignar como un intercambio normal mediante mkswap y habilitar mediante swapon.
El autor enfatiza que este enfoque se eligió debido a las limitaciones de las tarjetas gráficas NVIDIA de consumo. Un camino más directo a través de NVIDIA P2P API en GeForce, según él, se encuentra con EINVAL, ya que las capacidades correspondientes están disponibles únicamente para modelos profesionales y de servidor. La opción de acceder directamente a BAR1 tampoco funcionó: solo se obtiene una pequeña región mapeada, y la lectura de la otra parte devuelve ceros. El enfoque NBD evita esta limitación, ya que utiliza copias CUDA normales cuMemcpyHtoD y cuMemcpyDtoH.
Funcionalidades
Uso de VRAM como un intercambio normal de Linux. Después de iniciar, el demonio proporciona la memoria de video como /dev/nbd0 u otro dispositivo NBD, que para el núcleo se ve como un dispositivo de bloque estándar.
Funciona sin un módulo de núcleo propio. El proyecto no requiere escribir, compilar y mantener un módulo del núcleo separado, no utiliza símbolos internos del controlador de NVIDIA y debe sobrevivir las actualizaciones del núcleo y del controlador sin necesidad de recompilación.
Enfoque en las GPU NVIDIA de consumo. Los requisitos incluyen GPU NVIDIA con soporte para CUDA, incluidas las tarjetas RTX/GTX para consumidores, el controlador oficial de NVIDIA con libcuda.so.1, el módulo nbd en el núcleo de Linux, nbd-client, gcc y make. No se necesita el CUDA Toolkit.
Integración con systemd. La instalación a través de install.sh agrega el servicio vram-swap-nbd, que se puede iniciar a través de systemctl; tras la instalación, el servicio se habilita para arrancar automáticamente al iniciar.
Configuración del tamaño y la prioridad de swap. En el archivo unit de systemd se puede definir VRAM_SETUP_SIZE_MB, es decir, el límite máximo de VRAM asignada, y VRAM_SWAP_PRIORITY, que es la prioridad del dispositivo de swap. Cuanto mayor sea la prioridad, antes utilizará Linux esta capa de swap.
Reducción automática del tamaño solicitado. Si la cantidad de VRAM requerida no está disponible, el demonio intenta reducir el tamaño en bloques de 512 MiB para asignar el máximo disponible, por ejemplo, si parte de la memoria ya está ocupada por el compositor o la sesión gráfica.
Scripts de prueba. En el repositorio hay test-nbd.sh para una prueba de humo con lectura/escritura de 1 MiB y test-fill.sh para una prueba de estrés de toda la partición de VRAM.
Rendimiento declarado de aproximadamente 1,3 GB/s. En la RTX 3070 Laptop, el autor midió una escritura secuencial de 7 GB en bloques de 4 MB a aproximadamente 1,3 GB/s.
Escenarios de aplicación
Portátiles con RAM soldada. El escenario principal son los portátiles modernos, donde 16 o 32 GB de RAM ya no son suficientes, pero no se pueden expandir. Si en tal máquina hay una tarjeta RTX dedicada, parte de la VRAM se puede utilizar como una capa de swap adicional. Esto no convierte la VRAM en RAM completa, pero puede salvar al sistema de caer en un swap de SSD lento o de OOM-killer bajo cargas pico.
Entornos de desarrollo pesados. IDE, navegadores con decenas de pestañas, contenedores Docker, bases de datos locales, compilaciones de grandes proyectos y entornos de prueba crean fácilmente picos temporales en el consumo de memoria. En tal escenario, NBD-VRAM puede funcionar como un búfer: no acelera el trabajo normal, sino que suaviza el momento en que se acaba la RAM.
Reducción de la carga en el swap de SSD. Si el swap en SSD se utiliza con frecuencia, esto no solo es más lento, sino que también genera escritura innecesaria en el dispositivo. Se puede establecer un swap en VRAM con una prioridad más alta, de modo que, al desbordarse la RAM, el sistema envíe primero las páginas a la memoria de video y solo después acceda al SSD. Esto es especialmente relevante para laptops, donde el SSD también suele ser no extraíble o caro de reemplazar.
Combinación con zram. El autor describe claramente un esquema donde el swap en VRAM tiene una prioridad más alta y recibe el primer "desbordamiento" de memoria, zram se utiliza en el siguiente nivel, y el SSD permanece como la última línea de defensa. Este esquema puede ser útil para estaciones de trabajo y laptops, donde es más importante mantener la capacidad de respuesta del sistema ante la falta de memoria que obtener la máxima previsibilidad de latencias.
Tareas locales de IA/LLM alrededor de la GPU, pero no en lugar de VRAM para el modelo. NBD-VRAM no aumenta la memoria de video disponible para la aplicación CUDA como VRAM para el modelo. Es un escenario inverso: no se utiliza RAM como VRAM, sino que VRAM se utiliza como swap para la memoria ordinaria de Linux. Por lo tanto, el proyecto no permitirá cargar directamente un modelo más grande en la GPU. Sin embargo, puede ser útil en una máquina donde, junto con la inferencia LLM, trabajan un navegador, un IDE, indexadores, entornos de Python y contenedores, y la RAM del sistema comienza a escasear.
Estaciones de trabajo domésticas y experimentales. El proyecto es interesante para los usuarios cuya tarjeta gráfica a menudo permanece inactiva fuera de juegos, renderizado o tareas de ML. Por ejemplo, se pueden convertir temporalmente 8–12 GB de VRAM en un escritorio GeForce en una capa adicional de swap para tareas pesadas de compilación, procesamiento de datos o ejecución. máquinas virtuales.
Limitaciones
NBD-VRAM no es un sustituto de la memoria RAM. El acceso a este swap se realiza a través de la cadena kernel swap → /dev/nbdX → controlador nbd → socket Unix → demonio → copia CUDA → VRAM, por lo que las latencias y el comportamiento serán diferentes de la verdadera RAM. Es más bien una capa de emergencia o intermedia entre RAM y SSD, que un modo de "agregar memoria" sin consecuencias.
Además, el proyecto está vinculado al stack oficial de NVIDIA con CUDA. Nouveau/Nova no son adecuados para esto, ya que se requiere libcuda.so.1. Phoronix también señala, que NBD-VRAM fue creado específicamente para las GPU NVIDIA de consumo, donde enfoques alternativos a través de la API P2P de NVIDIA no funcionan.
En resumen, NBD-VRAM es un pequeño pero interesante hack de sistema para Linux: no realiza maravillas ni sustituye una actualización de RAM, pero permite utilizar la memoria de video inactiva como una capa adicional de swap antes del SSD. Para laptops con memoria soldada y una tarjeta RTX dedicada, esto puede ser una forma práctica de manejar picos de carga sin que las aplicaciones caigan de inmediato o sin experimentar una lenta transición a un disco más lento.
Fuente: linux.org.ru
