把显卡那昂贵的显存，变成你的虚拟内存。听起来像天方夜谭？一位开发者让它成了真，代价可能是你的桌面直接崩掉。
开发者的“野路子”，绕开了官方铜墙铁壁
开源项目 nbd-vram 的核心思路很清晰：在Linux上写一个守护进程，通过CUDA驱动API申请显存，然后用NBD协议把它伪装成一个块设备。系统内核接管后，它就是一块标准的swap分区。
数据流路径：内核交换子系统 -> /dev/nbdX -> nbd内核驱动 -> Unix套接字 -> nbd-vram守护进程 -> GPU显存。
没有内核模块要写，不依赖NVIDIA任何内核符号，驱动更新也无需重新编译。这代码写得，像在走钢丝。
官方大门紧锁，他翻窗户找到了路
为什么不直接用NVIDIA官方的P2P（点对点）API？nvidia_p2p_get_pages_persistent 听起来是正解，它能让CPU直接通过PCIe访问映射到BAR1空间的显存页。
但所有尝试过的项目都撞上了同一堵墙：在消费级GeForce显卡上，这个API返回 EINVAL。 无论持久性还是非持久性调用，都被驱动在RM（资源管理器）层面锁死了，只有Quadro或数据中心卡才能用。
直接 ioremap_wc 显卡的BAR1物理地址呢？也不行。GPU内部页表只映射了大约16 MiB的BAR1空间（通常只是显示帧缓冲区）。对未映射区域的读取会返回全零。mkswap 可能看起来成功了，但 swapon 会失败，因为交换文件头根本没写进去。
NBD方案巧妙地绕开了所有限制。cuMemcpyHtoD 和 cuMemcpyDtoH 这两个CUDA内存复制函数，在任何支持CUDA的GPU上都能用，无需特殊权限。官方不给路，民间高手就用最基础的“搬砖”方式，自己搭了一座桥。
性能：惊喜与争议并存
在RTX 3070笔记本上的测试显示，7GB顺序写入的吞吐量约为1.3 GB/s。项目作者强调，由于数据路径经过PCIe直达GPU而非存储设备，延迟比NVMe SSD更低。
对于已经使用zram压缩内存的笔记本，可以设置这个VRAM交换区为更高优先级，让溢出数据先落到显存里，而不是写进SSD。听起来，这是为内存焊死、无法升级的笔记本用户量身定做的“救生圈”。
但这个“1.3 GB/s”的数字，引爆了争议。
网友灵魂拷问：这速度，认真的吗？
热门评论里，最尖锐的质疑直指性能：
This RTX 3070 chip is on PCIe 4.0 x16 which should give 64GB/s. The 8GB of GDDR6 is 448GB/s. Swapping to an NVMe drive would be twice as fast, but with higher latency.
一块PCIe 4.0 x16显卡的理论带宽是64 GB/s，显存带宽更是高达448 GB/s，结果实测只有1.3 GB/s？ 这落差大得让人困惑。有人直接评论：“听起来低得离谱，而且随机读写速度不是更关键吗？”
性能问题，成了这个巧妙创意身上最显眼的瑕疵。
潜在的“自杀”按钮：VRAM不够了怎么办？
另一个更实际的忧虑，是显存资源的管理。
What about backpressure, how does it handle requirements for VRAM allocation when VRAM is used for swap space?
当系统本身需要显存进行图形渲染或计算时，这个交换空间就会成为一颗“定时炸弹”。特别是在动态分配显存更频繁的Wayland下，显存耗尽极易导致整个桌面崩溃。一位网友就分享了在Hyprland+llama-server环境下，因显存耗尽而崩溃的经历。
把系统稳定的基石，建立在可能随时被图形任务征用的显存上，这本身就是个冒险。
真香？闲置的巨量显存有了新可能
但另一面，是巨大的诱惑。一位开发者的评论道出了不少人的心声：
Given my dev machine has 32GB of RAM and 32GB of VRAM that sits mostly idle when I'm not running AI models, this is not that bad of an idea.
对于拥有大容量显存，且非重度图形或AI使用者的群体，闲置显存就是巨大的浪费。这个项目提供了一种“废物利用”的思路。
更有人展望了未来：既然数据已经在显存里，GPU强大的并行计算能力，是否能让数据库操作在这里原地起飞？当存储与计算的距离被压缩到零，想象力就有了空间。
结语：一个值得尊重的“竹筏”
nbd-vram 这个项目，本质上是一次精彩的“技术挪用”。它不是优雅的工程方案，更像是在系统限制的夹缝中，用最朴素的工具搭建的一艘“竹筏”。它解决了特定场景下的燃眉之急，性能瓶颈和资源冲突风险也同样明显。
它提醒我们，在看似封闭的硬件和驱动生态中，民间智慧依然能找到撬动的支点。也许未来，随着硬件和驱动策略的开放，更好的方案会出现。但此刻，这艘竹筏，是属于某些用户的唯一选择。
所以，你愿意用稳定的系统，去赌一把闲置显存的速度吗？
【锐评】：这项目把“有多少内存，就办多大事”的格言，硬生生改成了“有多少显存，就撑多大摊子”。
参考链接：
https://github.com/c0dejedi/nbd-vram