GPU硬件架构基础：SM与CUDA Core、显存层次结构

大家好，我是你们的老朋友。今天咱们聊聊GPU的硬件架构。说实话，搞吞吐优化和显存优化，不懂硬件就像开车不看仪表盘——能跑，但迟早要出事。

我个人习惯，拿到一块新GPU，先看它的SM数量和显存带宽。为什么？因为这两个数字直接决定了你能跑多快、能装多大模型。咱们今天就把这两块掰开揉碎了讲。

SM与CUDA Core：GPU的“车间”与“工人”

SM（Streaming Multiprocessor）是GPU的核心计算单元。你可以把它想象成一个车间，每个车间里有很多工人——这些工人就是CUDA Core。

一个SM里通常包含：

• CUDA Core：负责整数和浮点运算。说白了就是干活的。
• Tensor Core：专门做矩阵乘加，AI训练和推理的利器。
• Warp Scheduler：调度32个线程为一组的warp。
• Register File：寄存器文件，速度最快但容量最小。
• Shared Memory：共享内存，同一个SM内的线程可以互相访问。

我记得刚入行时，以为CUDA Core越多越好。后来踩了个坑：在某个项目里，我用了A100（6912个CUDA Core），结果跑小batch推理时，性能还不如V100（5120个CUDA Core）。为什么？因为SM数量没变，但每个SM的调度开销大了。

你想想看，一个SM里有4个Warp Scheduler，每个调度器每周期可以发射两条指令。如果代码里分支太多，warp divergence严重，那调度器就闲着了。嗯，这里要注意：尽量让同一个warp里的线程走相同的执行路径。

显存层次结构：从HBM到寄存器

GPU的显存层次，说白了就是一个速度与容量的权衡游戏。从上到下，速度越来越慢，容量越来越大。

层级	典型容量	带宽	延迟
寄存器	256KB / SM	~20 TB/s	1 cycle
Shared Memory	48-164KB / SM	~10 TB/s	~20 cycles
L1 Cache	128-256KB / SM	~5 TB/s	~30 cycles
L2 Cache	40-80 MB	~2 TB/s	~200 cycles
HBM（显存）	40-80 GB	~2 TB/s	~400 cycles

看到这个表格，你可能会问：为什么HBM带宽这么高，延迟还是那么大？

原因很简单：HBM离计算单元远啊。数据要从显存跑到SM，中间要经过L2、L1、寄存器，每一步都有延迟。我曾经在优化一个Transformer模型时，发现大部分时间都花在数据搬运上，真正计算的时间不到20%。这就是典型的带宽瓶颈。

带宽与延迟的权衡：你该关注哪个？

很多新手一上来就问：怎么降低延迟？其实，对于GPU来说，带宽比延迟更重要。

为什么？因为GPU通过大量并行来隐藏延迟。一个warp在等数据时，调度器会切换到另一个warp。只要你有足够的warp来切换，延迟就被“隐藏”了。

我举个例子：假设一个SM能同时调度64个warp，每个warp的延迟是400 cycles。那只要每个warp的计算量足够小，调度器就能无缝切换，让ALU始终忙碌。这就是延迟隐藏。

但带宽不行。带宽是物理上限，你没法隐藏。HBM的带宽就那么多，你一次能搬的数据就那么多。所以，优化带宽才是王道。

知识体系结构图

下面这张图，是我自己总结的GPU硬件架构知识体系。你看一眼，就能明白各个组件之间的关系。

这张图把GPU分成两大块：计算单元和存储层次。计算单元的核心是SM，里面装着CUDA Core、Tensor Core这些“工人”。存储层次则从寄存器一路到HBM，速度越来越慢，容量越来越大。

我个人建议，做优化时先看这张图，问自己三个问题：

1. 我的数据在哪个层级？
2. 我的计算在哪个SM？
3. 数据从存储到计算，要走多少步？

这三个问题想清楚了，优化方向就明确了。

好了，这一章就到这里。记住：理解硬件，才能驾驭硬件。下一章咱们聊聊如何用这些知识做实际的吞吐优化。