做AI基础设施这一行我特别怕听到一句话“这块卡标称多少TFLOPS”问出这句话的人通常已经把GPU默认成一台“算数特别快的机器”。但真正把训练和推理集群跑起来的人都知道一张卡的落地性能从来不是算力一个数字说了算而是三条线同时结算的结果算力能出多少活、带宽能喂多少料、搬运能把多少数据准时送到。所谓“加速计算”说穿了就是这三角账怎么平衡的问题。这篇内容就是《AI基础设施系列》的第一篇把这三笔账拆开讲清楚算力是什么、带宽卡在哪、搬运有多贵。适合刚接触GPU编程的朋友也适合做大模型训练、部署、买卡、租云GPU或者给集群做调度的同学。读完你起码能给自己手头的任务做一次“三角审计”不再被一张规格表带走。1. 三角账怎么来的算力、带宽与搬运各占一角1.1 把GPU当成一家工厂看我习惯把GPU想象成一家工厂这样很多性能问题就特别好解释。SM流式多处理器和CUDA Core是车间里的机床负责真正的计算显存是原料仓库模型权重、激活值、中间结果都堆在这显存带宽是车间到仓库之间的传送带决定机床能多快拿到原料、多快把成品送回仓库PCIe、NVLink、网卡是厂区外的货运网络负责把数据从一个地方搬到另一个地方Kernel启动和copy引擎则像调度员每一次“发车”都有固定的手续和开销。一次训练迭代拆开看就是数据从磁盘/网线搬进显存物流权重和梯度流过计算单元传送带供料中间结果在显存里反复读写仓库内部周转最后更新完的权重还要同步出去再走一趟物流。任何一个环节堵住机床就得空转。这三角各有各的计价单位算力大体用TFLOPS量化带宽用GB/s量化搬运则要算“每一次搬多少字节、一共搬多少次”。把三本账加在一起才是你真正感受到的训练时间或推理延迟。1.2 只看FLOPs的翻车现场FLOPs是峰值不是实际产出。它描述的是“机床全速运转时的最大加工量”但要达到这个数工作负载的形状、数据排布、流水线调度都得配合到位。现实里绝大多数任务根本摸不到峰值。我见过不少配置单两张卡算力差了三倍结果跑同一个小模型耗时却差不多。原因往往是带宽和搬运已经把天花板焊死了。比如一个逐元素加法的任务每读一个元素才做一次加法算力再高也使不上劲真正决定速度的是显存带宽。这种情况下把算力从50TFLOPS换成100TFLOPS收益可能只有百分之几。还有一种更常见的翻车场景数据在CPU和GPU之间来回搬GPU大部分时间不是在算而是在“等货”。很多新手把数据从Pandas里切出来再tensor.to(cuda)每步都做全量拷贝结果一看Nsightmemcpy占了四成时间算力利用率低得可怜。所以“三角账”的本质是任何一个角成为短板都会拖住整体。优化的目标不是把某一角拉满而是让三角互相匹配。2. 算力这一角CUDA Core、Tensor Core与精度档位2.1 warp、CTA与Tensor Core算力是怎么组织起来的先回答一个很多人第一次接触CUDA时会懵的问题cooperative thread arrayCTA和warp到底是什么关系。CTA是软件层面的概念你可以把它理解成“一个班组”。一个CTA里的线程可以协作能通过__syncthreads()互相等待能共享一块显存。而warp是硬件调度的最小单位固定32个线程由GPU的调度器一次性打包发射。一个CTA里通常包含一个或多个warp比如CTA128线程那它会被拆成4个warp来执行。搞清楚这两层你才能理解为什么GPU擅长矩阵乘法但又不擅长所有矩阵运算。矩阵乘法是大量同构运算数据复用率高、分支少、指令开销低非常适合SIMT模式批量处理。而跳跃访问多的逻辑、稀疏数据结构GPU跑起来就特别别扭因为“送料”比“加工”更费劲。Tensor Core则是另一种“压路机”它不是通用计算单元而是专门吃矩阵乘加GEMM的专用电路能一次完成一块小矩阵的乘加。训练和推理之所以这几年突飞猛进很大程度就是靠它把矩阵乘的每瓦性能抬上去了。2.2 精度换算力FP32、FP16、BF16、INT8的性价比Tensor Core支持的精度档位是分级的FP32、TF32、FP16、BF16、FP8、INT8。大体规律是位宽每降一档吞吐翻一番。拿常见卡举例均指Tensor Core密集计算卡FP32TFLOPSFP16 Tensor密集TFLOPS备注A100 SXM 80GB19.5312FP16是FP32的约16倍H100 SXM 80GB67495FP16是FP32的约7倍RTX 409082.6330消费卡也能吃到Tensor红利为什么低了精度就快了两方面一是同样面积的电路可以塞更多MAC单元二是数据位宽减半后内存带宽的消耗也减半。大模型训练普遍用FP16/BF16混合精度推理端再用INT8/FP8做量化都是冲着这层性价比去的。代价也很现实低精度容易溢出、误差大。FP16的范围比FP32窄得多训练里梯度可能直接变成0所以需要loss scaling这类技巧推理量化则要做校准不然模型输出可能稀烂。精度不是越低越好是“够用且能省则省”。2.3 算力版本不匹配capability (9,0)与(12,0)是怎么回事最近热词里有一条特别典型requires device with capability (9, 0) but your gpu has capability (12, 0)。翻译成人话就是你运行的程序只带了算力9.0及以下GPU的程序产物但你的显卡硬件是12.0的新架构两者对不上。这里的9.0、12.0叫compute capability是GPU硬件代际编号。比如A100是8.0H100是9.0RTX 40系是8.9RTX 50系Blackwell是12.0。CUDA程序在编译时会针对某个capability生成SASS底层机器码这份机器码老架构产品往往没法在新架构上直接执行除非程序里同时打包了PTX中间代码由驱动JIT转译。老版本的PyTorch、TensorRT引擎、cuDNN通常只带旧capability的产物插上新Blackwell卡就会在加载阶段报这个错。踩过坑之后我的处理顺序是先把NVIDIA驱动更新到支持新架构的版本换用支持新capability的CUDA运行库比如PyTorch装cu128及以上的wheel再用python -c import torch; print(torch.cuda.get_device_capability())确认识别到的能力是不是(12,0)如果还跑自定义C/CUDA扩展就设置TORCH_CUDA_ARCH_LIST12.0重新编译。千万别去“改”capability那是硬件属性改不了。也别以为新显卡向下兼容所有老库现实是二进制产物经常不兼容。3. 带宽这一角内存带宽才是大多数场景的真瓶颈3.1 操作强度算力和带宽之间的“汇率”判断一个任务到底卡在算力还是卡在带宽有个非常实用的指标叫“操作强度”Arithmetic Intensity单位FLOP/Byte也就是“每读一个字节的数据能顺便完成多少次浮点运算”。举两个极端例子逐元素加法读两个数、写一个数每个元素才做2次浮点运算操作强度大约0.2 FLOP/Byte大矩阵乘法一个4096×4096的GEMM算下来操作强度能到1300多 FLOP/Byte。再把卡的“峰值算力÷峰值带宽”算出来这是Roofline模型里的“脊点”。以H100为例约495 TFLOPS的FP16密集算力除以3.35 TB/s的带宽脊点大约148 FLOP/Byte。任务的操作强度高于148算力才能吃饱低于148就算计算单元再快也是带宽先到顶。所以“提高算力”对带宽瓶颈任务几乎无效。机器再多也快不起来因为传送带就那么大。这解释了很多迷惑现象GPU跑矩阵乘法飞快跑哈希、排序、稀疏操作却像蜗牛。3.2 一张表看清主流GPU的算力与带宽采购和调优前先把规格表摊开看GPUFP32TFLOPSFP16 Tensor密集TFLOPS显存带宽GB/s显存RTX 4060 Laptop14.6未单独列2568GB GDDR6RTX 409082.6330100824GB GDDR6XA100 SXM 80GB19.5312203980GB HBM2eH100 SXM 80GB67495335080GB HBM3注意这里有个反常识点RTX 4090的FP32算力比A100还高但它的显存带宽只有A100的一半左右。真跑起大模型推理A100往往更稳因为它不被带宽卡得那么死。消费卡的浮点看起来很猛但“供料”跟不上很多任务根本发挥不出账面数字。3.3 用带宽直接算大模型推理的token速度大模型自回归推理有一个非常硬核的物理约束每生成一个token都要把模型全部权重从显存读一遍。所以理论上的单用户token速度大概等于token/s ≈ 显存带宽 ÷ 模型权重体积7B模型用FP16存大约14GB。那么RTX 4090带宽1008GB/s大约72 token/sA1002039GB/s大约145 token/sH1003350GB/s大约239 token/s。70B模型则是140GBH100也只能跑24 token/s左右H2004.8TB/s能到34 token/s。这就是为什么大模型推理天生是带宽生意而不是算力生意。理解了这一点很多工程决策就顺理成章了为什么大家都往INT8、4bit量化上冲因为权重体积减半再减半token速度近乎线性翻倍为什么prefill长prompt处理和decode逐个生成要分开调度因为prefill是计算密集靠Tensor Coredecode才是带宽密集靠显存带宽和缓存为什么单卡H100理论上也就能同时服务十几个用户因为要满足每人每秒输出20个token左右就要占掉每秒200多个token的带宽额度。下次有人问“这卡能扛多少并发”先别聊算力拿带宽除一除心里就有底了。4. 搬运这一角PCIe、NVLink与kernel启动的隐性账单4.1 CPU与GPU之间一次memcpy到底多贵GPU自己再快数据也得先到显存里。CPU和GPU之间的通道主要是PCIe。单条PCIe Gen4 x16的单向理论带宽是32GB/s实际传输效率大约24~28GB/s。听着不低但算一笔账就心疼了往显存里搬一个2GB的权重文件大约要80毫秒。如果训练脚本每个step都做一次全量拷贝1000步就是80秒纯等待。而这80秒里GPU的计算单元是彻底闲着没事干的功耗和成本一点没省。有三个马上能做的事DataLoader(pin_memoryTrue)固定页内存能绕过驱动中转搬得快不少用CUDA stream做异步拷贝把搬运和kernel计算重叠起来认真审视代码里有没有“每步都to(device)”的无谓搬运把数据预处理留在GPU上做。很多“慢训练”查到最后根本问题不是算力不够而是CPU里用Pandas折腾半天再一次性搬上显卡账单全记在搬运这一栏。4.2 GPU与GPU之间NVLink不是每张卡都有单卡放不下模型就要多卡跑。多卡之间梯度同步的本质也是搬运。A100的NVLink总带宽约600GB/sH100约900GB/s比PCIe快一两个数量级。但消费级RTX 4090没有NVLink多卡只能走PCIe梯度同步慢得想哭。这也是为什么很多人组了几张4090做分布式训练发现“加卡反而更慢”——通信账单把收益吃光了。具体算一下7B模型FP16梯度约14GB8张卡做一次全量allreducering算法下每个rank要搬运大约24.5GB。在NVLink 600GB/s上约41毫秒在PCIe Gen4 x16上要近一秒。如果你的训练step本身就一两秒那这笔通信开销占比相当可观。跨节点就更夸张了。200Gbps的InfiniBand约25GB/s千兆以太网只有0.125GB/s。算力再猛数据在网络上搬不过去一切都是白搭。这也顺带解释了一个现象现在大家都在做东西本质上是想办法让“搬运与算力”在多个任务之间匹配而不是让一张大卡被一个任务独占后、其余时间空转到天荒地老。4.3 Kernel启动开销小算子如何拖垮大任务除了显式搬运还有一个隐藏账单kernel启动。每次在GPU上执行一个kernelCPU要打包参数、下发给驱动、进队列、等待GPU调度执行、再通知CPU结果。这一来一回的固定开销大约5~10微秒。单个kernel看似不贵但架不住数量多。我分析过一个朴素的训练脚本一个step里跑了三千多个小算子光是启动开销就占了三四十毫秒而算子本身的运算可能只有几毫秒。对策主要三条kernel融合把连续逐元素操作合并成一个kernel减少启动也减少中间张量的显存读写CUDA Graph一次性捕获整个计算图重复使用时启动开销几乎归零torch.compile或融合库它们自动帮你做上述合并实测很多小模型能白捡一截速度。另外提醒一句小数据别迷信UVM和zero-copy。显卡访问零拷贝内存时可能触发缺页中断数据被切成小片慢慢搬延迟反而比一次性memcpy高。针对小张量直接拷过去往往更省心。5. 实战给训练任务做一次三角审计5.1 三件套工具nvidia-smi、nsys、ncu排查性能问题我固定用三个工具分工明确nvidia-smi板卡级观测。看利用率、显存占用、功耗、温度。缺点是它只反映瞬时平均小kernel之间的空隙会被抹平所以“利用率低”不能直接说明算力有问题nsys profileNsight Systems全局时间线。能直接看出哪段时间在算、哪段时间在memcpy、哪段时间CPU和GPU两头都在等。强烈建议先跑它因为它能告诉你“问题在哪个环节”ncuNsight Compute单kernel显微镜。ncu --set roofline能给出操作强度、SM利用率、内存吞吐精准告诉你这个kernel是算力受限还是带宽受限。常用命令就很直白nvidia-smi nsys profile -o myapp python train.py ncu --set roofline --target-processes all python train.py有的云GPU租用平台不让开profile那也没关系nvidia-smi加时间戳采样也能看出个大概只是精度差点。5.2 算账流程判断负载卡在哪一角别急着优化先记账。我一般按四步走列出一次训练step或一次推理请求必须搬运的最小数据量权重读取、梯度同步、数据批次、中间结果写回分别除以对应的带宽得到理论耗时下限跑一次nsys看实际耗时分布把实际分布和理论下限比对短板就自己现形了。给出一个速查表方便对号入座现象大概率瓶颈手段GPU利用率高但全局吞吐上不去搬运间隙、kernel启动排队异步流水、CUDA Graph、融合利用率低且显存带宽接近打满带宽受限减少访存、换高带宽卡利用率低且带宽也没打满算子太小、等待依赖融合、重排loop、增大batchmemcpy占比超过30%搬运账太高pin_memory、缩短H2D链路、缓存我自己常用的判断很简单nvidia-smi里GPU利用率虽然高但nsys里的kernel之间有大片空白那就是“搬运/启动拖后腿”如果利用率低但内存带宽接近上限那就是“带宽天花板”。5.3 三个立刻见效的优化动作针对小模型微调这类场景我实测下面三个动作最划算融合算子用torch.compile把逐元素操作合到一起能明显减少中间张量读写开启pin_memory并做异步搬运把数据加载放到独立进程用CUDA stream提前搬到显存让GPU在算上一批的时候下一批已经在路上用CUDA Graph收拢小kernel固定shape的训练step可以整段捕获成图之后每次重复执行启动开销几乎消失。代码层面大概长这个样子train_loader DataLoader(ds, pin_memoryTrue, num_workers4) s torch.cuda.Stream() for epoch in range(epochs): for x, y in train_loader: # 让搬运流等当前计算流让出再异步拷贝 s.wait_stream(torch.cuda.current_stream()) with torch.cuda.stream(s): x x.cuda(non_blockingTrue) y y.cuda(non_blockingTrue) torch.cuda.current_stream().wait_stream(s) loss model(x, y) loss.backward() optimizer.step()注意这些动作只是改变搬运节奏不改变算法。真正更进一步的加速还要靠FlashAttention这类访存优化算子以及把整个计算图交给框架级编译器。但把三角账里的搬运账单先降下来永远是性价比最高的第一步。6. 常见问题速查热词背后的事故现场6.1 核显和独显并存用错卡是很多诡异问题的源头很多笔记本的设备管理器里同时挂着“Intel UHD Graphics”和“NVIDIA GeForce RTX 4060 Laptop GPU”。如果你跑AI程序发现GPU没用上先别怪驱动多半是应用默认落到了核显上。排查顺序是这样终端执行nvidia-smi确认系统里能看到的独显和驱动版本代码里设置CUDA_VISIBLE_DEVICES0显式指定独显Windows的“设置→系统→屏幕→显卡”里为Python、游戏或特定软件指定“高性能NVIDIA处理器”NVIDIA控制面板→管理3D设置把全局或特定程序的GPU选到独显。有些软件即使指定了还是会出问题比如Adobe Camera Raw 18.6里GPU选项灰掉、某些游戏报“unsupported GPU”一般就是驱动版本太旧或者软件对新架构支持不全。先把驱动升级到最新再把程序强制切到独显八成能解决。6.2 新卡被报unsupported GPU游戏和软件排查顺序热词里有条“天国拯救2 unsupported gpu”其实这类报错在AI软件里一样常见只是表现形式不同。游戏判断GPU支不支持通常看两件事一是驱动版本二是显卡是否具备它要求的功能特性比如DX12 Ultimate、特定Vulkan版本、硬件光追。老显卡或老驱动被报“不支持”太常见了新显卡被报“不支持”往往也是驱动太老软件白名单还认不出新架构。AI软件类似。比如ComfyUI装插件报冲突、Camera Raw勾不了GPU根子上多半是驱动、CUDA runtime、三方库版本互相错配。我的经验是先把环境重建一遍装最新厂商驱动→装支持当前GPU的PyTorch/CUDA版本→再加插件。别在一堆旧版本上打补丁越打越乱。6.3 云GPU和租卡怎么选别被TFLOPS带偏现在租卡渠道很多常见的有按卡计费的云GPU平台、算力租赁站。挑卡时请把规格表按四个列看而不是只盯浮点算力显存容量能不能放下模型和KV cache显存带宽决定推理token速度和一部分训练效率卡间互联多卡训练必须看有没有NVLink别组廉价PCIe集群价格把前两者折算成“每GB/s带宽多少钱”再比。开发调试阶段显存够用就行正式训练优先看带宽和互联部署推理服务直接拿带宽除模型体积来估并发。至于“用个人电脑共享算力出租”这种玩法输出带宽和延迟是硬伤跑推理服务的网络瓶颈会远大于本地算力当个玩具可以当生产主力不划算。集群层面还有一个常被忽略的细节共享带宽必须用调度机制管起来。GPU虚拟化和配额管理工具比如HAMI这类开源方案存在的意义就是让多个任务共享一张卡时谁也别把传送带独占谁也别把带宽吃干榨净。没有这层调度一个任务就能拖垮整机箱的邻居。6.4 个人习惯固定先做三角审计再动手优化最后分享一个我自己的固定动作。每拿到一个新任务我不看模型代码先跑三行命令nvidia-smi看全局、nsys profile看时间线、ncu --set roofline看关键kernel然后把算力、带宽、搬运三笔账填到一张表里。多数时候问题在填表的过程中就自己暴露了。还有一个装机后必做的检查python -c import torch; print(torch.cuda.get_device_capability(), torch.version.cuda)这条命令能一次性确认三件事GPU是否被正确识别、capability是哪个代际、CUDA runtime版本是否匹配。很多莫名其妙的“程序跑不起来”检查完这一步就省掉大半天排查时间。我自己踩过太多次“换卡解决一切”的坑。后来发现真正值钱的不是换更贵的卡而是先把钱花在刀刃上算力不够就换算力带宽不够就换显存带宽更高的型号或做量化搬运太贵就改流水线和融合。以后不管是调优还是采购先让这三笔账上桌很多决定会变得异常清晰。
