1. 一个反直觉的显存占用现象第一次遇到这个问题是在一台 Windows 工作站上调试视频处理管线。显卡是 24GB 显存的消费级卡模型权重加载完还剩十几个 G按理说绰绰有余。结果程序跑到某个阶段直接抛cudaErrorMemoryAllocation用nvidia-smi一看显存几乎被吃满。排查了半天最后定位到一行看起来人畜无害的代码cudaMallocHost。这件事的诡异之处在于cudaMallocHost分配的是主机端锁页内存pinned memory顾名思义是系统内存跟显存八竿子打不着。在 Linux 上跑同样的代码显存纹丝不动换到 Windows显存就跟着涨。如果你也在 Windows 上做 CUDA 开发尤其是涉及大块锁页内存、多卡、或者显存本来就紧张的场景这个坑几乎一定会踩到。这篇就把这个现象的来龙去脉、验证方法、规避手段讲透不管你是刚接触 CUDA 的新手还是做了几年异构计算的老手都能从中拿到可以直接用的结论。先把结论摆前面在 Windows 的 WDDM 驱动模型下锁页内存会被映射进 GPU 的地址空间从而占用显存配额。这不是 bug是驱动模型决定的必然行为。理解这一点后面所有的现象都能解释通。2. WDDM 驱动模型理解一切的起点2.1 WDDM 和 TCC 到底差在哪要讲清楚为什么 Windows 上锁页内存会吃显存必须先说清楚 Windows 显卡驱动的两套模型WDDMWindows Display Driver Model和TCCTesla Compute Cluster。WDDM 是 Windows 面向图形显示的驱动模型从 Vista 开始成为默认。它的核心设计目标是多任务图形显示多个进程共享 GPU桌面合成、视频播放、游戏渲染、计算任务要和平共处还要保证系统在显卡驱动崩溃时能恢复而不蓝屏。为了实现这些目标WDDM 引入了一套复杂的显存虚拟化与分页机制。TCC 则是 NVIDIA 面向纯计算场景的驱动模式主要用在数据中心卡如 A100、H100上。TCC 模式下 GPU 不参与图形显示驱动行为更接近 Linux 上的做法显存管理更直给。关键差异在于WDDM 下GPU 的显存不是一块独占的物理内存而是被操作系统统一调度的一种可分页资源。每个进程能用的显存有配额超了就会被换出到系统内存。这套机制对图形应用很友好但对计算任务来说就带来了很多反直觉的行为。2.2 显存虚拟化带来的连锁反应WDDM 的显存虚拟化大致是这样工作的GPU 访问的地址是虚拟地址由 GPU 的 MMU 翻译成物理显存地址。当物理显存不够时驱动可以把一部分页换出到系统内存等需要时再换回来。这套机制和 CPU 的虚拟内存几乎是一个思路。问题就出在这里。为了让 GPU 能直接访问主机内存比如锁页内存做 DMA 传输驱动需要把这些主机内存页登记到 GPU 的地址空间里建立映射关系。在 WDDM 下这种映射不是零成本的——它需要在 GPU 的页表里占位而 GPU 页表本身、以及映射所涉及的资源都算在进程的显存配额里。换句话说你调用cudaMallocHost分配一块锁页内存驱动为了让 GPU 能高效访问它会在显存侧建立对应的映射结构。这块映射占用的显存就是你在nvidia-smi里看到的凭空消失的那部分。2.3 为什么 Linux 上没这个问题Linux 用的是 NVIDIA 自己的内核驱动显存管理模型和 WDDM 完全不同。在 Linux 上锁页内存的映射走的是另一套机制比如通过 IOMMU 或者直接的 DMA 映射不需要在显存里占配额。所以同样的代码Linux 上nvidia-smi显示的显存占用几乎不变Windows 上却蹭蹭往上涨。这也解释了为什么很多在 Linux 上开发、部署的 CUDA 程序移植到 Windows 后会莫名其妙地 OOM。开发者往往只盯着模型权重和中间激活值算显存完全没把锁页内存算进去。3. 复现与量化到底吃多少显存3.1 一个最小复现实验光讲原理不够得能复现。下面这段代码可以在 Windows 上直接跑观察cudaMallocHost对显存的影响#include cuda_runtime.h #include cstdio #include unistd.h // Windows 上用 windows.h Sleep void printMem(const char* tag) { size_t freeMem, totalMem; cudaMemGetInfo(freeMem, totalMem); printf([%s] free%.2f MB, total%.2f MB, used%.2f MB\n, tag, freeMem / 1024.0 / 1024.0, totalMem / 1024.0 / 1024.0, (totalMem - freeMem) / 1024.0 / 1024.0); } int main() { printMem(start); const size_t N 512 * 1024 * 1024; // 512 MB void* hostPtr nullptr; cudaMallocHost(hostPtr, N); printMem(after cudaMallocHost 512MB); cudaFreeHost(hostPtr); printMem(after cudaFreeHost); return 0; }在 Windows 上跑你会看到after cudaMallocHost 512MB那一行的used明显增加增量通常在几十 MB 到上百 MB 之间具体取决于驱动版本和分配大小。在 Linux 上跑这一行几乎不变。注意cudaMemGetInfo返回的是当前进程可见的显存信息在 WDDM 下这个值本身也受驱动调度影响所以观察到的数字会有波动但趋势是明确的。3.2 占用量的经验规律实测下来cudaMallocHost占用的显存和分配的主机内存大小不是 1:1 关系而是有一个基础开销加上按比例增长的部分。大致规律是锁页内存分配量Windows 显存增量经验值Linux 显存增量64 MB约 10-20 MB接近 0256 MB约 30-60 MB接近 0512 MB约 50-100 MB接近 01 GB约 100-200 MB接近 04 GB约 400-800 MB接近 0这个表是经验值不同驱动版本、不同显卡、是否多卡都会有差异。但核心结论是分配越大显存占用越高而且这个占用在cudaFreeHost之前不会释放。3.3 多卡场景下的放大效应如果你的程序用多张卡每张卡都要访问同一块锁页内存比如做数据并行那么这块锁页内存会在每张卡的显存里都建立映射。4 张卡、每张卡映射 200MB加起来就是 800MB 的显存开销。对于显存本来就紧张的多卡推理场景这可能是压垮骆驼的最后一根稻草。我见过一个案例8 卡工作站上跑数据预处理每张卡分到的显存配额本来就不多结果因为一块 2GB 的锁页缓冲区每张卡被吃掉 300 多 MB直接导致 batch size 上不去。后来把锁页内存改成普通内存 分块传输问题才解决。4. 排查这类问题的完整链路4.1 第一步确认是不是锁页内存的锅遇到 Windows 上显存异常占用先别急着怀疑模型或框架。按这个顺序排查用nvidia-smi看整体占用确认是显存真的被吃满还是只是配额问题。在代码里插桩cudaMemGetInfo在关键节点前后打印显存定位是哪一步涨的。搜索代码里的cudaMallocHost、cudaHostAlloc、cudaHostRegister这三个都是锁页内存相关的 API。检查框架层PyTorch 的pin_memoryTrue、TensorFlow 的 pinned memory 选项、各种数据加载器的pin_memory参数底层都会调cudaMallocHost。4.2 第二步区分真占用和配额占用这里有个容易混淆的点WDDM 下nvidia-smi显示的显存占用有一部分是驱动预留和映射开销不完全是你的数据。所以看到显存涨了不一定是你的 tensor 变大了。判断方法用cudaMemGetInfo拿到的free值才是你真正能用的。如果nvidia-smi显示占用高但cudaMemGetInfo的free还很充裕那多半是驱动侧的映射开销不影响你分配。反之如果free明显减少那就是实打实被吃掉了。4.3 第三步用工具确认映射关系Windows 上可以用GPUView或者Windows Performance Analyzer来看 GPU 的内存映射情况。这两个工具能看到每个进程的显存分配、分页活动、以及主机内存到显存的映射。虽然上手有点门槛但对于定位这类看不见的占用非常有用。另一个土办法写个循环逐步增加cudaMallocHost的大小同时记录cudaMemGetInfo的free变化画出曲线。曲线会告诉你占用和分配量的关系也能帮你估算实际项目里需要预留多少显存。5. 规避与优化把显存省回来5.1 方案一能不用锁页内存就不用最直接的办法评估锁页内存是否真的必要。锁页内存的核心价值是加速主机到设备的数据传输DMA 可以直接访问不需要驱动做额外的页锁定。如果你的数据传输不是瓶颈或者传输量不大完全可以用普通内存malloc/new让 CUDA 在传输时自己处理。实测数据对于 1GB 级别的传输锁页内存相比普通内存能快 2-3 倍。但如果你的传输只占整个 pipeline 的 5%这点加速意义不大反而搭进去几百 MB 显存不划算。5.2 方案二分块复用控制峰值如果确实需要锁页内存那就控制它的峰值大小。常见做法是用固定大小的环形缓冲区而不是每次分配新的。比如固定 256MB 的锁页缓冲循环复用。分块传输把大块数据拆成小块每块传输完就复用同一块锁页内存。及时释放cudaFreeHost之后显存映射会释放不要一直持有。这里有个细节cudaFreeHost释放锁页内存后显存映射的释放可能不是立即的驱动会延迟回收。所以如果你在循环里反复分配释放可能会看到显存占用缓慢爬升。解决办法是复用而不是反复分配释放。5.3 方案三用cudaHostRegister替代cudaMallocHostcudaHostRegister可以把已有的普通内存注册成锁页内存它的显存映射行为和cudaMallocHost类似但有一个好处你可以精确控制注册的范围和时机。比如只在传输前后注册传输完立即cudaHostUnregister把映射占用的时间窗口压到最小。void* ptr malloc(size); cudaHostRegister(ptr, size, cudaHostRegisterDefault); // ... 做传输 ... cudaHostUnregister(ptr); free(ptr);5.4 方案四切换到 TCC 模式如果硬件支持如果你的卡支持 TCC 模式一般是数据中心卡切换到 TCC 可以彻底绕开 WDDM 的显存虚拟化锁页内存不再占用显存配额。切换方法是在管理员权限下用nvidia-sminvidia-smi -g 0 -dm 1 # 切换到 TCC nvidia-smi -g 0 -dm 0 # 切换回 WDDM注意切换驱动模式需要重启而且消费级卡GeForce 系列通常不支持 TCC。另外 TCC 模式下 GPU 不能用于图形显示如果你的机器还要接显示器得留一张卡跑 WDDM。5.5 方案五显存预算里预留映射开销如果以上都改不了那就在显存预算里主动预留这部分开销。经验做法是按锁页内存总量的 10%-20% 预留显存。比如你计划用 2GB 锁页内存就在显存预算里多留 200-400MB。这个预留比例不是拍脑袋来的是根据前面那张经验表推出来的。分配量越大比例可以适当降低因为基础开销被摊薄了。6. 几个容易踩的连带坑6.1 PyTorch DataLoader 的 pin_memoryPyTorch 的DataLoader有个pin_memoryTrue选项开了之后每个 batch 的数据会被放进锁页内存。在 Windows 上这会持续占用显存。如果你的 DataLoader 有多个 worker每个 worker 都可能持有锁页内存占用会成倍增加。规避方法在 Windows 上训练时如果显存紧张先把pin_memory关掉试试。如果数据传输确实是瓶颈再考虑开但要相应减小 batch size 或模型规模。6.2 多进程共享锁页内存cudaMallocHost分配的锁页内存默认是进程私有的。如果你用多进程比如 PyTorch 的num_workers 0每个子进程都会独立分配自己的锁页内存显存映射也是独立的。这会导致显存占用随进程数线性增长。如果确实需要多进程共享可以用cudaHostAlloc配合cudaHostAllocMapped标志或者用共享内存 cudaHostRegister。但要注意共享锁页内存在 WDDM 下的映射行为更复杂实测下来不一定省显存。6.3 显存碎片化反复分配释放锁页内存除了映射开销还会导致显存碎片化。WDDM 的显存分配器对碎片比较敏感碎片多了之后即使总空闲显存够也可能分配不出连续的大块。解决办法还是那句话复用别反复分配释放。6.4 驱动版本的影响不同版本的 NVIDIA 驱动对锁页内存的显存映射处理有差异。实测下来较新的驱动比如 5xx 系列之后在映射开销上有所优化但并没有消除。所以升级驱动可能缓解但不能根治。如果你的项目对显存极其敏感建议在目标驱动版本上做一次完整的显存 profiling别照搬别人的经验值。7. 我个人的几条实操建议折腾这个问题断断续续花了不少时间总结几条我觉得最有用的第一在 Windows 上做 CUDA 开发显存预算一定要留余量。别按 Linux 上的经验算Linux 上能跑满的配置Windows 上大概率 OOM。我一般会留 15%-20% 的余量。第二锁页内存能少用就少用能复用就复用。除非数据传输是明确的瓶颈否则普通内存完全够用。真要用就固定一块缓冲区循环用别在循环里反复分配释放。第三排查显存问题时先怀疑锁页内存。这个坑太隐蔽了代码里一行pin_memoryTrue或者一个cudaMallocHost就能让你找半天。养成习惯看到 Windows 上显存异常先 grep 一遍锁页内存相关的 API。第四多卡场景要按卡数乘算。一块锁页内存在 N 张卡上映射开销就是 N 倍。做多卡规划时这部分一定要算进去。最后说个观察这个问题在社区里讨论得不多很多人遇到了也不知道原因以为是驱动 bug 或者显存泄漏。其实它是 WDDM 设计使然理解了机制应对起来就有章法了。如果你正在 Windows 上做显存敏感的开发希望这篇能帮你少走点弯路。
