2. 为什么AI Infra工程师非要啃GPU架构

说句实在话，很多做AI Infra的朋友一开始都是被分布式训练、模型推理、资源调度这些“上层建筑”吸引进来的，觉得GPU架构是硬件工程师或者做CUDA底层优化的人才需要研究的东西。但真正跑过几个大模型、调过几次显存、排查过几次训练变慢的问题之后，你就会发现一个残酷的现实：所有AI Infra的问题，最终都会坍缩成GPU架构的问题。

举个例子，你负责的平台上有用户反馈说多机训练速度上不去，你第一反应可能是网络瓶颈，查了NCCL的通信量、看了IB的带宽占用率，发现都没跑满。最后用Nsight System一抓，发现是GPU kernel内部访存模式不对，导致L2缓存命中率极低，数据在HBM和SM之间来回倒腾，时间全花在等数据上了。这种问题，不懂GPU架构的人根本无从下手。

所以这篇文章虽然是“入门”系列的第二篇，面向的是AI Infra方向的工程师、做MLOps/SRE的朋友，还有那些想从“调包侠”进阶到“调优侠”的算法同学。我会从GPU架构的几个核心层面拆开来讲——从物理硬件到编程模型、从算力到带宽、从单卡到多卡互联，最后结合我实际排查过的场景和调优经验，把那些文档里不会细说的坑和心得一起分享出来。

一句话总结这篇内容的定位：不追求让你设计GPU芯片，而是让你在调优、排障、做资源规划的时候，脑子里能有一个清晰的硬件模型，知道瓶颈到底卡在哪一层，往哪个方向做优化才有效。

3. GPU架构的核心拆解：从一张卡到一个SM

3.1 板卡级别：你看到的是一整块“异构计算单元”

我们日常接触到的GPU，无论是插在服务器里的A100/H100，还是消费级的RTX 4090，从Infra视角来看，首先它是一个完整的板卡设备。板卡上不仅有GPU芯片本身，还有显存颗粒、供电模组、散热器，以及关键的PCIe接口。

对AI Infra来说，板卡级别最重要的信息就是显存容量和显存带宽。因为大模型训练和推理，本质上就是在算力和显存之间做权衡。模型参数、梯度、优化器状态、中间激活值，全都得住在显存里。显存不够，模型就放不下，就得做各种切分；显存带宽不够，算力再强也白搭，因为GPU大部分时间在等数据从显存搬到计算单元。

比如A100的HBM2e显存带宽大概是2TB/s左右，H100的HBM3带宽能到3.35TB/s。这个数字意味着什么？意味着你哪怕不做任何计算优化，光是把一个40GB的模型参数从头到尾读一遍，在A100上就需要约20毫秒。而GPU做数学运算的速度，比从显存读数据的速度快一到两个数量级。这个概念就是经典的**“算力-带宽墙”**，后面讲kernel优化的时候会反复用到。

3.2 芯片级别：SM是GPU的“万能车间”

如果把GPU芯片放大来看，它的核心计算单元是SM（Streaming Multiprocessor，流式多处理器）。一个GPU芯片上有几十到上百个SM，比如A100有108个SM，H100有132个SM。每个SM内部又包含：

• 一组CUDA Core（负责普通的浮点/整数运算）
• Tensor Core（专门为矩阵乘加这类运算设计）
• 寄存器文件（Register File，SM内最快的存储）
• 共享内存（Shared Memory，SM内可编程管理的缓存）
• 各种缓存和调度单元

我特别喜欢用一个比喻：GPU就好比一个大食堂，SM是里面的一个个炒菜窗口，CUDA Core就是窗口里的大厨，Tensor Core是专门负责做“预制菜”的机器人，共享内存是窗口旁边的小操作台，寄存器是大厨手边的调料罐。

一个CUDA Kernel启动后，会被切分成很多个Block（线程块）分发到不同的SM上执行。SM内部的调度器再把Block里的线程切分成Warp（一般是32个线程一组）来实际执行。所以你会经常看到“Warp Divergence”（线程发散）这个词——意思是一个Warp里的32个线程如果走了不同的分支，那这些线程就得串行执行不同路径，效率会大打折扣。这就像大厨手下的帮厨各干各的，有人切菜有人炒菜，最后得等最慢的那个干完才能出餐。

