1. GPU架构入门：从图形处理器到AI算力引擎
很多刚接触AI Infra的朋友会有个误区，觉得GPU就是一块“打游戏的显卡”，跟AI训练关系不大。实际上，从2012年AlexNet用两块GTX 580跑出惊人成绩开始，GPU就逐渐从图形渲染管线里的一颗专用芯片，演变成了整个AI基础设施中最核心的算力单元。我刚开始做模型部署的时候，也曾经天真地以为“显卡嘛，显存大就行”，结果被现实狠狠教育了一顿——同样显存的两块卡，跑同一个模型，吞吐量能差出三倍。这背后的差距，就藏在GPU架构的细节里。
这篇文章主要面向三类人：一是刚入行AI Infra、准备系统学习GPU底层知识的工程师；二是做模型训练或推理、需要选卡和调优的算法同学；三是运维或平台侧、要管理GPU集群的技术人员。我会从GPU的整体架构讲起，把SM、CUDA Core、Tensor Core、显存层次、NVLink这些核心概念串起来，再落到实际选卡、环境配置和常见坑的排查上。读完你至少能搞清楚：为什么A100和H100的差距不只是“新一代”三个字，为什么你的模型在4090上跑得好好的换到A100反而变慢了，以及CUDA版本到底该怎么选。
提示：本文涉及的架构参数和配置方法均基于公开技术资料和实际项目经验整理，具体数值请以官方最新文档为准。
2. GPU架构核心组件拆解：从宏观到微观
2.1 GPU与CPU的本质差异：为什么AI训练离不开GPU
要理解GPU架构，先得搞清楚它和CPU的根本区别。CPU的设计哲学是“低延迟”，它把大量晶体管花在了分支预测、乱序执行、大容量缓存上，为的是让单个线程跑得尽可能快。你可以把CPU想象成一个博士，什么复杂问题都能处理，但一次只能专心做一两件事。GPU则完全相反，它的设计哲学是“高吞吐”，核心数量动辄上千，但每个核心的能力相对简单，擅长的是“同时处理大量相似的简单任务”。这就像一个几千人的施工队，每个人只会砌砖，但一起干活的时候，盖楼速度远超一个博士。
深度学习恰好就是这种“大量相似简单任务”的典型场景。神经网络的训练本质上是海量的矩阵乘法和加法，每个输出元素的计算过程高度一致，天然适合并行。这就是为什么GPU在AI领域能把CPU甩开几十倍甚至上百倍的原因。但要注意，GPU并不是在所有场景都优于CPU。如果你的任务有大量复杂的条件分支、串行依赖强，那CPU反而更合适。我见过有同学硬要把一个逻辑复杂的推荐系统全搬到GPU上，结果性能还不如CPU，这就是没搞清楚两者适用边界。
从硬件层面看，一块现代GPU大致包含这几个部分：若干个流多处理器（SM，Streaming Multiprocessor）、多级显存层次、显存控制器、互连总线（如NVLink、PCIe），以及负责调度和分发的GigaThread引擎。其中SM是最核心的计算单元，也是我们后面要重点拆解的对象。
2.2 SM内部结构：CUDA Core、Tensor Core与调度器
SM（流多处理器）是GPU的基本计算单元，一块GPU里通常有几十到上百个SM。以A100为例，它拥有108个SM；H100则增加到132个。每个SM内部又包含多个子单元，理解这些子单元的分工，是理解GPU性能表现的关键。
CUDA Core是最基础的标量计算单元，负责执行普通的浮点和整数运算。你可以把它理解为一个“全能型工人”，什么活都能干，但干得不算特别快。一块A100有6912个CUDA Core，分布在108个SM里，每个SM有64个。这些CUDA Core按照SIMT（单指令多线程）的方式工作，32个线程组成一个warp，同一个warp内的线程在同一时刻执行同一条指令，但操作不同的数据。这种设计的好处是硬件调度简单、吞吐量高，代价是遇到分支发散时会串行化执行，性能下降。
Tensor Core则是专门为矩阵乘法设计的加速单元，从Volta架构开始引入。它能在单个时钟周期内完成一个小矩阵的乘加运算，比如4x4x4的矩阵乘法。到了Hopper架构的H100，第四代Tensor Core已经支持FP8精度，吞吐量相比FP16又翻了一倍。Tensor Core是AI训练和推理性能的核心来源，但它有使用门槛：需要特定的数据类型（如FP16、BF16、TF32、FP8）和特定的矩阵维度对齐要求。如果你的矩阵维度不是8或16的倍数，Tensor Core的利用率会大幅下降，这时候就需要做padding或者调整模型结构。
除了计算单元，SM里还有调度器（Warp Scheduler）和分发单元（Dispatch Unit）。每个SM通常有4个调度器，每个调度器管理一组warp，负责从warp池里挑选就绪的warp发射指令。调度器的效率直接影响SM的利用率。如果warp数量不够，调度器就会“无米下锅”，SM的算力就浪费了。这就是为什么在写CUDA kernel时，occupancy（占用率）是一个重要指标——它衡量的是SM里活跃warp数量与最大支持warp数量的比值。
2.3 显存层次：寄存器、共享内存、L2与HBM
GPU的显存层次设计直接决定了数据搬运的效率，而数据搬运往往是性能瓶颈的真正来源。很多同学调优时只盯着计算单元，忽略了显存访问模式，结果怎么调都上不去。
最靠近计算单元的是寄存器（Register），每个线程有自己私有的寄存器空间，访问速度最快，但容量极小。A100每个SM有64K个32位寄存器，分给每个线程的数量取决于线程块的大小。如果寄存器用超了，会发生“寄存器溢出”，数据被挤到本地内存（实际上是显存），性能断崖式下跌。
往下一层是共享内存（Shared Memory），它是SM内部所有线程共享的一块高速缓存，容量通常在几十到一百多KB。共享内存的访问延迟远低于显存，是CUDA编程中做数据复用和线程间通信的关键。但共享内存有个坑：bank conflict。共享内存被划分为32个bank，如果同一个warp内的多个线程同时访问同一个bank的不同地址，就会发生冲突，访问被串行化。我踩过最典型的坑就是矩阵转置时没做padding，导致严重的bank conflict，性能直接砍半。
再往下是L2缓存，所有SM共享，容量在几MB到几十MB之间。A100的L2是40MB，H100是50MB。L2缓存的作用是减少对HBM的访问次数，对于有数据复用模式的访问非常有效。
最底层是HBM（高带宽显存），也就是我们常说的“显存”。A100用的是HBM2e，带宽约1.5TB/s；H100用的是HBM3，带宽约3TB/s。HBM的带宽虽然看起来很大，但相对于GPU的计算能力来说仍然是瓶颈。以A100为例，FP16 Tensor Core的算力是312 TFLOPS，而显存带宽只有1.5TB/s，计算与访存的比例超过200:1。这意味着如果每次计算都需要从显存读数据，GPU的算力根本发挥不出来。所以高性能CUDA kernel的核心思路之一就是提高数据复用率，让数据尽量在寄存器或共享内存里被多次使用。
2.4 互连技术：NVLink与PCIe的取舍
当你需要多卡训练时，卡间通信就成了关键瓶颈。传统的PCIe 4.0 x16带宽是32GB/s（双向），而NVLink 3.0在A100上提供的是600GB/s（双向），差了将近20倍。这个差距在张量并行（Tensor Parallelism）场景下尤为致命，因为张量并行每层都要做All-Reduce通信，通信量巨大。
NVLink的工作方式是点对点直连，不经过PCIe交换机，延迟更低、带宽更高。在DGX A100这样的系统里，8块GPU通过NVSwitch全互联，任意两块卡之间的带宽都是600GB/s。而如果用PCIe，8块卡共享总线带宽，实际每块卡能分到的带宽可能只有几GB/s。
但NVLink也不是没有代价。它需要专门的硬件支持，主板和GPU都要有对应的接口，成本高。而且NVLink的拓扑结构有限制，不是所有GPU之间都能直连。在实际选型时，我的经验是：单卡能放下模型就用单卡，数据并行用PCIe也够，只有模型大到必须做张量并行时才值得上NVLink。很多团队一上来就买最贵的NVLink机器，结果模型根本用不到张量并行，钱花在了用不上的地方。
3. 从架构到实践：GPU选型与环境配置
3.1 怎么根据架构参数选卡：算力、显存与带宽的三角权衡
选GPU本质上是在算力、显存容量、显存带宽和价格之间做权衡。我一般会按这个顺序来筛选：先看显存容量能不能放下模型，再看显存带宽够不够喂饱计算单元，最后看算力是否满足训练时间要求。
显存容量的估算有个经验公式：模型参数量 × 精度字节数 × 4~6倍。多出来的倍数用于存储梯度、优化器状态和中间激活值。比如一个7B参数的模型，用FP16训练，光参数就是14GB，加上梯度14GB、Adam优化器状态28GB，这就56GB了，还没算激活值。所以7B模型全量微调至少需要80GB显存的卡。如果做LoRA微调，优化器状态大幅减少，24GB的4090也能凑合。
显存带宽决定了数据搬运的速度。有一个简单的判断方法：看你的模型是计算密集型还是访存密集型。Transformer类模型在训练时是计算密集型的，Tensor Core利用率高，带宽压力相对小；但在推理时，尤其是自回归生成，每生成一个token都要读一遍全部权重，是典型的访存密集型，带宽就是瓶颈。这就是为什么推理场景下，H100相比A100的提升没有训练场景那么明显——H100的算力翻倍了，但带宽只从1.5TB/s提升到3TB/s，只翻了一倍。
算力方面，不要只看厂商标称的峰值TFLOPS。那个数字是在理想条件下的理论值，实际能达到60%就算不错了。而且不同精度下的算力差异巨大：A100的FP32算力是19.5 TFLOPS，TF32是156 TFLOPS，FP16是312 TFLOPS。如果你的代码没有用Tensor Core，那实际算力就是FP32的水平，跟标称值差了一个数量级。我见过不少同学抱怨“A100怎么这么慢”，一查发现代码里全是FP32运算，Tensor Core根本没启用。
| 型号 | 显存 | 带宽 | FP16算力 | NVLink | 适用场景 |
|---|---|---|---|---|---|
| RTX 4090 | 24GB GDDR6X | 1TB/s | 165 TFLOPS | 无 | 小模型微调、推理 |
| A100 40GB | 40GB HBM2e | 1.5TB/s | 312 TFLOPS | 支持 | 中等模型训练 |
| A100 80GB | 80GB HBM2e | 2TB/s | 312 TFLOPS | 支持 | 大模型训练 |
| H100 80GB | 80GB HBM3 | 3TB/s | 990 TFLOPS | 支持 | 大模型训练/推理 |
| H200 141GB | 141GB HBM3e | 4.8TB/s | 990 TFLOPS | 支持 | 超大模型推理 |
3.2 CUDA环境配置：版本选择与多版本共存
CUDA版本的选择是新手最容易踩坑的地方。核心原则是：CUDA版本由PyTorch/TensorFlow版本决定，而不是反过来。很多人先装了最新版CUDA，然后发现PyTorch不支持，又得重装。
截至我写这篇文章时，PyTorch 2.x系列主要支持CUDA 11.8和12.1/12.4。如果你用的是最新的PyTorch 2.5+，可以支持到CUDA 12.4。CUDA 12.8虽然已经发布，但PyTorch的官方wheel可能还没跟上。所以正确的顺序是：先确定PyTorch版本，再查它支持的CUDA版本，最后装对应的CUDA Toolkit。
多版本CUDA共存是常见需求，比如你既需要跑老代码（CUDA 11.8），又要跑新模型（CUDA 12.4）。在Linux下，标准做法是把不同版本的CUDA装到/usr/local/cuda-11.8和/usr/local/cuda-12.4，然后用环境变量切换：
# 切换到CUDA 11.8 export CUDA_HOME=/usr/local/cuda-11.8 export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH # 切换到CUDA 12.4 export CUDA_HOME=/usr/local/cuda-12.4 export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH在Windows下，CUDA安装器会自动管理版本，通过修改系统环境变量来切换。但要注意，Windows下CUDA版本和显卡驱动有兼容性要求。比如CUDA 12.8需要驱动版本>=570，而很多笔记本的出厂驱动可能只有550左右，需要先更新驱动。
注意：安装CUDA Toolkit时，如果已经装了显卡驱动，不要勾选安装驱动组件，否则可能覆盖掉现有驱动导致显示异常。只勾选CUDA核心组件即可。
3.3 验证GPU是否可用：从nvidia-smi到实际跑通一个kernel
装完环境后，第一步是验证。nvidia-smi是最基础的检查命令，能看到GPU型号、驱动版本、CUDA版本、显存使用情况。但nvidia-smi显示的CUDA版本是驱动支持的最高版本，不是你实际安装的CUDA Toolkit版本。要查实际版本，用nvcc --version。
接下来验证PyTorch能否调用GPU：
import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))get_device_capability返回的是计算能力（Compute Capability），比如A100是(8, 0)，H100是(9, 0)，4090是(8, 9)。这个数字很重要，因为编译CUDA代码时需要指定对应的架构。如果你在4090上编译时用了-arch=sm_80，虽然能跑，但无法利用4090的新特性；如果用了-arch=sm_90，在4090上直接报错。
最后跑一个实际的矩阵乘法，确认Tensor Core能正常工作：
import torch a = torch.randn(4096, 4096, dtype=torch.float16, device='cuda') b = torch.randn(4096, 4096, dtype=torch.float16, device='cuda') c = torch.matmul(a, b) print(c.shape, c.dtype)如果这一步报错，常见原因是CUDA版本和PyTorch版本不匹配，或者显卡驱动太旧。错误信息里通常会提示“CUDA error: no kernel image is available for execution on the device”，这说明编译的架构和实际GPU不匹配。
4. 实操过程中的典型问题与排查
4.1 版本兼容性排查：CUDA、驱动、PyTorch的三方博弈
版本兼容性问题占了GPU环境问题的八成以上。我整理了一个排查顺序，按这个顺序走基本能定位到问题。
第一步，查显卡驱动版本：nvidia-smi右上角显示的“Driver Version”。第二步，查驱动支持的最高CUDA版本：同样是nvidia-smi右上角的“CUDA Version”。第三步，查实际安装的CUDA Toolkit版本：nvcc --version。第四步，查PyTorch编译时用的CUDA版本：torch.version.cuda。
这四个版本必须满足：驱动版本 >= 驱动支持的最低版本（对应CUDA Toolkit版本），CUDA Toolkit版本 <= 驱动支持的最高版本，PyTorch的CUDA版本 == CUDA Toolkit版本（或兼容）。
常见错误组合：
| 现象 | 原因 | 解决 |
|---|---|---|
torch.cuda.is_available()返回False | PyTorch装的是CPU版 | 重装GPU版PyTorch |
CUDA error: no kernel image | 编译架构与GPU不匹配 | 重新编译，指定正确arch |
undefined symbol: cudaXXX | CUDA版本与PyTorch不匹配 | 统一版本 |
out of memory但显存明明够 | 显存碎片或缓存未释放 | torch.cuda.empty_cache() |
| 多卡训练卡住 | NCCL版本或NVLink拓扑问题 | 检查NCCL配置和拓扑 |
4.2 性能不达预期：从occupancy到bank conflict的排查路径
性能调优是个系统活，我一般按这个路径排查：先看GPU利用率（nvidia-smi的GPU-Util），如果利用率低，说明计算单元在等数据；再看显存带宽利用率（用ncu工具），如果带宽打满了，说明是访存瓶颈；最后看occupancy，如果occupancy低，说明并行度不够。
一个实际案例：有同学反馈他的自定义CUDA kernel比PyTorch内置的慢5倍。用ncu一查，发现occupancy只有25%，原因是每个线程用了太多寄存器（超过128个），导致SM里能同时驻留的warp数量不足。解决办法是减少寄存器使用，或者用__launch_bounds__限制寄存器数量，让编译器做取舍。
另一个常见问题是bank conflict。共享内存的32个bank，如果warp内32个线程访问的地址恰好落在同一个bank的不同位置，就会冲突。最简单的避免方法是在声明共享内存数组时加padding：
// 有bank conflict __shared__ float tile[32][32]; // 加padding后无conflict __shared__ float tile[32][33];这个技巧在矩阵转置、卷积等操作中非常常用，加一列padding就能让访问模式错开，性能提升可能超过30%。
4.3 多卡通信问题：NVLink拓扑与NCCL调优
多卡训练时，通信往往是瓶颈。首先要确认NVLink是否正常工作：nvidia-smi nvlink -s可以查看NVLink的状态和带宽。如果显示“inactive”，说明NVLink没启用，可能需要在BIOS里开启。
NCCL是NVIDIA的集合通信库，PyTorch的分布式训练底层用的就是它。NCCL会自动选择最优的通信路径，但有时候自动选择不是最优的。可以通过环境变量干预：
export NCCL_DEBUG=INFO # 打印NCCL调试信息 export NCCL_IB_DISABLE=1 # 禁用InfiniBand（如果没有IB网络） export NCCL_P2P_LEVEL=NVL # 强制使用NVLink做P2P通信 export NCCL_SOCKET_IFNAME=eth0 # 指定网络接口我遇到过一个典型问题：8卡A100机器，做数据并行训练时，NCCL默认走了PCIe而不是NVLink，导致通信时间占了总时间的40%。加上NCCL_P2P_LEVEL=NVL后，通信时间降到5%以下。这个问题的根源是NCCL的拓扑探测有时候会误判，手动指定能避免。
提示：多卡训练前，先用
nvidia-smi topo -m查看GPU拓扑，确认哪些卡之间有NVLink连接。如果拓扑显示都是“SYS”或“PHB”，说明没有NVLink，这时候做张量并行效果会很差。
5. 一些踩坑后的经验之谈
关于GPU架构和AI Infra，我最大的体会是：不要被参数迷惑，要理解参数背后的约束。厂商标称的TFLOPS是在理想条件下的峰值，实际能达到多少取决于你的代码、数据布局、并行策略。我见过太多人买了最贵的卡，却因为代码没优化，实际性能还不如别人用中端卡跑得好。
另一个经验是：环境配置的坑，八成可以用容器解决。如果你不想在CUDA版本、驱动版本、Python依赖之间反复折腾，直接用NVIDIA的PyTorch容器镜像是最省事的。nvcr.io/nvidia/pytorch:24.10-py3这样的镜像已经把CUDA、cuDNN、NCCL、PyTorch都配好了，拉下来就能跑。当然，容器也有代价，比如镜像体积大、需要配置GPU透传，但对于快速验证和团队统一环境来说，收益远大于成本。
最后分享一个查CUDA错误的小技巧：CUDA的错误信息往往很隐晦，比如“an illegal memory access was encountered”，它不会告诉你哪一行代码出的问题。这时候可以用compute-sanitizer工具，它是CUDA版的“内存检查器”，能精确定位到出错的kernel和行号：
compute-sanitizer --tool memcheck python your_script.py这个工具帮我在无数次调试中省下了大量时间，强烈建议每个写CUDA代码的人都掌握。
