如果你正在做 GPU 并行编程，或者刚开始学 CUDA，迟早会遇到这样一件事：代码在自己电脑上跑得好好的，发到一台服务器上编译，却直接报一句 “unsupported gpu architecture”。第一次碰到这行报错的时候，大多数人都在怀疑工具链配错了，实际上问题往往出在最底层——你根本没搞清楚目标机器上的 GPU 属于哪一代架构、计算能力是多少。这一章要解决的，正是这个“查户口”的问题：把抽象架构名、芯片型号、计算能力编号、编译目标选项全部对起来。搞懂了这张对应表，你再去看 CUDA 例程、深度学习模型脚本里的各种-arch参数，就会有一种豁然开朗的感觉。
1. 为什么写代码前先搞清楚架构和芯片型号
1.1 一次编译报错引发的“户口普查”
先讲一个我印象很深的场景。有次帮同事调一个图像处理的 Demo，代码在本地 RTX 30 系卡上跑得很欢，推到实验室一台旧服务器后，编译阶段直接死了，报错信息大概意思是“不支持的 GPU 架构”。我第一反应是 CUDA 版本太旧，结果检查之后发现版本没问题，问题出在那台服务器的卡是一块老架构的专业卡，计算能力是 6.x，而代码里的编译参数默认写成了sm_86。高版本的 SASS 指令在低计算能力的卡上根本不认，就像你拿一把只有 Windows 11 驱动的设备去接 Windows 7 的系统，接口都对不上。
这种事在真实项目里非常常见。因为很多教程和开源项目都会把编译选项写死成某个新架构，而你手里的卡可能比作者预设的机型老一两个世代。要快速定位这样的问题，你就必须有一张清晰的“架构与芯片型号对照表”在脑子里。这章从头到尾要做的，就是把这张表彻底讲透。
1.2 架构、芯片、计算能力三个概念的分工
很多初学者会把“架构”和“芯片型号”混为一谈。比如会说“RTX 3090 是 Ampere 架构”“A100 是 Ampere 架构”，这话没错，但不够严谨。严格来说，架构是一套硬件设计方案，芯片是这套方案的具体物理实现，而计算能力（Compute Capability）是这套实现对外暴露的编程接口版本。
我用一个生活化的类比解释一下。架构就好比一套住宅的设计图纸，芯片是按照图纸盖出来的具体房子，计算能力则是门牌号。同一套图纸可以盖出不同面积、不同装修档次的房子，对应同一代架构下有不同核心代号、不同型号的芯片；而门牌号决定了你能否用某种钥匙开门、门内有没有电梯，对应了代码能使用哪些硬件特性和指令。
具体到 NVIDIA 的产品线：Ampere 是一个架构，它的数据中心级芯片是 GA100，消费级芯片是 GA102、GA104、GA106，前者的计算能力是 8.0，后三者是 8.6。你写代码时通常不需要关心芯片内部到底是 GA100 还是 GA102，但你必须知道目标卡的计算能力是多少，因为编译器和运行时是根据这个数字来决定能生成什么指令、启用什么特性的。
1.3 查架构到底在查什么
当你准备在一台 GPU 机器上跑并行程序时，你需要确认的信息其实有三层：
第一层是“架构代际”，也就是这块卡属于哪一代产品，这决定它支持哪些硬件特性，比如是否有 Tensor Core、是否支持独立线程调度、是否支持 FP8 计算。第二层是“计算能力版本”，也就是那串形如8.6、9.0的数字，代码编译目标、CUDA 运行时兼容性都看它。第三层才是“具体芯片型号和显存规格”，这影响你的任务能不能装得下、带宽够不够。
实际操作中很多人只看第三层，比如只看显存多少、看着是某型号的高端卡就直接上了，结果下一层出了兼容性问题。所以我在做项目时有个习惯：进入一个新环境，先花两分钟把这三层信息全部查出来写进笔记，再做任何编译和性能测试。这习惯救了我很多次。
2. 从 Kepler 到 Blackwell：五代架构芯片型号全景速查表
2.1 一套能直接抄作业的对照表
下面这张表是我自己整理并一直在更新的，覆盖面从还能在实验室角落里碰到的老卡，一直到最新的消费级和数据中心级产品。没有必要死记硬背，把它当成词典查就行，但每个架构后面的关键特性要大致有印象，因为它决定了你能用什么 API、能达到什么性能水平。
| 架构代号 | 计算能力 | 代表芯片型号 | 关键定位与特性 |
|---|---|---|---|
| Kepler | 3.0 / 3.5 / 3.7 | GTX 680、GTX Titan、GTX 780、Tesla K80 | 太老，编程模型与现代差异大，只建议跑兼容性测试 |
| Maxwell | 5.0 / 5.2 | GTX 750 Ti、GTX 980、Tesla M40 | 当年低功耗代表，无 Tensor Core，深度学习性能很弱 |
| Pascal | 6.0 / 6.1 | Tesla P100、GTX 1080、GTX 1070、Tesla P40 | FP64 性能尚可，NVLink 首次出现，老代码兼容性广 |
| Volta | 7.0 | Tesla V100、Titan V | Tensor Core 初代，独立线程调度引入，AI 训练里程碑 |
| Turing | 7.5 | RTX 2080 Ti、RTX 2070、Tesla T4、GTX 1660 | 首次加入光线追踪硬件，T4 是推理场景经典卡 |
| Ampere | 8.0 / 8.6 | A100、RTX 3090、RTX 3080、RTX 3070、RTX 3060 | TF32、BF16 支持，MIG 多实例，AI 训练主流选择 |
| Ada Lovelace | 8.9 | RTX 4090、RTX 4080、RTX 4070、RTX 4060 | 能效大幅提升，DLSS 3 补齐，消费级 AI 生产力 |
| Hopper | 9.0 | H100、H200 | FP8、Transformer 引擎、NVLink Switch，大模型基础设施 |
| Blackwell | 10.0 数据中心级 / 12.0 消费级 | B200、RTX 5090、RTX 5080 | 双芯片封装设计，面向超大模型与新一代推理需求 |
注意几个细节。同样是 Ampere 架构，A100 的计算能力是 8.0，而 RTX 30 系是 8.6；同样是 Turing 架构，带光追核心的 RTX 20 系和砍掉光追单元的 GTX 16 系都叫 7.5，但硬件能力差了一截。这也验证了前面说的：架构、芯片、计算能力是三件事，查表时不能只看一个维度。
2.2 关键规格参数怎么读
对照表给了架构和型号，但实际选型时你还要会读几个关键参数。
第一个是计算能力编号的含义。比如8.6，第一位“8”代表大的架构代际，第二位“6”是小版本差异。小版本通常意味着在同一代架构里加入了特定的指令变体或硬件配置调整，比如 Ampere 的 8.0 和 8.6 在指令细节上就有差别。代码按sm_80编译出来的 cubin 可以在sm_86的卡上运行，但按sm_86编译的 cubin 拿到sm_80的 A100 上就可能跑不了。所以写可移植代码时，要么用 PTX 层面的中间表示，要么针对多个算力版本分别生成机器码。
第二个是流处理器数量和显存带宽。这两个参数决定了理论算力和实际数据搬运速度。很多新手只看显存容量，觉得 24GB 一定比 12GB 好，但如果是训练大模型、持续读写数据，带宽比容量更重要。A100 的显存带宽差不多是普通 GDDR6 游戏卡的三四倍，这才是它在训练场景下不可替代的核心原因之一。
第三个是 Tensor Core 代际。Volta 开始有第一代 Tensor Core，Turing 加入 INT8/INT4 推理优化，Ampere 支持 TF32 和 BF16，Hopper 引入 FP8。这个列表直接决定了你做混合精度训练时能吃到多少红利。拿一张没有 Tensor Core 的老卡去跑现代 PyTorch 模型，速度和精度都会很吃亏。
2.3 容易踩的坑：同型号显卡的“马甲”与阉割
还有一类情况特别容易让人翻车，就是只看型号不看芯片。同一个型号名，尤其是笔记本 GPU 和部分入门台式卡，内部芯片可能根本不一样。
举几个真实存在的例子：GTX 16 系用的确实是 Turing 架构的芯片，但砍掉了光追核心和 Tensor Core，所以它和同代的 RTX 20 系在并行计算能力上完全不是一个量级；RTX 3050 在不同批次里出现过不同的核心版本，参数和功耗都有细微差别，虽然计算能力都还是 8.6；一些老专业卡的显存很大，比如某些 Maxwell 压垮时代的 24GB 大显存卡，但它完全没有现代深度学习需要的硬件加速特性。
所以当别人给你推荐“便宜大碗”的二手卡或“高性价比”计算卡时，不要只问显存多大，一定要查清楚它是哪一代架构、有没有 Tensor Core、计算能力是多少。后面我会专门讲怎么查这信息。
3. 拿到一块 GPU，三步确定它的架构和算力
3.1 最稳妥的方式：运行时 API 查询
最可靠的方法永远是通过 CUDA 运行时 API 去读设备属性，因为这是硬件和驱动直接给出的答案，不掺杂任何第三方推测。
写一个很小的 C 程序就能办到。先建一个文件，就叫dev_query.cu，内容如下：
#include <stdio.h> #include <cuda_runtime.h> int main() { int count = 0; cudaGetDeviceCount(&count); for (int i = 0; i < count; i++) { cudaDeviceProp prop; cudaGetDeviceProperties(&prop, i); printf("Device %d: %s\n", i, prop.name); printf(" Compute Capability: %d.%d\n", prop.major, prop.minor); printf(" Global Memory: %.2f GB\n", prop.totalGlobalMem / 1024.0 / 1024.0 / 1024.0); printf(" Multiprocessors: %d\n", prop.multiProcessorCount); } return 0; }然后用nvcc -o dev_query dev_query.cu编译，直接运行。输出的“Compute Capability”就是计算能力。这个程序在任何装了 CUDA 工具链的机器上都能编译运行，是我在陌生服务器上排查兼容性问题的第一板斧。另外 CUDA 示例包里自带的deviceQuery也是同样的道理，看输出里的CUDA Capability major/minor version那一栏即可。
如果不想碰 C 语言，Python 用户有更省事的办法。只要环境里装了 PyTorch，两行代码就能查：
import torch print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))输出结果类似8.6，秒出。没有 PyTorch 的话，装一个支持 CUDA 的版本本身也不复杂。
3.2 系统命令行工具查询
还有一种更轻量的方式，不依赖 CUDA 工具链，只要装了显卡驱动就能用。终端执行：
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv这会告诉你显卡名称、显存容量和驱动版本。部分较新版本的nvidia-smi也能直接输出产品架构信息，比如执行nvidia-smi -q后在硬件信息里查找 “Product Architecture” 字段，但不同驱动版本格式有差异。
需要注意的是，nvidia-smi查不到计算能力版本，它更多是给你一个“这机器上到底插了什么卡、驱动多老、有没有其他进程占了显存”的宏观印象。如果后续要在老卡上跑新代码，光靠它无法判断兼容性，还是得回到运行时 API 那一步。
我自己在本地的一贯做法是组合拳：先nvidia-smi看驱动和整体状态，再跑一段运行时 API 查询拿到计算能力，最后查一下 GPU-Z（Windows 下）或nvidia-smi -q里的核心代号，三份信息合起来，这张卡的“户口”就彻底清楚了。
3.3 从产品型号命名反推架构
在没有命令行环境的时候，光看型号也能反推大概。NVIDIA 消费级产品的规律很明显：GTX 9 系是 Maxwell，GTX 10 系是 Pascal，GTX 16 系和 RTX 20 系是 Turing，RTX 30 系是 Ampere，RTX 40 系是 Ada Lovelace，RTX 50 系是 Blackwell。数据中心级产品更好记，V100 对应 Volta，A100 对应 Ampere，H100/H200 对应 Hopper，B200 对应 Blackwell。
但反推只能作为辅助判断，因为同一个型号内部可能有马甲，而且不少专业卡、嵌入式卡的命名跟消费级完全不同。比如型号里带“T”的 Tesla 各代产品，单看数字完全看不出架构。所以我的原则是：型号命名只用来建立初步印象，任何重要决策前必须用工具确认一次真实计算能力。反推省不了那个确认的步骤。
4. 不同架构编程时的适配要点
4.1 算力与编译目标选项的对应关系
当你知道一块卡的计算能力之后，最关键的动作就是把编译参数写对。CUDA 编译器里有两个容易混淆的选项：一个是-arch=compute_XX，表示生成某种虚拟架构（PTX）的中间代码；另一个是-arch=sm_XX，表示直接生成某种实际架构（SASS）的机器码。
举个例子。你的卡是计算能力 8.6 的 RTX 3070，那么最直接的编译方式是：
nvcc -arch=sm_86 -o demo demo.cu这样生成的 cubin 只能跑在 8.6 及兼容的后续架构上。如果换成：
nvcc -arch=compute_86 -code=sm_86 -o demo demo.cu意思就是先生成 8.6 的 PTX 中间代码，再把它编译成 8.6 的机器码。插一句，compute_XX生成的 PTX 代码在运行时还有可能被驱动进一步 JIT 编译成其他近世代架构的指令，所以它的兼容性比直接sm_XX更好一些。
如果你希望同一个二进制能在不同世代的卡上跑，可以用多组-gencode参数，让编译器同时生成多份机器码：
nvcc -gencode arch=compute_70,code=sm_70 \ -gencode arch=compute_80,code=sm_80 \ -gencode arch=compute_90,code=sm_90 \ -o demo demo.cu代价是二进制体积变大、编译时间变长，好处是拿到 V100、A100、H100 的机器上都能直接跑。我在发布一些要分发给别人的演示程序时，就喜欢这样干，免得到别人机器上又被“不支持的架构”绊一跤。
4.2 架构代际的编程语义差异
除了编译参数，架构代际还直接影响你的核函数该怎么写。这个很多人一开始没概念，等写出 bug 才反应过来。
一个典型差异是 Volta 架构引入的独立线程调度。在更老的架构上，一个 warp 里的线程在执行分支时是共享程序计数器的，遇到发散分支（warp divergence），整个 warp 会串行跑每个分支路径。而 Volta 之后，每个线程有独立的程序计数器，发散分支的处理变得更高效，但代价是某些依赖“同一个 warp 中线程隐式同步”的老写法会失效。
另一个差异是共享内存和寄存器的资源上限。每一代架构的每线程寄存器数、每块共享内存上限都不同，直接写死了共享内存用量的核函数，换到新架构上可能分配失败，也可能浪费了新架构提供的更大空间。有经验的开发者会通过类似cudaFuncSetAttribute的方式来主动申请更大的共享内存，而不是依赖默认值。你在读别人代码时看到类似设置，大概率就是为了适配特定架构的容量上限。
Tensor Core 的使用方式也一样。从 Volta 到 Ada，混合精度编程接口和推荐做法变了好几次。跑老教程里的 FP16 代码可能没问题，但那些代码在 Ampere 之后往往没有充分利用 TF32/BF16 能力。想真正吃到新架构性能红利，就得按新指令和库函数重新调整计算路径。
4.3 驱动、CUDA 版本与架构的兼容搭配
架构兼容性不止表现在编译器上，驱动和 CUDA 工具链版本同样关键。
一个很容易踩的坑是：新卡的硬件功能需要新驱动才能完整启用。装一块最新架构的卡，却使用两年前的老驱动，虽然系统能识别，但某些指令或库函数可能直接禁用或崩溃。反过来，老架构的卡在太新的 CUDA 版本下不一定能用到所有新特性，好在 NVIDIA 对老计算能力的支持周期非常长，所以真正常见的坑还是“新代码 + 老卡”的组合。
另外要注意驱动版本和 CUDA 运行时版本之间的关系。CUDA 程序运行到目标机器上时，它需要的驱动版本必须不低于编译时对应的最低驱动版本。你可以用nvidia-smi看到的 CUDA 版本那一栏来判断当前驱动支持到什么程度的 CUDA 运行时，但那只是驱动支持的上限，实际项目里还要看编译目标架构是否被驱动覆盖。遇到运行时报“CUDA driver version is insufficient”这类错误，排查方向基本都是驱动太老，而不是代码写错。
给一个实用建议：进入一个团队或项目组，先统一一份“工具链白名单”，包括 CUDA 版本、驱动版本、支持的计算能力范围。别小看这件事，它能省掉大量因为架构不匹配而产生的无效排查时间。我自己通常会在项目 README 里写清楚开发机器的 GPU 架构和编译参数，因为一个月后回来翻项目的往往就是自己。
5. 按场景挑芯片型号的实战建议
5.1 深度学习训练：显存、Tensor Core、NVLink 一个都不能少
做深度学习训练，选卡的第一原则是显存，因为模型参数、梯度、优化器状态都要塞进显存里，装不下就是装不下，再多理论算力也没用。第二原则才是架构新，因为新架构的 Tensor Core 代际更高，混合精度训练的加速比非常明显。第三原则是多卡场景下的 NVLink，这是很多人忽视的。
举个例子，两张 GPU 如果只靠 PCIe 通信，训练大模型时梯度同步会成为巨大瓶颈；而有 NVLink 直连的卡，通信带宽能高一个量级。这就是为什么数据中心级产品如 A100、H100 那么贵还有人抢，不是贵在算力本身，而是贵在整个并行效率。
如果你的预算只够买消费级卡，那 RTX 30 系和 40 系是主要选择。30 系里 3090 几乎是性价比天花板，24GB 显存至今还能跑不少开源模型微调；40 系里 4090 性能更强，但价格也高。唯一要避免的是买老架构的大显存专业卡，比如一些 Maxwell、Pascal 时代的 24GB 卡，它们虽然显存够，但没有 Tensor Core，训练速度会让你怀疑人生。
5.2 科学计算和长时间任务：稳定与 FP64 性能优先
科学计算和深度学习的选卡逻辑差别很大。很多科学计算程序，比如流体仿真、分子动力学、有限元分析，非常依赖 FP64 双精度浮点性能。而消费级游戏卡通常会把 FP64 性能砍得很低，大约是 FP32 的 1/64，因为在游戏场景里 FP64 几乎用不到。这个差别真的是天壤之别。
如果主要跑这类任务，老老实实选数据中心级或专业级卡，比如 P100、V100、A100 系列，它们的 FP64 吞吐量是实打实的。同样，长时间跑任务的场景下，公版和专业卡的散热设计、显存 ECC 校验也是重要优势。消费卡跑几天几夜的训练或仿真，遇到掉驱动、内存错误重算，损失的时间成本远高于省下的买卡钱。
这里还提醒一个冷门点：老一代的 Tesla 卡虽然架构旧，但很多特性设计得比新游戏卡更“耐造”，适合作为低成本方案跑科学计算，前提是你对计算能力要求不高、且能接受驱动配置上的麻烦。
5.3 入门学习和桌面场景：不必追新，重在跑通特性
如果你是刚开始学 GPU 并行编程，或者只是把 GPU 当普通加速工具用，那完全没有必要上顶级卡。入门阶段最应该关心的是“教程里的代码能不能跑起来”。这要求卡的架构不能太老，至少是 Pascal 或 Turing 以上，因为很多现代教材和开源项目默认编译目标已经提到了sm_70甚至更高。
一块 RTX 3060 或者 RTX 4060 笔记本卡就足够跑绝大多数入门到中级例程了，甚至一块二手 GTX 1080 也能坚持很久。真正卡脖子的反而是驱动配置、开发环境，而不是硬件本身。等你明确知道自己要跑什么模型、什么计算负载之后，再根据瓶颈选卡，这样钱花得最值。
如果你连本机都没有 GPU，也没关系，现阶段不少云平台都提供按小时计费的 GPU 实例，选择时重点看一下它给的架构型号和显存，然后对照本章的表格查一下计算能力。对我个人来说，在一个能随时重装系统的云环境里做实验，往往比折腾本地驱动更省心。
6. 常见问题与排查技巧实录
6.1 编译报错“不支持的算力”怎么办
这类报错通常有两种形态。一种是nvcc fatal : Unsupported gpu architecture 'compute_XX'，多数情况下是 CUDA 工具链版本太老，不认识这么新的算力编号，比如用 CUDA 11.0 去编译compute_90就会报错，升级工具链即可。另一种是代码默认编译目标太高，而你的卡计算能力太低，比如默认sm_86的代码跑到 Pascal 卡上。解决办法是按目标卡的实际计算能力重新编译，或使用多架构-gencode。
排查步骤我一般是这样：先查目标卡计算能力，再查本机nvcc版本支持的架构范围，最后把编译参数改成与卡匹配的目标。三步走完，95% 的编译兼容问题都能解决。
6.2 显存大不等于性能强
这句话我几乎每次做技术咨询都要重复一遍。有人拿一块 24GB 显存的老加速卡来跑深度学习，被速度气到怀疑人生。这里的问题很可能不在显存，而在架构。老卡没有 Tensor Core，或者 Tensor Core 代际太老，导致的混合精度加速完全用不上；同时老卡的内存带宽、指令集效率也比现代卡差很多。同样跑一个 batch size 固定的训练，3090 可能比老卡快五倍以上。
真要说“显存大户”该怎么选，我会先算三个数：模型权重多大、激活值峰值多大、优化器状态多大，三个数加在一起才是底线显存。然后在这个前提下，尽量选架构新、带宽高、带 Tensor Core 的卡。顺序不要反过来。
6.3 二手卡快速识别架构真伪
二手市场水深，尤其是一些“高性价比”计算卡，你看到的型号未必代表里面的芯片。识别方法并不难：拿到卡后先跑一次真实的设备查询代码，把计算能力记录下来，再和官方规格对照。还可以用 GPU-Z 之类的工具直接读核心代号和流处理器数量，看是否和型号对应。
另外就是跑一个标准 Benchmark，比如说矩阵乘法吞吐、显存带宽测试，和网上同型号公开数据对比。如果型号对得上但跑分相差太多，要么是芯片被换过，要么是散热/供电出了问题。我的习惯是任何二手卡到手先做 30 分钟满载测试，同时观察温度和功耗曲线，然后再决定是否把它用在正式项目里。
最后再分享一个我个人的实战习惯：现在我到任何一台 GPU 机器上，第一件事永远是查三样东西——驱动版本、CUDA 工具链版本、所有 GPU 的计算能力，并把结果写进项目笔记。很多人觉得这是多余动作，但正是这个动作，让我在几十次“换机器跑代码”的场景里几乎没有被架构兼容性问题卡住超过十分钟。GPU 并行编程的很多坑都是信息不对称造成的：只要你先把硬件底细摸清楚，后面所有编译、调试、性能优化都变得顺理成章。希望这份架构与芯片型号对照，也能帮你少走一段弯路。