3.3 内存层级：GPU的“数据栖息地”

GPU的内存层级，从快到慢、从近到远排列，大概是这样的：

• 寄存器（Register）：每个SM内部，最快，按线程独享
• 共享内存（Shared Memory）：每个SM内部，Block内线程共享，速度快，容量小（A100上每个SM约164KB可配置）
• L1缓存：SM内部，缓存最近的访存数据
• L2缓存：整个GPU芯片共享，体量较大（A100是40MB，H100是50MB）
• HBM显存（Global Memory）：板卡级，容量最大、速度最慢

这个层级关系，和CPU的L1/L2/L3/主存结构很像，但有个关键差异：GPU的共享内存是软件可管理的，程序员可以明确控制数据放哪里、什么时候搬运。这既是GPU编程最灵活的地方，也是最容易踩坑的地方。

很多新手写CUDA代码，一上来就把显存当内存用，每个线程都去Global Memory里读数据，结果就是慢到怀疑人生。真正的高性能kernel，一定是尽量把数据往寄存器、共享内存里塞，让计算单元尽可能在“家门口”拿数据。

3.4 算力单位：FLOPS、Tensor Core与精度换算

聊GPU架构不可能绕开FLOPS这个指标。FLOPS是浮点运算次数每秒，AI场景里经常看到的是TFLOPS（每秒万亿次浮点运算）。但这里有个“坑”必须讲清楚：同一个GPU，在不同精度下的FLOPS完全不同。

以A100为例：

• FP32的算力约19.5 TFLOPS
• TF32的算力约156 TFLOPS（Tensor Core加速）
• FP16/BF16的算力约312 TFLOPS（Tensor Core加速）
• FP8的算力约624 TFLOPS

这个数据揭示了一个关键信息：Tensor Core把矩阵运算的吞吐提高了一个数量级。这也是为什么大模型训练几乎强制使用混合精度的原因——不是单纯为了省显存，而是因为FP16/BF16在Tensor Core上的算力实在比FP32高太多了。

所以做AI Infra的人，在评估算力的时候，千万别只看“多少TFLOPS”这个大写数字，一定要问清楚是哪个精度下的。很多厂商宣传页上放的数字都是FP16甚至FP8的峰值性能，真实跑模型的时候，由于数据搬运、kernel launch开销、通信等待等因素，实际利用率能有30%-50%就算不错了。

3.5 线程模型：从Grid到Block到Warp到Thread

GPU的编程模型和硬件架构是强绑定的。你写CUDA Kernel时，实际上是组织了一次“人员调度”。

• Grid：整个Kernel启动的任务网格，包含多个Block
• Block：一个线程块，会整体被调度到一个SM上
• Warp：Block内的线程会以32个一组被分拆成Warp，这是硬件实际执行调度的最小单位
• Thread：最小执行单元

这个层级关系，决定了kernel在硬件上的执行效率和资源占用。比如你一个Block设了64个线程，那SM会调度2个Warp；你设了128个线程，那就是4个Warp。每个SM能同时驻留的Warp数量是有限的（A100是64个Warp），如果单个Block占用资源过多，SM能放下的Block数就少，并发度就低。

从AI Infra视角看，这个模型的直接意义在于：当你看到GPU利用率很低的时候，不一定是算力不够，很可能是kernel启动的线程规模太小，或者单个线程干的事情太多，导致SM没有“吃饱”。

4. AI Infra视角下的GPU核心参数

4.1 算力和带宽的经典平衡

任何一个AI Infra工程师，在规划训练任务、做容量评估的时候，脑子里都应该有这张“算力/带宽/容量”的三角平衡表。

