课程导入：学习目标、适用人群、课程整体框架与学习路径

TensorRT 作为 NVIDIA 推出的高性能深度学习推理优化引擎，在工业界和学术界都扮演着举足轻重的角色。然而，许多开发者在实际部署中常常遇到一个棘手的问题：模型转换成功了，推理速度也达标了，但显存占用却居高不下，甚至出现显存溢出（OOM）导致服务崩溃。更令人困惑的是，TensorRT 的 workspace 参数（旧版本中称为 workspaceSize，新版本中为 memoryPoolLimit）究竟应该如何设置？设置太小会导致层融合失败、性能下降，设置太大又可能造成显存浪费或与其他服务争抢资源。本课程正是为系统性地解决这些问题而设计，我们将从显存分配机制出发，深入剖析 TensorRT 的构建期与运行期行为，并通过大量可复现的实验数据，帮助你建立一套科学的分析与调优方法论。

上图展示了本课程的整体框架。可以看到，我们将学习内容划分为三个递进模块：基础认知、分析方法、实战调优。这三个模块并非孤立存在，而是环环相扣——只有深刻理解了 TensorRT 的显存分配机制，才能正确使用分析工具；只有掌握了分析工具的输出含义，才能进行有针对性的调优。课程的最后，我们还会通过多个真实场景的案例复盘，将零散的知识点串联成一套完整的决策框架。

1.1 学习目标：从“能用”到“会用”再到“精通”

本课程的学习目标分为三个层次，对应不同的能力阶段。第一层次是“能用”，即能够正确配置 workspace 参数，使模型正常构建和运行，不出现 OOM 错误。第二层次是“会用”，即能够通过 NVIDIA 提供的性能分析工具（如 nsys、ncu）定位显存瓶颈，理解不同层类型（卷积、全连接、归一化、注意力等）的显存消耗特征，并据此调整网络结构或推理配置。第三层次是“精通”，即能够针对复杂的生产环境（多模型部署、动态输入形状、多 GPU 负载均衡）设计显存优化方案，在性能与资源占用之间找到最优平衡点。

为了达到上述目标，我们不仅需要学习 TensorRT 的 API 用法，更需要理解其底层的内存管理哲学。TensorRT 的显存管理可以概括为“构建期规划、运行期复用”八个字。在构建引擎时，TensorRT 会分析整个计算图，为每个张量分配“生命周期”，并尝试将生命周期不重叠的张量复用到同一块物理内存上。而 workspace 参数则决定了构建器在搜索层融合策略时，最多可以使用多少临时显存来存储中间计算结果。这个参数并不直接限制引擎运行时的显存总量，但它通过影响层融合的决策，间接改变了最终引擎的显存占用和推理延迟。

1.2 适用人群：谁需要这门课程？

本课程主要面向三类人群。第一类是算法工程师，他们训练好的 PyTorch 或 TensorFlow 模型需要部署到 GPU 服务器上，但经常遇到“训练正常、推理爆显存”的尴尬局面。第二类是推理平台开发工程师，他们负责维护多个模型的推理服务，需要确保不同模型之间不会因为显存争抢而互相影响，同时还要最大化 GPU 利用率。第三类是性能优化工程师，他们的任务是在给定的硬件资源下，将推理延迟压到最低，这往往意味着要在层融合、精度校准和显存复用之间做出精细的权衡。

对于初学者，我们建议先掌握课程中“基础认知”部分的内容，尤其是 TensorRT 的内存池模型和构建期/运行期的区别。对于有经验的开发者，可以直接跳到“实战调优”部分，结合具体案例进行针对性学习。无论你属于哪类人群，都需要具备一定的 Python 或 C++ 编程基础，并了解深度学习模型的基本结构（卷积、池化、全连接等）。如果你对 CUDA 编程有初步了解，那将更有助于理解显存分配的具体细节，但并非必需。

1.3 课程整体框架：30 章的系统化设计

