显存泄漏需先验证真实存在：Windows用IDXGIAdapter3::QueryVideoMemoryInfo、Linux用nvmlDeviceGetMemoryInfo连续采样5–10分钟，确认used持续单向增长且重启回落、无业务触发才属泄漏。
显存泄漏不是普通内存泄漏，得先确认它真存在
GPU 显存泄漏和堆内存泄漏机制完全不同：显存由驱动层统一管理，cudaMalloc 或 vkAllocateMemory 分配的显存不会自动归还给 GPU，必须显式释放；但更常见的情况是“驱动没回收”或“应用没释放句柄”，而非传统意义的“指针丢失”。所以第一步不是跑工具，而是验证是否真泄漏：在 Windows 上用 IDXGIAdapter3::QueryVideoMemoryInfo 查 CurrentUsage，Linux 上用 nvmlDeviceGetMemoryInfo 看 used 字段，连续采样 5–10 分钟，排除瞬时抖动。如果 used 持续单向增长、重启进程后回落、且无对应业务逻辑（如加载新模型/纹理）触发，才值得往下查。
Windows 下定位 CUDA/Vulkan 显存分配点：靠 DXGI + ETW + GPUView
Windows 没有类似 valgrind 的显存追踪器，但可以组合使用三类信息源：
-
IDXGIAdapter3::QueryVideoMemoryInfo只能告诉你“用了多少”，不能告诉你“谁干的”。必须配合 ETW（Event Tracing for Windows）采集 GPU 内存事件：启用Microsoft-Windows-DxgKrnlprovider，过滤DXGK_EVENT_TYPE_ALLOCATE_MEMORY和DXGK_EVENT_TYPE_FREE_MEMORY事件，导出.etl后用GPUView打开，按时间轴看分配/释放是否匹配 - 若用 CUDA，编译时加
-g -lineinfo，运行时用cuda-memcheck --leak-check full ./app，它会报告未配对的cudaMalloc/cudaFree调用栈（注意：仅对 host 端调用有效，不覆盖cuMemAlloc等 driver API） - 常见误判点：
CurrentUsage包含系统保留显存（如桌面合成器占用），不是所有增长都算泄漏；E_NOINTERFACE错误说明驱动不支持 WDDM 2.0+，换驱动或改用 Nsight Graphics
Linux NVIDIA GPU：NVML + cuda-gdb + nvidia-smi -l 1 实时盯住
NVIDIA 是唯一提供稳定用户态显存监控路径的厂商，但 NVML 本身不记录分配栈，需靠交叉验证：
- 用
nvidia-smi -l 1每秒刷新，确认Used是否持续上涨；同时用nvmlDeviceGetMemoryInfo在代码里埋点，把时间戳和used值打到日志，和请求 trace 关联 - 开启 CUDA 上下文调试：设置环境变量
CUDA_LAUNCH_BLOCKING=1让 kernel 同步执行，再用cuda-gdb ./app在疑似分配点（如cudaMalloc返回前）下断点，手动检查cudaGetErrorString返回值，避免因错误码被忽略导致后续cudaFree失败 - 关键陷阱：
nvmlInit()必须在主线程首次调用，多线程反复 init/shutdown 会导致驱动状态混乱；cudaFree对空指针不报错，但若传入非法地址会静默失败——务必检查返回值
跨平台通用兜底法：重载 GPU 分配函数 + 全局计数器
当驱动层工具失效（比如 AMD GPU 或自研驱动），最可靠的方式是侵入代码，接管所有显存入口：
立即学习“C++免费学习笔记（深入）”；
- 对 CUDA：用 weak symbol 替换
cudaMalloc，内部维护一个std::unordered_map<void std::pair int>></void>，键为分配地址，值为__FILE__ + __LINE__，每次分配时插入，cudaFree时删除；程序退出前遍历 map 输出未释放项 - 对 Vulkan：拦截
vkAllocateMemory，在pAllocateInfo->pNext链中注入自定义结构体，存调用栈（用backtrace()）；注意 Vulkan loader 层可能绕过你的 hook，必须确保在vkGetInstanceProcAddr后立即 patch - 性能影响必须考虑：每分配一次就做
backtrace()会拖慢 10 倍以上，线上只开计数器 + 文件行号，调试环境再开完整栈；AMD GPU 可读/sys/class/drm/card*/device/mem_info_vram_used，但该值精度低、更新延迟高，仅作趋势参考
真正难的不是找到泄漏点，而是区分“显存没释放”和“显存不该释放”。很多所谓泄漏其实是设计使然：比如 Vulkan descriptor pool 预分配后长期复用，或 CUDA stream 中 pending 的 memory copy。这类情况需要结合业务语义判断，而不是盲目加 free。
