老黄的显存刀法这些年是越来越精准了，一块2080Ti搁在五年前是顶级旗舰，放到今天，11GB显存却成了跑个像样模型都费劲的瓶颈。最近社区里冒出一个开源GPU显存虚拟化项目，思路倒是直给：显存不够，就让主机内存来凑，把显存做成类似系统虚拟内存那样的一层。我跟大部分人的情况差不多，手里卡着2080Ti没法立刻升级，所以第一时间把这个项目拉到本地折腾了一周。这篇文章就是完整的实测记录，包括原理拆解、部署步骤、真实跑模型的数据，还有我踩过的几个坑。如果你手里也是老卡，或者单纯不想花大几千换卡，这篇应该能帮你省下不少试错时间。

1. 先说结论：这个项目到底在干什么

1.1 2080Ti为什么突然不香了

2080Ti本身不弱，Turing架构的算力放在今天做推理、做中小规模微调，依然能打。问题出在显存上，11GB这个容量在当年是"为所欲为"，现在却卡在了一个很尴尬的位置：跑个7B模型，FP16权重就要13GB左右，直接溢出；跑SD系列画图，512×512的batch稍微大一点，显存也就见底了；更别提做LoRA微调的时候，权重、梯度、优化器状态全压在显存里，OOM几乎是家常便饭。

我见过不少人的解法是换卡，但二手市场什么价格大家都懂。也有人说用CPU offload，这个思路方向对，但PyTorch自带的offload机制比较粗糙，它把整层整层地搬到内存，访存局部性差，速度忽快忽慢，体验并不好。开源GPU显存虚拟化项目解决的就是这个问题，它在显存和内存之间加了一层"调度器"，让显存像操作系统里的物理内存一样，可以按需换入换出，跑不下的模型就不必再被11GB的物理容量锁死。

1.2 显存虚拟化的三种常见玩法

在深入这个项目之前，我把目前主流的显存扩展方案过了一遍，方便你理解它到底属于哪一类。

很多底层特性里其实已经内置了类似"统一寻址"的能力，但它的缺页处理对AI负载来说太脆弱了，稍微大一点的模型跑起来，系统会疯狂触发迁移，性能直接崩。这个开源项目做的是第一类，它在CUDA API层插入了一个分配拦截器，自己管理显存页面的调度策略，默认用LRU算法把不常用的页面换到主机内存，等用到的时候再换回来。

为什么要自己实现而不直接用底层特性？因为AI负载的访存规律是可以预判的。比如推理的时候，模型权重是反复访问的热数据，KV cache却是逐渐增长、老数据慢慢变冷的，这种明显的局部性特征，完全可以通过可控的换页策略来利用。自己实现交换层，意味着可以精确控制"什么时候换、换多少、保留哪些热页"，这是固有机制给不了的。

2. 部署前的准备：硬件、系统与依赖

2.1 内存和硬盘才是最大的门槛

既然思路是"显存不够内存凑"，那主机内存就是第一道硬门槛。我实测下来，至少要有被模型溢出量的1.5倍空闲内存，体验才勉强合格。以7B模型为例，FP16权重约13GB，如果显存只能放10.5GB，那就要腾出至少4~6GB内存给它换页；如果你还想开大上下文，KV cache再膨胀个几GB，内存就得奔着32GB去了。想跑13B模型，听我一句劝，先把内存加到64GB再折腾，不然内存先爆，系统 swap 起来数据盘，那速度能让人绝望。

第二个容易被忽略的是换页盘的性能。这层交换机制读的是PCIe带宽，写的是内存，但页面从内存往盘的路径上，如果触发系统级别的swap，那就全完了。项目本身提供了把交换页固定到某块磁盘的能力，实测下来Intel 670p这种QLC盘和主流PCIe 4.0盘差距非常明显，冷页面换入一次可能差出一倍时间。有条件的话，哪怕给项目划一个20GB的NVMe分区都行，尽量别用机械盘。

CPU倒不用太担心，交换逻辑本身不消耗多少算力，但内存通道数会影响带宽。插两根组双通道是底线，四通道主板能跑四通道就开四通道，内存带宽直接决定换页的极限速度。

2.2 系统与驱动环境搭配

这个项目目前对Linux的适配最完善，Windows下的支持比较勉强，我是在Ubuntu 22.04上跑的。驱动和CUDA工具链的版本搭配很关键，先说结论：驱动建议525及以上，CUDA Toolkit用11.8或12.1，PyTorch尽量选2.x系列。如果你的驱动版本太老，底层的CUDA API符号表对不上，插件的拦截层会直接加载失败，而且不会有明显报错，只是打开项目日志功能后能看见"symbol not found"之类的信息。

