在进入正文之前做AI Infra的兄弟估计都经历过这种尴尬别人嘴里蹦出SM、Tensor Core、HBM、NVLink自己只能微笑点头然后回来偷偷查资料。尤其是看GPU规格表的时候只看显存大小和CUDA核心数别的参数一律划过。这不怪你因为网上讲GPU架构的教程不是照搬NVIDIA官方白皮书翻译就是堆术语让人越看越懵。但这个坎过不去AI Infra就干不深。做训练的人要知道为什么数据并行到32卡扩展比上不去做推理的人要知道为什么A100跑小模型比4090还慢做K8s调度的人要知道为什么有些Pod必须绑定在特定节点上——这些问题的根源全都在GPU架构里。这篇就是入门第二篇我打算把GPU架构里跟AI Infra最相关的几个核心概念掰开揉碎讲透从SM到显存再到卡间互联把每个为什么都解释到位。不搞那种读起来跟天书一样的架构图就当作一个懂硬件的同事在给你讲内部知识。1. GPU架构到底在解决什么问题1.1 从一个矩阵乘法说起CPU为什么跑不动先做一个思想实验。假设我们要算两个4096乘4096的矩阵相乘这是大模型里注意力机制的最基础操作。直接算的话要做大概690亿次乘加运算4096的三次方乘以2大约700亿次浮点操作。如果用一颗很强的CPU比如双路64核的服务器理论浮点算力大概在2到4 TFLOPS左右也就是每秒2到4万亿次浮点运算。跑一次这个矩阵乘法需要大约2到3秒。听起来好像也不慢对吧但问题在于大模型训练可不止做一次矩阵乘法。一个70B参数的大模型一次训练step要在每个token上跑几百次这样的矩阵运算一次step要处理几万到几百万个token。算下来一个step需要的总浮点操作数动辄几十PFLOPs1 PFLOPs 1000万亿次。用CPU一天24小时跑可能几个月都训不了一个像样的模型。那GPU是怎么解决这个问题的思路特别朴既然一个核跑不快那我就堆几千个核一起跑。一个A100有6912个CUDA核心每个核心频率只有1.4GHz左右单核算力远不如CPU但6912个核同时开工叠加Tensor Core的特殊设计峰值算力可以到312 TFLOPSFP16稠密比双路CPU高两个数量级。这就是GPU的基本哲学用海量简单计算单元并行替代少量复杂计算单元串行。1.2 AI Infra视角GPU是台偏科的计算机做AI Infra的人脑子里必须有一个概念GPU不是一台通用的计算机它是一台为了吞吐而优化的偏科机器。它擅长的是大批量、高并行、计算密集型的任务而一旦遇到分支多、串行依赖强、访存随机的任务表现就很拉胯。在AI Infra的语境里我们关心GPU的无非就四个指标算力FLOPS每秒能做多少次浮点运算决定算得快不快。显存带宽Memory Bandwidth每秒能从显存里读多少数据决定数据喂得上喂不上。显存容量Memory Capacity能装下多大的模型、多大的batch决定单卡能干什么活。互联带宽Interconnect Bandwidth卡与卡之间数据交换的速度决定多卡能不能scale。这四个指标共同决定了一个GPU在AI链路里的实际价值缺一个都会变成瓶颈。而且这四个指标之间还经常打架显存容量大了带宽不一定高算力高了可能功耗也上去了机房散热和电费都是真金白银。这就是为什么AI Infra需要懂架构——因为选型、规划、排查故障的每一步都建立在理解这些参数之间关系的基础上。2. 拆解GPU核心从SM到Tensor Core2.1 SM一切并行度的起点GPU的最小并行计算单元叫SMStreaming Multiprocessor流式多处理器。以Ampere架构的A100为例一颗芯片上总共有108个SM。每个SM内部又包含若干个CUDA CoreA100的每个SM里有64个FP32 CUDA Core这样一算就是108乘以64约等于6912个CUDA核心。但这里有个关键细节GPU不是以单个线程为单位调度计算的而是以warp为单位。一个warp是32个线程GPU的调度器每次把一个warp里的32个线程同时分发到SM上执行。如果这32个线程走的指令是一致的也就是SIMT模式单指令多线程就一起执行一旦出现分支比如if elsewarp里的线程走了不同的路径就会分叉执行性能就会下降。这是我们排查GPU利用率上不去时经常忽略的一个原因。每个SM里还有围绕执行单元配套的东西寄存器堆Register File、共享内存Shared Memory、L1缓存、线程调度器Scheduler等。做AI Infra不一定要抠到每个细节但必须明白一件事SM的数量决定了并行度的上限而每个SM内部资源寄存器、共享内存充足与否决定了这个并行度能不能真正跑满。比如你启动的CUDA核函数里用了太多寄存器导致每个SM能同时驻留的线程块变少occupancy占用率就掉下来了算力自然会打折。这就像一家餐厅本来有100张桌子但每张桌子要占80平米的面积实际只能摆下30张接待量自然上不去。2.2 Tensor CoreAI时代的胜负手如果说CUDA Core是为了通用并行计算准备的那Tensor Core就是NVIDIA专门给深度学习埋的外挂。Tensor Core的本质是在硬件层面实现了一次指令完成一个4x4x4的小矩阵乘加的操作。GPU的通用核心需要一条指令做一次乘加而Tensor Core可以在一个时钟周期内完成一个4x4矩阵乘以4x4矩阵再加一个4x4矩阵的累积操作。这个效率提升是非常明显的。拿A100举例FP32 CUDA Core的算力是19.5 TFLOPS而加上Tensor Core之后FP16算力是312 TFLOPS差距超过16倍。Tensor Core支持的数据精度也很有讲究。AI训练里最常用的是FP16和BF16。FP16的好处是显存占用减半、计算速度翻倍但它的表示范围有限大数容易溢出所以训练时经常配合混合精度策略——梯度用FP32保存计算用FP16。BF16是Google后来推的指数部分和FP32一样范围够大但尾数精度低所以现在大模型训练更偏好BF16。到了H100还有一个FP8格式进一步压缩精度、提速主要用于推理场景。做AI Infra的在实际部署模型时一定要弄清楚你的推理框架到底用没用上Tensor Core。如果所有算子都跑在CUDA Core上GPU算力利用率可能连20%都不到但你以为卡已经满负荷了。很多GPU利用率高但速度慢的诡异现象往深了查都是Tensor Core没用上——算子没有融合或者是旧版本框架不支持某些精度导致的。2.3 三代架构变化的启示从Volta到Ampere再到HopperGPU架构并不是简单的堆核心数。以NVIDIA三代数据中心卡的演进为例几个关键变化很能说明架构设计的思路第一代VoltaV100首次引入了Tensor Core概念把FP16算力拉到125 TFLOPS直接改变了深度学习训练的游戏规则。AmpereA100则做了两个重大决策引入TF32格式让Tensor Core可以利用FP32的输入数据不用转FP16就能享受Tensor Core加速显著改善训练精度问题同时大幅加强了NVLink互联为多卡训练铺路。到了HopperH100更是推出了Transformer Engine可以根据不同层自动切换FP8和FP16把Transformer模型训练再提一个档次。从AI Infra角度看每次架构迭代带来的不光是算力提升还伴随着功耗的急剧上涨。V100单卡功耗300WA100到了400WH100直接到了700W一台8卡的H100服务器满载功耗接近6kW相当于一个家用小锅炉。这直接影响了IDC建设机柜散热、配电容量、制冷方案全部要重新设计。很多公司不是买不起H100而是机房的柜子撑不住——单机柜功率上限5kW的传统数据中心根本塞不下8卡H100服务器。做AI Infra的如果不懂这点规划时准会踩坑。3. 显存层次带宽比算力更值钱3.1 为什么HBM是AI的命根子把GPU的算力和访存分开看就能发现AI里一个很扎心的事实算力增长的速度远快于带宽增长的速度。A100相比V100FP16算力翻了2.5倍但HBM2的带宽只从900GB/s涨到1.6TB/s左右没跟上。到了H100带宽到3.35TB/s但FP8算力已经飙到近2000 TFLOPS差距依然在拉大。这意味着什么意味着一个计算强度不高的算子比如逐元素操作element-wise或者简单的归约数据从显存搬到计算单元的时间比实际计算的时间还要长——这就是所谓的访存密集型任务。这种情况下GPU算力再高也只是个等饭吃的厨子锅热到飞起但菜就是送不上来。HBMHigh Bandwidth Memory高带宽内存就是为了解决这个问题而生的。它跟普通显卡用的GDDR显存不一样不是平铺在PCB上而是通过2.5D封装技术垂直堆叠在GPU核心旁边用密密麻麻的硅通孔TSV做数据通道。类比一下GDDR像是城市外环的快速路路面宽但路程远HBM像是直接在地底下挖了几百条隧道通到市中心路程极短但出口极多。HBM的位宽可以做到4096位甚至更大GDDR通常只有32位到64位所以HBM的带宽能轻松到几个TB/s。3.2 算算账roofline模型与计算访存比既然带宽和算力是两种不同的资源那么我们怎么判断一个模型跑在GPU上到底是算力瓶颈还是带宽瓶颈业界通常用Roofline模型来定性地回答这个问题。核心就一个公式计算强度Arithmetic Intensity 总浮点操作数 / 总字节访存量单位是FLOP/byte。GPU平台的屋顶是一条斜线和一条水平线拼成的斜线是带宽上限水平线是算力上限。如果计算强度低于某个临界点性能就会被带宽卡住高于临界点才会触及算力天花板。打个具体点的比方。一个reshape操作读1GB数据做1亿次运算计算强度极低纯粹是带宽游戏换再贵的卡都差不多而一个大的矩阵乘法读入400GB的数据做几十PFLOPS的计算属于典型算力敏感型操作必须上Tensor Core才能跑得快。这就是为什么大模型训练要用高带宽的HBM而一些数据预处理任务用普通卡就够了。3.3 显存容量为什么H200往141GB走做AI Infra的同学还关心另一个参数显存容量。这个模型要70GB显存80GB的卡够不够要不要买H200的141GB版本这类问题是日常。显存容量直接影响的是单卡能容纳的模型规模。大模型推理时要加载模型权重还要预留KV Cache推理过程中缓存每个token的Key和Value加快生成速度上下文窗口越长、并发越高KV Cache越占显存。也正因如此H100从80GB升级到H200的141GB看起来只是容量多了76%但在大模型推理场景里它能支持的上下文长度和并发度能翻好几倍。这不只是装得下的问题更是跑得久、跑得多的问题。但容量大不等于万事大吉。有些推理框架为了把更多请求塞进同一张卡把KV Cache量化压缩省下显存却损失了精度、增加了延迟。有些场景里显存大但带宽不够推理速度反而不理想。正确理解显存容量和带宽的关系是AI Infra做容量规划的基本功——别只看表面容量要顺着模型推理链路把每部分显存开销都算一遍。4. 卡间互联单卡强不算强集群才算数4.1 多卡训练的通信账单单张GPU再强总有装不下的一刻。大模型动辄几百GB的参数单卡肯定放不下于是就有了多卡训练。但多卡训练不是简单地把模型切几块丢到几张卡上跑而是要处理卡与卡之间的数据同步。以最基础的数据并行Data ParallelismDP为例。每张卡上有模型的完整副本各自处理不同的batch数据算完梯度以后需要把梯度在所有卡之间做一次全量同步AllReduce保证每张卡拿到的梯度平均值一样才能更新出同一个模型参数。这个过程就是通信开销的来源。算一下这个账单。假设模型70B参数用BF16训练每个参数占2字节那么一次梯度同步要传输大约140GB的数据。在8卡A100上用NVLink互联拓扑好的话可以做到600GB/s左右的有效带宽同步一次需要约0.23秒但如果你用的是普通千兆以太网按1GB/s算要140秒——训练完全无法进行。这就是为什么做AI Infra的人看到有人用普通网卡组多卡训练会血压飙升的原因。4.2 NVLink和NVSwitch把GPU变成一台大GPU解决卡间通信的NVIDIA方案最早是PCIe后来是NVLink再到现在的高端服务器里加上NVSwitch。PCIe 4.0 x16的带宽大约32GB/s双向听着还行但跟NVLink一比就是天壤之别。A100时代NVLink 3.0单条链路提供600GB/s双向带宽H100的NVLink 4.0更是做到900GB/s。这比PCIe快了接近30倍。但是有个问题如果8张卡两两之间都要高速互联怎么连连线数量会爆炸。于是出现了NVSwitch——你可以理解成一个超级交换机让8张卡之间的通信全部通过这个中心节点转发任何两张卡之间都有高带宽通道。在8卡A100/H100服务器里靠的正是这一整套 NVLink NVSwitch 机制让8卡集群在通信层面看起来像一台拥有8倍显存和8倍算力的巨型GPU。做AI Infra的配置多卡训练时一定要去看GPU拓扑nvidia-smi topo -m确认卡间的NVLink连接是否完整。我曾经踩过坑服务器某个NVLink桥接坏了系统自动降级走PCIe通信训练速度直接掉一半查了很久才通过nvidia-smi -q -d nvlink发现链路编号全是ERR。4.3 三种互联层次的正确认知在多卡和跨节点训练里信息其实是在三个不同层次的交通系统里流动的片内GPU内部SM之间通过L2和共享内存交换数据速度最快。片间同一台机器内的多卡走NVLink/NVSwitch速度次之但仍然很快。节点间不同服务器之间通常走InfiniBand或RoCERDMA over Converged Ethernet速度受限于网络架构和交换机的带宽最慢。训练时通信的带宽需求从片内到节点间依次递减但延迟开销依次递增。所以模型并行策略的制定原则简单说就一句话把最频繁的通信放在最快的那层上比如张量并行尽量放在单机8卡内流水线并行再考虑跨节点。还有一个实际经验跨节点训练时如果用的是RoCE网络需要特别关注交换机的流控和拥塞控制配置否则一旦多任务并发网络延迟抖动就会直接体现在训练迭代时间上。这些都是纯软件层面排查不出来、非得到架构层面才能理解的问题。5. 实操视角看懂GPU规格表与选型5.1 一张规格表应该怎么看做AI Infra日常少不了的活儿就是对比GPU规格表。很多人只看显存大小和价格这很容易吃亏。这里我整理了一张以NVIDIA主流数据中心卡为参照的对比表重点标出做选型时真正应该关注的信息参数A100 80GBH100 80GBH200 141GBL40SRTX 4090架构AmpereHopperHopperAda LovelaceAda LovelaceFP16 Tensor Core算力稠密312 TFLOPS756 TFLOPS756 TFLOPS362 TFLOPS330 TFLOPS*FP8 Tensor Core算力不支持1513 TFLOPS1513 TFLOPS725 TFLOPS661 TFLOPS*显存容量80GB HBM2e80GB HBM3141GB HBM3e48GB GDDR624GB GDDR6X显存带宽1.6 TB/s3.35 TB/s4.8 TB/s864 GB/s1008 GB/s互联NVLink 600GB/sNVLink 900GB/sNVLink 900GB/sPCIe 5.0PCIe 4.0TDP400W700W700W300W450W*4090的Tensor Core算力在单精度浮点上表现不错但整体架构和驱动对多卡并行、虚拟化、企业级功能的支持和真正的数据中心卡有本质差异看规格表有个核心心法先想清楚你的工作负载类型再往表里套参数。如果是做7x24小时在线推理服务你要重点看显存容量、带宽和功耗如果是做离线大规模训练算力和互联更重要如果是做实验性质的微调性价比和上手难度反而要考虑。很多人拿着H100跑小模型发现速度不一定比4090快多少就是因为小模型吃不满H100的高算力反而是4090的性价比更香。5.2 训练、推理、微调分别怎么选不同场景下的选型逻辑差别很大说几个标配思路大模型预训练首选H100/H200这类Hopper架构卡最好配满8卡NVLink。训练的核心瓶颈在于算力和卡间通信Hopper架构不仅有强大的Tensor Core还有NVLink高带宽能有效支撑张量并行。另外要注意供电和散热机房的单机柜功率预算必须按照满载设计别买完卡发现机房插不上电。大模型推理显存容量和带宽双重要。如果追求极致吞吐H200的141GB HBM3e就是为这个场景准备的——单位卡能塞下更多KV Cache、服务更多并发请求。但如果是中小模型的推理比如7B、13B参数一张4090或L40S可能就够用了成本差距却是十倍量级。微调/实验数据量不大、训练时间短、迭代频繁这种情况下先别急着上H100。4090虽然多卡通信几乎没有没有NVLink但单卡算力足够跑LoRA显存24GB也够处理一些中小模型。很多研究团队的踩坑经验都是微调场景上H100算力严重过剩花了大价钱却跟4090速度差不多。5.3 成本视角算算单位算力的价格选型除了看技术参数还得看钱。这里引入一个做AI Infra经常用的简单指标每TFLOPS每秒的价格。假设云上租用H100大约每小时2.5美元A100大约1.5美元4090大约0.4美元。用FP16 Tensor Core峰值算力一除卡型每小时价格FP16算力每TFLOPS每小时成本H100$2.5756 TFLOPS约$0.0033A100$1.5312 TFLOPS约$0.00484090$0.4330 TFLOPS*约$0.0012光看这个数字4090的性价比似乎一骑绝尘但别忘了算力利用率差别巨大。4090的330 TFLOPS是FP16 Tensor Core算力实际跑分布式训练时因为没有NVLink多卡扩展性差可能只能发挥20%~30%的算力。而H100在成熟框架上跑Transformer模型算力利用率经常能到50%以上。再算上显存容量限制24GB放不下大模型、可靠性问题消费级卡长时间满载容易降频或故障成本账就得重新算了。核心结论是省钱不是只看单价而是看单位有效算力的成本而有效算力恰恰和架构特性强相关。这也是我不厌其烦劝人先学架构再学部署的原因。6. 常见问题与排查实录6.1 显存没满Training却OOM了做训练的经常遇到一个诡异现象nvidia-smi看显存占用才50多GB卡是80GB的你明明还有接近30GB的余量但跑训练时直接OOM连下个step都进不去。这个问题的根源在于PyTorch的显存管理机制。PyTorch为了提高效率会预申请大块显存作为缓存caching allocator即使某个张量释放了显存也不马上还给驱动而是留在缓存里供后续复用。所以nvidia-smi看到的显存占用是已经分配缓存的总和而实际可用空间零碎得很。加上训练过程中有大量临时张量比如loss、中间激活值、梯度大小不一申请大块连续显存时如果碎片化严重就会OOM。排查思路不要只看nvidia-smi的已用显存要看torch.cuda.memory_summary()里的allocated和reserved两个值——如果两者差距很大说明缓存碎片化然后检查是否有显存泄漏每step结束内存持续上涨最后再考虑调整PYTORCH_CUDA_ALLOC_CONF环境变量比如设置expandable_segments:True来改善碎片问题。这些方案的前提是理解底层显存分配逻辑不然就会瞎清缓存、白重启进程。6.2 小模型在高端卡上跑不快有朋友拿H100跑一个几百MB的小模型发现每token生成速度和4090差不多甚至还不如非常困惑。这就是典型的算力吃不饱——小模型的算子小每次计算的数据量小卡上几千个核心大部分都在等数据等待显存把下一块数据送上来算力利用率极低。这种场景里问题不在GPU的峰值算力而在于带宽和延迟。推理时的batch size不够大无法有效隐藏访存延迟框架也没有把算子融合到一起每个小算子都触发一次kernel launch和一次显存访问开销巨大。解决办法是换用TensorRT或vLLM这类经过深度优化、算子融合更充分的推理引擎或者想办法增大并发batch让显存带宽被充分压榨。这是选型之外更重要的优化点——有时候瓶颈不在硬件而在软件没有利用好硬件架构的特性。6.3 多卡训练扩展比上不去32卡训练出来的吞吐只有8卡的三四倍扩展比0.8都不到这种问题几乎每个做分布式训练的人都遇到过。核心瓶颈几乎都在通信上。首先查卡间通信拓扑nvidia-smi topo -m确认同一台机器内NVLink是否全部打通跨节点查网络ibstat或ibstatus看InfiniBand链路是否处于Active状态。再往前查软件层通信后端是不是NCCLNCCL的环境变量比如NCCL_DEBUGINFO能不能打出通信耗时的分布还要看网络配置比如RoCE的PFC流控是否生效交换机的MTU是否一致。通信优化的顺序永远是硬件链路先查再查协议栈最后才去调框架参数。这类问题的排查需要一点耐心本质上是对GPU架构决定通信链路通信链路决定扩展性这个认知的印证——你不懂硬件就永远不知道瓶颈出在哪一层。6.4 判断GPU利用率的正确姿势最后聊一个日常天天见但经常被误读的指标GPU利用率。nvidia-smi最顶上显示的Utilization是过去采样周期内GPU上有一个或多个kernel正在执行的时间百分比。注意它的粒度哪怕GPU上只跑了一个很小的算子占用1%的算力只要它一直在跑利用率也能显示99%。所以“利用率99%”完全不代表算力用满了。真正判断GPU有没有吃满要看这几个指标nvidia-smi -q -d UTILIZATION里的计算和内存利用率分开看训练场景结合nsysNVIDIA Nsight Systems看kernel时间和空闲时间比例如果大量时间在wait那多半是训练代码IO瓶颈或通信瓶颈推理场景用DCGMData Center GPU Manager的指标比如sm_occupancy、tensor_active看SM占用和Tensor Core利用率比单纯看利用率准得多。顺便科普一个冷知识NVIDIA有个nvidia-smi -q -d CLOCK可以看当前实际运行频率。如果GPU显示跑在低频率比如500MHz往往说明任务不够密集、功耗管理降频了——这也是判断是否真满载的一个好信号。7. 写在最后的实在话做AI Infra这几年我最大的感受是GPU架构不是一门孤立的知识它是整个AI系统性能逻辑的地基。你搞不清楚SM和Tensor Core就理解不了为什么一个算子是带宽瓶颈搞不清NVLink和网络拓扑就扎不透分布式训练的性能调优搞不清显存分配机制就躲不开线上不时冒出来的OOM。这一篇是入门第二篇其实还只聊了最底层的几个概念后面的CUDA编程模型、通信库原理、训推引擎优化全都要在这个地基上继续盖楼。最后送一个实操小技巧拿到一台新GPU服务器先别急着部署模型花十分钟把这几件事做了——nvidia-smi -q -d COMPUTE确认驱动和卡状态nvidia-smi topo -m确认NVLink拓扑用NCCL的all_reduce_perf工具实测一下卡间通信带宽hbm的带宽可以用bandwidthTest简单评估。这些操作都不复杂但能让你在真正跑任务前就对这台机器的体力心里有数。以后排查问题的时候一想到这张底盘图心里就踏实很多。