简介本资源是一份系统梳理NVIDIA显卡CUDA算力与版本兼容关系的权威参考文档面向深度学习工程师、GPU开发者及高性能计算初学者解决选型时‘某型号显卡支持哪些CUDA版本’‘不同CUDA版本对应哪些计算能力Compute Capability’等核心问题。文档以PDF格式呈现内容涵盖G8x至最新Ampere/Ada架构显卡的完整算力代号如3.5、6.1、8.6、8.9、各CUDA Toolkit版本1.0至11.7所支持的算力范围、微架构演进对照以及macOS支持终止CUDA 10.2起、二进制兼容性说明等关键细节。资源包仅含1个PDF文件大小1.17MB轻量易读适合作为开发环境搭建前的快速查阅手册。目前已有13582人学习下载内容源自CSDN社区高频需求整理结构清晰、数据准确可直接用于驱动安装、CUDA版本选择与跨平台迁移决策。1. CUDA详细参数算力CUDA支持版本为什么查对GPU算力和驱动兼容性比调参还决定模型能不能跑起来你刚在某实验室服务器上nvidia-smi看到 Tesla V100-SXM2-32GB兴冲冲pip install torch2.1.0cu118结果import torch报CUDA error: no kernel image is available for execution on the device或者用新买的 RTX 4090 跑一个老项目nvcc --version显示 12.2但编译的.so在运行时直接段错误——这些不是玄学是 CUDA 算力Compute Capability和 CUDA Toolkit / 驱动版本三者没对齐的硬性报错。本篇不讲“CUDA 是什么”只聚焦一线工程师每天要查、要填、要核对的三组关键参数GPU 的硬件算力代号如 7.5、8.6、9.0、驱动最低要求版本Driver Version、CUDA Toolkit 最高/最低支持版本CUDA Version。它决定了你能否装上对应 PyTorch/TensorFlow能否编译成功.cu文件甚至决定一个预编译 wheel 是否能在你的机器上加载。适合所有需要在多卡、多代 GPU 环境下部署模型的开发者、MLOps 工程师、高校实验室运维人员——别再靠试错来验证兼容性这张表这套查法就是你的后悔药。2. 查清 GPU 硬件算力从型号到 compute capability 的精准映射GPU 的算力Compute Capability简称 CC是 NVIDIA 定义的一组硬件特性集合它不是性能分数而是功能开关清单是否支持 Tensor Core是否支持 FP16 warp shuffle是否支持异步内存拷贝不同 CC 值意味着 CUDA 编译器生成的 PTX/SASS 指令集不同低算力卡无法执行为高算力卡编译的二进制代码。因此第一步永远不是装 CUDA而是确认你手上那块物理卡的准确 CC 值。2.1 用 nvidia-smi 官方文档交叉验证最稳nvidia-smi只显示 GPU 型号和驱动版本不显示算力。常见误区是看到 “RTX 4090” 就默认 CC8.9 —— 错。RTX 4090 是 Ada Lovelace 架构CC8.9但同属 Ada 的 L40数据中心卡是 CC8.9而 L4推理卡却是 CC8.9L40S 是 CC8.9 —— 看似一样实则需查证。正确做法是先用nvidia-smi -L获取完整设备名含 PCI ID$ nvidia-smi -L 0: NVIDIA RTX A6000 (UUID: GPU-xxxxxx) 1: NVIDIA A100-SXM4-40GB (UUID: GPU-yyyyyy)对照 NVIDIA 官方 CUDA GPUs 文档 注意必须用当前最新版文档旧版可能遗漏新卡。该页按架构分组每行明确列出型号、架构、CC 值、发布年份。例如搜索 “RTX A6000”可定位到 Ampere 架构下RTX A6000: Compute Capability 8.6A100-SXM4-40GB: Compute Capability 8.0提示文档中 “Architecture” 列Ampere / Ada / Hopper比型号名更可靠。同一架构下不同型号 CC 可能不同如 H100 PCIe 是 9.0H100 SXM5 也是 9.0但跨架构一定不同Turing7.5Ampere8.xAda8.9Hopper9.0。2.2 用 deviceQuery 工具实测验证编译环境是否识别正确deviceQuery是 CUDA SDK 自带的诊断工具它会实际调用 CUDA Driver API 查询设备能力比查文档更“落地”。它能暴露驱动/CUDA Toolkit 是否真能与硬件握手# 确保 CUDA 已安装且 PATH 包含 bin 目录 $ which deviceQuery /usr/local/cuda/bin/deviceQuery $ deviceQuery ./deviceQuery Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 2 CUDA Capable device(s) Device 0: NVIDIA RTX A6000 CUDA Driver Version / Runtime Version: 12.4 / 12.2 CUDA Capability Major/Minor version number: 8.6 # ← 这里是真实返回的 CC 值 Total global memory: 48601 MBytes ...注意输出中CUDA Capability Major/Minor version number这一行——它由 GPU 固件和驱动共同决定若此处显示0.0或报错no CUDA-capable device is detected说明驱动未正确加载或 CUDA 安装路径混乱此时查文档也没用。2.3 常见卡型算力速查表2023–2024 主流型号GPU 型号架构Compute Capability备注RTX 4090 / 4080Ada8.9支持 FP8 Tensor CoreRTX A6000Ampere8.6数据中心级双精度强于消费卡A100-40GB / 80GBAmpere8.0SXM4/SXM5 接口支持结构化稀疏V100-SXM2 / PCIeVolta7.0不支持 Tensor Core 的 INT8/FP16T4Turing7.5低功耗推理卡无 FP64L4 / L40Ada8.9L40 是 8.9L4 是 8.9同架构H100-SXM5 / PCIeHopper9.0首款支持 FP8 和 Transformer Engine注意“RTX 3090” 是 AmpereCC8.6但 “RTX 3090 Ti” 仍是 8.6不是 8.7 —— NVIDIA 从未发布过 8.7。CC 值是离散的不存在小数点后两位随意递增。所有 “8.7”、“8.8” 均为误传。3. 驱动版本与 CUDA Toolkit 版本三者兼容性的黄金三角光知道 GPU 算力还不够。CUDA 生态有三层依赖GPU 硬件 → NVIDIA 驱动 → CUDA Toolkit → 应用PyTorch/TensorFlow。其中驱动和 Toolkit 的版本必须满足 NVIDIA 官方定义的向后兼容规则否则cudaMalloc都会失败。3.1 驱动版本决定 CUDA Toolkit 上限关键NVIDIA 驱动是向下兼容的新版驱动可运行旧版 CUDA Toolkit 编译的程序但旧版驱动无法加载新版 Toolkit 编译的模块。例如驱动版本 515.48.072022 年 8 月发布最高支持 CUDA 11.7驱动版本 525.60.132022 年 11 月最高支持 CUDA 11.8驱动版本 535.54.032023 年 6 月最高支持 CUDA 12.2驱动版本 535.104.052023 年 10 月最高支持 CUDA 12.3驱动版本 545.23.082023 年 12 月最高支持 CUDA 12.4。这个关系不是线性增长而是由驱动内置的libcuda.soABI 版本决定。你可以这样查当前驱动支持的最高 CUDA 版本# 方法一查驱动 release notes最准 $ nvidia-smi --query-gpuname,driver_version --formatcsv name, driver_version NVIDIA RTX A6000, 535.104.05 # 然后去 https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html # 找 “CUDA Toolkit v12.3 Release Notes” → “Supported Operating Systems and GPUs” 表 # 查 “Minimum Required Driver Version” 列535.104.05 → 支持 CUDA 12.3# 方法二用 nvidia-smi -q 输出隐含信息需解析 $ nvidia-smi -q | grep CUDA Version CUDA Version : 12.3 # ← 注意这是驱动声称自己能支持的最高 CUDA 版本非已安装版本提示nvidia-smi输出的 “CUDA Version” 是驱动支持能力不是你系统里装了哪个 CUDA。它告诉你“只要我驱动在这你装 CUDA 12.3 的 toolkit 就能用”。3.2 CUDA Toolkit 版本决定编译目标算力-gencode 关键参数CUDA Toolkit 安装包自带nvcc编译器它通过-gencode参数指定生成哪些算力的二进制代码。一个.cu文件编译出的.o文件可能同时包含sm_75,sm_80,sm_86多个版本的 SASS 代码运行时由 CUDA Runtime 根据实际 GPU 动态选择。但如果你只指定了sm_86而用户用的是 V100CC7.0就会报no kernel image is available。典型编译命令nvcc -gencode archcompute_86,codesm_86 \ -gencode archcompute_80,codesm_80 \ -gencode archcompute_75,codesm_75 \ -o my_kernel.o my_kernel.cu参数含义archcompute_86: 生成 PTX 中间码虚拟指令集兼容所有 ≥8.6 的卡codesm_86: 生成针对 CC8.6 GPU 的原生 SASS 二进制最快同时指定多个gencode可实现“一次编译多卡运行”。血泪经验PyTorch 官方 wheel 默认编译了sm_50,sm_60,sm_70,sm_75,sm_80,sm_86,sm_90—— 所以它能在从 M40 到 H100 的全系列卡上运行。但你自己写的 extension若只写sm_86就锁死了只能在 A100/A6000/4090 上跑。3.3 PyTorch/TensorFlow wheel 的 CUDA 版本绑定逻辑你pip install torch时选的cu118或cu121不是指“用 CUDA 11.8 编译”而是指该 wheel 内置的.so是用 CUDA 11.8 Toolkit 编译的它要求系统驱动 ≥ CUDA 11.8 所需的最低驱动如 11.8 要求驱动 ≥ 450.80.02它内部torch.cuda.get_device_capability()返回的 CC 值由nvidia-smi 驱动决定与 wheel 无关。验证方式import torch print(torch.__version__) # 2.1.0cu118 print(torch.version.cuda) # 11.8 print(torch.cuda.get_device_capability(0)) # (8, 6) ← 来自 GPU 硬件 驱动非 wheel所以wheel 的cuXX后缀只约束你系统的驱动版本下限不约束 GPU 算力。RTX 4090CC8.9可以跑cu118的 PyTorch只要驱动够新≥450.80.02但 V100CC7.0不能跑只编译了sm_86的自定义 op哪怕 wheel 是cu121。4. 避坑CUDA 算力与版本兼容的 4 个高频翻车现场这些不是理论问题是我在三个不同实验室部署大模型训练 pipeline 时平均每周都会遇到的真实报错。列在这里是为了让你少花 3 小时 debug。4.1 现象ImportError: libcudnn.so.8: cannot open shared object file原因CUDA Toolkit 版本与 cuDNN 版本不匹配。cuDNN 是独立发布的库每个版本只支持特定范围的 CUDA 版本。例如 cuDNN 8.9.2 仅支持 CUDA 11.8/12.1/12.2不支持 12.3。而apt install libcudnn8默认装最新版可能与你export CUDA_HOME/usr/local/cuda-12.1冲突。解决查 cuDNN 官方兼容表 cuDNN Archive 下载与你 CUDA Toolkit 版本严格对应的 cuDNN runfile如cudnn-linux-x86_64-8.9.2.26_cuda12.1-archive.tar.xz解压后sudo cp头文件和 so 到/usr/local/cuda-12.1/对应目录不要用 apt。4.2 现象nvcc fatal : Unsupported gpu architecture compute_90原因你升级了 CUDA Toolkit 到 12.3但nvcc仍指向旧版本如/usr/local/cuda-11.8/bin/nvcc而旧版 nvcc 不认识 Hopper 架构的compute_90。解决which nvcc确认路径nvcc --version看实际版本若不一致export PATH/usr/local/cuda-12.3/bin:$PATH并重 source永久生效写入~/.bashrc或/etc/profile.d/cuda.sh。4.3 现象CUDA error: no kernel image is available for execution on the device原因最常见于自定义 CUDA Extension。你用setup.py编译时TORCH_CUDA_ARCH_LIST环境变量未设置或只设了8.6但运行时 GPU 是7.5如 T4。PyTorch 默认只编译当前主卡的算力不自动 fallback。解决# 编译前显式指定多算力空格分隔 export TORCH_CUDA_ARCH_LIST7.5 8.0 8.6 8.9 9.0 python setup.py build_ext --inplace注意TORCH_CUDA_ARCH_LIST是 PyTorch 的约定不是 nvcc 原生命令。它会被 PyTorch 的cpp_extension模块读取并转为-gencode参数。4.4 现象nvidia-smi正常但torch.cuda.is_available()返回 False原因驱动与 CUDA Toolkit 的libcuda.so/libcudart.so版本冲突。典型场景系统装了驱动 535但LD_LIBRARY_PATH指向/usr/local/cuda-11.7/lib64含旧版libcudart.so.11.7而 PyTorch 2.1 要求libcudart.so.11.8。解决ldd $(python -c import torch; print(torch.__file__)) | grep cuda查依赖的 sofind /usr/local/cuda* -name libcudart.so.*找所有版本export LD_LIBRARY_PATH/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH强制优先加载更彻底卸载旧 CUDA Toolkit只保留一个版本。5. 实战用 Python 脚本一键校验本地 CUDA 兼容性手动查表、比对版本太慢。我写了一个轻量脚本cuda_check.py它不依赖任何外部库只用标准库 subprocess5 秒内输出你环境的完整兼容快照。它解决了三个核心问题当前 GPU 型号 → 算力值调用deviceQuery或 fallback 到nvidia-smi 查表驱动版本 → 支持的最高 CUDA 版本查 NVIDIA 官方 release notes JSON已安装 CUDA Toolkit → 是否在驱动支持范围内比对nvcc --version与驱动上限。5.1 脚本核心逻辑与使用方式#!/usr/bin/env python3 # cuda_check.py - 本地 CUDA 兼容性快照生成器 import subprocess import json import sys import re def get_gpu_info(): try: out subprocess.check_output([nvidia-smi, -L], textTrue) gpus [line.split(: )[1].split( ()[0].strip() for line in out.strip().split(\n)] return gpus[0] if gpus else Unknown GPU except: return No GPU detected def get_driver_version(): try: out subprocess.check_output([nvidia-smi, --query-gpudriver_version, --formatcsv,noheader,nounits], textTrue) return out.strip() except: return N/A def get_cuda_version(): try: out subprocess.check_output([nvcc, --version], textTrue) m re.search(rrelease (\d\.\d), out) return m.group(1) if m else N/A except: return N/A def get_compute_capability(gpu_name): # 简化版映射表生产环境建议用 JSON 文件维护 cc_map { RTX 4090: 8.9, RTX 4080: 8.9, RTX A6000: 8.6, A100: 8.0, V100: 7.0, T4: 7.5, L4: 8.9, H100: 9.0 } for key in cc_map: if key in gpu_name: return cc_map[key] return Unknown def main(): gpu get_gpu_info() driver get_driver_version() cuda get_cuda_version() cc get_compute_capability(gpu) print(fGPU Model: {gpu}) print(fCompute Cap: {cc}) print(fDriver Ver: {driver}) print(fCUDA Toolkit: {cuda}) # 驱动支持的最高 CUDA 版本简化逻辑实际应查官方 JSON driver_to_max_cuda { 515.48.07: 11.7, 525.60.13: 11.8, 535.104.05: 12.3, 545.23.08: 12.4 } max_cuda_by_driver Unknown for drv, max_cu in driver_to_max_cuda.items(): if driver.startswith(drv.split(.)[0]): # 粗略匹配主版本 max_cuda_by_driver max_cu break print(fDriver supports up to CUDA: {max_cuda_by_driver}) if cuda ! N/A and max_cuda_by_driver ! Unknown: cuda_major float(cuda) max_major float(max_cuda_by_driver) if cuda_major max_major: print(❌ WARNING: CUDA Toolkit version exceeds driver support!) print(f Your driver {driver} only supports up to CUDA {max_cuda_by_driver}) else: print(✅ OK: CUDA version is within driver support range.) if __name__ __main__: main()逻辑说明get_gpu_info()用nvidia-smi -L提取型号避免lspci的模糊匹配get_compute_capability()是简化版查表实际项目中应替换为从 NVIDIA 官方 CSV 下载并缓存的完整映射含 PCI ID驱动到 CUDA 的映射表driver_to_max_cuda是静态的因为 NVIDIA 不会为旧驱动追加新 CUDA 支持脚本不联网不依赖requests适合在无外网的集群节点运行。5.2 运行效果与解读$ python cuda_check.py GPU Model: NVIDIA RTX A6000 Compute Cap: 8.6 Driver Ver: 535.104.05 CUDA Toolkit: 12.3 Driver supports up to CUDA: 12.3 ✅ OK: CUDA version is within driver support range.这表示你的 A6000CC8.6配驱动 535.104.05支持 CUDA 12.3 上限 CUDA 12.3 Toolkit三者完全对齐可安全安装 PyTorch 2.1cu121 或 2.2cu121它们都要求 CUDA ≥12.1。若输出❌ WARNING说明你必须升级驱动推荐或降级 CUDA Toolkit不推荐因新 Toolkit 修复大量 bug。6. 进阶技巧如何为跨代 GPU 集群构建统一 wheel在某高校超算中心我们管理着含 V100CC7.0、A100CC8.0、A6000CC8.6、H100CC9.0的混合集群。用户提交作业时不指定 GPU 类型调度器随机分配。此时若每个用户都pip install自己编译的 extension必然出现no kernel image报错。解决方案不是让所有人改代码而是构建一个“全算力兼容”的 wheel。6.1 编译阶段TORCH_CUDA_ARCH_LIST 的科学设置PyTorch 的cpp_extension通过环境变量TORCH_CUDA_ARCH_LIST控制编译目标。关键原则不漏覆盖集群中所有 GPU 的 CC不冗不编译未使用的算力增加 wheel 体积延长加载时间不越界不编译高于驱动支持的算力如驱动只到 12.2却编译sm_90nvcc 会报错。我们集群的 CC 清单7.0 8.0 8.6 9.0。对应设置export TORCH_CUDA_ARCH_LIST7.0 8.0 8.6 9.0 # 注意不要写成 7.0PTXPyTorch 不识别 PTX 语法然后执行python setup.py bdist_wheel # 生成的 wheel 名类似myop-0.1-py3-none-manylinux2014_x86_64.whl6.2 验证 wheel 是否真含多算力wheel 本质是 zip 包。解压后检查.so文件是否嵌入多段 SASSunzip -l myop-0.1-py3-none-manylinux2014_x86_64.whl | grep .so # 输出myop/_myop.cpython-310-x86_64-linux-gnu.so # 用 strings 查看二进制中的算力标识 strings myop/_myop.cpython-310-x86_64-linux-gnu.so | grep sm_ # 应看到sm_70 sm_80 sm_86 sm_90提示strings输出中若只有sm_86说明TORCH_CUDA_ARCH_LIST未生效检查是否在setup.py执行前 export。6.3 运行时动态选择PyTorch 如何加载正确 SASSPyTorch Runtime 不是“加载所有 SASS”而是调用cudaGetDeviceProperties(prop, device, 0)获取当前 GPU 的major/minor在.so的 ELF section 中查找匹配的sm_xx段若未找到 exact match则尝试加载compute_xxPTX 段需 GPU 支持 JIT 编译若两者皆无才报no kernel image。因此为 H100CC9.0编译的sm_90代码在 A100CC8.0上不会被加载也不会报错——它只是被跳过。这就是多算力 wheel 安全的底层机制。6.4 生产环境 checklist我们每天 deploy 前必做检查项命令/方法通过标准GPU 型号与 CC 一致nvidia-smi -L 查 NVIDIA 官网型号匹配CC 值确认无误驱动支持 CUDA 上限nvidia-smi -q | grep CUDA Version≥ 你计划安装的 CUDA Toolkit 版本CUDA Toolkit 版本nvcc --version与 PyTorch wheel 的cuXX后缀一致多算力编译生效strings xxx.so | grep sm_输出包含集群所有 CC 值wheel 在目标卡运行python -c import myop; print(myop.test())在 V100/A100/H100 上均不报no kernel image最后说一句血泪教训在混合集群上永远不要相信“它以前能跑”。GPU 型号、驱动版本、CUDA Toolkit、PyTorch 版本任意一个变了兼容性就要重验。我把cuda_check.py放进 CI 流程每次 merge PR 前自动跑省下无数半夜救火时间。希望帮到你。本文还有配套的精品资源点击获取