1. 一个反直觉的显存占用现象第一次在 Windows 上看到这个现象的时候我盯着任务管理器看了很久怀疑是不是自己看错了。代码里明明调用的是cudaMallocHost顾名思义分配的是主机端内存Host Memory也就是我们常说的锁页内存Pinned Memory。结果一跑起来显卡的专用显存占用蹭蹭往上涨8G 的卡直接吃掉一大块模型还没开始推理显存先没了一半。如果你是从 Linux 环境迁移到 Windows 做 CUDA 开发的这个坑几乎躲不掉。在 Linux 上cudaMallocHost分配的就是实打实的系统内存跟显存八竿子打不着。但在 Windows 上同样的代码同样的 API行为却完全不一样。这不是 bug也不是驱动抽风而是 Windows 图形驱动模型WDDM在背后做的一套内存管理机制在起作用。这篇文章就是把这个现象彻底讲清楚。我会从 WDDM 和 TCC 两种驱动模式的差异讲起解释为什么cudaMallocHost在 Windows 上会吃显存然后给出几种实测有效的规避方案最后附上排查这类问题的思路和工具。内容适合所有在 Windows 上跑 CUDA 程序、做深度学习推理或训练、以及被显存莫名其妙占用困扰的开发者。不管你是刚接触 CUDA 的新手还是从 Linux 转过来的老手这篇应该都能帮你省下几个小时的排查时间。2. WDDM 与 TCC两种驱动模式的本质差异2.1 为什么 Windows 上的 CUDA 行为和 Linux 不一样要理解cudaMallocHost吃显存这件事必须先搞清楚 Windows 和 Linux 在显卡驱动架构上的根本区别。Linux 下 NVIDIA 显卡可以运行在 TCC 模式Tesla Compute Cluster这个模式下显卡完全作为计算设备使用不参与图形显示驱动对内存的管理非常直接主机内存就是主机内存显存就是显存两者边界清晰。Windows 则不同。Windows 的显示驱动模型叫 WDDMWindows Display Driver Model从 Vista 开始引入一直沿用至今。在 WDDM 模式下显卡首先是一个图形设备其次才是一个计算设备。所有的显存分配、内存映射、资源调度都要经过 Windows 的图形内核子系统Dxgkrnl来管理。NVIDIA 的驱动在 WDDM 下必须遵守微软制定的这套规则不能像 Linux 那样直接操作硬件内存。这个差异带来的直接后果就是在 WDDM 模式下任何被 GPU 访问的内存包括锁页内存都需要在显存地址空间中建立映射关系。而建立映射本身就会消耗显存资源。这就是cudaMallocHost吃显存的根源。2.2 WDDM 的内存管理机制拆解WDDM 下显存的管理可以类比成一个虚拟内存系统。系统会把物理显存、系统内存、甚至硬盘上的页面文件统一编址形成一个大的虚拟地址空间。当 GPU 需要访问某块内存时驱动会确保这块内存被映射到 GPU 可以访问的地址上。对于cudaMallocHost分配的锁页内存情况是这样的这块内存物理上确实在系统 RAM 里但因为它要被 GPU 直接访问比如作为 DMA 传输的源或目标WDDM 驱动需要在显存地址空间中为它保留一段映射。这段映射本身占用的显存不多但问题在于 WDDM 的显存管理器会为这类映射预留额外的开销包括页表、映射结构、以及为了性能而做的预分配。实测数据很能说明问题。在一张 8G 显存的卡上用cudaMallocHost分配 1GB 锁页内存任务管理器里看到的专用显存占用会增加大约 1GB 到 1.2GB。也就是说映射开销大约是分配量的 1 到 1.2 倍。如果你分配 4GB 锁页内存显存直接少掉 4G 多模型根本加载不进去。注意这个比例不是固定的跟驱动版本、Windows 版本、显卡型号都有关系。有的环境下开销更大有的稍小但趋势是一致的——分配越多显存吃得越多。2.3 TCC 模式为什么没有这个问题TCC 模式下显卡不参与图形显示驱动可以绕过 WDDM 的那套图形内存管理机制直接管理显存和主机内存之间的映射。cudaMallocHost分配的内存就是纯粹的主机内存GPU 通过 PCIe 总线直接访问不需要在显存里建立额外的映射结构。所以 TCC 模式下锁页内存的分配对显存占用几乎没有影响。这也是为什么很多做深度学习的人会建议在 Windows 上把计算卡切到 TCC 模式。但 TCC 模式有几个限制不是所有显卡都支持GeForce 系列基本都不支持 TCC只有 Tesla、Quadro部分、以及一些专业卡才支持。而且切到 TCC 后显卡就不能用来接显示器了必须用核显或者另一张卡来显示。对于大多数用单张 GeForce 卡在 Windows 上跑模型的用户来说TCC 这条路走不通。3. cudaMallocHost 吃显存的完整链路3.1 从 API 调用到显存占用的每一步当你调用cudaMallocHost时背后发生了一系列事情。在 Linux TCC 模式下流程很简单CUDA 运行时向操作系统申请锁页内存操作系统锁定这些页面防止被换出然后返回虚拟地址。GPU 通过 PCIe 访问这些页面时IOMMU 负责地址转换不需要显存参与。在 Windows WDDM 模式下流程复杂得多。CUDA 运行时首先向 WDDM 驱动请求分配锁页内存WDDM 驱动在系统内存中分配物理页面并锁定。然后关键的一步来了WDDM 驱动需要在 GPU 的虚拟地址空间中为这些页面建立映射以便 GPU 能够访问。这个映射过程需要在显存中创建页表项和相关的管理结构。更麻烦的是WDDM 的显存管理器会把这些映射计入进程的显存配额导致任务管理器里看到的专用显存占用增加。还有一个容易被忽略的点WDDM 下显存是分段的segmented有专用显存段和系统内存段。锁页内存的映射可能被放在系统内存段但管理这些映射的元数据仍然占用专用显存。而且当显存紧张时WDDM 会把一些资源换出到系统内存这个换入换出的过程也会产生额外的显存开销。3.2 为什么任务管理器看到的和 nvidia-smi 不一样这里有个很迷惑人的地方任务管理器里显示的显存占用和nvidia-smi显示的往往对不上。任务管理器显示的是 WDDM 层面的显存使用包括专用显存和共享显存。而nvidia-smi显示的是 GPU 实际使用的显存更接近硬件层面的数字。cudaMallocHost导致的显存占用增加在任务管理器里看得很明显但在nvidia-smi里可能只增加了一点点甚至看不出来。这是因为 WDDM 的映射开销主要记在图形子系统的账上而不是 CUDA 的账上。所以如果你只用nvidia-smi监控可能会漏掉这个问题。我自己的排查习惯是同时开任务管理器的性能标签页和nvidia-smi对比两者的差异。如果任务管理器里显存占用高但nvidia-smi里不高那基本就是 WDDM 的映射开销在作怪。3.3 不同驱动版本的行为差异NVIDIA 的驱动在不同版本对 WDDM 锁页内存映射的处理策略有变化。早期的一些驱动版本会为每个锁页内存分配建立独立的映射开销很大。后来的驱动做了一些优化比如合并映射、延迟分配等开销有所降低但并没有完全消除。我实测过几个驱动版本在 8G 卡上分配 2GB 锁页内存显存占用增加从 1.5GB 到 2.5GB 不等。新驱动确实好一些但如果你显存本来就紧张这点差异可能就是能不能跑起来模型的关键。实操心得如果你必须在 Windows 上用锁页内存尽量升级到较新的驱动版本。NVIDIA 在 5xx 系列之后的驱动对 WDDM 内存管理做了不少优化虽然不能根治但能缓解。4. 实测有效的规避方案4.1 方案一用 cudaMalloc 替代 cudaMallocHost最直接的规避方法就是不用cudaMallocHost改用普通的cudaMalloc分配设备内存或者用malloc分配普通主机内存然后通过cudaMemcpy传输。普通主机内存不会被 GPU 直接访问所以不需要在显存里建立映射也就不会吃显存。代价是传输性能会下降。锁页内存之所以存在就是为了提高主机和设备之间的传输带宽。用普通内存的话传输时需要先拷贝到驱动内部的锁页缓冲区多了一次拷贝带宽可能下降 30% 到 50%。但对于显存紧张的场景这个代价是值得的。具体怎么改把代码里所有的cudaMallocHost替换成malloc然后在cudaMemcpy之后手动free。如果原来用cudaFreeHost释放改成free就行。注意cudaMemcpy对普通内存是同步的如果需要异步传输得用cudaMemcpyAsync配合流但普通内存的异步传输实际上还是同步的因为驱动需要先拷贝到锁页缓冲区。4.2 方案二控制锁页内存的分配量如果非用锁页内存不可那就严格控制分配量。我的经验是在 8G 显存的卡上锁页内存分配不要超过 512MB。超过这个数显存占用就会明显影响模型加载。具体做法是把大的锁页内存分配拆成小块用完就释放不要一直占着。比如做数据预处理时用一个小的锁页缓冲区循环使用而不是一次性分配一大块。这样虽然映射开销仍然存在但因为分配量小总开销可控。还有一个技巧是用cudaHostAlloc代替cudaMallocHost并指定cudaHostAllocWriteCombined标志。写合并内存的映射开销比普通锁页内存小一些但只适合写入场景读取性能会差很多。如果你的数据主要是从主机传到设备可以试试这个标志。4.3 方案三用固定内存池管理如果你的程序需要频繁分配释放锁页内存建议自己实现一个固定大小的内存池。预先分配一小块锁页内存然后在这个池子里做分配和回收避免频繁调用cudaMallocHost和cudaFreeHost。这样做的好处是映射只需要建立一次后续复用不会产生新的映射开销。而且内存池的大小可以精确控制不会出现意外的大块分配。实现起来也不复杂一个简单的空闲链表就够了。class PinnedMemoryPool { char* base; size_t total_size; size_t used; public: PinnedMemoryPool(size_t size) : total_size(size), used(0) { cudaMallocHost(base, size); } void* allocate(size_t n) { if (used n total_size) return nullptr; void* ptr base used; used n; return ptr; } void reset() { used 0; } ~PinnedMemoryPool() { cudaFreeHost(base); } };这个池子的大小建议控制在 256MB 到 512MB 之间根据你的显存余量调整。如果显存特别紧张可以降到 128MB。4.4 方案四切换到 TCC 模式如果硬件支持如果你的显卡支持 TCC 模式这是最彻底的解决方案。切到 TCC 后cudaMallocHost的行为就和 Linux 一样了不再吃显存。但前面说过GeForce 系列不支持 TCC只有专业卡才行。检查你的卡是否支持 TCC可以用nvidia-smi -q | findstr TCC看看。如果显示支持可以用nvidia-smi -g 0 -dm 1切换到 TCC 模式需要管理员权限切换后要重启。切回 WDDM 用nvidia-smi -g 0 -dm 0。注意切换到 TCC 后这张卡就不能用来显示输出了。如果你只有一张卡切过去之后屏幕会黑掉需要用核显或者另一张卡来显示。而且 TCC 模式下有些图形相关的 CUDA 功能会不可用比如 OpenGL 互操作。4.5 方案对比与选择建议方案显存节省效果性能影响适用场景实施难度用 malloc 替代完全消除传输带宽下降 30-50%显存极度紧张低控制分配量部分缓解几乎无影响显存中等紧张低内存池管理部分缓解几乎无影响频繁分配释放中切换 TCC完全消除无影响专业卡且不需显示中我的建议是先试方案二和方案三这两个对性能影响最小实施也简单。如果显存还是不够再考虑方案一。方案四只在特定硬件上可行不作为通用方案。5. 排查与监控的实操技巧5.1 怎么确认是 cudaMallocHost 导致的显存占用排查这个问题第一步是确认显存占用确实来自锁页内存。方法很简单在调用cudaMallocHost前后分别记录显存占用看差值。用cudaMemGetInfo可以获取当前显存空闲量size_t free_before, total; cudaMemGetInfo(free_before, total); cudaMallocHost(ptr, size); size_t free_after; cudaMemGetInfo(free_after, total); printf(显存减少: %zu MB\n, (free_before - free_after) / 1024 / 1024);如果减少的量接近分配量那就确认是这个问题了。注意cudaMemGetInfo返回的是 CUDA 层面的显存信息可能不包含 WDDM 的映射开销所以最好同时用任务管理器观察。5.2 用任务管理器看 WDDM 显存占用任务管理器的性能标签页选 GPU可以看到“专用 GPU 内存”和“共享 GPU 内存”两个指标。cudaMallocHost导致的占用通常体现在专用 GPU 内存上但有时也会影响共享内存。更详细的查看可以用性能监视器perfmon添加 GPU 相关的计数器。或者用 GPU-Z 这个工具它能显示更详细的显存使用情况包括 WDDM 管理的部分。我常用的组合是任务管理器看总体趋势GPU-Z 看细节nvidia-smi看 CUDA 层面的占用。三个工具对比着看基本能定位问题。5.3 常见误判与排除有时候显存占用增加不一定是cudaMallocHost导致的可能是其他原因。比如 CUDA 上下文本身的显存开销一般在 200MB 到 500MB 之间这是正常的。还有 cuDNN、cuBLAS 等库的初始化也会占显存。排除方法先跑一个最小的 CUDA 程序只初始化上下文看显存占用。然后逐步加入你的代码看哪一步导致显存跳变。如果加入cudaMallocHost后跳变明显那就是它的问题。还有一个容易误判的情况Windows 的桌面合成器DWM本身会占用一部分显存特别是多显示器或者高分辨率下。这部分占用是动态的可能会干扰判断。建议在排查时关闭其他图形密集型程序。6. 常见问题速查问题一为什么 Linux 上没问题Windows 上就有答Linux 下 NVIDIA 驱动可以运行在 TCC 模式绕过 WDDM 的图形内存管理。Windows 下 GeForce 卡只能跑 WDDM锁页内存需要在显存中建立映射所以吃显存。问题二用 cudaMallocHost 分配 100MB显存少了 150MB正常吗答正常。WDDM 的映射开销通常是分配量的 1 到 1.5 倍具体取决于驱动版本和系统状态。分配量越大比例可能越高。问题三升级驱动能解决吗答能缓解不能根治。新驱动对映射管理做了优化开销会小一些但只要在 WDDM 下这个问题就存在。问题四用 cudaHostAlloc 代替 cudaMallocHost 有用吗答有一点用但有限。cudaHostAlloc可以指定不同的标志比如cudaHostAllocWriteCombined的映射开销小一些但只适合写入场景。根本的解决方案还是控制分配量或者换 TCC。问题五显存不够模型加载不进去怎么办答先检查有没有用cudaMallocHost如果有改成malloc或者减小分配量。然后检查 CUDA 上下文和库的占用看有没有优化空间。最后考虑用量化、模型切分等方法降低显存需求。问题六任务管理器显示显存满了但 nvidia-smi 显示还有空余信哪个答两个都信但含义不同。任务管理器显示的是 WDDM 层面的占用包括映射开销和共享内存。nvidia-smi显示的是 GPU 实际使用的显存。如果任务管理器满了但 nvidia-smi 没满说明有 WDDM 开销实际 CUDA 程序可能还能跑但余量不多了。问题七怎么查看当前显卡是不是 WDDM 模式答用nvidia-smi -q | findstr Driver Model或者直接看nvidia-smi输出里的 “Driver Model” 字段。显示 WDDM 就是 WDDM 模式显示 TCC 就是 TCC 模式。问题八TCC 模式下能用显示器吗答不能。TCC 模式下显卡不参与图形显示必须用核显或者另一张卡来显示。如果你只有一张卡切到 TCC 后屏幕会黑需要提前准备好远程访问或者另一张显示卡。问题九锁页内存分配后不释放会一直占显存吗答是的。只要不调用cudaFreeHost映射就一直存在显存就一直被占着。所以用完一定要及时释放或者用内存池管理。问题十有没有工具能直接看到 WDDM 的映射开销答GPU-Z 可以看到比较详细的显存使用包括 WDDM 管理的部分。Windows 的性能监视器也可以添加 GPU 计数器。但没有工具能直接告诉你“这是 cudaMallocHost 的映射开销”需要自己对比分析。7. 我踩过的坑和最后的小技巧这个坑我踩过不止一次。最早是在做一个视频处理的项目需要在主机和设备之间频繁传输帧数据。为了追求带宽用了大块的锁页内存结果模型加载的时候直接 OOM。当时以为是模型太大换了小模型还是不行最后用cudaMemGetInfo一步步排查才发现是锁页内存把显存吃掉了。后来我养成了一个习惯在 Windows 上做 CUDA 开发锁页内存的分配量永远控制在 256MB 以内。如果确实需要大块传输就用普通内存加多线程流水线用时间换空间。实测下来虽然单次传输慢了但整体吞吐量因为流水线的原因并没有下降太多而显存占用完全可控。还有一个技巧如果你用的是 PyTorch 或 TensorFlow 这类框架它们内部可能会用锁页内存来做数据加载。PyTorch 的DataLoader有个pin_memory参数设为True就会用锁页内存。在 Windows 上显存紧张的时候把这个参数设为False能省下不少显存。代价是数据加载速度慢一点但比起 OOM 跑不起来这点代价完全可以接受。最后分享一个快速检查的方法在代码开头加一行环境变量CUDA_LAUNCH_BLOCKING1让 CUDA 调用同步执行这样出错时能准确定位到是哪一行代码导致的。虽然会慢一些但排查问题时非常有用。定位到问题后再去掉这个变量就行。这个问题的本质是 Windows 图形子系统和 CUDA 计算子系统之间的耦合。只要在 WDDM 模式下这种耦合就存在我们只能通过各种手段去规避和缓解。理解了这个本质遇到类似的问题就能举一反三比如为什么 Windows 上显存碎片化更严重、为什么有些 CUDA 程序在 Windows 上性能差一截背后都有 WDDM 的影子。
