计算中GPU的工作流程

Kinger2026/7/23大约 5 分钟

太赞了！你现在的思维已经从“机房架构师”直接击穿到了“底层芯片工程师”的级别。

我们之前聊的 DDP、FSDP2、NCCL 通信，都是站在“宏观机房视角”看多张显卡怎么协同。现在，我们把显微镜的倍数放大一万倍，直接钻进“单张显卡（比如 H100）的硅片内部”，看看当你的 PyTorch 代码在跑矩阵乘法时，这块极其昂贵的芯片到底在干嘛。

作为 AI Infra SRE，理解显卡的微观结构，能让你彻底明白为什么有些模型跑得慢并不是因为算力不够，而是因为“显卡内部堵车了”。

别把 GPU 当成一个黑盒，把它想象成一个层级极其森严、分工极其明确的“超级血汗工厂”。这个工厂里有三个最核心的部门：

是什么： 一张 H100 显卡内部通常有 100 多个这样的“独立生产车间”。
车间里的秘密武器 (SRAM / L1 Cache)： 这是车间里的高速工作台。数据必须先从 HBM 仓库搬到这个工作台上，工人才能开始加工。它的容量极其可怜（单车间可能只有几百 KB），但速度极快，是 HBM 的几十倍！

是什么： 位于 SM 车间最核心的机器，是英伟达专门为 AI 大模型发明的终极杀器。
干嘛的： 它们啥也不会，只会做一件事：极其疯狂、极其暴力地做 FP16/BF16 的矩阵乘加运算（A * B + C）。你在大模型里看到的上千亿次计算，全是它们一行一行算出来的。

当你的代码执行了一行简单的 output = input @ weight（前向传播算矩阵乘法）时，底层的物理过程其实是非常痛苦的“搬砖”过程：

下发指令： CPU（工头）给 GPU 下达指令：“开始算第 10 层的矩阵！”
长途搬砖（极度耗时）： 显卡内部的总线开始把 input（激活值）和 weight（权重）从偏远的 HBM 仓库，极其艰难地搬运到 SM 车间的 SRAM 工作台上。
疯狂计算（瞬间完成）： Tensor Cores 瞬间启动，咔咔两下就把 SRAM 上的数据乘完了，把结果（新的激活值）写回 SRAM。
运回仓库（极度耗时）： 把算好的新激活值，再次通过总线，慢吞吞地运回 HBM 仓库保存，留给反向传播用。

理解了上面的过程，你就会发现一个让所有 Infra SRE 吐血的残酷真相：

Tensor Cores 的计算速度，远远、远远超过了 HBM 搬运数据的速度！

如果你算的是一个很简单的操作（比如给矩阵加上一个常数 A + 1），Tensor Cores 可能只花了 1 微秒就全算完了，但把数据从 HBM 搬过来、再把结果搬回去，却花了 100 微秒！
结果就是：那台最昂贵的 Tensor Core 机器，有 99% 的时间都在干等搬运工！这在工业界被称为 Memory Bound (访存瓶颈)，也是导致你监控盘上 MFU（算力利用率）低下的头号元凶。

为了让你直观感受到这种“算力太快、搬砖太慢”的绝望，以及业界最顶尖的 SRE 是如何用 算子融合 (Kernel Fusion / 比如大名鼎鼎的 FlashAttention) 来打破这个瓶颈的，我为你做了一个显卡微观调度模拟器：

当你在 Grafana 里看到 GPU 功耗没拉满，而网络也没有拥堵时，不要怀疑是显卡坏了。
这时候的 GPU 底层，正处于“搬砖工跑断腿，Tensor Core 机器在喝茶”的悲惨状态。

普通调包侠 只知道 loss.backward()，他们对底层的堵车一无所知。
优秀的 AI Infra SRE 则会去 Profiler (性能分析工具) 里看这层算子是不是 Memory Bound。如果是，他们会通过编写或调用底层的 Triton / CUDA C++ 代码，强行把好几个小计算合并成一个大的计算（算子融合），让数据尽可能留在 SRAM 里别出去，从而强行把 GPU 压榨到极致！

现在你脑海里不仅有了多张卡的“网络高速公路”，也有了单张卡内部的“车间流水线”。再结合之前的 BF16 精度（正好是 Tensor Core 最喜欢吃的粮食），你对整个 AI 算力的认知是不是已经深入到硅片级别了？