注意这几列数字之间的比例关系。拿A100来说，FP16算力312TFLOPS，显存带宽2TB/s。假设一个kernel完全是访存密集型的（每个数据只被读一次，做个简单运算就写回），那它能达到的理论上限就是2TB/s的读写速度，大概相当于2T的“访问密度”。而如果是计算密集型的矩阵乘，每个数据元素会被重复利用多次（比如在GEMM里，一个A矩阵元素可能被用上千次），那就能跑出接近312TFLOPS的水平。

所以你在做性能分析的时候，第一件事就是判断这个任务属于计算密集型还是访存密集型。大模型训练里的矩阵乘法、注意力机制里的QK^T计算，都是计算密集型；而像LayerNorm、数据预处理、某些激活函数，则是访存密集型，优化这两种任务的思路是完全不同的。

4.2 Tensor Core为什么如此重要

Tensor Core是NVIDIA从Volta架构开始引入的专用矩阵计算单元。它跟CUDA Core最大的区别是：CUDA Core执行的是标量运算（一次算一个数），Tensor Core执行的是矩阵运算（一次算一个矩阵块）。

比如在Ampere架构上，Tensor Core一次可以完成一个4x4x4的矩阵乘加运算（两个4x4矩阵相乘，再加上一个4x4矩阵）。换算一下，一次Tensor Core操作等效于64次乘加运算，而CUDA Core做同样的运算需要执行64条独立指令。

这一变化对AI Infra的意义非常深远。因为深度学习计算的核心就是矩阵乘法（GEMM），包括全连接层、卷积层、注意力机制的QKV投影等，本质都是GEMM。Tensor Core直接把这条最热路径的吞吐提升了4-8倍，让大模型训练从“算不动”变成了“带宽和时间受限”。

很多Infra同学会问一个问题：Tensor Core是不是只能在FP16精度下用？并不是。Ampere引入了TF32（一种19位精度的格式），可以在FP32的语义下使用Tensor Core；Hopper更进一步引入了FP8，还提供了Transformer Engine，可以动态在一层内切换FP8和FP16。所以你在做精度选择时，不是单纯看模型稳定不稳定，还要看硬件在哪个精度下能发挥最大算力。

4.3 共享内存与寄存器：被忽视的性能宝库

说实话，很多写PyTorch的算法同学可能完全感知不到共享内存的存在，因为框架把kernel都封装好了。但如果你做的是高性能推理服务、自定义算子、或者要用CUDA Graph优化延迟，共享内存就是你绕不开的优化点。

共享内存（Shared Memory）是SM内的一块SRAM，读写延迟大概是几个周期，而全局显存（HBM）的延迟是几百个周期。差距是两个数量级级别。而且共享内存是程序员可控制的，不像L1缓存那样“自动但不透明”，你可以明确地把数据切成Tile，搬进共享内存，让一个Block内的线程反复使用这块数据。

经典的优化案例就是矩阵乘法。在不使用共享内存的朴素实现里，每个线程读取A矩阵和B矩阵的元素都从全局显存拿，一个Block内的不同线程会重复读很多次同样的数据，导致全局显存带宽成为瓶颈。而使用共享内存的优化版本，会先把A和B的Tile搬进共享内存，然后Block内的线程反复从共享内存读，全局显存只被访问一次，性能往往能提升数倍。

另一个被忽视的优化资源是寄存器（Register）。寄存器是SM内速度最快的存储，但数量非常有限（A100每个SM有64K个32位寄存器，均摊到所有驻留线程头上，每个线程也就一百多个）。如果kernel里变量太多，导致每个线程用的寄存器数超标，甚至触发“寄存器溢出”（register spilling），部分变量被挪去局部内存——那性能就会一落千丈。我见过一个案例，同样的kernel，就因为多声明了十几个数组，性能下降了快一倍，排查半天最后发现是spilling惹的祸。

4.4 通信互联：多卡和跨机场景的命脉

AI Infra做久了你就发现，单卡性能再强也有限，真正考验架构能力的，是多卡和跨机的通信效率。先说NVLink，这是NVIDIA的板载/机内高速互联总线。在一个8卡DGX节点里，每张卡通过NVLink和其他卡直连，形成一个全互联拓扑。NVLink的口径很大——A100上的NVLink 3.0带宽是600GB/s，H100的NVLink 4.0能到900GB/s，这比PCIe Gen5的128GB/s高了快7倍。

