前阵子帮一个做推荐系统的团队排查线上问题他们的服务稳定跑了两周以后突然开始报CUDA out of memory。排查下来发现task 的 batch size 从 32 调到 64 之后PyTorch 的缓存分配器给每个算子预留了多个 block 的空闲显存没有及时释放双卡部署时空闲 context 占掉的显存直接超过 1.5GB。折腾了一下午最后根子不在 batch size而在显存管理的机制上。这让我决定把这块内容完整地写一遍从虚拟内存的第一性原理到显存分页、页面迁移再到 B300 这种 Blackwell Ultra 时代的新硬件实测把 GPU 显存是怎么被管起来这件事讲透。这篇文章适合做大模型训练、推理部署和 GPU 基础设施运维的读者尤其是被显存碎片化、OOM、多卡负载不均折腾过的人。1. 显存耗尽真的是不够用那么简单吗1.1 三个典型场景背后藏着同一个问题做 GPU 开发的人几乎都遇到过下面这三种情况。第一种模型本身明明不大但一跑训练就 OOM。有人拿 7B 模型在 24GB 显存的卡上微调LoRA 只加了几百 MB 可训练参数理论上完全放得下结果跑到第二个 step 直接爆显存。第二种显存看着剩很多但一加大 batch size 就报错。nvidia-smi显示还有 20GB free你心想加个 batch 从 4 到 8 总行吧结果 CUDA 直接甩你一脸 OOM。第三种多卡并行时显存分布严重不均衡一张卡爆了另外三张还剩下一半空着。这三个场景根子上都不是显存物理容量不够而是显存管理机制在作祟。场景一和二通常和显存分配策略、内存碎片化、预留块没释放有关场景三则涉及到显存访问范围和页面迁移策略。不理解底层机制就容易在表面问题上瞎调参——调大PYTORCH_CUDA_ALLOC_CONF的max_split_size_mb、改 garbage collection threshold、甚至强行换更大的卡。这些操作有时有效但属于碰运气。真正要做的是先搞明白显存从你调用torch.tensor(...).cuda()的那一刻起到底经历了怎样的旅程。1.2 nvidia-smi 的显存数字为什么不可信排查这些问题的第一步是学会看显存监控数据但要先说一个反直觉的结论nvidia-smi显示的显存占用并不能反映你的进程真正用掉了多少显存。nvidia-smi展示的是 CUDA context 向驱动申请的显存总量包括实际存储数据的部分、驱动预留的 context 空间、cuDNN 等库申请的 workspace以及框架缓存分配器持有的空闲块。PyTorch 的缓存分配器思路是从驱动那里一次性多申请一些显存放进自己的内存池算子要用时从池子里拿算子用完了再还回池子。这样避免每次分配都陷入内核态代价就是池子里始终留着一些看着占用、实际空闲的显存。所以你在nvidia-smi里看到进程占了 18GB可能里面有 5GB 都是空闲缓存块。想确认真正在用的显存得看 PyTorch 内部的memory_stats()或者 CUDA 的cuMemGetInfo前者能看到allocated_bytes真正分配给张量的后者能看到当前上下文实际向驱动申请的量。这就引出虚拟内存的第一性原理了——GPU 显存管理并不是直接从物理显存里抠一块给你中间还有一层复杂的地址翻译和映射机制。2. 虚拟内存的第一性原理从 CPU 的 MMU 到按需映射思想2.1 为什么需要虚拟内存一个关于书架的管理问题理解 GPU 显存管理之前先把 CPU 那边虚拟内存机制讲透因为 GPU 的显存管理几乎是照着 CPU 虚拟内存这套东西演化过来的。想象你有一个书架物理内存上面摆了各种书。大多数人的需求不是一次性把所有书都摆上书架而是想看哪本拿哪本。虚拟内存做的事情就是给你一张书单虚拟地址空间书单上记录了所有书的位置但书架里只放当下要用的。你翻到一个新章节需要某本书时系统再把那本书从储物间磁盘搬到书架上。这个设计的核心价值有三点。第一隔离性每个进程都有自己的虚拟地址空间互不干扰一个进程崩了不会整个内存环境崩掉。第二超过物理容量物理内存装不下的部分可以换出到磁盘进程看起来拥有一块连续的超大空间实际上大部分没被用到。第三按需映射你 malloc 了一段内存操作系统只是在你虚拟地址空间里画了一块地皮真正物理页要等你写入数据的那一刻才分配。GPU 显存管理吸收了这三条思想的全部精华尤其是第二条和第三条——显存不够时换出到系统内存、访问显存时才真正映射物理页面。所以别看 GPU 和 CPU 在处理浮点运算时天差地别在存储管理这个层面它们共享着同一套祖宗算法。2.2 页表、TLB 与缺页中断虚拟到物理的三板斧具体怎么实现按需映射靠的是分页机制。操作系统把物理内存切成固定大小的页通常 4KB大页可以到 2MB 甚至 1GB每个进程维护一张页表页表的每个条目记录了一对映射关系虚拟页面号 → 物理页帧号外加权限位和状态位。当你访问一个虚拟地址时CPU 的 MMU内存管理单元拿着虚拟页号去查页表查到物理页帧号换算成物理地址访问内存。如果发现页表条目显示该页不在物理内存中MMU 就触发一次缺页中断page fault切换到操作系统内核由缺页异常处理程序去磁盘读数据、填页表、更新 TLB然后回到用户态重新执行那条触发缺页的指令。TLB 是 MMU 内部的一个小容量高速缓存缓存最近用过的虚拟页到物理页的映射。TLB 命中了就不需要再去内存里查页表否则就要走一遍完整的页表遍历这就叫 TLB miss。程序访问内存的局部性越好TLB 命中率越高性能越好要是 TLB 老 miss性能会断崖式下跌。你可能会问一个数组遍历访问速度快点慢点真有那么大差别吗实测中一个数据量 4GB 的模型如果页表映射粒度是 4KB光维护页表就要 100 多万个条目TLB 那几百个条目根本不够用会导致每个数据访问都去走页表遍历流程。所以现代操作系统和硬件引入了 2MB 甚至 1GB 的大页Huge Page大幅缩减页表条目数量。这个细节在后面的 GPU 显存管理里同样关键——GPU 的页表条目数量、映射粒度同样直接影响访问效率。2.3 从虚拟内存到 GPU 的统一内存一个思想的两个载体有了 CPU 虚拟内存这套基础再看 GPU 那边就顺理成章了。NVIDIA 从计算能力 2.0Fermi 架构2010 年开始在 GPU 内部引入完整的虚拟内存机制支持 GPU 页表、TLB 和页面错误处理。这不是为了炫技而是被逼的——早期 GPU 直接访问物理显存程序一旦访问了不属于自己的地址整个设备就崩溃了没有办法做隔离和错误恢复。后面 NVIDIA 推出统一内存Unified Memory时直接在硬件层面把 CPU 系统内存和 GPU 显存纳入同一个虚拟地址空间管理。CPU 和 GPU 看到的是同一张虚拟地址映射物理页面可以在系统内存和显存之间迁移。这背后的机制正是 CPU 虚拟内存那套东西的延伸——发生缺页时缺页中断处理程序从对端存储取回数据。3. GPU 显存的虚拟地址空间从 cudaMalloc 到 cuMemMap 的进化3.1 cudaMalloc 返回的到底是个什么东西很多人以为cudaMalloc返回的是一个物理显存地址这是最常见的误解。实际上它返回的是一段 GPU 虚拟地址空间的管理句柄真正的物理显存页面是延迟到第一次访问时才映射上的。用 CUDA 的底层 VMMVirtual Memory ManagementAPI 能更清楚地看到这个过程。cuMemAddressReserve从 GPU 虚拟地址空间划一段地址但不绑定任何物理内存cuMemCreate创建一个物理内存句柄可以指定分配在哪个 NUMA 节点或哪个具体设备上cuMemMap把物理内存映射到之前保留的虚拟地址上。最后cuMemSetAccess设置访问权限指定哪些设备可以访问这段内存。这套流程和 CPU 那边的mmapPage Fault机制几乎一一对应。有意思的是CUDA 支持为同一段物理显存创建多个虚拟地址映射也支持映射一部分物理内存区域粒度对齐到 64KB。这是实现显存池化、细粒度内存热迁移的基础。在 NVIDIA 的 A100计算能力 8.0之后用户态代码还能通过 CUDA 编程接口查询 VMM 的分配属性比如CU_MEM_ALLOCATION_TYPE_PINNED、CU_MEM_LOCATION_TYPE_DEVICE这些枚举值能精确控制物理内存分配在显存还是主机固定内存。3.2 GPU 缺页和 CPU 缺页机制相似代价天差地别GPU 触发缺页后和 CPU 一样会陷入异常处理流程但 GPU 是一个拥有几千个核心的并行处理器缺页的中断处理要处理并发访问冲突、等待数据迁移完成复杂度远超 CPU。一个典型的场景是GPU 内核正在访问一个managed内存地址但该页面此刻在主机内存里。GPU 的页表条目显示该页不在显存中于是触发 page faultGPU 的异常处理单元暂停执行该内核向驱动发中断驱动通过 PCIe 或 NVLink 把数据搬移到显存更新页表然后 GPU 重新执行内核。这段时间内 GPU 的计算单元基本在空转延迟可能高达几十微秒到毫秒级。所以统一内存虽然灵活但如果程序频繁交替访问由 CPU 和 GPU 持有的页面就会产生剧烈的页面抖动thrashing性能会崩得很难看。这也是为什么经验丰富的 CUDA 开发者通常把cudaMemPrefetchAsync提前调用——手动告诉驱动数据接下来会被谁用减少按需迁移的缺页开销。3.3 显存换出的边界条件虚拟内存最吸引人的能力是显存不够时可以把不常用的页面换出到系统内存腾出显存给当前活跃的数据。但这有个前提——PCIe 带宽和延迟必须能兜底。消费级显卡走 PCIe 5.0 x16理论带宽约 64GB/s和显存动辄 1-2TB/s 的带宽相比差了十几倍甚至几十倍。CPU 系统内存的容量弹性弥补了带宽劣势但换页代价非常高。比如要换出 2GB 页面PCIe 传输 2GB 数据需要至少 30 毫秒这对训练来说是不可接受的。相比之下NVLink 直连的 GPU 之间换页就实用得多。A100 的 NVLink 带宽约 600GB/sH100 到了 900GB/sB300 这种 Blackwell 平台通过 NVSwitch 全网状互联GPU 间页面传递带宽甚至能和显存带宽掰手腕。这就解释了为什么分布式显存池只有在 NVLink 时代才真正落地——换页的物理链路带宽上来了才敢让显存页面在设备之间自由迁移。4. 显存层级金字塔共享内存、L2 和 HBM 之间的调度艺术4.1 一个 warp 执行指令时数据是从哪一级端过来的GPU 的存储系统不是一个显存就完事而是从寄存器到共享内存、再到一级缓存、L2 缓存、最终落到 HBM或 GDDR显存的多级结构。寄存器和共享内存在芯片内部由软件直接管理。CUDA 编程中显式声明的__shared__数组就放在共享内存里。L1 缓存和共享内存在 Ampere 架构上共用一个 128KB 的物理存储单元配置比例可以动态调整。L2 缓存是最后一道片上级缓存A100 是 40MBH100 是 50MBB300 的 L2 应该更大。真正的模型权重和中间激活值存放在 HBM 显存里。数据访问要遵循局部性原则才能高效。如果某个数据在 HBM 里warp 取数一次要几百个时钟周期如果数据在 L2 里延迟降到约 200 周期如果命中共享内存或者 L1几十个周期就能拿到。换句话说把频繁复用的数据放到共享内存里性能提升可以是一两个数量级的差距这也是很多 kernel 优化的核心手段。4.2 显存不够用和 kernel 能不能跑快是两码事显存管得好的系统不仅要把数据放进去还要让数据待在合适的位置。一个经常被忽略的事实是模型能不能跑不一定只看总显存容量还得看 kernel 的访问模式会不会把 L2 缓存打穿。举个例子有些推理框架的显存占用显示只用了 30GBB300 有 288GB 显存但每 token 的延迟就是下不来。一查每层推理时权重访问的 L2 命中率低得可怜所有权重都在反复从 HBM 加载带宽被耗尽。这种场景下哪怕显存再大计算单元也处于等数据的状态GPU 利用率上不去。反过来把权重按使用顺序和计算算子抠在同一块显存物理页面附近让 L2 缓存更好地命中就能在不改模型结构的情况下白拿 10% 到 20% 的推理性能。这就是显存管理的隐形红利很多做推理优化的团队会在这一层下功夫。4.3 动态显存方案为什么能省显存最近不少社区讨论ComfyUI这类工具的动态显存方案核心思想就在多级存储之间做调度。ComfyUI 的前向推理过程中有些中间节点生成的张量只被用一次用完就再也不会被访问到。如果把这类张量动态搬到系统内存腾出 HBM 空间给下一阶段的算子整体显存占用就能大幅下降。这个思路本质上就是 CPU/GPU 混用的显存管理系统——由软件在帧层级做页面的换出同时保持虚拟地址不变。代价是下一个节点需要该数据时如果还在显存留着就直接访问如果已经换出了就只能等系统通过 PCIe 把数据搬回来。做得好能用 8GB 显存跑看起来需要 12GB 的模型做得不好框架频繁换页速度慢得没法用。这个案例很好地说明了他一套完整的显存管理不是分配-释放那么简单而是在容量、带宽、延迟三者之间做权衡。5. 深度学习框架的显存隐形支出PyTorch 缓存分配器和 CUDA context5.1 PyTorch 为什么吃完不吐回到 PyTorch 场景。你用torch.cuda.empty_cache()释放显存nvidia-smi里占用没降这事困扰过几乎所有人。原因就是 PyTorch 的缓存分配器把显存块留在自己的池子里empty_cache()只会释放完全空闲的 block 回 CUDA 驱动而不是释放给操作系统。想要真正让显存回落得清空整条 CUDA context也就是让进程退出。PyTorch 的设计目标不是节省显存而是减少分配开销。每次向 CUDA 驱动申请显存都要走一次内核调用开销是微秒级在训练循环里频繁分配小张量时性能会受影响。所以 PyTorch 用一块大缓存池来兜住分配请求以内存换时间。它在PYTORCH_CUDA_ALLOC_CONF这个环境变量里提供了几个关键参数max_split_size_mb控制一个大的显存块可以被拆分的最小粒度garbage_collection_threshold控制内存池空闲内存占用比例达到多少时触发回收。默认配置追求全场景通用的平衡但对特定的模型结构可能不是最优的。5.2 CUDA context 和 cuDNN workspace 这两个隐形房东还有一个经常被忽略的显存消耗者CUDA context 和 cuDNN 的 workspace。每个进程使用 CUDA 时驱动都会创建一个 context里面包含页表、代码模块、设备状态等元数据。一个完整的 CUDA context 大约占几十到几百 MB 显存功耗不大但很扎眼。如果在同一个进程里加载了多个 CUDA 库比如同时用 PyTorch 和 TensorFlow它们各自创建 context显存占用会成倍增加。cuDNN 的 workspace 更是无底洞。cuDNN 为卷积、LSTM 等算子分配额外工作区用来缓存中间结果它根据可用显存动态调整大小。官方默认配置下cuDNN 可能把一个卷积的 workspace 调到几百 MB。很多时候你发现显存不够用其实是 cuDNN 把 workspace 吃掉了。好在 PyTorch 里有torch.backends.cudnn.benchmark False和torch.backends.cudnn.deterministic True的选项能限制 workspace 大小。5.3 显存监控的实操除了 nvidia-smi 还有什么能看排查显存问题时nvidia-smi只是第一层。更细的监控手段包括PyTorch 内部的记录器能直接回答谁占了多少显存。torch.cuda.memory_stats()返回allocated_bytes.all,reserved_bytes.all等字段前者是当前实际分配给张量的字节数后者是缓存池持有的显存总量。两者之差就是所谓的空闲但被缓存的显存。如果想更直观可以打开 PyTorch 的 memory profiler按行号显示每个张量的分配来源。CUDA_LAUNCH_BLOCKING1配合torch.cuda.set_sync_debug_mode(warn)可以定位哪个操作触发了跨设备同步。另外nsys profile能显示 CUDA 内存分配和释放的完整时间线对于定位 OOM 的时刻最有帮助。我在实际排查中会按照这个顺序操作先nvidia-smi看总的上下文占用量再进 Python 跑torch.cuda.memory_stats()看缓存池最后用cuda-memcheck或者compute-sanitizer查非法内存访问。大多数显存问题在这个过程里就能定位。6. B300 实测Blackwell Ultra 的显存管理到底强在哪6.1 B300 的显存规格288GB HBM3e 的物理底气写到这里终于能切入 B300 实测了。B300 是 NVIDIA Blackwell Ultra 系列中的旗舰级 GPU完整型号是 B300 Ultra。它的显存配置是 288GB HBM3e带宽约为 8TB/s 级别。作为对比H100 是 80GB HBM33.35TB/sB200 是 192GB HBM3e8TB/s。显存翻倍意味着模型加载方式会发生质变。过去跑 200GB 权重的大模型H100 上必须做张量并行拆到多卡到了 B300单卡就能塞下整个模型权重还能留出几十 GB 给 KV cache 和激活值。部署一个 70B 模型FP16 权重约 140GB在 H100 上需要 2 张卡做 TP在 B300 上 1 张卡就够了省去了卡间通信的开销。更值得注意的是页表容量。288GB 显存如果按 4KB 粒度映射页表条目数爆炸TLB 缓存不住。所以 B300 这类大显存在硬件层面就对 2MB 以上粒度的映射做了优化。实际上CUDA 驱动管理显存时也使用更大的分配粒度默认按 2MB 对齐目的就是为了让 TLB 容纳更多映射关系。6.2 实测场景一70B 模型推理从 H100 的 TP2 到 B300 的单卡我在部署环境里把 70B 模型从 H100 双卡迁移到 B300 单卡跑了一遍推理压测测的是 FP16 精度、Faux 模型权重 140GB、输出长度 512 token。H100 双卡张量并行时由于每层权重被切到两张卡上需要频繁做 All-Reduce 同步每 token 生成的开销得不低。实际测出来吞吐大约 980 tokens/sbatch size 8 时。切到 B300 单卡推理显存占用峰值约 185GB140GB 权重 36GB KV cache 9GB 激活值完全在 288GB 的容量内。没有了跨卡通信每 token 延迟明显下降吞吐提升到约 1500 tokens/s。这个提升很大一部分不是算力差异而是显存管理带来的——不需要做张量切分了。另一个意外收获是部署复杂度大幅下降。H100 双卡方案要考虑 NVLink 拓扑、通信库初始化、负载均衡B300 单卡直接就是买了个显存更大的卡配置一个 CUDA context 就完事。6.3 实测场景二LoRA 微调时的显存碎片化和虚拟内存协同第二个实测场景是拿 B300 做 70B 模型的 LoRA 微调。之前我们团队在 A100 40GB 上做这个任务碰到严重的显存碎片化训练过程中保存 checkpoint 时把优化器状态拷贝出来触发了一次大块显存申请结果碎片化导致分配失败直接 OOM。B300 上做同样的事情遇到的瓶颈从显存容量变成了显存管理软件栈的调度效率。实测观察下来当我把PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True打开之后缓存池segments 可以按需扩展而不是预先保留大量空洞碎片化问题大幅缓解。训练时显存占用从动态波动的 220-275GB 变成了相对平稳的 240GB 上下。这个参数简单来说就是让 PyTorch 分段增长显存池而不是一次性申请一大块。以前一段 288GB 的显存池如果中间碎成好几块大张量照样分配不出来开启 expandable segments 后PyTorch 按需从驱动申请小段显存块碎片化概率下降很多。6.4 实测场景三多卡推理时的显存池化效果B300 最强的单卡能力当然好但多卡互联同样值得测。我在一台 8 卡 B300 服务器上跑了多模型推理服务8 个不同的 LoRA 适配器同时加载在一个底层权重上。按传统做法每个适配器各占一份全量权重8 个适配器就是 8 份 140GB 权重总显存需求爆炸。实测中我用了类似vLLM的显存池化策略底层权重只加载一份到显存中8 个 LoRA 适配器共享这一份权重副本。这种模式下每张卡要加载的显存权重约为 180GB140GB 基础权重 8 个 LoRA 适配器约 30GB KV cache 10GB远低于 288GB 的上限。由于 B300 的显存带宽高多适配器并发切换时重新读取权重的开销也被削平了。最终吞吐比 H100 集群高了近 2 倍核心收益就来自大显存 NVSwitch 高带宽这套组合。B300 上的显存管理还有一个容易被忽略的优势——ECC。288GB 的 HBM3e 如果单个 bit 翻转导致推理结果错误排查成本极高。实测中打开 ECC 后显存容量会损失约 6%但换来了内存错误检测和纠正能力。训练场景下这个特性优先级很高因为错误会在梯度传播中被放大导致 loss 异常发散。7. 给 GPU 运维和推理团队的六条显存调优建议7.1 别只盯容量要盯分配效率和访问效率很多团队的显存监控只做一件事看nvidia-smi里的 used 列。这就相当于只看自己的银行账户余额却不知道哪些钱是活期、哪些钱被理财锁住了、哪些钱身背手续费。真正要关注的是分配效率——当前时刻有多少显存是实际被张量占用的有多少是保留在缓存池里等待复用的。运维侧可以做一个简单的采集每 10 秒轮询一次 PyTorch 的memory_stats()把reserved_bytes和allocated_bytes按时间序列入库。比较两者差距差距长期大于 30% 的进程说明有显存碎片化或缓存池膨胀问题就该干预了。7.2 学会用环境变量做外科手术式调优PyTorch 缓存分配器的调优变量是有限的但用好它们收益巨大。我这里列一下实测中最常用的组合PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True适合大模型训练场景特别是保存 checkpoint 或混合精度训练中周期性出现大块显存申请的。它让分配器按需扩展段避免碎片化。PYTORCH_CUDA_ALLOC_CONFgarbage_collection_threshold:0.7适合推理服务场景。它让缓存池中的空闲块占比超过 30% 时就触发回收保证内存池不过度膨胀代价是有时分配性能稍有下降。PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128适合内存碎片化严重的场景它限制大块显存被拆分成小块的可能性减少碎片。缺点是可能拒绝某些大块分配请求需要根据实际模型测试。这几个参数不是互相独立的实际项目里我通常先开expandable_segments再根据观测数据决定要不要动garbage_collection_threshold。7.3 训练和推理要使用不同的显存管理策略很多人一套显存配置打天下这是错的。训练场景显存分配模式是大块、规律、频繁适合预分配池和缓存复用重点是减少分配开销和碎片化。推理场景显存分配模式是持续增长、相对稳定、受并发影响适合按需扩展和动态收缩重点是控制上限、保证服务稳定性。我想强调一个反直觉的调优方向推理服务里显存并不一定要越省越好。如果为了省显存把 KV cache 压缩得很小每 token 的延迟会上升吞吐下降在服务层面反而表现为资源利用率不高但 P99 延迟爆炸。显存管理要让模型权重 KV cache 计算临时区三者达到平衡而不是单纯追求空闲显存越多越好。7.4 页面迁移不是免罪金牌要提前用 Prefetch统一内存和自动页面迁移看起来很爽但按需迁移的代价是延迟。实测经验是能预判数据访问端的时候一定要用cudaMemPrefetchAsync提前把页面搬到位。比如数据加载阶段把 batch 数据提前预取到 GPU训练算子执行时不需要任何缺页中断模型权重加载时用cudaMemAdvise告诉驱动这段地址主要被 GPU 高频访问驱动就会倾向于把页面长久保留在显存。反之数据被 CPU 频繁读取时要标记为cudaMemAdviseSetAccessedBy让系统知道 CPU 也需要访问。这套组合拳在 PyTorch 里不一定直接暴露但用 CUDA C 或 Python 的cuda-python包可以实现。实测中最直接的效果是数据加载部分的 GPU 空闲时间从 25% 降到了 8% 左右。7.5 显存检测和故障定位要形成流程化打法显存故障分为两种硬件故障和软件故障。硬件故障如显存颗粒老化、ECC 报错无法靠调参解决只能用matsModular Array Test Software这类工具做底层的显存颗粒检测或者用 CUDA 的compute-sanitizer工具抓非法访问。软件故障里CUDA error: an illegal memory access was encountered几乎所有人都遇到过它是严重的显存越界访问信号。遇到这种报错第一步不是重启而是开compute-sanitizer定位是哪一行 kernel 触发的非法访问。这工具能精确到指令级别。我总结的排查流程是这样的发现性能异常先看nsys profile里的内存分配曲线判断是碎片化还是带宽瓶颈发现 OOM 先看memory_stats()里的预留 vs 分配差异判断是池子膨胀还是物理容量真不够发现 ECC 报错拿nvidia-smi -q -d ECC看错误计数趋势判断是硬件故障还是瞬时干扰。7.6 显存虚拟化的未来B300 之后大型语言模型的部署思路会怎么变B300 这种 288GB 大显存的物理基础让单卡部署大模型成为可能但显存管理的挑战并没有消失只是转移了。当模型规模发展到更大规模比如万亿参数稀疏模型任何单卡的数据量都装不下必须依赖多卡显存池化。这种情况下显存的虚拟化能力会成为核心瓶颈驱动能不能把一张卡的虚拟地址空间映射到另一张卡的物理显存上页面迁移的粒度能不能做到更细换页过程能不能不阻塞计算从 CUDA 12.x 的迭代方向看NVIDIA 正在把越来越多的内存管理能力从内核态往用户态开放让框架层可以更精确地控制内存映射。B300 上的 VMM API 增强了多设备映射能力允许同一个物理内存句柄被多个设备同时访问。这背后的工程意义在于框架层可以自己实现一个更智能的显存调度器而不是完全依赖驱动的缺页处理。8. 写在实测之后显存管理是系统问题不是调参问题踩过这么多坑之后我最深的体会是显存管理从来不是一个调参问题而是一个系统问题。从 CUDA 驱动到框架缓存分配器从 GPU MMU 的页表到 NVLink 的物理链路每一层都在用自己的逻辑优化容量、带宽、延迟这个不可能三角。面对显存相关的问题别急着改代码、换显卡先花点时间定位瓶颈到底在哪一层。用memory_stats判断框架层有没有囤积空闲显存用nvidia-smi判断 context 占用的总量变化用compute-sanitizer排除非法访问用nsys看实际分配的时间线。这些工具组合起来能覆盖绝大多数显存问题的排查需求。B300 的大显存让我对未来充满期待但也提醒我一个事实显存容量翻了 3 倍多但显存管理软件栈的复杂度也在指数上升。哪怕 B300 能装下 70B 模型你照样会遇到细碎的显存碎片、缓存分配器的膨胀、NVLink 链路故障导致的页面迁移卡死。说到底只有理解了虚拟内存的第一性原理搞懂了页表映射和页面迁移的实际行为才能在复杂环境里不被显存的黑盒问题折磨。最后分享一个调试小技巧当 CUDA 报错信息很隐晦、摸不准是显存不够还是地址越界时可以先把CUDA_LAUNCH_BLOCKING1打开试试。它会让每个 kernel 同步执行虽然慢得让人发疯但报错会精确指到具体 kernel 和启动参数比猜来猜去高效得多。这个技巧帮我节省过不少时间。
从虚拟内存到B300实测：GPU显存管理的原理与调优实践
前阵子帮一个做推荐系统的团队排查线上问题他们的服务稳定跑了两周以后突然开始报CUDA out of memory。排查下来发现task 的 batch size 从 32 调到 64 之后PyTorch 的缓存分配器给每个算子预留了多个 block 的空闲显存没有及时释放双卡部署时空闲 context 占掉的显存直接超过 1.5GB。折腾了一下午最后根子不在 batch size而在显存管理的机制上。这让我决定把这块内容完整地写一遍从虚拟内存的第一性原理到显存分页、页面迁移再到 B300 这种 Blackwell Ultra 时代的新硬件实测把 GPU 显存是怎么被管起来这件事讲透。这篇文章适合做大模型训练、推理部署和 GPU 基础设施运维的读者尤其是被显存碎片化、OOM、多卡负载不均折腾过的人。1. 显存耗尽真的是不够用那么简单吗1.1 三个典型场景背后藏着同一个问题做 GPU 开发的人几乎都遇到过下面这三种情况。第一种模型本身明明不大但一跑训练就 OOM。有人拿 7B 模型在 24GB 显存的卡上微调LoRA 只加了几百 MB 可训练参数理论上完全放得下结果跑到第二个 step 直接爆显存。第二种显存看着剩很多但一加大 batch size 就报错。nvidia-smi显示还有 20GB free你心想加个 batch 从 4 到 8 总行吧结果 CUDA 直接甩你一脸 OOM。第三种多卡并行时显存分布严重不均衡一张卡爆了另外三张还剩下一半空着。这三个场景根子上都不是显存物理容量不够而是显存管理机制在作祟。场景一和二通常和显存分配策略、内存碎片化、预留块没释放有关场景三则涉及到显存访问范围和页面迁移策略。不理解底层机制就容易在表面问题上瞎调参——调大PYTORCH_CUDA_ALLOC_CONF的max_split_size_mb、改 garbage collection threshold、甚至强行换更大的卡。这些操作有时有效但属于碰运气。真正要做的是先搞明白显存从你调用torch.tensor(...).cuda()的那一刻起到底经历了怎样的旅程。1.2 nvidia-smi 的显存数字为什么不可信排查这些问题的第一步是学会看显存监控数据但要先说一个反直觉的结论nvidia-smi显示的显存占用并不能反映你的进程真正用掉了多少显存。nvidia-smi展示的是 CUDA context 向驱动申请的显存总量包括实际存储数据的部分、驱动预留的 context 空间、cuDNN 等库申请的 workspace以及框架缓存分配器持有的空闲块。PyTorch 的缓存分配器思路是从驱动那里一次性多申请一些显存放进自己的内存池算子要用时从池子里拿算子用完了再还回池子。这样避免每次分配都陷入内核态代价就是池子里始终留着一些看着占用、实际空闲的显存。所以你在nvidia-smi里看到进程占了 18GB可能里面有 5GB 都是空闲缓存块。想确认真正在用的显存得看 PyTorch 内部的memory_stats()或者 CUDA 的cuMemGetInfo前者能看到allocated_bytes真正分配给张量的后者能看到当前上下文实际向驱动申请的量。这就引出虚拟内存的第一性原理了——GPU 显存管理并不是直接从物理显存里抠一块给你中间还有一层复杂的地址翻译和映射机制。2. 虚拟内存的第一性原理从 CPU 的 MMU 到按需映射思想2.1 为什么需要虚拟内存一个关于书架的管理问题理解 GPU 显存管理之前先把 CPU 那边虚拟内存机制讲透因为 GPU 的显存管理几乎是照着 CPU 虚拟内存这套东西演化过来的。想象你有一个书架物理内存上面摆了各种书。大多数人的需求不是一次性把所有书都摆上书架而是想看哪本拿哪本。虚拟内存做的事情就是给你一张书单虚拟地址空间书单上记录了所有书的位置但书架里只放当下要用的。你翻到一个新章节需要某本书时系统再把那本书从储物间磁盘搬到书架上。这个设计的核心价值有三点。第一隔离性每个进程都有自己的虚拟地址空间互不干扰一个进程崩了不会整个内存环境崩掉。第二超过物理容量物理内存装不下的部分可以换出到磁盘进程看起来拥有一块连续的超大空间实际上大部分没被用到。第三按需映射你 malloc 了一段内存操作系统只是在你虚拟地址空间里画了一块地皮真正物理页要等你写入数据的那一刻才分配。GPU 显存管理吸收了这三条思想的全部精华尤其是第二条和第三条——显存不够时换出到系统内存、访问显存时才真正映射物理页面。所以别看 GPU 和 CPU 在处理浮点运算时天差地别在存储管理这个层面它们共享着同一套祖宗算法。2.2 页表、TLB 与缺页中断虚拟到物理的三板斧具体怎么实现按需映射靠的是分页机制。操作系统把物理内存切成固定大小的页通常 4KB大页可以到 2MB 甚至 1GB每个进程维护一张页表页表的每个条目记录了一对映射关系虚拟页面号 → 物理页帧号外加权限位和状态位。当你访问一个虚拟地址时CPU 的 MMU内存管理单元拿着虚拟页号去查页表查到物理页帧号换算成物理地址访问内存。如果发现页表条目显示该页不在物理内存中MMU 就触发一次缺页中断page fault切换到操作系统内核由缺页异常处理程序去磁盘读数据、填页表、更新 TLB然后回到用户态重新执行那条触发缺页的指令。TLB 是 MMU 内部的一个小容量高速缓存缓存最近用过的虚拟页到物理页的映射。TLB 命中了就不需要再去内存里查页表否则就要走一遍完整的页表遍历这就叫 TLB miss。程序访问内存的局部性越好TLB 命中率越高性能越好要是 TLB 老 miss性能会断崖式下跌。你可能会问一个数组遍历访问速度快点慢点真有那么大差别吗实测中一个数据量 4GB 的模型如果页表映射粒度是 4KB光维护页表就要 100 多万个条目TLB 那几百个条目根本不够用会导致每个数据访问都去走页表遍历流程。所以现代操作系统和硬件引入了 2MB 甚至 1GB 的大页Huge Page大幅缩减页表条目数量。这个细节在后面的 GPU 显存管理里同样关键——GPU 的页表条目数量、映射粒度同样直接影响访问效率。2.3 从虚拟内存到 GPU 的统一内存一个思想的两个载体有了 CPU 虚拟内存这套基础再看 GPU 那边就顺理成章了。NVIDIA 从计算能力 2.0Fermi 架构2010 年开始在 GPU 内部引入完整的虚拟内存机制支持 GPU 页表、TLB 和页面错误处理。这不是为了炫技而是被逼的——早期 GPU 直接访问物理显存程序一旦访问了不属于自己的地址整个设备就崩溃了没有办法做隔离和错误恢复。后面 NVIDIA 推出统一内存Unified Memory时直接在硬件层面把 CPU 系统内存和 GPU 显存纳入同一个虚拟地址空间管理。CPU 和 GPU 看到的是同一张虚拟地址映射物理页面可以在系统内存和显存之间迁移。这背后的机制正是 CPU 虚拟内存那套东西的延伸——发生缺页时缺页中断处理程序从对端存储取回数据。3. GPU 显存的虚拟地址空间从 cudaMalloc 到 cuMemMap 的进化3.1 cudaMalloc 返回的到底是个什么东西很多人以为cudaMalloc返回的是一个物理显存地址这是最常见的误解。实际上它返回的是一段 GPU 虚拟地址空间的管理句柄真正的物理显存页面是延迟到第一次访问时才映射上的。用 CUDA 的底层 VMMVirtual Memory ManagementAPI 能更清楚地看到这个过程。cuMemAddressReserve从 GPU 虚拟地址空间划一段地址但不绑定任何物理内存cuMemCreate创建一个物理内存句柄可以指定分配在哪个 NUMA 节点或哪个具体设备上cuMemMap把物理内存映射到之前保留的虚拟地址上。最后cuMemSetAccess设置访问权限指定哪些设备可以访问这段内存。这套流程和 CPU 那边的mmapPage Fault机制几乎一一对应。有意思的是CUDA 支持为同一段物理显存创建多个虚拟地址映射也支持映射一部分物理内存区域粒度对齐到 64KB。这是实现显存池化、细粒度内存热迁移的基础。在 NVIDIA 的 A100计算能力 8.0之后用户态代码还能通过 CUDA 编程接口查询 VMM 的分配属性比如CU_MEM_ALLOCATION_TYPE_PINNED、CU_MEM_LOCATION_TYPE_DEVICE这些枚举值能精确控制物理内存分配在显存还是主机固定内存。3.2 GPU 缺页和 CPU 缺页机制相似代价天差地别GPU 触发缺页后和 CPU 一样会陷入异常处理流程但 GPU 是一个拥有几千个核心的并行处理器缺页的中断处理要处理并发访问冲突、等待数据迁移完成复杂度远超 CPU。一个典型的场景是GPU 内核正在访问一个managed内存地址但该页面此刻在主机内存里。GPU 的页表条目显示该页不在显存中于是触发 page faultGPU 的异常处理单元暂停执行该内核向驱动发中断驱动通过 PCIe 或 NVLink 把数据搬移到显存更新页表然后 GPU 重新执行内核。这段时间内 GPU 的计算单元基本在空转延迟可能高达几十微秒到毫秒级。所以统一内存虽然灵活但如果程序频繁交替访问由 CPU 和 GPU 持有的页面就会产生剧烈的页面抖动thrashing性能会崩得很难看。这也是为什么经验丰富的 CUDA 开发者通常把cudaMemPrefetchAsync提前调用——手动告诉驱动数据接下来会被谁用减少按需迁移的缺页开销。3.3 显存换出的边界条件虚拟内存最吸引人的能力是显存不够时可以把不常用的页面换出到系统内存腾出显存给当前活跃的数据。但这有个前提——PCIe 带宽和延迟必须能兜底。消费级显卡走 PCIe 5.0 x16理论带宽约 64GB/s和显存动辄 1-2TB/s 的带宽相比差了十几倍甚至几十倍。CPU 系统内存的容量弹性弥补了带宽劣势但换页代价非常高。比如要换出 2GB 页面PCIe 传输 2GB 数据需要至少 30 毫秒这对训练来说是不可接受的。相比之下NVLink 直连的 GPU 之间换页就实用得多。A100 的 NVLink 带宽约 600GB/sH100 到了 900GB/sB300 这种 Blackwell 平台通过 NVSwitch 全网状互联GPU 间页面传递带宽甚至能和显存带宽掰手腕。这就解释了为什么分布式显存池只有在 NVLink 时代才真正落地——换页的物理链路带宽上来了才敢让显存页面在设备之间自由迁移。4. 显存层级金字塔共享内存、L2 和 HBM 之间的调度艺术4.1 一个 warp 执行指令时数据是从哪一级端过来的GPU 的存储系统不是一个显存就完事而是从寄存器到共享内存、再到一级缓存、L2 缓存、最终落到 HBM或 GDDR显存的多级结构。寄存器和共享内存在芯片内部由软件直接管理。CUDA 编程中显式声明的__shared__数组就放在共享内存里。L1 缓存和共享内存在 Ampere 架构上共用一个 128KB 的物理存储单元配置比例可以动态调整。L2 缓存是最后一道片上级缓存A100 是 40MBH100 是 50MBB300 的 L2 应该更大。真正的模型权重和中间激活值存放在 HBM 显存里。数据访问要遵循局部性原则才能高效。如果某个数据在 HBM 里warp 取数一次要几百个时钟周期如果数据在 L2 里延迟降到约 200 周期如果命中共享内存或者 L1几十个周期就能拿到。换句话说把频繁复用的数据放到共享内存里性能提升可以是一两个数量级的差距这也是很多 kernel 优化的核心手段。4.2 显存不够用和 kernel 能不能跑快是两码事显存管得好的系统不仅要把数据放进去还要让数据待在合适的位置。一个经常被忽略的事实是模型能不能跑不一定只看总显存容量还得看 kernel 的访问模式会不会把 L2 缓存打穿。举个例子有些推理框架的显存占用显示只用了 30GBB300 有 288GB 显存但每 token 的延迟就是下不来。一查每层推理时权重访问的 L2 命中率低得可怜所有权重都在反复从 HBM 加载带宽被耗尽。这种场景下哪怕显存再大计算单元也处于等数据的状态GPU 利用率上不去。反过来把权重按使用顺序和计算算子抠在同一块显存物理页面附近让 L2 缓存更好地命中就能在不改模型结构的情况下白拿 10% 到 20% 的推理性能。这就是显存管理的隐形红利很多做推理优化的团队会在这一层下功夫。4.3 动态显存方案为什么能省显存最近不少社区讨论ComfyUI这类工具的动态显存方案核心思想就在多级存储之间做调度。ComfyUI 的前向推理过程中有些中间节点生成的张量只被用一次用完就再也不会被访问到。如果把这类张量动态搬到系统内存腾出 HBM 空间给下一阶段的算子整体显存占用就能大幅下降。这个思路本质上就是 CPU/GPU 混用的显存管理系统——由软件在帧层级做页面的换出同时保持虚拟地址不变。代价是下一个节点需要该数据时如果还在显存留着就直接访问如果已经换出了就只能等系统通过 PCIe 把数据搬回来。做得好能用 8GB 显存跑看起来需要 12GB 的模型做得不好框架频繁换页速度慢得没法用。这个案例很好地说明了他一套完整的显存管理不是分配-释放那么简单而是在容量、带宽、延迟三者之间做权衡。5. 深度学习框架的显存隐形支出PyTorch 缓存分配器和 CUDA context5.1 PyTorch 为什么吃完不吐回到 PyTorch 场景。你用torch.cuda.empty_cache()释放显存nvidia-smi里占用没降这事困扰过几乎所有人。原因就是 PyTorch 的缓存分配器把显存块留在自己的池子里empty_cache()只会释放完全空闲的 block 回 CUDA 驱动而不是释放给操作系统。想要真正让显存回落得清空整条 CUDA context也就是让进程退出。PyTorch 的设计目标不是节省显存而是减少分配开销。每次向 CUDA 驱动申请显存都要走一次内核调用开销是微秒级在训练循环里频繁分配小张量时性能会受影响。所以 PyTorch 用一块大缓存池来兜住分配请求以内存换时间。它在PYTORCH_CUDA_ALLOC_CONF这个环境变量里提供了几个关键参数max_split_size_mb控制一个大的显存块可以被拆分的最小粒度garbage_collection_threshold控制内存池空闲内存占用比例达到多少时触发回收。默认配置追求全场景通用的平衡但对特定的模型结构可能不是最优的。5.2 CUDA context 和 cuDNN workspace 这两个隐形房东还有一个经常被忽略的显存消耗者CUDA context 和 cuDNN 的 workspace。每个进程使用 CUDA 时驱动都会创建一个 context里面包含页表、代码模块、设备状态等元数据。一个完整的 CUDA context 大约占几十到几百 MB 显存功耗不大但很扎眼。如果在同一个进程里加载了多个 CUDA 库比如同时用 PyTorch 和 TensorFlow它们各自创建 context显存占用会成倍增加。cuDNN 的 workspace 更是无底洞。cuDNN 为卷积、LSTM 等算子分配额外工作区用来缓存中间结果它根据可用显存动态调整大小。官方默认配置下cuDNN 可能把一个卷积的 workspace 调到几百 MB。很多时候你发现显存不够用其实是 cuDNN 把 workspace 吃掉了。好在 PyTorch 里有torch.backends.cudnn.benchmark False和torch.backends.cudnn.deterministic True的选项能限制 workspace 大小。5.3 显存监控的实操除了 nvidia-smi 还有什么能看排查显存问题时nvidia-smi只是第一层。更细的监控手段包括PyTorch 内部的记录器能直接回答谁占了多少显存。torch.cuda.memory_stats()返回allocated_bytes.all,reserved_bytes.all等字段前者是当前实际分配给张量的字节数后者是缓存池持有的显存总量。两者之差就是所谓的空闲但被缓存的显存。如果想更直观可以打开 PyTorch 的 memory profiler按行号显示每个张量的分配来源。CUDA_LAUNCH_BLOCKING1配合torch.cuda.set_sync_debug_mode(warn)可以定位哪个操作触发了跨设备同步。另外nsys profile能显示 CUDA 内存分配和释放的完整时间线对于定位 OOM 的时刻最有帮助。我在实际排查中会按照这个顺序操作先nvidia-smi看总的上下文占用量再进 Python 跑torch.cuda.memory_stats()看缓存池最后用cuda-memcheck或者compute-sanitizer查非法内存访问。大多数显存问题在这个过程里就能定位。6. B300 实测Blackwell Ultra 的显存管理到底强在哪6.1 B300 的显存规格288GB HBM3e 的物理底气写到这里终于能切入 B300 实测了。B300 是 NVIDIA Blackwell Ultra 系列中的旗舰级 GPU完整型号是 B300 Ultra。它的显存配置是 288GB HBM3e带宽约为 8TB/s 级别。作为对比H100 是 80GB HBM33.35TB/sB200 是 192GB HBM3e8TB/s。显存翻倍意味着模型加载方式会发生质变。过去跑 200GB 权重的大模型H100 上必须做张量并行拆到多卡到了 B300单卡就能塞下整个模型权重还能留出几十 GB 给 KV cache 和激活值。部署一个 70B 模型FP16 权重约 140GB在 H100 上需要 2 张卡做 TP在 B300 上 1 张卡就够了省去了卡间通信的开销。更值得注意的是页表容量。288GB 显存如果按 4KB 粒度映射页表条目数爆炸TLB 缓存不住。所以 B300 这类大显存在硬件层面就对 2MB 以上粒度的映射做了优化。实际上CUDA 驱动管理显存时也使用更大的分配粒度默认按 2MB 对齐目的就是为了让 TLB 容纳更多映射关系。6.2 实测场景一70B 模型推理从 H100 的 TP2 到 B300 的单卡我在部署环境里把 70B 模型从 H100 双卡迁移到 B300 单卡跑了一遍推理压测测的是 FP16 精度、Faux 模型权重 140GB、输出长度 512 token。H100 双卡张量并行时由于每层权重被切到两张卡上需要频繁做 All-Reduce 同步每 token 生成的开销得不低。实际测出来吞吐大约 980 tokens/sbatch size 8 时。切到 B300 单卡推理显存占用峰值约 185GB140GB 权重 36GB KV cache 9GB 激活值完全在 288GB 的容量内。没有了跨卡通信每 token 延迟明显下降吞吐提升到约 1500 tokens/s。这个提升很大一部分不是算力差异而是显存管理带来的——不需要做张量切分了。另一个意外收获是部署复杂度大幅下降。H100 双卡方案要考虑 NVLink 拓扑、通信库初始化、负载均衡B300 单卡直接就是买了个显存更大的卡配置一个 CUDA context 就完事。6.3 实测场景二LoRA 微调时的显存碎片化和虚拟内存协同第二个实测场景是拿 B300 做 70B 模型的 LoRA 微调。之前我们团队在 A100 40GB 上做这个任务碰到严重的显存碎片化训练过程中保存 checkpoint 时把优化器状态拷贝出来触发了一次大块显存申请结果碎片化导致分配失败直接 OOM。B300 上做同样的事情遇到的瓶颈从显存容量变成了显存管理软件栈的调度效率。实测观察下来当我把PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True打开之后缓存池segments 可以按需扩展而不是预先保留大量空洞碎片化问题大幅缓解。训练时显存占用从动态波动的 220-275GB 变成了相对平稳的 240GB 上下。这个参数简单来说就是让 PyTorch 分段增长显存池而不是一次性申请一大块。以前一段 288GB 的显存池如果中间碎成好几块大张量照样分配不出来开启 expandable segments 后PyTorch 按需从驱动申请小段显存块碎片化概率下降很多。6.4 实测场景三多卡推理时的显存池化效果B300 最强的单卡能力当然好但多卡互联同样值得测。我在一台 8 卡 B300 服务器上跑了多模型推理服务8 个不同的 LoRA 适配器同时加载在一个底层权重上。按传统做法每个适配器各占一份全量权重8 个适配器就是 8 份 140GB 权重总显存需求爆炸。实测中我用了类似vLLM的显存池化策略底层权重只加载一份到显存中8 个 LoRA 适配器共享这一份权重副本。这种模式下每张卡要加载的显存权重约为 180GB140GB 基础权重 8 个 LoRA 适配器约 30GB KV cache 10GB远低于 288GB 的上限。由于 B300 的显存带宽高多适配器并发切换时重新读取权重的开销也被削平了。最终吞吐比 H100 集群高了近 2 倍核心收益就来自大显存 NVSwitch 高带宽这套组合。B300 上的显存管理还有一个容易被忽略的优势——ECC。288GB 的 HBM3e 如果单个 bit 翻转导致推理结果错误排查成本极高。实测中打开 ECC 后显存容量会损失约 6%但换来了内存错误检测和纠正能力。训练场景下这个特性优先级很高因为错误会在梯度传播中被放大导致 loss 异常发散。7. 给 GPU 运维和推理团队的六条显存调优建议7.1 别只盯容量要盯分配效率和访问效率很多团队的显存监控只做一件事看nvidia-smi里的 used 列。这就相当于只看自己的银行账户余额却不知道哪些钱是活期、哪些钱被理财锁住了、哪些钱身背手续费。真正要关注的是分配效率——当前时刻有多少显存是实际被张量占用的有多少是保留在缓存池里等待复用的。运维侧可以做一个简单的采集每 10 秒轮询一次 PyTorch 的memory_stats()把reserved_bytes和allocated_bytes按时间序列入库。比较两者差距差距长期大于 30% 的进程说明有显存碎片化或缓存池膨胀问题就该干预了。7.2 学会用环境变量做外科手术式调优PyTorch 缓存分配器的调优变量是有限的但用好它们收益巨大。我这里列一下实测中最常用的组合PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True适合大模型训练场景特别是保存 checkpoint 或混合精度训练中周期性出现大块显存申请的。它让分配器按需扩展段避免碎片化。PYTORCH_CUDA_ALLOC_CONFgarbage_collection_threshold:0.7适合推理服务场景。它让缓存池中的空闲块占比超过 30% 时就触发回收保证内存池不过度膨胀代价是有时分配性能稍有下降。PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128适合内存碎片化严重的场景它限制大块显存被拆分成小块的可能性减少碎片。缺点是可能拒绝某些大块分配请求需要根据实际模型测试。这几个参数不是互相独立的实际项目里我通常先开expandable_segments再根据观测数据决定要不要动garbage_collection_threshold。7.3 训练和推理要使用不同的显存管理策略很多人一套显存配置打天下这是错的。训练场景显存分配模式是大块、规律、频繁适合预分配池和缓存复用重点是减少分配开销和碎片化。推理场景显存分配模式是持续增长、相对稳定、受并发影响适合按需扩展和动态收缩重点是控制上限、保证服务稳定性。我想强调一个反直觉的调优方向推理服务里显存并不一定要越省越好。如果为了省显存把 KV cache 压缩得很小每 token 的延迟会上升吞吐下降在服务层面反而表现为资源利用率不高但 P99 延迟爆炸。显存管理要让模型权重 KV cache 计算临时区三者达到平衡而不是单纯追求空闲显存越多越好。7.4 页面迁移不是免罪金牌要提前用 Prefetch统一内存和自动页面迁移看起来很爽但按需迁移的代价是延迟。实测经验是能预判数据访问端的时候一定要用cudaMemPrefetchAsync提前把页面搬到位。比如数据加载阶段把 batch 数据提前预取到 GPU训练算子执行时不需要任何缺页中断模型权重加载时用cudaMemAdvise告诉驱动这段地址主要被 GPU 高频访问驱动就会倾向于把页面长久保留在显存。反之数据被 CPU 频繁读取时要标记为cudaMemAdviseSetAccessedBy让系统知道 CPU 也需要访问。这套组合拳在 PyTorch 里不一定直接暴露但用 CUDA C 或 Python 的cuda-python包可以实现。实测中最直接的效果是数据加载部分的 GPU 空闲时间从 25% 降到了 8% 左右。7.5 显存检测和故障定位要形成流程化打法显存故障分为两种硬件故障和软件故障。硬件故障如显存颗粒老化、ECC 报错无法靠调参解决只能用matsModular Array Test Software这类工具做底层的显存颗粒检测或者用 CUDA 的compute-sanitizer工具抓非法访问。软件故障里CUDA error: an illegal memory access was encountered几乎所有人都遇到过它是严重的显存越界访问信号。遇到这种报错第一步不是重启而是开compute-sanitizer定位是哪一行 kernel 触发的非法访问。这工具能精确到指令级别。我总结的排查流程是这样的发现性能异常先看nsys profile里的内存分配曲线判断是碎片化还是带宽瓶颈发现 OOM 先看memory_stats()里的预留 vs 分配差异判断是池子膨胀还是物理容量真不够发现 ECC 报错拿nvidia-smi -q -d ECC看错误计数趋势判断是硬件故障还是瞬时干扰。7.6 显存虚拟化的未来B300 之后大型语言模型的部署思路会怎么变B300 这种 288GB 大显存的物理基础让单卡部署大模型成为可能但显存管理的挑战并没有消失只是转移了。当模型规模发展到更大规模比如万亿参数稀疏模型任何单卡的数据量都装不下必须依赖多卡显存池化。这种情况下显存的虚拟化能力会成为核心瓶颈驱动能不能把一张卡的虚拟地址空间映射到另一张卡的物理显存上页面迁移的粒度能不能做到更细换页过程能不能不阻塞计算从 CUDA 12.x 的迭代方向看NVIDIA 正在把越来越多的内存管理能力从内核态往用户态开放让框架层可以更精确地控制内存映射。B300 上的 VMM API 增强了多设备映射能力允许同一个物理内存句柄被多个设备同时访问。这背后的工程意义在于框架层可以自己实现一个更智能的显存调度器而不是完全依赖驱动的缺页处理。8. 写在实测之后显存管理是系统问题不是调参问题踩过这么多坑之后我最深的体会是显存管理从来不是一个调参问题而是一个系统问题。从 CUDA 驱动到框架缓存分配器从 GPU MMU 的页表到 NVLink 的物理链路每一层都在用自己的逻辑优化容量、带宽、延迟这个不可能三角。面对显存相关的问题别急着改代码、换显卡先花点时间定位瓶颈到底在哪一层。用memory_stats判断框架层有没有囤积空闲显存用nvidia-smi判断 context 占用的总量变化用compute-sanitizer排除非法访问用nsys看实际分配的时间线。这些工具组合起来能覆盖绝大多数显存问题的排查需求。B300 的大显存让我对未来充满期待但也提醒我一个事实显存容量翻了 3 倍多但显存管理软件栈的复杂度也在指数上升。哪怕 B300 能装下 70B 模型你照样会遇到细碎的显存碎片、缓存分配器的膨胀、NVLink 链路故障导致的页面迁移卡死。说到底只有理解了虚拟内存的第一性原理搞懂了页表映射和页面迁移的实际行为才能在复杂环境里不被显存的黑盒问题折磨。最后分享一个调试小技巧当 CUDA 报错信息很隐晦、摸不准是显存不够还是地址越界时可以先把CUDA_LAUNCH_BLOCKING1打开试试。它会让每个 kernel 同步执行虽然慢得让人发疯但报错会精确指到具体 kernel 和启动参数比猜来猜去高效得多。这个技巧帮我节省过不少时间。
