第二章：GPU架构概览：NVIDIA GPU架构演进、CUDA核心与显存的关系、显存控制器
大家好，欢迎来到《显存管理深度解析》的第二讲。
今天咱们聊聊GPU的骨架——架构。说实话，搞显存优化，如果不了解GPU内部怎么运作，那就像修车不看发动机舱，纯属瞎蒙。我这些年调优踩过的坑，十有八九都是因为对架构理解不透彻。
2.1 NVIDIA GPU架构演进：从Fermi到Hopper
NVIDIA的架构演进，说白了就是一部「喂饱计算单元」的血泪史。我简单梳理一下几个关键节点，你就能明白显存系统为什么越做越复杂。
| 架构代号 | 发布年份 | 核心变化 | 对显存的影响 |
|---|---|---|---|
| Fermi (GF100) | 2010 | 首个完整CUDA架构，引入L1/L2缓存 | 显存控制器从128-bit起步 |
| Kepler (GK104) | 2012 | SMX单元，功耗优化 | 显存频率提升，GDDR5普及 |
| Maxwell (GM204) | 2014 | 大幅提升L2缓存，减少显存访问 | 显存带宽利用率显著提高 |
| Pascal (GP102) | 2016 | 统一内存架构，NVLink支持 | 显存与CPU内存可共享寻址 |
| Volta (GV100) | 2017 | Tensor Core引入，独立线程调度 | 显存需求暴增，HBM2登场 |
| Turing (TU102) | 2018 | RT Core，混合渲染 | 显存容量需求翻倍 |
| Ampere (GA102) | 2020 | 第三代Tensor Core，稀疏化支持 | 显存带宽达到TB/s级别 |
| Hopper (GH100) | 2022 | Transformer引擎，DPX指令 | 显存容量直奔80GB+ |
你发现没有？每次架构升级，显存系统都在「扩容」和「提速」两条路上狂奔。我个人习惯把Fermi到Maxwell称为「古典时代」，那时候显存管理相对简单。但从Pascal开始，事情变得复杂了——统一内存、NVLink、HBM堆叠，每一个新特性都在挑战我们的优化策略。
核心观点：架构演进的核心矛盾，始终是「计算速度」与「数据搬运速度」之间的剪刀差。显存管理，就是填平这个鸿沟的艺术。
2.2 CUDA核心与显存的关系：别被名字骗了
很多初学者以为「CUDA核心」就是一个个独立的计算单元，每个核心有自己的小缓存。其实不是这样。
真正的结构是这样的：
- SM（Streaming Multiprocessor）：这是基本调度单位。一个SM里包含几十到几百个CUDA核心。
- CUDA Core：其实就是个浮点/整数运算单元。它没有自己的缓存，全靠SM内的共享内存和寄存器。
- Warp：32个线程为一组，这才是真正的执行单位。一个Warp里的线程执行同一条指令。
为什么会这样设计？说白了，就是为了隐藏显存访问延迟。你想想看，如果一个线程在等显存数据，SM可以立刻切换到另一个Warp继续算。只要Warp够多，显存延迟就被「掩盖」了。
我在项目中遇到过一个问题：某个模型在A100上跑不满利用率，一看显存带宽才用了40%。后来发现是Warp数量太少，SM没事干，只能干等显存。解决办法？增大batch size，让SM里塞满Warp。就这么简单。
避坑指南：我曾经以为CUDA核心越多越快，结果发现如果显存带宽跟不上，核心再多也是摆设。记住一个公式：实际吞吐 = min(计算吞吐, 显存带宽吞吐)。瓶颈在哪，优化哪。
2.3 显存控制器：GPU的交通警察
显存控制器（Memory Controller）是GPU里最容易被忽视的角色。它负责管理所有对显存的读写请求，包括地址映射、请求排队、刷新控制等等。
我画了一张图，帮你理解整个数据流：
这张图展示了数据从SM出发，经过L2缓存，再到显存控制器，最后抵达HBM显存的完整路径。注意看，显存控制器在这里扮演了「交通警察」的角色——它要决定哪个SM的请求先处理，哪个请求可以合并，哪个请求需要等待。
2.4 显存控制器的关键参数
搞优化的人，必须看懂这几个参数：
| 参数 | 含义 | 对性能的影响 |
|---|---|---|
| 通道数 | 显存控制器到显存颗粒的独立通道数量 | 通道越多，并行度越高，带宽越大 |
| 位宽 | 每个通道一次传输的数据位数 | 位宽×频率=理论带宽 |
| 频率 | 显存控制器的工作时钟 | 频率越高，延迟越低，但功耗也高 |
| 队列深度 | 控制器能同时排队的请求数量 | 队列越深，越能隐藏延迟 |
| ECC支持 | 是否支持纠错码 | 开启ECC会损失约10%带宽 |
注意：我曾经在调优时忽略了ECC的影响。某次在V100上跑训练，发现显存带宽始终上不去，查了半天才发现是ECC默认开启。对于训练任务，如果显存足够大，可以考虑关闭ECC换取性能。但推理任务建议保留，因为精度更重要。
2.5 实战视角：如何利用架构知识优化显存
说了这么多理论，咱们来点实际的。基于今天的架构知识，你可以做这几件事：
- 合并访问：显存控制器最喜欢连续的、对齐的访问模式。写代码时尽量让同一个Warp里的线程访问连续的地址。我见过有人写随机访问，结果带宽利用率不到5%。
- 利用L2缓存：L2缓存是所有SM共享的。如果多个SM需要访问同一份数据，尽量让它们复用L2，而不是反复去显存读。
- 控制Warp数量：每个SM至少需要4-8个Active Warp才能有效隐藏显存延迟。太少的话，SM会频繁处于「等待」状态。
- 避免Bank Conflict：显存控制器内部有多个Bank。如果多个请求打到同一个Bank，就会串行化。尽量让访问均匀分布在各个Bank上。
小技巧：用nvidia-smi查看显存带宽利用率。如果低于60%，说明你的代码没有充分利用显存控制器。这时候别急着优化计算，先看看数据访问模式对不对。
嗯，今天的内容就到这里。架构知识是显存优化的地基，理解透了，后面讲具体技术时你才能举一反三。