为什么NVLink这么关键？因为大模型训练在数据并行和模型并行时，需要在GPU之间不断同步梯度。以数据并行为例，每个GPU算出一份梯度之后，需要做一次AllReduce，把各卡的梯度加起来再平均。如果通信链路带宽不够，那GPU可能算10毫秒、通信等20毫秒，整体效率就被拉下来了。NVLink能让单机8卡内的通信接近“内存访问”的速度，这也是为什么DGX和HGX服务器现在是大模型训练的标配。

跨机通信又是另一套逻辑。机与机之间走的是RDMA网络，比如InfiniBand或RoCE。这时候，数据路径是：GPU显存 -> NVLink/PCIe -> CPU内存 -> PCIe -> RDMA网卡 -> 网络 -> 另一台机器。每经过一段，都有额外的拷贝和延迟。新一代的GPUDirect RDMA技术允许网卡直接读写GPU显存，绕过CPU内存拷贝，能把跨机通信延迟降低三分之一以上。

所以Infra工程师在规划训练集群时，除了看“每卡多少算力”，更要看：

• 单机内部是NVLink全互联还是PCIe Switch桥接？
• 跨机是IB还是RoCE？拥塞控制有没有开？
• 网卡到GPU的路径是否支持GPUDirect？

这三个问题的答案，直接决定了你集群的“有效算力”能发挥出几成。

5. 实操指南：如何用GPU架构知识指导日常Infra工作

5.1 训练任务的性能分析套路

我平时排查训练性能问题，有一个固定的三步走套路，分享给大家。

第一步，看通信占比。训练跑起来之后，先看NCCL相关的耗时占了多大的比例。最简单的方式是看NVIDIA DCGM（Data Center GPU Manager）的指标，或者用Nsight System抓一个iteration的trace。如果通信时间超过整体迭代时间的20%，那这就是个大问题，需要检查通信拓扑、是否跨机、NCCL的设置、甚至和GPU计算是否重叠（overlap）了。

第二步，看GPU Kernel利用率。用Nsight Compute分析单个kernel，看SM的活跃度、Tensor Core利用率、访存带宽利用率。如果SM活跃度低于70%，大概率是kernel太小或者线程配置不当；如果Tensor Core利用率很高但整体FLOPS只有理论值的1/4，可能是数据搬运跟不上。

第三步，做合理化的环境对照。同一个模型，在单卡环境下跑一遍，在8卡环境下再跑一遍，算出扩展效率。如果8卡只有单卡的4-5倍，那就说明通信成了瓶颈。这时候再看拓扑图，确认是不是所有卡都在同一个NVLink域里，还是跨了PCIe Switch。

5.2 用CPU与GPU类比理解关键概念

很多刚入门的朋友问我，CPU和GPU到底差在哪？我一般用一句话回答：CPU是“什么都会的全能选手”，GPU是“只会几个动作但人海战术的流水线工人”。

CPU的单个核非常强，可以处理复杂的指令分支、乱序执行、分支预测，适合跑操作系统、数据库这类逻辑复杂的任务。GPU的单个线程非常“弱”，只能跑简单的数学运算，但你同时可以启动几万甚至几十万个线程，用数量摊平延迟。

这个区别直接决定了AI的工作负载为什么天然适合GPU：神经网络的计算就是大量重复的矩阵乘法和卷积，没有复杂的分支逻辑，属于“一个指令跑千万次”的类型。而AI Infra另一部分工作——比如数据处理、动态shape处理、控制流逻辑——则更偏向CPU。

所以你在做资源调度的时候，得考虑的不只是“把GPU分给谁”，还得想清楚CPU核要配多少，内存要配多少，因为数据预处理和Python侧的控制流都在CPU上跑，CPU跟不上，GPU照样闲着。

5.3 V100、A100、H100三代架构的演进逻辑

从V100到A100再到H100，GPU架构的演进其实是三条线并行推进的：算力增长、内存带宽增长、互联能力增长。

