1. 显存不够用这件事，卡在哪了
这两年玩大模型的朋友应该都体会过那种滋味——好不容易把依赖环境配好了，模型权重也下下来了，结果程序一启动就弹出来一行红色的CUDA out of memory。尤其是手头只有一块11GB显存卡的朋友，面对时下主流的13B、14B甚至更大参数量的模型，基本都是还没进门就被劝退了。
显存焦虑就是这么来的。模型在变大的速度远比你换显卡的速度快，而显卡的价格更是一言难尽。但先别急着去翻购物软件。开源社区里其实一直有人在折腾一条不同的路：让显存不够的显卡，通过软件手段把系统内存甚至硬盘空间借用过来，变相把显存“撑大”。这类方案就是GPU显存虚拟化，或者叫显存扩展、显存交换。核心思想一句话——把那些不常用的数据暂时挪到慢一点的存储里，等真要用的时候再换回来。本质上和你电脑内存不够、系统开始用硬盘做虚拟内存是一个道理。
这类项目对谁最有用？首当其冲就是老卡用户。11GB显存卡跑不动13B原始精度模型，但配合显存虚拟化，把一部分权重放到系统内存里，模型照样能加载起来跑推理。其次是用小卡跑长上下文任务的场景——上下文越长，KV Cache占的显存就越大，这类项目也能帮你多撑一段上下文。另外，多卡但显存不均衡的机器同样受益，可以把显存池化和扩展结合使用。当然，学生党、桌面级部署爱好者、预算有限的独立开发者，都会被这类项目吸引。
我看了一圈现在社区里比较活跃的方案，基本思路都类似：在用户态拦截显存分配请求，建立一张从虚拟显存到物理显存加系统内存的映射表，然后通过换入换出策略把数据在两者之间搬运。区别主要在于搬运的粒度、调度策略，以及对上层框架和驱动接口的透明程度。这个方向虽然不能让你获得和原生大显存完全一致的速度，但“能跑起来”这件事本身就价值巨大。
这篇文章就围绕这套技术方案展开。我会先拆解显存到底是怎么被吃掉的、虚拟化的原理边界在哪里，再给出一个完整的实操流程和调优经验，最后整理一些我实际踩过的坑。
2. 显存被谁吃掉了，以及为什么能“借”内存
2.1 大模型推理时的显存账本
想搞懂显存虚拟化能做什么，先得知道模型推理时显存花在哪。通常记一本账：模型权重、KV Cache、激活值、临时缓冲区，这四类是大头。
以13B模型为例，FP16权重一张就是26GB左右。INT8量化后大约13GB，INT4量化后大约6.5GB。也就是说，11GB显存的卡跑FP16的13B模型直接不可能，跑INT8也超一点，INT4倒是能勉强塞进11GB，但推理时的KV Cache和激活还会继续占空间，所以实际还是容易爆。
KV Cache是自回归生成过程中的缓存——每生成一个token，就要把之前所有token的Key和Value向量缓存下来，供注意力机制重复使用。它的大小和模型层数、注意力头数、序列长度成正比。序列长度翻一倍，KV Cache就涨一截。长上下文场景下，KV Cache吃掉的显存甚至能超过模型权重本身。13B模型跑2048上下文，FP16下KV Cache大约要1到2GB，跑8192上下文就奔着5GB以上去了。
激活值是前向传播过程中每一层的中间结果，和batch size、序列长度强相关。单条推理时它不大，但开大batch或长序列时也会涨得很快。
所以显存账本很清晰：权重是固定支出，KV Cache随上下文增长，激活值随批次和长度波动。老卡用户的困境本质上是固定支出加浮动支出叠加，超过物理显存上限。
2.2 虚拟显存的空间从哪里来
显存虚拟化的空间来源有两个层次。第一层是系统内存，也就是DDR内存。第二层是硬盘上的交换文件，通常作为最次级存储。
系统内存和显存的传输路径是：显存 -> PCIe总线 -> 内存控制器 -> 系统内存，反过来也是一样。PCIe 3.0 x16单方向理论带宽大约12到16GB/s，实际可用能到10GB/s以上就算不错。PCIe 4.0 x16带宽翻倍，实际能跑到20GB/s左右。而显存本身的带宽是另一个数量级——11GB显存卡的带宽通常在500GB/s到600GB/s之间。这意味着，每从系统内存换入1GB数据到显存，CPU侧大概要花0.1秒（按PCIe 3.0实际速度算），而这1GB数据在显存里，GPU算完它只需要毫秒级。
听起来很慢对吧？但对推理场景来说并没有那么致命。因为推理是一个“权重到处流动”的过程——每一层的前向计算需要用该层的权重，算完这层，下一层的数据又得从显存读。如果权重总是按层组织，每次只把当前要算的层换入显存，那么换入一次权重的开销被摊到该层的前向计算时长上。一层的计算如果耗时几十毫秒，换入耗时一百多毫秒，最终单token生成时间会翻几倍，但至少能完整运行起来。
如果只做模型托管和离线批处理，这个速度完全可以接受。如果是实时对话，体验会明显打折扣，但也并非不可用——大多数情况下，配合量化模型，单token生成时间从几十毫秒涨到几百毫秒，还能忍受。
2.3 什么场景适合、什么场景不适合
基于上面的带宽账，可以画一条清晰的分界线。
适合显存虚拟化的场景：显存只差一点点就能跑起来的情形，比如11GB显卡跑14B INT4模型，加载权重时差两三个GB；长上下文推理导致KV Cache波动涨显存；单卡跑不下的模型但有多张卡可以分布式部署的补充；以及冷启动、模型加载、评测跑分这种不追求实时性的任务。
不适合的场景：高频实时交互对话、训练或微调大模型、大批量并发推理、需要稳定低延迟的生产环境。训练场景对显存带宽和通信频率要求极高，虚拟化的换入换出会成为灾难级别的瓶颈。
一句话总结：它是把“跑不了”变成“跑得了”的工具，不是把“慢卡”变成“快卡”的魔法。搞清楚这个边界，你就知道什么时候该用它，什么时候该老老实实换硬件。
3. 显存虚拟化方案的技术细节与实现思路
3.1 分层架构：你看到的大显存是一张映射表
这类开源项目在架构上一般分三层：API层、调度层、存储层。
API层负责拦截显存分配请求。框架调用显存分配函数时，调度层返回的不是真实显存地址，而是一个虚拟地址。真实物理显存地址和虚拟地址之间的对应关系，存在一张映射表里。上层框架无感知——它以为自己在用一块巨大显存，实际上这块显存里只有一部分是真实的。
调度层是最核心的部分。它决定哪些数据留在显存、哪些数据被换到系统内存或磁盘。调度策略直接决定性能。绝大多数项目采用最近最少使用（LRU）策略的变体：被访问过的数据块打上时间戳，显存不足时优先淘汰最久没被访问的块。
存储层是数据真正待的地方。系统内存作为中间层，磁盘交换文件作为兜底层。内存与显存之间用PCIe搬运，内存与磁盘之间走普通文件I/O。这里有一个细节：内存和磁盘的交换速度远低于显存和内存的交换速度。内存带宽普遍在50GB/s到100GB/s（双通道DDR4/DDR5），而磁盘顺序读写通常在几个GB/s级别。好在系统内存通常容量足够，只要不疯狂触发磁盘交换，性能就不会跌得太狠。
3.2 换入换出的粒度：层、张量还是页
项目中一个关键设计决策是：以什么粒度做换入换出。
我们按模型的天然组织结构来拆。以层为粒度最简单——13B模型，30多层的transformer块，每层的权重加KV缓存可能占用0.3到1GB不等。加载时按层换入，算完一层可以立刻换出。实现最简单，但粒度粗，显存碎片率高，如果某一层本身就超过剩余显存空间，就会出问题。
以张量为粒度更精细。一个层的权重里面还分成多个张量，比如注意力头的Q、K、V矩阵、输出投影矩阵、MLP的两层全连接等。每个张量几百MB到一GB不等。按张量换入换出可以减少碎片，但调度复杂度上升，映射表管理开销也更大。
以固定大小为粒度像操作系统分页一样，把显存和内存都分成固定大小的页，比如4KB或2MB。这种最灵活、碎片最少，但要处理的问题最多——一个大张量可能分布在几十个不连续的页上，访问时要处理分页表，框架不透明性差。
实际项目里，多数作者会在张量或层粒度之间选取。显存紧张时优先按层批量换出，显存还有富余时只换出最久未用的张量。我自己的使用经验是：无论是层还是张量粒度，只要能稳定工作且不频繁触发磁盘交换，性能差异其实没那么大，反而是在调度策略和预取逻辑上的差异更值得关注。
3.3 预取：隐藏延迟的关键手段
预取机制是这类项目性能好坏的分水岭。简单做法是：计算层A时，只等层A算完，才去换入层B。这样层B的换入时间完全暴露在关键路径上，每层都白白等一趟I/O。高级做法是异步预取：计算层A的同时，后台线程把层B的数据从系统内存搬运到显存。只要计算层A的耗时大于换入层B的耗时，那么换入开销就被完全隐藏了。
这里有个工程判断要做出：系统内存到显存的搬运走的是PCIe总线，而GPU计算层A时也在频繁读写显存，两者会争抢PCIe带宽。结果就是预取虽然隐藏了一部分延迟，但也会拖慢正在进行的计算。好在transformer的一层计算里，PCIe流量主要是权重读取和激活写入，预取带来的额外流量和正常流量交错发生时，实际影响没有想象中大。我在测试中观察到，开启预取后整体推理速度能提升40%到70%不等，具体取决于模型大小和PCIe版本。
3.4 显存不足时的降级路径
再深一步，当系统内存也不够时怎么办。比如系统内存只有16GB，虚拟显存池设了24GB，模型加载到一半时内存爆了怎么办。正常情况下，项目会把暂时不用的数据写回磁盘交换文件。
但这里必须提醒一个事实：磁盘交换和内存交换完全不是一个量级。SSD顺序读速度说是有3GB/s甚至更高，但随机读和写入混合时，实际吞吐会掉到几百MB/s。一旦模型进入“每一层都需要从磁盘换入”的状态，性能会急剧恶化到基本不可用。所以，我对这类项目的建议从来都是：系统内存容量至少要是目标模型权重的1.5到2倍，否则别开虚拟显存。磁盘交换是拿来应急的，不是拿来日常用的。
4. 实操上手：让11GB显存卡跑起14B量化模型
4.1 环境准备与依赖安装
开始动手前，先把环境捋清楚。我用的是一块11GB显存的老卡，系统内存32GB，操作系统是常见的Linux发行版，驱动和CUDA运行时已装好。操作系统本身对这类项目比较友好，因为底层需要拦截显存API，Linux下用预加载机制就能实现动态库级别的拦截，比在Windows上折腾驱动层要省事得多。
依赖分两类。一类是基础编译工具链：build-essential、cmake、git都是标配。另一类是CUDA工具包，版本不用太新，和驱动匹配即可。我用10.x到11.x都试过，项目本身对CUDA版本要求不算苛刻，但要注意别用太老的版本，有些新一点的特性会缺失。
装依赖我用的是系统包管理器，没什么特别讲究。唯一会踩坑的是cmake版本过老，导致项目构建时报出莫名其妙的选项不识别错误。建议先确认cmake版本在3.15以上，不够的话手动编译装一个新版，省得后面来回折腾。
sudo apt update sudo apt install -y build-essential cmake git nvcc --version # 确认CUDA工具包可用 gcc --version # 确认编译器版本4.2 拉取项目并完成构建
项目本体一般是一个共享库文件，安装好后通过环境变量注入到目标进程中。
标准流程是：克隆仓库、创建构建目录、用cmake生成构建文件、编译、安装动态库。这里给出一个常见项目的通用构建流程：
git clone <项目仓库地址> gpu-vmm cd gpu-vmm mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release make -j$(nproc) sudo make install构建过程通常很快，依赖不多的情况下，几分钟就能编译完。编译产物一般是一个类似libgpu_vmm.so的共享库，外加一个命令行工具，用来设置虚拟显存池的大小和配置换入换出的参数。
这里有一个实际经验：构建时如果遇到找不到CUDA路径的报错，九成是cmake没有自动探测到CUDA安装位置。手动指定一下即可：
cmake .. -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc4.3 配置虚拟显存池
安装完成后，下一步是设置显存池大小。这一步很关键——设太大，模型能加载但系统内存会被吃满，进而触发磁盘交换；设太小，又起不到扩展效果。我的经验公式是：虚拟显存池大小 = 模型权重大小 + KV Cache预估值 + 2GB余量。系统内存小于这个数值时，优先考虑用低比特量化模型而不是硬撑。
以14B INT4模型为例，权重大概7GB，KV Cache按4096上下文预留3GB，再加2GB余量，虚拟显存池设12GB比较合适。总共需要消耗的物理资源是：11GB真实显存加上12GB系统内存，系统内存在32GB的机器上完全无压力。
有些项目还支持设置自动扩展策略——显存池可以动态增长，而不是一次性分配固定大小。我倾向于设置一个固定上限，防止模型加载时内存无节制增长导致系统卡死。设置方式一般是环境变量或配置文件，不同项目不同，但都大同小异，核心就两个参数：虚拟显存池大小、交换文件路径（可选）。
配置完成后，启动目标进程时注入动态库：
export LD_PRELOAD=/usr/local/lib/libgpu_vmm.so export GPU_VMM_SIZE=12G export GPU_VMM_SWAP_PATH=/path/to/swapfile python run_model.py注意LD_PRELOAD只对当前进程生效。如果你是图形界面启动或通过服务方式启动模型，需要把环境变量写进对应的启动脚本里。
4.4 用14B量化模型做一次完整推理验证
环境配好以后，我用一个14B量化模型做了完整验证。加载过程明显比纯显存模式慢——模型权重需要从磁盘读进系统内存，再由虚拟化层搬运到显存。整个过程多花了大概十几秒，但最终加载成功，没有出现显存不足的错误。
推理过程中的速度变化也符合预期。换入换出发生时，单token生成时间明显拉长。我做了一个简单对比，纯11GB显存能跑动的模型，单token生成时间大约150ms；换成通过虚拟显存跑的14B模型，单token生成时间稳定在500ms到800ms之间，偶尔遇到需要批量换入权重时会冲到1秒以上。这个速度做离线批量任务完全能接受，实时对话会有些迟滞感，但终归是跑起来了。
这里有一个很重要的验证点：模型输出的正确性。显存虚拟化如果实现有bug，最常见的问题就是数据换入换出时发生损坏，导致推理结果出现乱码或者概率分布错乱。我用同一段测试文本连续跑了20遍，输出结果完全一致，说明虚拟化层的数据搬运没有发生错位或丢数据。
KV Cache表现也值得一说。我把上下文从2048拉到8192，KV Cache占用明显增加，但换入换出策略平稳地把一部分历史KV数据挪到了系统内存。长上下文生成过程中没有出现显存溢出，只是生成速度进一步下降到800ms到1.2秒之间。对于追求长文档分析和摘要生成的用户，这个体验至少是可用的。
4.5 多卡用户怎么配合使用
如果你手头有两张11GB显存卡，情况会更好。虚拟显存和传统多卡并行是两条可以同时走的路。
传统多卡方案是张量并行或流水线并行，把模型切到多张卡上计算。虚拟显存的介入方式不一样：每张卡各自可以配一个虚拟显存池，等于把两卡各自的11GB显存各扩展12GB，总可用显存达到46GB。代价是两张卡之间的数据同步和虚拟化层的换入换出叠加，通信开销更大。但如果是追求“模型能放进显存”的边界场景，这种方式能跑的模型上限又高了一大截。
不过多卡加虚拟显存的组合，性能衰减会更明显。卡间通信本身走PCIe或NVLink，虚拟显存交换也走PCIe，两者争抢带宽，整体吞吐可能会掉到单卡虚拟模式的60%左右。我的建议是：能纯多卡跑的就纯多卡，不要叠虚拟化；只有模型过大、单卡或纯多卡都放不下时，再上虚拟显存兜底。
5. 常见问题与排查技巧实录
5.1 性能突然暴跌到不可用，先查磁盘交换
我遇到过最典型的问题：启动时一切正常，跑了几十轮推理后速度断崖式下跌，单token生成时间从几百毫秒直接涨到几十秒。第一反应是显存换入换出太频繁，实际查了系统监控才发现，是系统内存被虚拟显存池吃满了，然后操作系统的内存回收机制开始把数据往swap分区里写，而swap分区在机械硬盘上，速度惨不忍睹。
排查方式很简单，一条命令的事：
free -h观察available列，如果系统可用内存已经低于总内存的10%，基本就是虚拟显存池设置过大或者模型权重过大导致的内存饥饿。解决办法通常是调小GPU_VMM_SIZE，或者换一个量化位数更低的模型。
我的习惯是：系统内存低于模型权重的1.5倍时不开启虚拟显存，低于2倍时不开磁盘交换路径。64GB内存的机器，跑15GB权重以内的INT4模型，内存是够的；32GB的机器就得精打细算一些。
5.2 模型加载时报段错误或非法指令
这个问题在我使用过程中出现过两次。一次是项目版本和其他依赖库不兼容导致的，另一次是预加载库和CUDA运行时版本冲突。段错误发生的位置很随机，有时候在初始化，有时候在第一次前向推理时。
排错的思路是：先确认LD_PRELOAD环境变量是否生效，再确认显卡驱动和CUDA运行时版本能对上。如果用的是自定义编译的CUDA内核，还得确认所用的CUDA架构参数包含你的显卡代号。不然编译出来的库虽然能加载，但运行到GPU本地代码时直接崩掉。
最有用的排查工具是ldd和strace：
ldd your_model_process # 查看动态库依赖是否完整 strace -f -o trace.log your_model_process # 跟踪系统调用，定位崩溃前发生了啥大多数情况下，把项目升级到最新版本，同时保证系统环境干净，这类问题就能消除。旧版本项目对新一代CUDA的兼容性往往没那么好。
5.3 显存碎片导致虚拟显存池无法充分利用
这种情况比较隐蔽。虚拟显存池设了16GB，模型加载到13GB时突然报分配失败，但显存池明明还有空间。问题出在碎片化上——换出操作释放的显存页不连续，新请求的显存块跨越多个不连续物理页时，映射表可能无法合并，导致可用碎片空间大于实际分配出去的连续空间。
缓解手段有三个：一是缩短单次推理的上下文长度，减少KV Cache的频繁增长和释放；二是把batch size调小，减少临时缓冲区的反复分配；三是如果项目支持，显式触发一次碎片整理，把分散的显存页重新规整。碎片整理会导致当前所有显存数据全部换出，耗时较长，属于最后手段。
从我的使用经验看，碎片问题在长对话场景下最常见。每轮对话都会改变KV Cache的长度，反复分配释放容易积累碎片。如果可以，建议每做几百轮推理后重启一次模型进程，或者设置脚本定时清理并重新加载模型，虽然麻烦但效果立竿见影。
5.4 长时间运行后的内存泄漏和累积性能衰减
还有一类问题属于“用时才发现”——模型挂机跑了好几个小时，系统内存使用量持续上涨，最终导致整机卡顿。
这类项目的换入换出逻辑里，频繁的分配释放如果存在引用未释放的bug，就会积少成多。排查时可以通过观察模型进程的RES内存占用趋势来判断，如果内存占用随时间稳定增长且没有回落趋势，基本可以断定是泄漏问题。
缓解措施：升级到最新版本，或者换个实现更完善的项目。开源项目的更新速度很快，这类底层bug通常会在社区曝光后几周内修复。在此之前，可以设置定时任务，在低峰期自动重启模型进程释放内存。
5.5 多实例并发时的资源竞争
最后一种情况：一台机器上同时跑两个模型进程，各自都开了虚拟显存。表面上互不干扰，实际PCIe带宽被两边的换入换出平分，每个进程的推理速度都会下降，而且系统内存总量被瓜分后，调度器的换页行为会变得更激进。
解决方式不算复杂：尽量错峰运行，或者给不同进程分配不同的显存池上限。如果两个进程的业务特性不一样，一个需要长上下文（频繁KV Cache增长），另一个只是短查询，优先把虚拟显存资源让给前者，后者直接用原生显存模式跑。
6. 调优实战：让虚拟显存的性能再靠近原生一些
6.1 先摸清你的PCIe总线版本
调优的第一步是确认你的PCIe版本和通道数。PCIe 3.0 x16和PCIe 4.0 x16的带宽差了一倍，直接影响换入换出的天花板。
查看方式：
lspci -vv | grep -A30 "VGA compatible controller"重点看LnkCap和LnkSta两个字段，分别表示链路最大能力和当前状态。如果显示LnkSta: Speed 8GT/s, Width x16，说明跑在PCIe 3.0 x16模式。如果显示Speed 16GT/s，就是PCIe 4.0。
PCIe 4.0设备建议把虚拟显存池的上限调高，因为换入换出效率更高，系统内存的利用价值更大。PCIe 3.0设备则要控制显存池上限，宁可在系统内存里留一点冗余，也别把内存吃满导致双重交换。
6.2 换出优先级：保住KV Cache还是保住权重
这是调优里最微妙的一个决策。推理过程中，模型权重是一整块需要反复读取的静态数据，KV Cache是动态增长的数据。换出权重意味着下次用到时得重新从系统内存搬回来，换出KV Cache则可能导致历史上下文丢失或者需要重新计算。
我的实测结论：优先换出权重，尽量保留KV Cache。因为权重数据量固定、访问规律性强，预取逻辑能提前把下一层权重搬进显存，隐藏延迟。KV Cache的访问模式更随机，换出后要么丢失上下文，要么随机换入，性能波动更大。
如果项目允许设置不同数据块的换出优先级，建议把KV Cache设为最高优先级，权重设为默认优先级，临时缓冲区设为最低优先级。每次显存不足时，先换出临时缓冲区，再换权重，最后才动KV Cache。
6.3 预取窗口大小与带宽竞争平衡
预取窗口越大，隐藏延迟的效果越好，但同时会挤占正常推理的PCIe带宽。
我建议从窗口大小等于模型2到3层权重的容量开始调。举例来说，如果每层权重约0.5GB，预取窗口1GB到1.5GB是一个合理的起点。在这个范围内，逐渐加大预取窗口并观察推理速度变化，找到拐点。
判断拐点有个简便方法：查看PCIe的总线占用率。如果预取窗口加大后，单token生成时间没有明显下降，但总线占用已经接近80%，说明带宽竞争已经抵消了预取收益，这时候就该把窗口往回缩。
6.4 针对不同任务的参数组合建议
不同的模型和任务，调优参数组合差异很大。根据我的实际经验，整理了一张常用组合表，可以当作起点，微调后再用：
| 场景 | 显存池大小 | 预取窗口 | 换出策略 | 磁盘交换 |
|---|---|---|---|---|
| 14B INT4量化学术问答 | 11GB原生 + 8GB虚拟 | 一层半权重 | 优先换出临时缓冲区 | 关闭 |
| 13B INT8长文档摘要 | 11GB原生 + 12GB虚拟 | 两层权重 | 优先换出旧KV | 开启，SSD路径 |
| 7B INT4实时对话 | 不开启虚拟显存 | 无 | 无 | 关闭 |
| 30B INT4离线批处理 | 11GB原生 + 24GB虚拟 | 三层权重 | 优先换出权重 | 开启，但确保内存充足 |
| 代码补全实时推理 | 11GB原生 + 6GB虚拟 | 半层权重 | 优先换出临时缓冲区 | 关闭 |
这组参数的核心思路是：实时交互场景尽量少用虚拟显存，离线任务可以大胆开；上下文增长越快的任务，越要保留KV Cache；磁盘交换是最后的兜底手段，一旦启用就要意识到性能已经进入“慢但能跑”的模式。
6.5 用日志和监控定位瓶颈
不要凭感觉调优。这类项目通常在启用时会输出详细日志，包括每次换入换出的数据量、耗时、触发原因。把这些信息收集起来，就能看出性能瓶颈到底出在换入太频繁、预取不够、还是系统内存不足导致的磁盘交换。
Linux下的监控工具组合很简单：nvidia-smi看显存和GPU利用率，htop看CPU和内存，iostat看磁盘I/O。我通常会在一个终端跑watch -n 1 nvidia-smi，另一个终端看项目日志，跑一轮推理后对比分析。
如果发现GPU利用率长期低于50%，而日志显示换入换出耗时占比很高，问题出在预取不够或换出策略不当。如果GPU利用率和换入换出占比都不高，但单token生成时间仍然很长，问题可能出在模型本身的batch推理效率上，和虚拟显存关系就不大了。
7. 踩坑实录：这些坑我替你先踩了
7.1 别把虚拟显存池设得比系统内存大
这条是最容易犯的错。我早期测试时把虚拟显存池设了48GB，机器系统内存才32GB，结果模型加载到一半，整个系统开始疯狂交换，鼠标都开始卡顿。后来想通了，虚拟显存池的总量不是拍脑袋定的，它是模型权重、KV Cache和系统内存三者博弈的结果。
一个比较稳妥的计算方式：虚拟显存池大小 = 系统内存总量 × 0.6 - 操作系统预留量。32GB内存的机器，虚拟显存池上限约18GB；64GB内存的机器，上限约38GB。这样做能保证操作系统和模型进程本身还有充足的物理内存，不至于陷入双重交换的泥潭。
7.2 磁盘交换文件的放置位置很讲究
如果必须要开磁盘交换，交换文件的位置不要放在系统盘。系统盘通常还要承担操作系统写日志、进程I/O等任务，交换文件的读写会加剧IO竞争。放在独立SSD上是更好的选择，而且尽量保证空闲空间充足。
用Linux的fallocate命令预分配一个固定大小的交换文件，比让它动态增长要稳定得多。动态增长会在关键时刻触发文件系统分配逻辑，造成不可预期的卡顿。
另外，我从来不用机械硬盘做交换目标。机械硬盘顺序读写勉强能用，但虚拟显存模式的访问模式是随机读为主，机械硬盘的随机I/O性能简直灾难。SSD是底线，NVMe更好。
7.3 关掉一些图形界面的多余特效
这个坑比较偏门，但确实会实质影响性能。如果跑模型的机器同时装了桌面环境，尽量把桌面特效、动画、视频硬解之类的功能关掉。这些功能本身也会调用显卡资源，和虚拟显存的换入换出争夺显存空间和PCIe带宽。
部署环境干净到只有命令行是理想状态。如果是开发机，建议模型推理用独立的虚拟终端跑，别开着浏览器视频通话的同时跑大模型任务。我实测过，桌面环境下模型推理速度比纯命令行环境慢了差不多20%，这个差距完全可以通过环境清理拿回来。
7.4 版本锁定是救命稻草
开源项目迭代快，新版本可能修复bug，也可能引入新的问题。我的做法是：稳定跑通的版本，锁死不升级；只有出现明确的功能需求或bug需要修，才考虑升级，并且升级前一定备份当前可用的配置和版本号。
我在一次升级后就遇到过换出策略行为大变的问题，之前正常的推理场景突然开始频繁触发磁盘交换，性能大幅退化。回滚到旧版本后一切正常。所以，别追求“永远最新”，稳定最重要。
8. 这套技术还能往哪儿走
显存虚拟化这个方向，当前还属于快速演进期。以我接触到的信息来看，几个方向正在被社区积极尝试。
一是更细粒度的调度算法，不再局限于简单的LRU，而是结合模型计算图来做先知式的换入换出。既然推理过程的计算顺序是确定的，理论上换入序列也可以提前规划，做到完全隐藏延迟。已经有项目在朝这个方向探索，效果取决于计算图解析的深度。
二是异构存储的更深度融合。系统内存容量大但带宽中等，磁盘容量大但速度慢，如果把冷热数据按照“热数据驻留显存、温数据驻留内存、冷数据驻留磁盘”的分层思想组织，配合高效的分层调度，能让虚拟显存池的容量上限提升到接近磁盘容量级别。这个方向对长文档处理、超长上下文的场景特别有吸引力。
三是与分布式推理框架的集成。当前分布式推理通常是显存不足时通过多机多卡解决，但如果每一张卡还能再叠加虚拟显存，等于每张卡的可承载模型规模又上了一个台阶。这种混布模式带来的调度复杂度会高不少，但想象空间也大——单机双卡，配合虚拟显存，跑一个原本需要四卡或八卡才能放下的模型，会成为现实。
就我个人的使用体验来说，这个方向最让人兴奋的一点是它的“用时间换空间”哲学，非常契合预算有限但又想体验大模型的用户群体。你不必为了跑一个14B模型去购置新显卡——只要机器有足够的内存，老卡照样能扛起这份工作负载。算力的天花板还在，但对于“能不能跑起来”这个问题，这些项目已经给出了另一种答案。