本课程共 30 章，按照“基础 → 方法 → 实战 → 高级”四个阶段组织。第 1 章（本章）为课程导入，明确学习目标和路径。第 2 至 5 章为基础认知模块，深入讲解 TensorRT 的显存分配机制、内存池模型、构建期与运行期的区别，以及 workspace 参数在不同版本中的演变。第 6 至 10 章为分析方法模块，重点介绍如何使用 nsys、ncu、TensorRT 日志和自定义回调函数来测量显存占用。第 11 至 20 章为实战调优模块，覆盖卷积模型、Transformer 模型、动态形状、多模型部署等典型场景。第 21 至 25 章为高级主题，包括 CUDA 图优化、多流推理、显存池自定义、量化感知训练与显存的关系等。第 26 至 30 章为综合案例与复盘，通过三个完整的项目案例（图像分类服务、目标检测流水线、大语言模型推理）将所学知识串联起来。

每一章都遵循统一的结构：核心原理、判断方法或操作流程、案例拆解或实战场景、常见误区或总结复盘。这种设计是为了让你在学习过程中始终保持“理论—实践—反思”的闭环。例如，在第 11 章“卷积模型的显存优化”中，我们会先讲解卷积层在 TensorRT 中的内存访问模式，然后介绍如何通过 ALGO_PREFERENCE 选择不同的卷积算法，接着用一个 ResNet-50 的案例展示不同 workspace 设置下的显存与延迟对比，最后总结常见的误区（如盲目使用 TensorCore 导致小 batch 显存浪费）。

1.4 学习路径与建议：如何高效使用本课程

我们建议你按照以下路径进行学习。第一步，通读第 1 章至第 5 章，建立对 TensorRT 显存管理的基本认知，不需要记住所有细节，但一定要理解“构建期规划、运行期复用”的核心思想。第二步，在第 6 章至第 10 章中，跟随教程动手操作 NVIDIA 的性能分析工具，建议使用你自己的模型或课程提供的示例模型，完成至少一次完整的显存测量实验。第三步，进入实战调优模块后，不要急于尝试所有技巧，而是选择一个与你工作最相关的场景（如动态形状或 Transformer 模型），深入钻研对应的章节，并尝试复现案例中的实验数据。第四步，在完成所有章节后，回到第 26 至 30 章的综合案例，尝试在不查看答案的情况下独立完成优化任务。

在学习过程中，强烈建议你准备一张 GPU 显卡（NVIDIA Turing 架构或更新版本，显存不低于 8GB），并安装好 TensorRT 8.5 或更高版本、CUDA 11.8 或更高版本、Python 3.8 以上环境。课程中的所有实验代码都将在 GitHub 仓库中提供，你可以直接运行或修改。此外，我们还会在每章末尾提供“思考题”和“动手实验”两个板块，前者帮助你检验概念理解，后者则要求你独立完成一个小型实验。

1.5 案例拆解：一次典型的显存 OOM 排障过程

为了让你对本课程的价值有一个直观感受，我们来看一个典型的 OOM 排障案例。某公司的推理团队部署一个 BERT-base 模型（12 层 Transformer，隐藏维度 768）用于文本分类，使用 TensorRT 8.6 版本，GPU 为 NVIDIA A10（24GB 显存）。初始配置中，workspace 设置为 2GB，批量大小为 32，输入序列长度为 128。模型构建成功，但在运行推理时出现 CUDA error: out of memory。

团队首先检查了模型本身的参数量：BERT-base 约有 1.1 亿参数，FP16 精度下模型权重占用约 220MB。按理说，24GB 显存绰绰有余。但问题出在中间激活值上。在 Transformer 层中，自注意力机制需要保存 Q、K、V 矩阵以及注意力分数矩阵，这些中间张量的大小与批量大小、序列长度的平方成正比。对于批量 32、序列长度 128 的配置，单层 Transformer 的注意力分数矩阵大小为 32 × 12 × 128 × 128 = 6,291,456 个元素，FP16 下约 12MB。12 层 Transformer 加上 Embedding 层和分类头，总激活值显存占用约为 1.5GB。这看起来并不大，但问题在于 TensorRT 在构建引擎时，为了寻找最优的层融合策略，会在 workspace 中尝试多种算法，每种算法都会产生不同的中间张量布局。当 workspace 设置为 2GB 时，构建器可能选择了一种需要大量临时显存的融合方案，导致构建期显存峰值超过 24GB。