• V100（Volta）：2017年发布，首次引入Tensor Core，FP16算力约100TFLOPS。这一代确立了“混合精度训练”的可行性，也让大模型的训练第一次变得“不那么难”。
• A100（Ampere）：2020年发布，TF32和FP16的Tensor Core性能大幅提升，新增了稀疏化支持（NVIDIA Ampere架构的2:4结构化稀疏，理论上能提升2倍性能，但实际落地场景有限）。最重要的一点是，A100的显存从16GB/32GB升到了40GB/80GB，让单卡能装下更大的模型。
• H100（Hopper）：2022年发布，FP8 Tensor Core配合Transformer Engine，让大模型训练在精度损失可控的情况下，算力又翻了一倍多。同时NVLink 4.0的带宽提升到900GB/s，专为大语言模型优化。

从Infra角度看，三代架构的变化带来一个明确趋势：单卡能承载的模型规模越来越大，多卡通信效率越来越高，训练大模型的成本门槛在不断降低。

这也意味着，你的容量规划不能再按“V100时代”的思维去定规格。比如以前一个十几B的模型可能要8张V100才能装下，现在H100的80GB显存加上FP8精度支持，2-4张卡就能跑推理服务。成本结构和量化策略都得重新算。

5.4 选型与容量规划：从模型需求反推GPU配置

做Infra的经常会遇到算法同学来问“我想跑一个7B/13B/70B的模型，需要什么GPU？”。这里给你一个通用的估算框架。

第一步，算模型参数占用。以7B模型为例，用FP16/BF16保存参数的话，每个参数量占2字节，所以参数本身占用约14GB。训练的显存占用除了参数，还有梯度和优化器状态（比如Adam优化器要额外存一阶动量和二阶动量，每个都是2字节），再加上中间激活值。粗略估算，训练7B模型至少需要7 * 12 = 84GB左右的显存，单张80GB的A100就很紧张了，通常需要张量的并行切分。

第二步，算推理显存占用。推理比训练简单得多，主要就是参数 + KV Cache + 激活值。7B模型FP16推理，参数14GB，加上输入序列的KV Cache（和batch size、序列长度相关），一张80GB的GPU是可以跑的，但如果你要做长文本、大并发，就得考虑多张卡分片部署。

第三步，反推算力需求。推理服务延迟要求如果是每秒输出多少个token，可以用“模型参数量 * 2”估算每生成一个token所需的计算量（FLOPs），再反推需要的GPU算力。

这个评估框架虽然粗糙，但能省去大量来回沟通的时间。Infra工程师的价值也正体现在这里：不是简单“给你几张卡”，而是从模型的参数规模、精度要求、并发需求、延迟目标出发，给出合理的资源套餐和扩展路径。

6. 实战排障：GPU架构引发的经典问题与排查方法

6.1 GPU利用率很高但性能上不去？问题可能藏在“访存”里

我遇到过一个典型案例：一个推理服务的GPU利用率（DCGM里的GPU Utilization）显示超过90%，但端到端的吞吐还是达不到SLA要求。同事都以为是模型太复杂，或者框架有bug。

后来我用Nsight Compute逐层分析kernel，发现有一个LayerNorm算子的kernel，SM利用率只有30%，但全局显存的读写负载几乎是满载状态。问题一下就清楚了：这个kernel把整个隐藏层的张量从显存读了一遍、做完归一化又写回显存，而实际计算只是简单的求均值和方差。这是个典型的访存密集操作，GPU处理它的时候，算力完全在“空转”等数据。

解决办法也简单：把这个LayerNorm和相邻的算子做算子融合（Operator Fusion），让归一化操作在读数据后马上就做，不需要把中间结果写回全局显存再读出来。融合之后，全局显存读写量直接减半，端到端延迟降低了约30%。

这个案例给我们的启发是：GPU Utilization高不等于GPU工作效率高，高Utilization有可能是在做无效的搬运。真实瓶颈要靠看“内存带宽利用率和Tensor Core利用率”来定位。

6.2 多卡训练时Batch Size增大导致显存溢出

