CUDA版本与显卡算力对照：支持矩阵、编译参数与错配排查

简介这份PDF文档围绕NVIDIA CUDA展开面向需要核对显卡算力等级与CUDA版本兼容性的开发者、深度学习环境配置人员及GPU选型学习者。内容从CUDA的基本概念、资料传输流程与GPGPU并行计算特点讲起梳理分散读取、统一虚拟内存、共享存储器等机制并延伸到图形渲染、生物信息学、密码学及数据密集计算等应用场景重点部分以表格形式列出各CUDA版本所支持的计算能力与对应微架构便于读者按显卡型号反查可用工具链版本避免驱动、编译器和框架版本错配。包体为1个PDF文件压缩后约1.17MB篇幅紧凑适合作为手边速查资料。该文档已有13597人学习说明其在CUDA版本对照场景中具有较高参考需求。读者可从中获得CUDA版本与算力对应关系、不同计算能力的功能差异、支持语言与计算接口等线索用于环境搭建前的兼容性确认和版本选择。1. CUDA 版本和显卡算力对不上的那些现场装完驱动、装完工具箱、pip 也装好了带 cu 后缀的包脚本跑到第一行还是报CUDA error: no kernel image is available for execution on the device另一种更直接nvcc当场甩一句Unsupported gpu architecture compute_xx连编都不让编。这两类报错看着八竿子打不着根子是同一件事手上这张卡的算力Compute Capability落在哪个区间手里的工具链到底支不支持这个区间。CUDA 版本支持和计算能力的对应表实际上是给三条需求打底的东西一是环境选型先算力后版本、不能倒过来二是编译参数sm_xx写错一个数字就是运行时才炸三是给老机器续命判断哪张卡在哪一代工具箱上就被彻底放弃了。做训练、推理、多卡运维、渲染加速的从业者都会反复查它这份资料把「版本 → 算力区间」和「算力 → 卡型」两条线并排放着可以直接当尺子用照着量完就知道该装哪一版。2. 算力到版本区间CUDA 支持矩阵解析2.1 计算能力是编译器最直接的目标先把一个容易混淆的概念分开计算能力Compute Capability下文简称算力或 CC是一个形如8.6的版本号由主版本号和次版本号组成它描述的是这一代 GPU 的硬件特性集合——每个多处理器里有多少个运算核心、共享内存最大能开多大、寄存器文件有多少、支不支持双精度、有没有张量核心、原子操作能到什么粒度、单个线程块里最多塞多少线程。这些参数不是软件配置是芯片流片时就固化下来的。工具链的所有行为都要围着它转。资料里明确写了只有计算能力 1.x 的那一代CUDA 使用的还是一个不含递归、不含函数指针的 C 语言子集到 2.x 才允许 C 类的子集进来成员函数可以不是虚函数双精度浮点也要到计算能力 1.3 及以上才有。这几条限制翻译过来就是你写同样的 C 代码目标算力不够编译器要么直接拒绝要么按最保守的方式生成指令性能差一截你还找不到原因。所以选型链条只有一条方向不能倒着走卡决定算力算力决定编译器能打哪些目标编译器版本再锁死工具链版本。很多人踩的第一个坑就是反过来做——先看到某个框架推荐 CUDA 11.x回去把工具箱一装插上一张算力 3.0 的老卡然后开始怀疑是驱动问题。其实在装之前查一次算力这个坑根本不会发生。还有一个概念要一并树立起来一套 CUDA 二进制里真正跑在 GPU 上的是设备代码可以是 PTX 中间语言也可以是针对某个算力生成的机器码SASS还可以是两者混合的 fatbin。主机的 C/C 代码仍然交给外部编译器Windows 下常见是 MSVCLinux 下主要是 GCC。这条分工决定了一个事实——主机能不能编过看的是 GCC/MSVC设备能不能跑起来看的是算力和 sm 目标两者出问题时的排查方向完全不同。2.2 一张表要读三遍下限、上限、分水岭资料里最核心的是下面这张版本对照表。里头的「支持算力区间」是闭区间两端都算区间外的卡要么装不上要么装上跑不了CUDA Toolkit 版本支持的计算能力覆盖的微架构备注1.0 ~ 2.01.0 ~ 1.1xTesla初代仅 G80/G92 一类2.1 ~ 2.3.11.0 ~ 1.3Tesla3.0 ~ 3.11.0 ~ 2.0Tesla、FermiFermi 从这一代入场3.2 ~ 4.21.0 ~ 2.1xTesla、Fermi增加 2.1 支持5.0 ~ 6.01.0 ~ 3.5 Kepler6.51.1 ~ 5.x Maxwell最后支持计算能力 1.x7.0 ~ 7.52.0 ~ 5.xFermi、Kepler、Maxwell8.02.0 ~ 6.x Pascal最后支持计算能力 2.x9.0 ~ 9.23.0 ~ 7.2 Volta10.0 ~ 10.23.0 ~ 7.5 Turing最后支持 3.x最后一个支持 macOS 的官方版本11.0 ~ 11.x3.5 ~ 8.6Maxwell、Pascal、Volta、Turing、Ampere下限抬到 3.5Kepler 全线出局提示这张表的版本号只到 11.x 一代再往后各家都会继续调整区间遇到新卡新工具链仍然要以官方当前公布的表格为准不要拿这张当永久答案。读这张表有三个动作缺一个就会误判。第一看下限比如 11.x 的下限是 3.5那么手上算力 3.0、3.2 的 Kepler 卡装 11.x 的任何一个小版本都是白搭最低也得退到 10.2。第二看上限10.2 封顶到 7.5插一张 8.6 的 Ampere 卡上去nvcc根本不认识这个目标。第三看备注列哪一代在哪个版本被砍掉全写在备注里这一列比前两列更容易被忽略也最容易让人在机房白折腾半天。2.3 四个分水岭对应四类现场问题表里真正改变处理方式的节点只有四个每一个都对应一类很具体的现场。6.5 是计算能力 1.x 的终点。从这一代起Tesla 初代架构再也不会被认出来。如果你手上还有一堆算力 1.x 的旧卡能用的最高版本就是 6.0再往上一步都不行。8.0 是计算能力 2.x 的终点。Fermi 从这一代被彻底放弃。这条在实践中比上一条更值得记住因为 Fermi 一代的 Quadro 和 Tesla 专业卡在很长一段时间里还在一些老工作站上服役插上去装新版工具箱表现就是装得上、跑不动、报错指向莫名其妙的地方。10.2 同时是计算能力 3.x 的终点和 macOS 支持的终点。资料里写得很直白CUDA Toolkit 10.2 是最后一个能用于 macOS 的官方版本往后就没了。这意味着一台 Mac 上想跑 CUDA 加速天花板就锁在 10.2而这个版本又不支持 Turing 之后的卡两头一夹基本没有可用的组合。做本地开发机选型的时候这条一定要提前知道别等环境搭一半才发现。11.0 把下限抬到 3.5。注意这一步把 Kepler 里算力 3.0 和 3.2 的卡排除掉了3.5 和 3.7 的 Kepler 反而还留着。也就是说「Kepler 支持不支持」不能一句话回答得看具体的次版本号。这种按次版本号一刀切的边界是这张表里最容易记错的地方我的习惯是遇到老卡就打开表对一遍绝不靠记忆。把这些边界记牢之后再看具体型号就好办了Tensor 系列的 TeGra、Jetson、DRIVE 那些板子也在表里单列了一行算力分别是 3.2Tegra K1、5.3Tegra X1、6.1TX2、6.2X2、7.2Xavier 系列专业卡和工作站卡的算力往往和同代桌面卡一致比如 Turing 一代从桌面到专业卡统一是 7.5。这些信息在给异构设备做统一构建脚本的时候非常有用——你需要的只是「这批设备的算力去重之后有几个值」。3. 查出身三条路径拿到卡的算力3.1 nvidia-smi 与 deviceQuery一个快一个全第一步永远是先把本机的算力读出来不要靠猜型号。最快的办法是直接问驱动# 查询本机所有 GPU 的名称、驱动版本、算力compute_cap 字段较新的驱动才有 nvidia-smi --query-gpuindex,name,driver_version,compute_cap \ --formatcsv,noheader这段命令的每个字段都有用name用来和后面第 3.3 节的型号表交叉验证driver_version是判断能不能跑某个 CUDA 运行时版本的依据compute_cap直接就是主版本号.次版本号例如输出8.6就代表sm_86。--formatcsv,noheader是为了让输出方便被脚本切分写自动化巡检的时候这一条很省事。需要注意compute_cap这个查询字段是较新的驱动才提供的旧驱动上整列会被省略命令本身不报错但拿不到值。所以在老机器上要备第二种办法也就是官方 samples 里的 deviceQuery# 官方 samples 里的 deviceQuery能拿到算力、SM 数量、显存总量等完整参数 cd /usr/local/cuda/samples/1_Utilities/deviceQuery make ./deviceQuery | grep -E Device [0-9]|CUDA CapabilitydeviceQuery输出的CUDA Capability Major/Minor version number就是算力格式是两个整数分开给出拼起来就是sm_majorMinor。从 CUDA 11 前后开始samples 不再跟着工具箱一起安装而是单独发布所以很多新环境里上面那个路径是空的得先单独拉 samples 仓库再编。这一步翻车的人不少现象就是cd进去提示目录不存在。3.2 PyTorch 和 cuPy 交叉验证运行时如果你是 Python 侧的用户直接从框架里读最省事而且还顺带把运行时版本一起验了import torch # 框架版本 它自己编译时用的 CUDA 运行时版本 print(torch:, torch.__version__, cuda:, torch.version.cuda) if not torch.cuda.is_available(): raise SystemExit(运行时不可用先查驱动和 toolkit再查框架包是不是 CPU 版) idx torch.cuda.current_device() print(device:, torch.cuda.get_device_name(idx)) print(capability:, torch.cuda.get_device_capability(idx)) # 返回 (major, minor)如 (8, 6)torch.version.cuda这个值特别关键它告诉你这个 wheel 在构建时链接的是哪一版 CUDA 运行时而不是你本机装的是哪一版。很多「明明装了 toolkit 还是报错」的场景根子就在这里——pip 源里默认拉到的可能是 CPU 版也可能是一个和你驱动不匹配的 cu 版本。get_device_capability返回元组把两个数字拼起来就是编译目标(8, 6)对应sm_86。如果框架这一层就已经报「no CUDA-capable device is detected」那问题在更底层回到 3.1 用nvidia-smi确认驱动是不是真的加载了。3.3 按型号反查够用的一张对照表有时候卡不在手边只有型号——采购清单、别人的机器、容器镜像里的设备白名单。这时候按型号反查算力更快计算能力微架构典型产品线1.0 / 1.1 / 1.3TeslaG80 / G92 / GT200桌面 8 系、9 系、GTX 2xx 一代及对应专业卡2.0 / 2.1FermiGTX 4xx / 5xx 一代3.0 / 3.5 / 3.7KeplerGTX 6xx / 7xx、K 系列专业卡、Tesla K20/K40/K805.0 / 5.2MaxwellGTX 7xx / 9xx 一代6.0 / 6.1 / 6.2PascalGTX 10xx 一代、P100 / P40 / P4、Jetson TX2 / X27.0 / 7.2VoltaV100、Titan V、Jetson Xavier 系列7.5TuringRTX 20xx、GTX 16xx、T4、Quadro RTX 系列8.0 / 8.6AmpereA100、RTX 30xx 一代这张表的价值在于把「型号」这个人类可读的标签翻译成「算力」这个机器可读的参数。实际用的时候有个细节同一代里次版本号可能不一样比如 Pascal 就有 6.0P100、6.1桌面 10xx、P40/P4、6.2Jetson三个值编多架构包的时候三个都得列进-gencode少一个就有一批设备跑不了。同理 Maxwell 的 5.0 和 5.2Kepler 的 3.0/3.5/3.7都不能当成一个值处理。还有一个历史遗留问题值得单独提GTX 1070 Ti 这块卡算力是 6.1但它不受 CUDA 9.0 支持要到 9.2 才被纳入。原因是设备发布晚于工具链冻结9.0 发布时这张卡还不存在设备支持列表里自然没有它。这类「卡比工具链新」的错配光看算力表是看不出来的只能靠版本号比发布时间。4. 定版本从 Toolkit 到编译参数的四层对齐4.1 先看算力上限再看框架侧要求选版本的正确顺序是三步顺序错了就得返工。第一步把本机或目标机群所有卡的算力列出来去重得到一个集合比如{6.1, 7.5, 8.6}。第二步拿这个集合去 2.2 节的表里筛版本。同时满足三个条件的版本才合格集合里的最小值不低于该版本的下限最大值不高于该版本的上限且该版本还没把集合里任何一代砍掉。以{6.1, 7.5, 8.6}为例11.x 的下限是 3.5、上限是 8.6三个值全部落在区间内合格10.2 上限只到 7.58.6 的卡就进不来。第三步才是看框架和第三方库的要求。深度学习框架的 wheel 都是按特定 CUDA 版本编好的你装的 toolkit 版本对不上要么重编框架要么换 wheel。这一步之所以放在最后是因为框架版本可以换卡的算力换不了。注意如果目标机群里同时存在算力 3.x 的老卡和 8.x 的新卡任何单一大版本都覆盖不了只能拆成两套环境或者把老卡从计算节点里摘出去。硬凑的结果一定是其中一端跑不起来。4.2 驱动与运行时次版本兼容规则工具箱版本定了还有一层容易被跳过驱动。CUDA 运行时对驱动有最低版本要求驱动版本不够装再新的工具箱也是白装运行时直接抛CUDA driver version is insufficient for CUDA runtime version。好消息是驱动侧有一条次版本兼容规则同一个大版本内为较低次版本编译的程序可以在较高次版本的驱动上跑反过来不行。换句话说驱动只能往上兼容不能往下兼容。实践中的策略很简单——驱动装到你能拿到的最新稳定版工具箱按算力需求往下选这样兼容性空间最大。容器场景要额外注意一点容器里看到的驱动版本来自宿主机不是镜像里装的那份。镜像里塞了再新的 toolkit宿主机驱动太老照样跑不了所以做镜像前先确认宿主机驱动版本这是运维侧踩得最多的一类坑。4.3 装完就验一个最小闭环工具箱装完不要直接上业务代码跑一个最小闭环把「驱动 → 运行时 → 编译器 → 设备执行」四段全串一遍# 1) 驱动与设备可见性 nvidia-smi # 2) 工具箱版本与编译器版本两者应当一致 nvcc --version cat /usr/local/cuda/version.json 2/dev/null | head -20 # 3) 编一个最小 kernel 并执行验证设备代码真的能跑 cat hello.cu EOF #include cstdio __global__ void hello() { printf(block %d thread %d on sm\n, blockIdx.x, threadIdx.x); } int main() { hello2, 4(); // 2 个块、每块 4 个线程规模刻意开小 cudaError_t err cudaDeviceSynchronize(); // 必须同步否则看不到设备端报错 if (err ! cudaSuccess) { printf(kernel failed: %s\n, cudaGetErrorString(err)); return 1; } return 0; } EOF nvcc -O3 -archnative hello.cu -o hello ./hello四个步骤各有各的用途。nvidia-smi确认驱动加载、设备可见nvcc --version和version.json确认工具箱版本两者不一致通常意味着 PATH 指到了另一份安装。编译那一步用-archnative让编译器自动探测本机算力新版 nvcc 支持这个写法省去手写sm_xx出错的可能。最后一段最关键cudaDeviceSynchronize()的返回值一定要查。CUDA 的 kernel 启动是异步的不同步的话设备端的错误根本传不回主机程序照样正常退出你会误以为一切正常直到业务代码里出现莫名其妙的错误结果。4.4 编译参数sm、compute 与 gencode 的组合真正决定二进制能不能在目标卡上跑的是编译参数。三种写法对应三种发布策略# 写法一只给单一目标生成 SASS体积最小、启动最快但换卡就废 nvcc -O3 -archsm_86 add.cu -o add # 写法二多目标每种算力各嵌一份 SASS一份包跑遍全机型 nvcc -O3 -gencode archcompute_86,codesm_86 \ -gencode archcompute_75,codesm_75 \ -gencode archcompute_61,codesm_61 \ add.cu -o add # 写法三只留 PTX目标机上由驱动 JIT 出对应架构的机器码兼容性最好、首次启动最慢 nvcc -O3 -gencode archcompute_86,codecompute_86 add.cu -o addarchsm_86是简写等价于-gencode archcompute_86,codesm_86。这里两个词要分清楚compute_xx指的是 PTX 的虚拟架构sm_xx指的是实际的机器码架构。codesm_86让编译器直接产出这一代的 SASS运行时不用再编译codecompute_86只产出 PTX运行时由驱动现场 JIT 成机器码好处是同一份 PTX 能在更高算力的卡上跑代价是首次启动有编译开销。同一次编译里混用两种目标也是常见做法。发布给多机型环境的包我一般按「主流卡留 SASS 留一份 PTX 兜底」来配这样即使遇到表里没列的新卡也还有 JIT 这条退路。还有一条规则必须记住SASS 的兼容方向是单向的。为较低次版本编译的 SASS 可以在同一主版本的较高次版本上跑比如sm_80的产物能跑在sm_86上反过来不行sm_86的产物拿到sm_80上会直接报找不到可执行的 kernel。跨主版本更不行sm_75的产物在 8.x 上是绝对跑不起来的。5. 排错算力与版本错配的五种典型现场5.1 构建阶段就拦住的错配现象nvcc报nvcc fatal : Unsupported gpu architecture compute_86加-archsm_86也一样。原因手上的工具链版本上限够不到这张卡的算力。算力 8.6 的卡要 11.x 才能编如果本机装的是 10.2它的上限只到 7.5自然不认识这个目标。解决升级工具箱到支持该算力的版本或者退一步用-archsm_75编出能在同主版本内向下跑的产物——但要清楚这只是权宜之计新架构指令一条都用不上。现象编译能过但deviceQuery一跑就挂或者列出设备后报错用nvcc编任何东西都提示设备不支持。原因卡比工具链新例如 GTX 1070 Ti算力 6.1配 CUDA 9.0。9.0 发布时这张卡还没上市设备支持列表里没有它要到 9.2 才补上。解决直接换 9.2 或更高版本不要试图靠改编译参数绕过这是设备支持列表的问题不是参数问题。5.2 编译过了、运行时才报的错配现象编译零警告运行时报no kernel image is available for execution on the device。原因产物的 fatbin 里没有目标卡对应的 SASS也没有留下可 JIT 的 PTX。典型场景是用-archsm_75编好拿到算力 8.6 的机器上跑跨主版本没有兼容性可言。解决用-gencode把目标算力补进构建如果分不清目标机型就再留一份codecompute_xx的 PTX 兜底。现象报CUDA driver version is insufficient for CUDA runtime version。原因驱动版本低于运行时要求的最低版本。容器里最常见镜像里的 toolkit 很新宿主机驱动停留在很久以前。解决升级宿主机驱动或者把镜像里的运行时降到驱动支持的版本。判断依据是nvidia-smi顶部显示的驱动版本以及运行时的版本号对不上就是这个问题。5.3 平台与老卡上的硬边界现象在较新的 macOS 上无论装哪一版都跑不起来或者装到某一步提示不再支持。原因CUDA Toolkit 10.2 之后官方就不再支持 macOS 了而这个版本本身又卡在 Turing 之前两头一夹基本没有可用的组合。解决不要在 macOS 上继续投入把计算搬到 Linux 或 Windows 机器上本地只保留编辑和调试。这条是硬边界绕不过去。另外还有一类不算错配但经常被误判的情况算力 3.x 的老卡装 11.x。表上看得很清楚11.x 的下限已经抬到 3.53.0 和 3.2 属于被砍掉的那一档但 3.5 和 3.7 的 Kepler 还活着。遇到老卡先确认次版本号别一句「Kepler 不支持」就下结论也别反过来以为「Kepler 都还支持」。6. 进阶把对照关系固化成一张内部清单用久了会发现每次排查都要重新走一遍「查算力 → 对表 → 定版本 → 验编译」这套流程效率很低。我的做法是把结论落成一张团队内部清单格式固定为四列机型 / 算力 / 可用的工具箱版本区间 / 已验证的编译参数。新机器接入时先补齐这张表再动环境。配套的验证动作也要固化。构建产物出来之后别只看编译有没有报错直接查产物里到底嵌了哪些架构# 列出可执行文件里包含的设备代码架构 cuobjdump -lelf hello 2/dev/null || cuobjdump -lelf hello.exe # 或者直接看 SASS 里的目标指令集确认目标架构真的在包里 cuobjdump -sass hello 2/dev/null | grep -m 5 arch -lelf列出的是包里所有 ELF 段对应的架构输出的架构清单和你-gencode里写的那几项应该完全对上少一项就说明编译参数漏了。这个动作我放在发布流程里作为硬性检查比出问题之后再回头翻构建日志省事得多。如果机器上有多种算力不同的卡测试矩阵也按算力划分而不是按机型划分——同算力的不同型号在编译层面是完全等价的没必要各测一遍。加上CUDA_VISIBLE_DEVICES做设备隔离一台机器就能覆盖多个算力档位的冒烟测试。这套组合跑顺之后环境类问题基本在构建阶段就会被拦住不会漏到线上。血泪经验的起点是有一次给一批老卡编包-gencode只写了集合里的最大值本地测试机刚好是那一档一切正常发到机房之后一半节点报 kernel 找不到翻了两小时日志才反应过来是漏了sm_61。从那以后我每次出包前都强制走一遍cuobjdump -lelf把产物里的架构清单和清单表逐项对一遍再也不敢只看编译有没有报错。希望帮到你。本文还有配套的精品资源点击获取