解决过程分为三步。第一步，使用 trtexec 工具（TensorRT 自带的命令行工具）重新构建引擎，并添加 --verbose 参数，观察构建日志中的显存分配信息。日志显示，在构建到第 8 层 Transformer 时，显存占用突然增加了 6GB，这是因为该层尝试了一种将 QKV 投影和注意力计算融合的算法，需要同时保存所有中间结果。第二步，将 workspace 从 2GB 降低到 1GB，重新构建。这次构建成功，但推理延迟从原来的 3.2ms 增加到 4.1ms，性能下降了约 28%。第三步，使用 nsys 对运行期进行剖析，发现显存占用峰值出现在第一个 Transformer 层，且存在大量的内存分配和释放操作。通过分析，团队决定采用“半精度 + 层间内存复用”的策略：在构建引擎时设置 setMemoryPoolLimit 为 1.5GB，并启用 setFlag 中的 kPREFER_PRECISION_CONSTRAINTS，允许 TensorRT 在部分层使用 FP32 计算以避免某些高显存消耗的融合。最终，在保持推理延迟 3.4ms（仅增加 6%）的情况下，将运行期显存峰值控制在 4.2GB，构建期显存峰值控制在 8GB 以内。

这个案例展示了本课程的核心方法论：显存问题不能只盯着 workspace 一个参数，而要从构建期和运行期两个维度分别分析。构建期显存峰值决定了你是否能成功生成引擎，运行期显存峰值则决定了你的服务能否稳定运行。两者之间往往存在矛盾——更大的 workspace 可能带来更优的层融合（降低运行期显存），但也会增加构建期显存压力。我们的目标是在两者之间找到平衡点，这需要系统性的测量和实验设计。

1.6 常见误区与总结复盘

在课程正式开始之前，我们先梳理几个初学者常见的误区，这些误区将在后续章节中反复出现并深入剖析。误区一：认为 workspace 越大越好。实际上，当 workspace 超过某个阈值后，层融合的收益会急剧递减，而构建期的显存峰值和构建时间会线性增长。误区二：混淆“构建期显存”和“运行期显存”。有些开发者发现构建引擎时显存占用很高，就认为推理时也会占用同样多的显存，从而不敢设置较大的 workspace。事实上，构建期使用的临时内存会在引擎序列化后释放，运行期显存主要由引擎中的持久化权重和激活值缓冲区决定。误区三：忽略批量大小对显存的影响。批量大小不仅影响激活值的大小，还影响 TensorRT 选择算法时的决策——某些算法在小批量下效率高但显存占用大，另一些则相反。误区四：在动态形状（Dynamic Shape）场景下使用固定的 workspace 配置。动态形状意味着输入尺寸在运行时可变，TensorRT 需要为最大可能的形状预留显存，这要求 workspace 的设置必须考虑最坏情况。

总结本章，我们明确了课程的学习目标、适用人群、整体框架和学习路径。显存优化不是一蹴而就的技巧，而是一套需要理论指导、工具辅助和实验验证的系统工程。在接下来的 29 章中，我们将逐步展开每一个知识点，从 TensorRT 的内存分配器原理，到 nsys 的详细使用教程，再到各种模型架构的专项优化，最终帮助你建立起自己的显存分析工具箱。请记住，每一次 OOM 都是一次学习的机会——当你能够准确回答“我的显存被谁占用了？为什么占用？如何减少占用？”这三个问题时，你就已经是一名合格的推理优化工程师了。