课程导入：CUDA显存碎片与TensorRT分配策略

学习目标：从“显存报错”到“分配策略”的认知升级

在深度学习推理与训练场景中，CUDA显存（GPU Memory）是最昂贵、最稀缺的硬件资源之一。许多工程师在部署模型时都遇到过类似困境：明明GPU显存总量足够，程序却抛出 CUDA out of memory；或者同一模型在不同批次大小下显存占用出现非线性的剧烈波动。这些现象的背后，往往不是显存“真的不够”，而是显存碎片化与分配策略不当共同作用的结果。

本节作为课程的第一章，将为你建立三个核心认知：

• 理解CUDA显存管理的基本架构——从设备端内存池到驱动层分配器，明确显存分配并非“随用随取”的简单操作。
• 识别显存碎片的成因与危害——区分内部碎片与外部碎片，理解为何频繁的分配/释放会导致可用显存“支离破碎”。
• 掌握TensorRT的显存分配策略——了解TensorRT如何通过内存池复用、张量生命周期规划来降低碎片化影响，并学会在工程中主动优化。

课程结构：五阶段递进式学习路径

全课程共30章，划分为五个递进阶段，每个阶段解决一类核心问题：

这种结构设计遵循“原理→检测→策略→实战→进阶”的认知曲线。每一章都包含理论讲解、代码示例、常见误区复盘三个固定模块，确保知识既能“看懂”也能“用上”。

核心原理：CUDA显存管理的三层架构

要理解碎片化，必须先看清显存分配的全链路。CUDA显存管理并非GPU硬件直接暴露给用户，而是经过三层抽象：

1. 设备端分配器（Device Allocator）：由GPU驱动维护，管理物理显存页。用户调用 cudaMalloc 时，实际是从驱动层的空闲列表中获取一段连续地址空间。
2. 运行时内存池（Runtime Memory Pool）：CUDA运行时（Runtime API）在驱动之上维护一个缓存池，用于加速频繁的小块分配。默认情况下，cudaMalloc 的内存块在释放后不会立即归还驱动，而是留在池中复用。
3. 应用层分配策略（Application-level Strategy）：即TensorRT、PyTorch等框架自行实现的内存管理逻辑。它们通过预分配大块显存、按需切分、延迟释放等手段，进一步降低对底层分配器的压力。

碎片化主要发生在第二层和第三层。当应用层频繁申请不同大小的内存块，且释放顺序与申请顺序不一致时，空闲内存被分割成多个不连续的小区域，即使总空闲量充足，也无法满足大块连续分配请求。

上图展示了三层架构中碎片产生的三个关键位置。值得注意的是，应用层策略对碎片的影响最大——因为TensorRT等框架控制着分配时机和块大小，它们的设计直接决定了底层内存池的碎片化程度。

案例场景：一次典型的显存碎片化故障

假设你正在部署一个实时视频分析服务，模型包含多个动态形状的张量（如检测框数量随帧变化）。初始配置如下：

# 伪代码示意
for each frame:
    boxes = model.detect(frame)          # 形状随帧变化
    features = model.extract(boxes)      # 动态batch
    model.nms(features)                  # 临时张量
    # 每帧结束后释放中间张量

运行数小时后，GPU显存占用从4.2GB缓慢增长至6.8GB，最终触发 CUDA out of memory。通过 nvidia-smi 查看，显存总量为8GB，但可用显存仅剩200MB。进一步使用 cuda-gdb 或Nsight Systems分析，发现大量 2MB~8MB 的空闲块散布在显存各处，无法合并成一个大块。

这个案例揭示了三个关键教训：

• 动态形状是碎片化的温床：每帧不同的张量尺寸导致分配器无法复用固定大小的内存块。
• 释放顺序与分配顺序不一致：后分配的张量先释放，导致空闲块不连续。
• 默认分配器缺乏合并机制：CUDA运行时不会自动合并相邻空闲块，除非它们恰好大小相同。

误区复盘：三个“想当然”的显存管理认知

在多年的CUDA开发与TensorRT部署经验中，以下三个误区反复出现，值得在课程开始时明确纠正：

这些误区的共同根源在于将显存视为“线性资源”，而忽略了其“地址空间连续性”这一关键属性。后续章节将逐一深入剖析这些问题，并给出可落地的解决方案。