📚 课程目录第4章显存管理基础

4、显存管理基础：显存分配机制、显存碎片化、显存溢出（OOM）的常见原因与排查方法

在GPU多路视频推理部署中，显存（VRAM）是最核心的硬件资源瓶颈之一。与CPU内存不同，GPU显存由CUDA运行时统一管理，其分配、复用与释放机制直接影响推理服务的稳定性与并发上限。许多工程团队在部署初期只关注模型精度与推理延迟，却忽视了显存分配策略与碎片化问题，导致服务运行数小时后出现OOM、显存泄漏或并发能力骤降。本章将从显存分配机制出发，系统梳理碎片化成因、OOM常见诱因，并给出可落地的排查与治理方法。

4.1 显存分配机制：从cudaMalloc到缓存池

GPU显存分配并非每次请求都直接向驱动申请物理显存。CUDA运行时与主流深度学习框架（PyTorch、TensorRT）均采用预分配+缓存复用策略，以降低频繁分配带来的性能开销。理解这一机制是排查显存问题的前提。

4.1.1 CUDA底层分配：cudaMalloc与cudaFree

cudaMalloc是CUDA驱动提供的底层显存分配接口，每次调用都会触发驱动层的显存管理操作，开销较大（通常数十微秒到数百微秒）。频繁调用会导致CPU与GPU同步等待，降低吞吐。因此，生产级推理引擎几乎不会直接使用裸的cudaMalloc，而是通过缓存池复用显存块。

4.1.2 PyTorch的Caching Allocator

PyTorch默认使用Caching Allocator管理显存。其核心逻辑是：当张量释放时，显存块并不立即归还给驱动，而是进入一个空闲块列表（block pool），供后续分配复用。该机制显著提升了小张量频繁创建/销毁场景下的性能，但也带来了两个副作用：显存峰值高于实际需求（因为缓存块不会自动收缩）和碎片化（不同大小的块交错分配后，空闲块不连续）。

4.1.3 TensorRT的TensorPool

TensorRT在构建引擎时，会通过ITensorPool预分配固定大小的显存池，推理过程中的中间张量均从池中申请。池大小由构建期配置决定，若设置过小，推理时会触发额外分配；若设置过大，则浪费显存。多路部署时，每个推理流（Stream）通常需要独立的TensorPool，这进一步增加了显存规划的复杂度。

分配方式	分配粒度	释放策略	适用场景	碎片风险
cudaMalloc	字节级	立即释放	一次性大块分配	低
PyTorch Caching	512B~2MB块	延迟释放（缓存）	动态图、研究原型	中高
TensorRT TensorPool	构建期预分配	引擎销毁时释放	生产推理、固定batch	低（池内管理）
CUDA Graph	捕获期固定	图销毁时释放	多路并发、低延迟	极低

经验提示：在PyTorch推理服务中，若显存峰值远高于模型理论占用，优先检查Caching Allocator的缓存块是否过大。可通过设置环境变量PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128限制最大缓存块，减少碎片化。

4.2 显存碎片化：成因、度量与治理

显存碎片化是指显存中存在大量不连续的空闲块，导致即使总空闲显存充足，也无法分配出满足请求的大块连续显存。碎片化分为外部碎片（空闲块分散）和内部碎片（分配块大于请求量）。

4.2.1 碎片化产生路径

动态shape输入：多路视频流的分辨率、帧率可能动态变化，导致每帧推理所需的中间张量大小不同，反复分配/释放不同大小的块，加速碎片化。
多流并发：不同推理流（Stream）的分配请求交错执行，块的生命周期重叠，空闲块被分割。
缓存块分裂：PyTorch Caching Allocator在分配大块时，会将大块分裂为小块；释放时若相邻块空闲，会尝试合并，但合并条件苛刻（需同属一个segment且相邻）。

4.2.2 碎片化度量指标

工程上常用碎片率（Fragmentation Ratio）量化碎片化程度：

碎片率 = 1 - (最大连续空闲块大小 / 总空闲显存大小)

当碎片率超过30%时，OOM风险显著上升。可通过以下命令查看显存块分布：

# PyTorch显存快照
torch.cuda.memory_snapshot()
# 查看每个segment的块大小与空闲状态

# 使用nvidia-smi查看整体占用
nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv

4.2.3 碎片化治理策略

固定输入尺寸：将多路视频统一resize到固定分辨率（如1280x720），避免动态shape。
使用CUDA Graph：捕获推理图，显存分配在捕获期一次性完成，运行期零分配。
显存池预分配：在服务启动时，按最大并发数预分配显存池，后续推理从池中申请。
定期碎片整理：在低峰期执行torch.cuda.empty_cache()，或重启推理进程（最彻底）。

风险提示：torch.cuda.empty_cache()会释放所有空闲缓存块，但不会释放正在使用的块。频繁调用会增加CPU开销，且可能导致后续分配重新触发cudaMalloc，反而降低性能。建议仅在显存压力大时调用。

