一台 RTX 3070 Laptop，16GB RAM，8GB VRAM。项目作者拿出 7GB 显存做 swap，再加上 zram 和 SSD swap，系统可寻址的内存 / swap 池约 46GB。
这听起来像“显存变内存”。实际不是。nbd-vram 做的是把 VRAM 包装成一个 Linux swap 设备，让内存溢出的页先去显存，尽量别马上落到 SSD。
对内存焊死的笔记本用户，这很有吸引力。对正在打游戏、跑渲染、跑 CUDA 任务的人，它又可能抢走本来就紧张的显存。收益和代价都很具体。
它做了什么：把 VRAM 伪装成 swap 设备
nbd-vram 的路线很克制：不写内核模块，不去碰 NVIDIA 内核符号。
它用一个 daemon 通过 CUDA 分配 VRAM，再通过 NBD 暴露成块设备。Linux 看到的是 /dev/nbdX，用户可以把它挂成 swap，并设置更高优先级。
工作路径是：
kernel swap → /dev/nbdX → nbd driver → Unix socket → daemon → CUDA cuMemcpy → GPU VRAM
重点在 swap 优先级。RAM 满后，页面可以先进入 VRAM swap，再到 zram，最后才落 SSD。项目的目标不是让系统拥有更多物理内存，而是减少 SSD swap 的压力。
| 问题 | 目前能确定的信息 | 现实判断 |
|---|---|---|
| 测试环境 | RTX 3070 Laptop、16GB RAM、8GB VRAM、分配 7GB VRAM | 单一环境，不应泛化到所有机器 |
| 接入方式 | NBD 块设备 + CUDA 拷贝 | 避开了直接让 CPU 访问 VRAM 的限制 |
| 优先级 | RAM 满后先进 VRAM swap，再到 zram，最后 SSD | 适合缓冲内存压力，不等于扩容 RAM |
| 性能锚点 | 作者测得 7GiB 顺序写约 1.3GB/s，并称延迟低于 NVMe | 只能当项目作者环境下的参考 |
| 使用条件 | Linux + NVIDIA CUDA GPU | 不适用于所有 GPU、驱动和发行版组合 |
最相关的人群其实很窄：Linux 笔记本用户，内存焊死，机器里有闲置 NVIDIA 显存，平时又容易被浏览器、IDE、容器、编译任务顶爆 RAM。
这类用户可以把它当一个实验性缓冲层。不是采购新机器的替代品，也不是让 16GB 笔记本变成 32GB 工作站。
关键变量：VRAM 比 SSD 近，但它不是 RAM
这个项目最聪明的地方，不是发现显存能存数据。显存本来就能存。
难点是怎么让 Linux 内核愿意把它当 swap 用，并且不被 NVIDIA 消费级卡的限制卡死。
直接路线并不顺。作者提到，想通过 NVIDIA P2P API pin 住 VRAM 页、让 CPU 直接访问，消费级 GeForce 卡会在相关接口上返回 EINVAL。这类能力更接近 Quadro / 数据中心卡的待遇。
另一条路也不好走：直接 ioremap_wc BAR1 物理地址。问题是 GPU 内部页表实际只映射了很小一段 BAR1。读其他区域可能只是零。mkswap 看似成功，swapon 才发现 swap header 不在。
所以 nbd-vram 选择绕开。它不要求 CPU 直接摸 VRAM，而是让 daemon 通过 CUDA 的 cuMemcpyHtoD/DtoH 搬数据。消费级 CUDA GPU 也能走这条路。
这就是它的工程价值：不硬刚封死的门，改从系统接口之间搭桥。
但桥就是桥。它比 SSD swap 可能更舒服，却不可能像 RAM 一样自然。
| 方案 | 优点 | 约束 |
|---|---|---|
| RAM | 延迟和语义最合适 | 焊死后无法升级 |
| zram | 不落盘，适合压缩可压缩页面 | 吃 CPU，容量受压缩率影响 |
| VRAM swap | 可利用闲置显存，减少 SSD 压力 | 依赖 CUDA、daemon、NBD、GPU 驱动 |
| SSD swap | 通用、稳定、路径成熟 | 慢，且长期高压会增加写入负担 |
对开发者来说，动作建议也很直接：如果你的机器常年 RAM 爆掉，而 GPU 显存大部分闲着，可以试；如果你的工作本来就吃 GPU，就先别急着上。
对小团队采购也一样。它可以延后一点换机压力，但不能拿来当采购理由。焊死 16GB 内存的机器，靠显存 swap 勉强撑，是补救，不是规划。
我的判断：好工程，也暴露了用户被动
我对 nbd-vram 的评价偏正面。它没有把自己包装成革命，也没有把 swap 说成内存升级。它解决的是一个窄问题：RAM 满了，SSD swap 太痛苦，显存又闲着。
这个问题窄，但真实。
现在很多笔记本把内存焊死，升级路径被封住。厂商得到的是更薄的机身、更简单的库存和更可控的产品分层。用户得到的是机器还没坏，内存先不够。
“天下熙熙，皆为利来。”这句话放在这里不玄。硬件设计的收益在厂商侧，寿命缩短和折腾成本在用户侧。nbd-vram 只是把这笔账在软件层面补了一刀。
它补得漂亮，但代价没消失。
VRAM 被拿去做 swap，就会挤占图形和计算负载。桌面合成器、游戏、渲染、CUDA 任务都可能受影响。项目可以在显存不足时按 512MiB 退让，也支持按插电 / 电池状态管理服务，但这只能缓和冲突。
更硬的限制是可靠性。
传统 SSD swap 路径短，机制成熟。nbd-vram 的链路多了 daemon、Unix socket、NBD、GPU 驱动、CUDA 拷贝。swap 承接的是系统内存压力下的页面，不是无所谓丢失的临时文件。链路越长，故障点越多。
所以接下来最该观察的不是跑分，而是三件事：
- 不同 NVIDIA GPU、驱动版本、Linux 发行版上的稳定性；
- GPU 负载和 VRAM swap 同时存在时，系统怎么退让；
- daemon、NBD 或驱动异常时，swap 链路会不会把系统拖进更糟的状态。
如果这些边界收得住，它就是内存焊死时代一个很实用的工具。如果收不住，它也仍然是一个聪明实验，只是不适合放进日常生产环境。
我更愿意把它看成一个信号：当硬件可扩展性被削掉，用户会从软件缝隙里把它一点点抠回来。
这次抠得很巧。但也提醒得很刺眼：机器不是不够快，是退路太少。