1. 一个反直觉的显存占用现象
如果你在 Windows 上做 CUDA 开发，尤其是涉及深度学习推理、视频处理或者高性能计算，大概率写过或者见过cudaMallocHost这个 API。它的官方定位很清晰：分配页锁定内存（Pinned Memory），也叫锁页内存，用于加速主机与设备之间的数据传输。按照 CUDA 文档的说法，这块内存属于主机端，跟显存是两码事。
但我第一次在 Windows 上遇到这个问题的场景是这样的：手头一张 8GB 显存的卡，模型本身权重加载完占了大概 5.2GB，按道理还剩 2.8GB 的余量。结果程序跑起来，cudaMallocHost分配了大概 1GB 的锁页内存之后，nvidia-smi一看，显存占用直接飙到了 7.6GB，剩下的余量连分配一个中等大小的中间张量都不够，程序直接报out of memory。
这就很离谱了。锁页内存不是应该在主机内存里吗？怎么跑到显存里去了？
后来我花了不少时间排查，翻了不少资料，也做了大量实测，才把这件事的来龙去脉搞清楚。这个现象不是 CUDA 的 bug，也不是显卡驱动的问题，而是 Windows 显示驱动模型（WDDM）下的一种正常但容易被忽视的行为。这篇文章就把我踩过的坑、排查的思路、背后的原理以及应对方案完整地梳理一遍，适合所有在 Windows 上做 CUDA 开发的朋友参考，尤其是那些显存本来就紧张、还在纳闷"为什么我明明没分配显存，显存就没了"的同学。
2. 先搞清楚 cudaMallocHost 到底做了什么
2.1 页锁定内存的基本概念
要理解这个问题，得先从cudaMallocHost本身说起。
普通的内存分配，比如malloc或者new，拿到的是可分页内存（Pageable Memory）。操作系统可以把这些内存页换出到磁盘上的页面文件里，也可以在不同物理页之间迁移。这种灵活性对操作系统来说很好，但对 GPU 来说就很麻烦。
原因在于，GPU 通过 DMA（直接内存访问）来读写主机内存时，需要的是物理地址连续、不会被操作系统随意挪动的内存。如果内存页是可分页的，CUDA 驱动在传输数据之前，必须先让操作系统把相关页面锁定住（pin 住），传输完成后再解锁。这个锁定和解锁的过程本身有开销，而且如果页面恰好被换出到磁盘了，还得先读回来，延迟就更大了。
cudaMallocHost分配的页锁定内存就解决了这个问题。它直接向操作系统申请一块不会被换出的物理内存，GPU 可以直接通过 DMA 访问，省去了锁定/解锁的开销，传输带宽也更高。这就是为什么在需要频繁进行主机-设备数据传输的场景下，大家都会用锁页内存。
2.2 官方文档没说清楚的那部分
CUDA 官方文档对cudaMallocHost的描述大致是：分配主机端页锁定内存，可以被设备直接访问，带宽高，但分配和释放的开销较大，且过量分配会影响系统性能。
注意最后那句话——"过量分配会影响系统性能"。文档只是笼统地提了一句，并没有展开说在 Windows 上具体会发生什么。而在 Linux 上，cudaMallocHost分配的内存确实就是实打实的主机物理内存，nvidia-smi里的显存占用不会有明显变化。
但在 Windows 上，情况就完全不一样了。
2.3 Windows 上的实际行为差异
在 Windows 的 WDDM 驱动模型下，GPU 的内存管理跟 Linux 有本质区别。Linux 上 NVIDIA 驱动可以直接管理显存，而 Windows 上，显存的管理要经过操作系统的图形内核子系统。WDDM 引入了一套自己的内存管理机制，其中有一个关键概念叫"内存预算"（Memory Budget）。
当你调用cudaMallocHost时，CUDA 运行时在 Windows 上会通过 WDDM 的接口来分配锁页内存。WDDM 为了优化 GPU 对这块内存的访问，会把这块内存同时映射到 GPU 的地址空间里。也就是说，这块内存在物理上属于主机内存，但在 GPU 的虚拟地址空间中占了一个映射。而这个映射，在nvidia-smi看来，就变成了显存占用。
更准确地说，WDDM 会把这块锁页内存纳入 GPU 的内存预算体系。虽然数据实际存在主机内存里，但 GPU 访问它的时候，需要通过 WDDM 的映射机制，这个映射会占用一部分 GPU 虚拟地址空间和相关的管理资源。在某些情况下，WDDM 甚至会把这部分内存当作"可以被 GPU 驱逐"的资源来管理，导致显存预算被进一步压缩。
3. 用实验数据说话：到底吃了多少显存
3.1 测试环境与方案设计
光讲原理不够直观，我设计了一组对比实验来量化这个问题。
测试环境如下：
| 项目 | 配置 |
|---|---|
| 操作系统 | Windows 11 专业版 23H2 |
| 显卡 | NVIDIA RTX 4060 Ti 8GB |
| 驱动版本 | 551.86 |
| CUDA 版本 | 12.4 |
| 主机内存 | 32GB DDR5 |
测试方案很简单：写一个 CUDA 程序，先查询初始显存占用，然后分别用cudaMallocHost和malloc分配不同大小的内存，每次分配后查询显存占用，记录变化。
3.2 不同分配大小下的显存变化
先看cudaMallocHost的结果：
| 分配大小 | nvidia-smi 显存占用变化 |
|---|---|
| 128MB | +约 130MB |
| 256MB | +约 260MB |
| 512MB | +约 520MB |
| 1GB | +约 1.05GB |
| 2GB | +约 2.1GB |
可以看到，cudaMallocHost分配的锁页内存，几乎是以 1:1 的比例反映到了nvidia-smi的显存占用上。分配 2GB 锁页内存，显存就少了 2GB 多。
再看malloc的对照组：
| 分配大小 | nvidia-smi 显存占用变化 |
|---|---|
| 128MB | 无明显变化 |
| 512MB | 无明显变化 |
| 1GB | 无明显变化 |
| 2GB | 无明显变化 |
普通malloc分配的内存，对显存占用没有任何影响。这验证了问题确实出在cudaMallocHost的页锁定机制上。
3.3 释放后显存是否归还
还有一个关键问题：调用cudaFreeHost释放之后，显存会不会还回来？
实测结果是：会还回来，但不是立即的。释放之后，nvidia-smi的显存占用不会马上下降，而是会延迟几秒到几十秒不等。这是因为 WDDM 的内存回收是异步的，需要等 GPU 完成相关的清理工作。如果你在释放后立刻查询显存，可能会误以为内存泄漏了。
注意：如果你的程序需要频繁地分配和释放锁页内存，这种延迟归还的特性可能会导致显存占用在短时间内持续攀升，最终触发 OOM。建议尽量复用已分配的锁页内存，而不是反复分配释放。
4. WDDM 的内存预算机制才是幕后推手
4.1 什么是 WDDM 内存预算
WDDM（Windows Display Driver Model）从 Windows Vista 开始引入，到 Windows 10 之后演变得更加复杂。它的核心目标之一是让多个应用程序能够安全、公平地共享 GPU 资源。
在这个模型下，每个进程都有一个"显存预算"（Video Memory Budget）。这个预算不是简单地等于物理显存大小，而是由操作系统根据当前系统的整体显存使用情况、其他进程的需求、以及一些预留资源来动态计算的。
你可以通过dxdiag或者一些第三方工具查看当前的显存预算。在 8GB 显存的卡上，实际可用的预算往往只有 7GB 出头，因为系统会预留一部分给桌面合成、浏览器硬件加速等用途。
4.2 锁页内存如何挤占显存预算
关键点来了：在 WDDM 下，cudaMallocHost分配的锁页内存会被计入这个显存预算。
为什么？因为 WDDM 需要保证 GPU 能够高效地访问这块内存。为了实现这一点，WDDM 会在 GPU 的虚拟地址空间中为这块内存建立映射，并且可能需要在显存中维护一些页表或者管理结构。虽然数据本身在主机内存里，但这些管理结构和地址空间映射是占用 GPU 资源的。
更麻烦的是，WDDM 会把这块内存标记为"可驱逐"（Evictable）。当显存紧张时，WDDM 会尝试把一些资源从显存中驱逐出去，而锁页内存的映射就是被驱逐的对象之一。驱逐和重新映射的过程会带来性能开销，而且在某些情况下，驱逐失败就会导致分配失败。
4.3 与 Linux 行为的对比
在 Linux 上，NVIDIA 驱动直接管理显存，cudaMallocHost分配的内存就是纯粹的主机内存，不会出现在nvidia-smi的显存占用里。这是因为 Linux 没有 WDDM 这样的中间层，驱动可以更直接地控制内存映射。
这也是为什么很多在 Linux 上跑得好好的代码，移植到 Windows 上就出现显存不足的问题。不是代码写错了，而是两个平台的内存管理模型根本不同。
5. 实际开发中怎么绕开这个坑
5.1 优先使用 cudaMallocManaged 替代
如果你的应用场景允许，可以考虑用cudaMallocManaged来替代cudaMallocHost。统一内存（Unified Memory）在 Windows 上的行为相对更可控一些，虽然它也有自己的开销，但至少不会像cudaMallocHost那样直接吃掉等量的显存预算。
不过要注意，cudaMallocManaged在 Windows 上的性能表现和 Linux 上也有差异，特别是在频繁访问的情况下，页面迁移的开销可能会比较明显。建议在实际使用前做充分的性能测试。
5.2 控制锁页内存的分配量
如果必须用cudaMallocHost，那就要严格控制分配量。我的经验是，在 8GB 显存的卡上，锁页内存的分配量最好不要超过 512MB。如果确实需要更大的缓冲区，可以考虑分块处理，每次只分配一小块，用完就释放，而不是一次性分配一大块。
另外，尽量在程序启动时就把需要的锁页内存分配好，避免在运行过程中动态分配。这样可以让 WDDM 的内存预算计算更加稳定，减少因为预算波动导致的分配失败。
5.3 监控显存预算而不是显存占用
在 Windows 上开发 CUDA 程序，光看nvidia-smi的显存占用是不够的。你还需要关注显存预算的变化。可以通过cudaMemGetInfo来查询当前可用的显存和总显存，但这个接口返回的值在 Windows 上也可能受到 WDDM 预算机制的影响。
更可靠的做法是结合 Windows 的性能计数器或者第三方工具来监控 GPU 的内存预算。这样可以在程序出现 OOM 之前就发现预算不足的趋势，提前做出调整。
5.4 考虑用固定大小的内存池
一个比较实用的方案是自己实现一个锁页内存池。在程序启动时分配一块固定大小的锁页内存，之后所有的数据传输都复用这块内存，而不是每次都调用cudaMallocHost。
这样做的好处有几个：一是避免了频繁分配释放带来的开销；二是锁页内存的总量是固定的，不会在运行过程中动态增长，WDDM 的预算计算更加可预测；三是内存池可以实现更精细的管理，比如按需划分不同大小的缓冲区。
实现内存池的时候要注意对齐问题。CUDA 对锁页内存的对齐有要求，通常需要 4KB 对齐。自己管理内存池的话，要确保每个缓冲区的起始地址都满足对齐要求。
6. 几个容易忽略的细节和排查技巧
6.1 驱动版本的影响
不同版本的 NVIDIA 驱动在 WDDM 内存管理上的行为可能有差异。我实测发现，较新的驱动版本（550 系列之后）在锁页内存的显存占用上做了一些优化，虽然问题依然存在，但占用的比例可能略有不同。
如果你遇到了类似的问题，建议先升级到最新的驱动版本试试。同时也要注意，Windows 系统更新有时会带来 WDDM 版本的升级，也可能影响显存管理的行为。
6.2 多进程场景下的放大效应
如果你的系统上同时运行多个使用 CUDA 的进程，每个进程都分配了锁页内存，那么显存预算的消耗会叠加。在极端情况下，即使每个进程只分配了几百 MB 的锁页内存，加起来也可能把显存预算耗尽。
这种情况下，可以考虑把多个进程的 CUDA 工作合并到一个进程里，或者使用 MPS（Multi-Process Service）来共享 GPU 资源。不过 MPS 在 Windows 上的支持有限，需要确认你的驱动和 CUDA 版本是否支持。
6.3 排查时的常见误区
很多人在遇到显存不足时，第一反应是检查模型大小、batch size、中间张量这些明显的因素。但如果你的代码里用了cudaMallocHost，一定要把它也纳入排查范围。
排查的方法很简单：在代码里把cudaMallocHost的调用暂时替换成malloc，看看显存占用是否恢复正常。如果恢复正常了，那问题就定位到了。然后再根据实际需求，决定是减少锁页内存的用量，还是改用其他方案。
还有一个误区是只看任务管理器的显存数据。Windows 任务管理器显示的显存信息跟nvidia-smi可能不一致，因为它们的统计口径不同。建议以nvidia-smi或者 CUDA 自己的 API 为准。
6.4 一个实用的调试片段
这里分享一个我常用的调试片段，用来快速定位锁页内存对显存的影响：
#include <cuda_runtime.h> #include <cstdio> void printMemInfo(const char* tag) { size_t freeMem, totalMem; cudaMemGetInfo(&freeMem, &totalMem); printf("[%s] Free: %zu MB, Total: %zu MB, Used: %zu MB\n", tag, freeMem / 1024 / 1024, totalMem / 1024 / 1024, (totalMem - freeMem) / 1024 / 1024); } int main() { printMemInfo("Initial"); void* hostPtr = nullptr; cudaMallocHost(&hostPtr, 512 * 1024 * 1024); printMemInfo("After cudaMallocHost 512MB"); cudaFreeHost(hostPtr); printMemInfo("After cudaFreeHost"); return 0; }运行这个程序，你就能直观地看到cudaMallocHost前后显存的变化。如果After cudaMallocHost那一行的 Used 增加了 500MB 左右，那就说明你的环境确实存在这个问题。
7. 从根上理解：为什么 Windows 要这么设计
7.1 WDDM 的设计哲学
WDDM 的核心设计目标是稳定性和安全性。在早期的 Windows 显示驱动模型（XPDM）下，显卡驱动运行在内核态，一个驱动崩溃就可能导致整个系统蓝屏。WDDM 把驱动的一部分移到了用户态，并且引入了更严格的内存管理和资源调度机制。
在这个模型下，GPU 的内存不再是由驱动随意分配的，而是由操作系统的图形内核子系统统一管理。这样做的好处是系统更稳定，不同应用之间的隔离更好。代价就是灵活性降低，一些在 Linux 上很直接的操作，在 Windows 上需要经过更多的中间层。
7.2 锁页内存的特殊性
锁页内存在 WDDM 的框架下是一个比较特殊的存在。它既属于主机内存，又需要被 GPU 高效访问。WDDM 为了兼顾这两点，选择了一种折中方案：把锁页内存纳入 GPU 的内存管理体系，但实际数据仍然存放在主机内存中。
这种折中方案在大多数情况下是合理的，因为锁页内存的用量通常不会太大。但在深度学习等需要大量锁页内存的场景下，问题就暴露出来了。
7.3 未来的可能变化
微软和 NVIDIA 都在持续改进 WDDM 的内存管理机制。从 Windows 11 开始，引入了一些新的 GPU 内存管理特性，比如更精细的内存预算控制和更好的异构内存支持。未来这个问题可能会得到缓解，但在当前阶段，开发者还是需要自己注意。
另外，随着 DirectStorage 等新技术的推广，GPU 和主机内存之间的数据通路也在发生变化。这些变化可能会间接影响锁页内存的管理方式，值得持续关注。
8. 一些实战中的经验补充
8.1 什么时候可以忽略这个问题
如果你的应用场景满足以下条件，那这个问题对你的影响可能不大：
- 显存充足，比如 24GB 以上的卡，锁页内存占用几百 MB 无所谓
- 锁页内存用量很小，比如只用来传输一些控制参数或者小批量数据
- 不需要频繁进行主机-设备数据传输，锁页内存的优势用不上
但如果你的场景是显存紧张、需要大量锁页内存做数据缓冲、或者需要频繁传输数据，那就必须认真对待这个问题。
8.2 跨平台开发的注意事项
如果你的代码需要在 Windows 和 Linux 上都能跑，建议把锁页内存的分配逻辑抽象出来，针对不同平台做不同的处理。比如在 Windows 上限制锁页内存的最大用量，在 Linux 上则可以更宽松一些。
可以通过预处理宏来区分平台：
#ifdef _WIN32 const size_t MAX_PINNED_MEMORY = 256 * 1024 * 1024; // Windows: 256MB #else const size_t MAX_PINNED_MEMORY = 2ULL * 1024 * 1024 * 1024; // Linux: 2GB #endif这样可以在不修改核心逻辑的情况下，适配不同平台的内存管理特性。
8.3 性能与显存的权衡
使用锁页内存的初衷是提升传输性能，但如果因为锁页内存占用了显存，导致模型跑不起来或者 batch size 被迫减小，那就得不偿失了。在实际项目中，需要根据具体情况做权衡。
我的建议是：先保证程序能跑起来，再考虑优化传输性能。如果显存实在紧张，可以先用普通内存跑通流程，然后再逐步把关键路径上的传输改成锁页内存，同时密切监控显存预算的变化。
8.4 一个真实的踩坑案例
最后分享一个我实际遇到的案例。当时在做一个视频处理的项目，需要把每一帧图像从主机传到 GPU 做处理。为了提升传输速度，我用cudaMallocHost分配了一个帧缓冲区，大小是 1920x1080x3 字节，大概 6MB。看起来不大对吧？
但问题是，我在每一帧处理时都重新分配和释放这个缓冲区。结果跑了大概几百帧之后，程序突然报 OOM。用nvidia-smi一看，显存占用比正常情况高了将近 1GB。
原因就是 WDDM 的内存回收是异步的，频繁分配释放导致大量锁页内存的映射还没有被及时清理，累积起来就把显存预算耗尽了。后来改成在程序启动时分配一次，之后一直复用，问题就解决了。
这个案例告诉我们，在 Windows 上使用cudaMallocHost，不仅要控制分配的总量，还要注意分配和释放的频率。复用永远比反复分配释放更安全。