4.3 显存溢出（OOM）的常见原因与排查方法

OOM（Out of Memory）是GPU推理部署中最常见的故障类型。其表象是CUDA报错CUDA error: out of memory，但根因往往不止一种。以下从多路视频场景出发，归纳四类典型诱因。

4.3.1 常见原因分类

类别	具体原因	典型特征	多路视频场景表现
配置超限	batch size过大、输入分辨率过高	启动即OOM或首个batch即OOM	并发路数增加时，显存线性增长直至超限
显存泄漏	张量未释放、缓存池无限增长	运行数小时后显存缓慢增长	长时间运行后，即使路数不变，显存占用持续上升
碎片化严重	动态shape、多流交错分配	总空闲显存充足但分配失败	运行一段时间后，新增一路视频流时OOM
多进程叠加	多个推理进程共享GPU，未做显存隔离	其他进程占用显存导致本进程分配失败	多路视频拆分为多个进程部署时，总显存超限

4.3.2 排查五步法

当OOM发生时，按以下步骤系统排查，避免盲目调参：

确认显存占用分布：执行nvidia-smi查看各进程显存占用，确认是否被其他进程挤占。
定位分配失败点：在代码中捕获CUDA错误堆栈，找到具体分配显存的张量或层。
生成显存快照：使用torch.cuda.memory._dump_snapshot()生成快照文件，用memory.html可视化分析块分布。
计算碎片率：根据快照数据计算最大连续空闲块与总空闲之比，判断是否碎片化。
验证泄漏假设：在固定输入下，每隔10分钟记录显存占用，绘制时间曲线；若持续上升则存在泄漏。

4.3.3 案例拆解：多路视频推理服务OOM排查实战

背景与约束：某安防平台部署8路1080p视频流，使用TensorRT引擎（FP16）进行行人检测。GPU为NVIDIA A10（24GB显存）。服务运行约6小时后，新增第9路视频流时触发OOM，重启后恢复。

初始现象：OOM报错出现在enqueueV2()调用处，但此时nvidia-smi显示显存占用仅18.2GB，空闲5.8GB。显然，并非总显存不足，而是无法分配出连续的大块显存。

关键数据：

每路视频流TensorRT引擎预分配显存池：1.8GB
推理时动态分配中间张量：约0.6GB/路
8路总占用：8 × (1.8 + 0.6) = 19.2GB
空闲显存：24 - 19.2 = 4.8GB（与nvidia-smi显示接近）

分析判断：新增第9路需要2.4GB连续显存，但空闲的4.8GB被分割为多个不连续块（最大连续块仅1.2GB）。碎片率 = 1 - (1.2 / 4.8) = 75%，严重碎片化。

实际操作步骤：

在服务启动时，为每路视频流预分配固定大小的TensorPool，并设置max_workspace_size为2.0GB，避免运行期动态分配。
将输入分辨率从动态（960x540~1920x1080）固定为1280x720，消除动态shape导致的碎片。
在服务中增加定时监控：每30分钟记录一次碎片率，超过50%时触发cudaDeviceReset()并重启推理进程。
将8路视频流拆分为两个进程，每个进程4路，分别绑定GPU的不同MIG实例（若硬件支持），实现显存隔离。

结果对比：优化后，9路视频流稳定运行72小时无OOM，显存峰值21.5GB，碎片率维持在15%以下。代价是启动时间增加约2秒（预分配耗时），但换来了长期稳定性。

复盘经验：多路视频场景中，OOM往往不是“显存不够”，而是“显存不连续”。固定shape + 预分配池 + 定期碎片监控是性价比最高的组合方案。

4.4 常见误区与总结复盘

在显存管理实践中，工程团队常陷入以下误区，导致问题反复出现：

  误区一：认为OOM只是batch size过大，盲目调小batch。实际上，碎片化导致的OOM与batch大小无关，调小batch反而可能增加碎片（因为分配块更小、更分散）。

  误区二：频繁调用torch.cuda.empty_cache()试图“清理”显存。该操作只释放空闲缓存块，对正在使用的张量无效，且频繁调用会降低性能。

  误区三：忽略多进程显存叠加。多个推理进程共享GPU时，每个进程的缓存池独立，总显存占用可能远超单进程估算。

  误区四：只在OOM发生时排查，缺乏主动监控。建议在服务中内置显存指标上报（碎片率、峰值占用、缓存块分布），实现预警。

总结复盘：显存管理的核心目标是降低峰值、减少碎片、快速定位。在架构层面，优先采用固定shape、预分配池、CUDA Graph等确定性分配策略；在运维层面，建立显存监控与预警机制，将碎片率作为关键指标；在故障处理层面，遵循“先看分布、再查快照、后算碎片、最后优化”的排查路径。多路视频部署的稳定性，很大程度上取决于显存管理的精细化程度。