lmganon16/nvidia-vram-research — explained in plain English
Analysis updated 2026-05-18
Free up reserved VRAM on an RTX 3060 to run larger CUDA or llama.cpp workloads.
Study how NVIDIA's proprietary driver internally allocates and reserves framebuffer memory.
Test driver registry settings that move memory reservations into system RAM instead of the GPU.
| lmganon16/nvidia-vram-research | 0-bingwu-0/live-interpreter | 010zx00x1/faresnipe | |
|---|---|---|---|
| Stars | 2 | 2 | 2 |
| Language | Python | Python | Python |
| Setup difficulty | hard | moderate | easy |
| Complexity | 5/5 | 2/5 | 2/5 |
| Audience | developer | general | general |
Figures from each repo's GitHub metadata at analysis time.
Only tested on one RTX 3060 configuration, changes can crash or hard-lock the system on other hardware.
This repository documents an experiment in reclaiming video memory that NVIDIA's proprietary Linux driver normally reserves for itself and does not report as used. It is aimed at people who want more usable VRAM on their graphics card, mainly for AI workloads like running large language models with llama.cpp, and it is explicit about being risky: the README itself warns of possible hard locks, crashes, or a dead GPU, and says testing has only been done on an RTX 3060 with software rendered X11. The core finding is that a stock driver on a GeForce RTX 3060 reserved about 133 MiB of framebuffer memory that tools like nvidia-smi do not count as used. Through reverse engineering, the author broke that reservation down into several categories: memory that is genuinely required, memory that could be moved into regular system RAM instead of the graphics card, conservative safety margins for situations that might not occur, and old allowances inherited from earlier NVIDIA hardware. By adjusting driver settings step by step, the project brought the reservation down to about 30.5 MiB, recovering roughly 102.5 MiB, while keeping CUDA workloads and llama.cpp working correctly. Three techniques are offered, roughly in order of increasing risk. The lowest risk is disabling GSP firmware, which NVIDIA itself documents, and can free up to 300 MiB. A medium risk option offloads part of the reserved memory into system RAM using a driver registry setting, freeing about 50 MiB. The highest risk path involves directly patching the proprietary kernel module, which can free 50 MiB or more but has no automatic scripts yet and requires a lot of manual testing. The repository is really a research writeup rather than a ready-to-run tool. It documents step by step configuration changes, a table of tested stable settings for one specific GPU and driver version, and warns that "stable" only refers to the exact hardware, driver, and workload tested, not to any other setup. Applying these changes on a different GPU or driver build is explicitly said to carry risk with no guarantee of safety.
A research writeup documenting how to reclaim reserved VRAM on NVIDIA GPUs by tweaking driver settings, aimed at freeing memory for AI workloads at real crash risk.
Mainly Python. The stack also includes Linux, NVIDIA driver, CUDA.
Setup difficulty is rated hard, with roughly 1day+ to a first successful run.
Mainly developer.
This repo across BitVibe Labs
double-check against the repo, no cap.