还有一个容易踩的坑是PyTorch的编译方式。官方预编译的PyTorch通常已经静态链接了不少CUDA符号，项目在运行时通过LD_PRELOAD注入拦截层，理论上兼容，但如果你用的是源码编译的PyTorch，并且编译时指定了特别的CUDA架构，拦截层和你本地库的ABI对不上，就会出现"分配了一切正常，但显存占用一点没降"的诡异状况。我的建议是：先用官方预编译包跑通，再考虑自己编译的事。

提示：装之前先跑一行python -c "import torch; print(torch.version.cuda)"确认PyTorch绑定的CUDA版本，再决定用哪个版本的插件。版本错配是这个项目最普遍的翻车原因。

2.3 编译安装的完整过程

拉源码编译的过程不算复杂，但有几个细节值得注意。假设你已经把仓库clone到了本地（项目不大，编译产物加依赖大概占几个GB），标准流程是：

cd memswap mkdir build cd build cmake .. -DCMAKE_BUILD_TYPE=Release -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda make -j$(nproc) sudo make install

编译前建议把/usr/local/cuda软链接指到你当前用的CUDA版本上，因为CMake默认找最新版本，如果机器上装了多个CUDA，容易链接错。编译完成后，项目会产出一个带版本号的动态链接库，之后通过环境变量启用：

export LD_PRELOAD=/usr/local/lib/libmemswap.so export MEMSWAP_LOG=1 export CUDA_VISIBLE_DEVICES=0 python my_inference_script.py

启用后第一件事是验证注入是否生效。项目自带一个小工具，可以打印逻辑显存分配总量，这个数值允许超过物理显存11GB，看到这个数字就说明拦截层已经接管了分配。我第一次跑的时候没注意日志，直接启动了Whisper的大模型脚本，结果还是报OOM，折腾半天才发现注入根本没生效，原因是PyTorch用的CUDA runtime版本和拦截层编译时的版本不一致。所以无论如何，先验证再跑正式任务，能少走很多弯路。

3. 实操记录：从跑不通到跑得动

3.1 接入方式：一张图说清调用链

这个项目用起来有多省事呢？它不需要你改模型代码，不需要往外挂载任何虚拟设备，甚至不需要改动PyTorch的DataLoader。原理是它拦截的是CUDA runtime层的内存分配函数，PyTorch在申请显存的时候，调用链是Python层到C++层，再到CUDA的cudaMalloc，项目在这个入口处截胡，把大块分配拆成小块页面，然后交给自己的管理器来跟踪热度，并对冷页面做换出。

所以从用户视角看，代码几乎不用动，只需要在启动脚本前把动态库加载进去。我用7B模型做了一次完整的LLM推理测试，模型加载逻辑完全没改，只加了一行环境变量，体验上就是"换个启动方式，显存就变大了"。它也会暴露一两个自定义的统计函数，可以查询当前逻辑显存大小、换页次数、命中率这些指标，不过不是必须的。

3.2 实测一：13B模型被硬生生救活了

先测的是最典型的场景：加载一个13B模型做对话推理。这个模型FP16权重约26GB，就算经过8bit量化也有13GB左右，物理显存无论如何装不下。我没有用项目之前，试过PyTorch自带的 offload，确实能跑，但第一次生成token的时候要等好几秒，后续每个token的速度也有很大波动。开启MemSwap后，策略上把模型权重当作高优先级热页，尽可能常驻显存，KV cache的最近部分也保留，冷数据才换出。

实测效果非常直观。量化后的13B模型实际显存占用约10GB，相当于溢出2~3GB交给交换层，首次推理的延迟比纯物理显存方案慢了一些，但每个token的生成速度基本稳定在每秒6~8个token，属于"能用且还算流畅"的水准。如果是跑7B FP16，溢出量只有3GB左右，生成速度损失就更小，几乎感觉不到明显差异。

这些数字说明一个问题：溢出比例是决定体验的关键。溢出几个GB，就是"小卡顿但能用"；溢出十几个GB，交换层忙不过来，性能会断崖式下跌。如果你真想跑大模型，先量化再上虚拟化，才是正确姿势。

3.3 实测二：扩散模型训练，效果奇差

推理场景体验不错，但我必须说实话：训练场景千万别对它抱期望。我拿扩散模型做了一次512×512、batch size为2的微调实验，内存256GB，理论上有充足空间容纳交换页。结果一个step的耗时从原来的1.2秒直接涨到接近8秒，吞吐量掉了将近七成。

原因其实不难理解。训练和推理的访存模式完全不一样，推理是一遍正向推完，权重被密集访问，属于天然的局部性热数据；训练则要在forward之后做backward，反向传播需要把所有参数再扫一遍，每个step从头到尾都会触达全部权重。这就导致每个训练step都会把所有换出去的页面重新搬回显存，算完再换出去，相当于每个step都多传了十几GB的数据，PCIe带宽直接被塞满。项目文档里也明确说了，它的设计目标本来就是推理加速，不是训练扩展池。

