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架构的核心拆解从一张卡到一个SM3.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芯片放大来看它的核心计算单元是SMStreaming Multiprocessor流式多处理器。一个GPU芯片上有几十到上百个SM比如A100有108个SMH100有132个SM。每个SM内部又包含一组CUDA Core负责普通的浮点/整数运算Tensor Core专门为矩阵乘加这类运算设计寄存器文件Register FileSM内最快的存储共享内存Shared MemorySM内可编程管理的缓存各种缓存和调度单元我特别喜欢用一个比喻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是40MBH100是50MBHBM显存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 TFLOPSTF32的算力约156 TFLOPSTensor Core加速FP16/BF16的算力约312 TFLOPSTensor 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到ThreadGPU的编程模型和硬件架构是强绑定的。你写CUDA Kernel时实际上是组织了一次“人员调度”。Grid整个Kernel启动的任务网格包含多个BlockBlock一个线程块会整体被调度到一个SM上WarpBlock内的线程会以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 (80GB)H100 (80GB)对Infra的影响FP16算力312 TFLOPS990 TFLOPS决定训练/推理的计算峰值BF16算力312 TFLOPS990 TFLOPSBF16对大模型更稳看这个更实际显存容量80GB80GB决定单卡能放多大的模型显存带宽2TB/s3.35TB/s决定数据搬运速度L2缓存40MB50MB影响访存密集任务的性能NVLink带宽600GB/s900GB/s决定多卡通信效率PCIe带宽64GB/s (Gen4)128GB/s (Gen5)影响数据传输和跨机通信注意这几列数字之间的比例关系。拿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 CoreHopper更进一步引入了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/sH100的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 DCGMData 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再到H100GPU架构的演进其实是三条线并行推进的算力增长、内存带宽增长、互联能力增长。V100Volta2017年发布首次引入Tensor CoreFP16算力约100TFLOPS。这一代确立了“混合精度训练”的可行性也让大模型的训练第一次变得“不那么难”。A100Ampere2020年发布TF32和FP16的Tensor Core性能大幅提升新增了稀疏化支持NVIDIA Ampere架构的2:4结构化稀疏理论上能提升2倍性能但实际落地场景有限。最重要的一点是A100的显存从16GB/32GB升到了40GB/80GB让单卡能装下更大的模型。H100Hopper2022年发布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算子的kernelSM利用率只有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与网络路径的协作跨节点训练还有一个经典问题明明上了InfiniBandNCCL AllReduce的实测带宽还是明显低于网卡的标称值。这通常是“数据路径”上出现了绕路。正常路径应该是GPU显存 - 网卡 - 网络中间尽量少经CPU内存做拷贝。但如果你没有开启GPUDirect RDMA数据就得先从GPU显存拷到CPU内存再经网卡发出去这一步的PCIe带宽和CPU内存带宽都可能成为瓶颈。排查方法很直接跑NCCL的allreduce测试脚本先测单机内的多卡通信带宽应该接近NVLink的数值再测跨机通信带宽。如果跨机数值只有标称的一半不到检查NCCL环境变量比如NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME这些设置以及是否加载了GPUDirect相关的内核模块。调通之后跨机通信带宽能提升50%以上。6.4 简要排查速查表症状可能的架构原因排查手段解决方向GPU利用率低但CPU高Kernel太小、启动开销大Nsight System看kernel时长算子融合、CUDA Graph捕获GPU利用率高但吞吐低访存瓶颈、全局显存搬运过多Nsight Compute看带宽利用率算子融合、共享内存优化显存OOM激活值爆炸、显存碎片用PyTorch显存追踪工具激活值重计算、更小批量gradaient accumulation多卡通信慢拓扑路径不优、未开GPUDirectNCCL测试脚本、拓扑查询调整NCCL环境变量、检查网络路径推理延迟高KV Cache访问未走优化profile kernel分布PagedAttention、KV Cache量化这个表值得你贴在工位上。实际排障中我发现自己90%以上的时间都花在“定位瓶颈在哪个硬件层级”上——是算力、是访存、是通信还是容量。一旦定位准确对应的优化工具箱就打开了。7. 我的一些个人经验讲到这里最后分享几个我做AI Infra这几年沉淀下来的判断不一定写在任何官方文档里但对日常工作确实很有用。第一永远不要只看GPU型号做容量规划。同一个A100跑不同精度的模型、不同框架版本、不同CUDA版本实际能发挥的性能可以差出30%-50%。做规划时宁可多花时间跑一两个基准测试也不要在扩容之后才发现性能不达标。第二性能分析工具一定要养成习惯。Nsight System和Nsight Compute虽然刚开始学习曲线有点陡但真的值得投入。我见过很多团队性能出了问题全靠猜“是不是网络慢”、“是不是存储慢”一猜就是几个小时。用工具定位五分钟就能锁定瓶颈层级。第三GPU架构知识要常看常新。从V100到A100到H100再到GH200、GB200这种CPUGPU超级芯片每一代都会带来新的互联方式、新的内存体系、新的精度支持。做Infra的人如果只盯着自己熟悉的架构很容易在新硬件落地时手足无措。说到底AI Infra这门技术表面上拼的是调度、监控、容错这些“管理功夫”但底层拼的是对硬件的理解有多深。GPU架构就是那块最短的木板。我自己的体会是把这块木板补上之后以前那些“玄学”一样的性能问题突然都变成了一道道有明确解法的应用题。这套系列后面我会接着聊CUDA编程模型、NCCL通信库、PyTorch分布式训练的原理每一篇都会带着实战案例去拆。如果你也想把AI Infra这条路走扎实先把GPU架构这些概念在心里立住后面会顺很多。