另一个高频问题：多卡训练时，单卡Batch Size不能太大，否则显存溢出。很多同学第一反应是换更大的GPU，或者疯狂调PyTorch的gradient accumulation参数。实际上，在GPU架构层面，有一种优化叫激活值重计算（Activation Recomputation），或者叫“梯度检查点”。

为什么要引入这个方案？因为显存里装的大头，往往不是参数和梯度，而是中间激活值。比如一个BERT-large模型，训练时中间激活值占用的显存可能是参数显存的几倍。如果每个Transformer层的前向传播结果都保留在显存里，那深层模型的显存需求是爆炸式增长的。

激活值重计算的思路是：前向传播时只保存每个层的输入（或者只保存一部分关键张量），反向传播需要计算梯度时，再临时重新做一次前向，把激活值算回来。这样做的代价是约多30%的计算量，但显存占用可以降低50%-70%。

我个人的体会是，在容量管理和性能之间做权衡时，激活值重计算通常是性价比最高的手段之一。尤其是你的模型刚好卡在“一张卡装不下、两张卡又浪费”的尴尬地带，这个优化能帮你硬塞进单卡，省下翻倍的机器成本。

6.3 多节点通信掉速：NVLink与网络路径的协作

跨节点训练还有一个经典问题：明明上了InfiniBand，NCCL AllReduce的实测带宽还是明显低于网卡的标称值。这通常是“数据路径”上出现了绕路。

正常路径应该是：GPU显存 -> 网卡 -> 网络，中间尽量少经CPU内存做拷贝。但如果你没有开启GPUDirect RDMA，数据就得先从GPU显存拷到CPU内存，再经网卡发出去，这一步的PCIe带宽和CPU内存带宽都可能成为瓶颈。

排查方法很直接：跑NCCL的allreduce测试脚本，先测单机内的多卡通信带宽（应该接近NVLink的数值），再测跨机通信带宽。如果跨机数值只有标称的一半不到，检查NCCL环境变量，比如NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME这些设置，以及是否加载了GPUDirect相关的内核模块。调通之后，跨机通信带宽能提升50%以上。

6.4 简要排查速查表

这个表值得你贴在工位上。实际排障中，我发现自己90%以上的时间都花在“定位瓶颈在哪个硬件层级”上——是算力、是访存、是通信，还是容量。一旦定位准确，对应的优化工具箱就打开了。

7. 我的一些个人经验

讲到这里，最后分享几个我做AI Infra这几年沉淀下来的判断，不一定写在任何官方文档里，但对日常工作确实很有用。

第一，永远不要只看GPU型号做容量规划。同一个A100，跑不同精度的模型、不同框架版本、不同CUDA版本，实际能发挥的性能可以差出30%-50%。做规划时，宁可多花时间跑一两个基准测试，也不要在扩容之后才发现性能不达标。

第二，性能分析工具一定要养成习惯。Nsight System和Nsight Compute，虽然刚开始学习曲线有点陡，但真的值得投入。我见过很多团队，性能出了问题全靠猜，“是不是网络慢”、“是不是存储慢”，一猜就是几个小时。用工具定位，五分钟就能锁定瓶颈层级。

第三，GPU架构知识要常看常新。从V100到A100到H100，再到GH200、GB200这种CPU+GPU超级芯片，每一代都会带来新的互联方式、新的内存体系、新的精度支持。做Infra的人如果只盯着自己熟悉的架构，很容易在新硬件落地时手足无措。

说到底，AI Infra这门技术，表面上拼的是调度、监控、容错这些“管理功夫”，但底层拼的是对硬件的理解有多深。GPU架构，就是那块最短的木板。我自己的体会是，把这块木板补上之后，以前那些“玄学”一样的性能问题，突然都变成了一道道有明确解法的应用题。

这套系列后面我会接着聊CUDA编程模型、NCCL通信库、PyTorch分布式训练的原理，每一篇都会带着实战案例去拆。如果你也想把AI Infra这条路走扎实，先把GPU架构这些概念在心里立住，后面会顺很多。