注意：如果你想让训练跑起来，建议只溢出优化器状态这类更新频率低的数据，至少能减少一半的交换量。但这需要手动配置哪些张量可以交换，操作门槛就上来了。

3.4 调优三板斧：阈值、块大小、热页策略

部署不是跑通就完事了，想让体验再往上拉一截，这三个参数是核心。

第一板斧是交换触发阈值，默认在0.85左右，也就是显存用到85%就开始换出。我实际体验下来，2080Ti设到0.90更合适，稍微激进一点，让更多页面留在显存里，命中率会更高。阈值调太低，冷页面被频繁冤枉，换出太早；阈值太高，底层开始报OOM的瞬间，项目来不及接管，就容易崩。

第二板斧是换页块大小，默认256MB。我跑了几个场景对比，图像类的模型，块小一点，128MB会让分配更均匀，显存碎片少一些；大语言模型推理，256MB反而好，因为参数权重本身就是连续大块，块小了反而增加管理开销。这个需要按模型微调。

第三板斧是热页保留策略。项目默认保留一定数量的热页面，你可以设定KV cache的最近N个页强制驻留显存。这个对长上下文场景特别有用，因为KV cache的访问几乎总是集中在尾部，把最近的页面保留住，能显著减少换页抖动。

4. 踩坑日志：常见问题与排查技巧

4.1 性能不升反降怎么办

这是我用下来遇到最多的反馈。开虚拟化之后，模型不OOM了，速度却慢到不能忍，这种情况八成不是项目的问题，而是负载本身不适合交换。训练场景我前面已经说了，直接劝退；还有一个隐藏场景是多轮对话，KV cache不断增长，如果不细分热页策略，老页会被大量换出，下一轮用户提问时又需要这些历史cache，就会反复换入换出，造成抖动。

解决方法分两步：先开日志看命中率，如果命中率低于80%，说明换页太频繁了，优先提高热页保留数；如果命中率正常但速度还慢，多半是主机内存带宽或者交换盘速度不够，检查一下内存是不是跑在单通道。我一度被这个坑折磨，以为参数有问题，结果发现内存只插了一根，双通道一开，问题直接解决。

4.2 显存碎片化引发分配失败

另一个诡异问题是：明明总显存空间够，运行中却突然报显存分配失败。这是因为交换层的页式管理会产生碎片，大块连续分配需求（比如注意力计算的临时缓冲区）可能找不到足够大的物理连续区域。PyTorch本身有缓存分配器，遇到这种二次分配失败，通常会在日志里打出 "CUDA error: out of memory"。

排查时有个笨办法很有效：把热页保留数降低，碎片会少一些；块大小调小也能改善。但如果运行时间特别长，碎片累积到一定程度，最稳妥的办法就是重启进程。虚拟化项目解决的是"显存不够用"的问题，不是"显存碎成渣"的问题，重度长时任务定期重启开销也不大。

4.3 多进程与显存上下文冲突

用torch.multiprocessing启动并行推理时，我遇到了显存上下文冲突。原因是每个子进程都会继承父进程的LD_PRELOAD环境变量，但它们各自尝试初始化交换管理器的元数据，互相覆盖状态，导致显存分配错乱。症状非常有意思：一两个进程跑得好好的，加到四个进程后，日志里开始出现"double free"或者随机的分配错误。

解决办法是把交换管理器的初始化控制权收回到主进程，让子进程只使用主进程已经建好的共享状态。具体操作是在启动子进程前先初始化一次，再配合spawn方式启动，进程间各自持有独立的CUDA上下文，避免状态串扰。要是还不行，就对每个子进程单独配置一份环境变量，保证它们各管各的交换空间。

4.4 常见问题速查表

5. 写在最后：这套方案值得折腾吗

我个人的结论很明确：如果你的主要负载是LLM推理、AI绘图出图这类"读多写少"的任务，手里又恰好是2080Ti这种算力够用、显存被卡死的卡，这个开源GPU显存虚拟化项目值得花半天时间折腾一次。它的介入成本低到几乎可以忽略，启动时加载一个动态库而已，跑不通随时退回原状，没有什么副作用。对我而言，最直接的收益是那台老机器又多撑了一年，13B模型量化之后能流畅对话，SD出图也不再动不动就爆显存。

但如果你打算拿它跑训练，或者想通过它硬上超大规模的模型，我的建议是趁早打消念头。交换层的本质是在带宽有限的PCIe通道上反复搬运数据，它解决的是"能不能跑"的问题，不是"跑得多快"的问题。硬件瓶颈就摆在那里，物理规律不会因为开源项目而改变。不过话说回来，能让老卡晚一年进垃圾桶，这项目已经算功德无量了。真到了48GB大显存卡普及的那天，我估计还会怀念这段用软件从石头缝里压出显存的日子。