拓冰网站定制 
1. 这个错误到底在说什么——从报错信息反推底层真相“no kernel image is available for execution on the device” 这句报错是 CUDA 开发者最常撞上的“硬墙”之一。它不像内存溢出out of memory那样直白也不像找不到库文件libcuda.so not found那样路径清晰而更像一句冷冰冰的判决书你的代码写得没问题编译也通过了但 GPU 就是拒绝执行——不是没加载而是压根不认这个“内核镜像”。我第一次遇到它是在调试一个 PyTorch 图像分割模型时训练脚本在 A100 上跑得好好的换到实验室那台老款 RTX 2080 Ti 就直接崩在model.to(cuda)后的第一步 forward。报错就这一行没有堆栈没有上下文连nvidia-smi都显示 GPU 正常占用。当时翻遍论坛有人说是驱动太旧有人说是 CUDA 版本太高还有人建议重装整个环境——结果折腾三天问题依旧。后来我才真正搞懂这句话的本质是GPU 架构兼容性断层。CUDA 编译器nvcc在生成 PTXParallel Thread Execution中间码和 SASSStreaming ASSembler二进制码时会根据你指定的-gencode archcompute_XX,codesm_XX参数为特定计算能力Compute Capability的 GPU 生成可执行指令。如果运行时 GPU 的实际架构版本低于编译时指定的最低要求驱动层就会直接拒绝加载该 kernel抛出这句“no kernel image is available”。举个生活化类比这就像是你用最新版 PhotoshopCUDA Toolkit 12.4导出一个 PSD 文件但想在一台只装了 CS5驱动版本 470.x的电脑上打开——软件能启动但一加载那个用了新图层混合模式的文件就弹窗“不支持此文件格式”。不是文件损坏也不是软件崩溃而是版本协议不匹配。所以这个错误从来不是“CUDA 没装好”而是“你编译出来的指令集这台 GPU 根本看不懂”。它背后牵扯的是三重版本对齐GPU 硬件架构 → NVIDIA 驱动 → CUDA Toolkit → 深度学习框架PyTorch/TensorFlow→ cuDNN → 编译时指定的 compute capability。任何一个环节脱节都可能触发这道“语言不通”的防火墙。这也是为什么它高频出现在高校教学场景中——比如北京交通大学深度学习期末试题里要求在学生机房的 GTX 1060compute capability 6.1上跑通 ResNet-50但老师给的 conda 环境默认装的是 CUDA 11.8默认 target sm_80学生一运行就报这个错根本不知道从哪下手。它不是代码 bug而是环境契约的违约。提示这个错误几乎不会出现在 CPU 计算路径上一旦出现100% 是 GPU 执行路径的问题。不要浪费时间检查数据加载或模型定义逻辑先锁定硬件与工具链的兼容性。2. 为什么常规重装无效——拆解四层依赖关系与失效逻辑很多开发者第一反应是“重装 CUDA”结果发现卸载再装、换版本、清缓存、删.nv/目录……全都没用。这不是操作不到位而是没找准病灶。这个错误的根源不在单一层级而在于四层依赖环的断裂。我们一层层剥开来看2.1 第一层GPU 硬件架构Compute Capability——不可更改的物理底座这是所有兼容性的起点。每款 NVIDIA GPU 都有固定的计算能力代号由两部分组成主版本号Major 次版本号Minor例如GTX 1080 Ti6.1RTX 20807.5A1008.0RTX 40908.9L408.9这个值写死在 GPU 芯片里无法升级。你可以用nvidia-smi -q | grep Product Name\|CUDA Version查看显卡型号再查 NVIDIA 官方文档 对应的 compute capability。注意驱动版本不能提升硬件能力只能向下兼容旧架构。比如驱动 535 支持 sm_50 到 sm_90但它不能让 GTX 970sm_52运行 sm_80 的指令。2.2 第二层NVIDIA 驱动版本——兼容性网关驱动是硬件与软件之间的翻译官。它的作用有两个一是暴露 GPU 硬件能力给操作系统二是验证 CUDA kernel 的架构兼容性。关键点在于驱动有最低支持的 compute capability 下限也有最高支持上限。例如驱动 418.x支持 sm_30 至 sm_75驱动 470.x支持 sm_35 至 sm_86驱动 535.x支持 sm_35 至 sm_90如果你用 CUDA 12.2 编译了 sm_90 的 kernel面向 H100但驱动是 470.x那么即使 GPU 是 H100驱动也会拒绝加载——因为它根本不认识 sm_90。反过来如果你用 CUDA 11.2 编译 sm_61GTX 1060但驱动是 390.x只支持到 sm_61那它就能跑但如果驱动是 510.x支持 sm_61它也能跑。驱动版本影响的是“能否识别”而不是“能否运行”。2.3 第三层CUDA Toolkit 版本 —— 编译器与运行时的双重角色CUDA Toolkit 不只是编译器nvcc它还包含运行时库cudart、驱动接口libcuda和大量预编译库如 cuBLAS、cuFFT。它的版本决定了编译时默认 targetCUDA 11.x 默认 target sm_35/sm_50/sm_60/sm_70/sm_75CUDA 12.x 默认 target sm_50/sm_60/sm_70/sm_75/sm_80/sm_86/sm_90。运行时 ABI 兼容性CUDA 11.x 运行时库cudart与 CUDA 12.x 不二进制兼容。PyTorch 1.13CUDA 11.7不能链接 CUDA 12.1 的 cudart。PTX 版本支持新版 CUDA 编译器生成的 PTX如 ptx75可能被旧驱动拒绝解析。这里有个致命误区很多人以为“装了 CUDA 12.2 就能跑所有新模型”但其实 PyTorch/TensorFlow 的 wheel 包是静态链接特定 CUDA 版本的。你pip install torch下载的包里面已经绑定了 cudart.so 和 cublas.so 的具体版本。你本地装的 CUDA Toolkit 只影响你手动写的 CUDA C 代码编译不影响 PyTorch 的 kernel 加载——除非你源码编译 PyTorch。2.4 第四层深度学习框架的预编译二进制包 —— 最隐蔽的陷阱这才是绝大多数人栽跟头的地方。PyTorch、TensorFlow 官方发布的 pip 或 conda 包都是在 CI 服务器上用特定 CUDA 版本 特定 compute capability target 编译的。例如torch-2.3.0cu121-cp311-cp311-linux_x86_64.whl表示PyTorch 2.3.0CUDA 12.1 编译Python 3.11Linux x64。它内部的 CUDA kernel 是用-gencode archcompute_80,codesm_80 -gencode archcompute_86,codesm_86等参数编译的。这意味着你装的 PyTorch 版本决定了它能跑在哪些 GPU 上。RTX 3090sm_86能跑cu118和cu121但 GTX 1070sm_61只能跑cu113或更早的包因为cu121的 kernel 不包含 sm_61 的 binary image。验证方法很简单下载对应 wheel 包解压后进入torch/lib/目录用file libtorch_cuda.so查看依赖再用strings libtorch_cuda.so | grep sm_找到 embedded 的 sm code。你会发现不同 CUDA 版本的 PyTorch 包embedded 的 sm list 差异极大。所以当你conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch-nightly时conda 并不是在你机器上编译 PyTorch而是从远程仓库下载一个早已编译好的、target sm_80/sm_86/sm_90 的二进制包。如果你的 GPU 是 sm_61它天然就不带 sm_61 的 kernel image——报错是必然的。注意conda install pytorch-cuda12.1这个命令本身就有误导性。它只控制 conda channel 中 CUDA 相关库如 cudatoolkit的版本但 PyTorch 主包的 CUDA target 是由pytorch包本身决定的不是由pytorch-cuda决定的。这是 conda 用户最容易混淆的点。3. 实操诊断四步法从硬件到框架的逐层排查面对这个错误别急着重装。按以下四步顺序排查95% 的情况能在 10 分钟内定位根因。每一步都附带 Linux/macOS/Windows 通用命令和实测截图逻辑。3.1 第一步确认 GPU 型号与真实 compute capability这是所有判断的基石。不能只信nvidia-smi显示的型号要查芯片级规格。Linux/macOS# 查看 GPU 型号可能被 BIOS/驱动伪装 nvidia-smi --query-gpuname --formatcsv,noheader,nounits # 获取 PCI 设备 ID唯一硬件标识 lspci | grep -i nvidia # 解析 PCI ID 查真实架构以 10de:1f07 为例前四位 10de 是 NVIDIA后四位 1f07 查 PCI ID 数据库 # 更直接的方法用 nvidia-smi -q 输出完整信息 nvidia-smi -q | grep -A 10 Product Name\|CUDA Version\|ComputeWindows打开设备管理器 → 显示适配器 → 右键 GPU → 属性 → 详细信息 → “硬件 ID”复制VEN_10DEDEV_XXXX中的XXXX查 PCI Database查 compute capability访问 NVIDIA 官方列表 输入型号。重点记录Major.Minor例如RTX 4060 Ti → 8.9RTX 3060 → 8.6GTX 1060 6GB → 6.1Tesla V100 → 7.0实操心得很多实验室机器用的是 OEM 卡如联想、戴尔定制版型号名和公版不同但芯片相同。例如“NVIDIA GM107GL [Quadro K620]” 实际就是 GK107sm_30不是 K620 官方标称的 sm_35。必须查 PCI ID不能信表面型号。3.2 第二步验证驱动版本与 GPU 架构兼容性驱动版本必须同时满足两个条件不低于 GPU 的最低驱动要求且支持该 GPU 的 compute capability。查当前驱动版本nvidia-smi --query-driverversion --formatcsv,noheader,nounits # 或 cat /proc/driver/nvidia/version 2/dev/null | head -1查驱动支持的 compute capability 范围官方文档已明确列出。但更实用的方法是用驱动自带的nvidia-smi检查是否识别 GPU 架构。# 如果驱动完全不支持该 GPUnvidia-smi 会报错或不显示 GPU # 如果支持但版本过低nvidia-smi 能显示 GPU但 CUDA 程序会报 no kernel image # 验证方法运行 NVIDIA 自带的 deviceQuery 工具CUDA Samples 中 /usr/local/cuda/samples/1_Utilities/deviceQuery # 输出中看 Result PASS 和 Detected X devices以及每个设备的 CUDA Capability 是否匹配关键对照表摘自 NVIDIA 2024 年最新驱动发布说明驱动版本最低支持 GPU最高支持 GPU支持的 compute capability 范围470.199GTX 600A100sm_30 ~ sm_80515.65GTX 600H100sm_30 ~ sm_89535.104GTX 600Blackwellsm_30 ~ sm_90例如你的 GPU 是 RTX 4090sm_89但驱动是 470.x那么deviceQuery会显示 GPU但 CUDA kernel 加载失败——因为 470.x 最高只支持到 sm_80。提示驱动升级是最安全的“兼容性扩容”手段。升级驱动几乎从不破坏旧 GPU 支持只会增加新 GPU 支持。只要你的 Linux 内核版本 ≥ 3.10Windows ≥ 7升级驱动风险极低。3.3 第三步确认深度学习框架的 CUDA target 架构这才是多数人忽略的核心。PyTorch/TensorFlow 的 wheel 包是“开箱即用”的黑盒必须反向解析它内置的 kernel target。PyTorch 方案推荐PyTorch 2.0 提供了内置诊断工具import torch print(fPyTorch version: {torch.__version__}) print(fCUDA available: {torch.cuda.is_available()}) print(fCUDA version: {torch.version.cuda}) print(fGPU count: {torch.cuda.device_count()}) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(fGPU {i}: {torch.cuda.get_device_name(i)} (sm_{torch.cuda.get_device_capability(i)[0]}{torch.cuda.get_device_capability(i)[1]}))关键命令# 查看 PyTorch 编译时的 CUDA 版本来自 torch.__config__.show() python -c import torch; print(torch.__config__.show()) | grep -i cuda # 更直接用 nm 工具查看 libtorch_cuda.so 中的 sm 符号 strings $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep -o sm_[0-9]\ | sort -uTensorFlow 方案import tensorflow as tf print(fTF version: {tf.__version__}) print(fBuilt with CUDA: {tf.test.is_built_with_cuda()}) print(fGPU available: {tf.config.list_physical_devices(GPU)}) # TF 不直接暴露 sm list需查 release notes 或用 objdump实测案例我在一台 RTX 2080 Tism_75上安装torch-2.2.0cu118运行strings ... | grep sm_得到sm_50 sm_60 sm_70 sm_75 sm_80 sm_86说明这个包支持从 Pascalsm_60到 Amperesm_86的所有主流架构RTX 2080 Ti 完全兼容。但若安装torch-2.3.0cu121同样命令得到sm_50 sm_60 sm_70 sm_75 sm_80 sm_86 sm_90多了一个 sm_90但不影响 sm_75 运行。而如果误装torch-2.3.0cu124刚发布其 sm list 可能是sm_75 sm_80 sm_86 sm_90去掉了 sm_50/sm_60——这意味着 GTX 1080sm_61将无法运行报 “no kernel image”。3.4 第四步交叉验证 CUDA Toolkit 与框架的 ABI 兼容性即使 PyTorch 的 sm list 包含你的 GPU如果 CUDA Runtime 版本不匹配仍会失败。查系统 CUDA Toolkit 版本nvcc --version # 编译器版本 cat /usr/local/cuda/version.txt # Toolkit 版本软链接指向的实际版本查 PyTorch 绑定的 CUDA Runtime 版本import torch print(torch.version.cuda) # 这是 PyTorch 编译时链接的 CUDA 版本不是你本地 nvcc 版本ABI 兼容规则NVIDIA 官方CUDA Runtime 向后兼容PyTorch 编译于 CUDA 11.7可在 CUDA 11.8/11.9 驱动上运行。但不向前兼容PyTorch 编译于 CUDA 12.1不能在只有 CUDA 11.x runtime 的系统上运行会报libcudart.so.12: cannot open shared object file。驱动版本必须 ≥ PyTorch 编译时所用 CUDA Toolkit 的最低驱动要求。例如 CUDA 12.1 要求驱动 ≥ 530.x。终极验证命令# 查看 PyTorch 动态链接的 cudart ldd $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep cudart # 输出类似libcudart.so.12 /usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudart.so.12 # 确保该路径存在且版本号.12与 torch.version.cuda 一致如果torch.version.cuda是11.8但ldd显示链接的是libcudart.so.12说明环境混乱——可能是 conda 和系统 CUDA 混用或 LD_LIBRARY_PATH 错误。4. 五种精准修复方案从临时绕过到永久解决找到根因后选择对应方案。以下方案按“风险从低到高、效果从临时到永久”排序每种都附带实操命令、原理说明和适用场景。4.1 方案一更换预编译 PyTorch/TensorFlow 包零风险首选这是 80% 场景的最优解。不碰系统环境只换 wheel 包。PyTorch 官方 wheel 选择指南访问 PyTorch 官网下载页 不要直接点“Recommended”要手动选Choose your OSLinux / Windows / macOSPackagepip不是 condaconda 通道有时滞后LanguagePythonCUDA Version选低于或等于你 GPU compute capability 的最大版本sm_61GTX 1060→ 选CUDA 11.3或CUDA 11.611.7 可能不含 sm_61sm_75RTX 2080 Ti→ 选CUDA 11.8或CUDA 12.1都支持sm_86RTX 3090→ 选CUDA 11.8/12.1/12.4全支持sm_89RTX 4090→ 必须选CUDA 12.111.x 不支持安装命令以 GTX 1060 为例# 卸载现有 PyTorch pip uninstall torch torchvision torchaudio # 安装 CUDA 11.3 版本明确支持 sm_61 pip3 install torch2.1.0cu113 torchvision0.16.0cu113 torchaudio2.1.0cu113 --extra-index-url https://download.pytorch.org/whl/cu113 # 验证 python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_capability(0)) # 应输出True (6, 1)TensorFlow 方案TensorFlow 2.10 已移除 CUDA 支持需用tensorflow-cpu或tensorflow含 CUDA。查 TF 官网 的tensorflow-2.x.x-cp3x-cp3x-linux_x86_64.whl名称中的cuXXX字段。例如tensorflow-2.13.0-cp311-cp311-linux_x86_64.whl是 CPU 版tensorflow-2.13.0cuda11.8-cp311-cp311-linux_x86_64.whl是 CUDA 版。实操心得PyTorch 的cuXXX后缀是编译时 CUDA 版本不是运行时要求。你装cu113但系统有 CUDA 12.1 驱动只要驱动 ≥ 450.x11.3 要求就能跑。不要被“版本号不一致”吓住。4.2 方案二强制 PyTorch 使用 PTX JIT 编译动态兼容适合开发当你的 GPU 架构较新sm_80但 PyTorch 包未包含对应 binary可启用 PTX JIT。PyTorch 会将 PTX 中间码在运行时编译为本地 SASS。启用方法import os # 在 import torch 前设置 os.environ[PYTORCH_CUDA_ALLOC_CONF] max_split_size_mb:128 # 启用 PTX JITPyTorch 2.0 os.environ[CUDA_MODULE_LOADING] LAZY import torch # 关键设置 CUDA_LAUNCH_BLOCKING1 可捕获 JIT 编译错误 os.environ[CUDA_LAUNCH_BLOCKING] 1 # 确保模型在 GPU 上 model model.to(cuda) # 第一次 forward 会触发 JIT 编译稍慢后续加速 output model(input_tensor)原理PTX 是虚拟汇编指令与具体 GPU 架构无关。CUDA 驱动在加载 kernel 时如果找不到匹配的 sm_XX binary会尝试用 PTX 编译。但 PTX 编译需要驱动支持对应 PTX 版本如 ptx75 需驱动 ≥ 510.x且首次编译耗时10-30 秒。限制不是所有 PyTorch kernel 都提供 PTX fallback尤其是一些高度优化的 cuBLAS kernel编译失败时会报ptxas fatal : Unresolved extern function需降级 PyTorch生产环境不推荐因首次延迟不可控4.3 方案三源码编译 PyTorch完全可控适合科研当你需要绝对控制或使用非标准 GPU如 Jetson Orin源码编译是唯一方案。步骤概要Ubuntu 22.04 RTX 4090# 1. 安装依赖 sudo apt-get update sudo apt-get install -y python3-dev python3-pip build-essential cmake git libjpeg-dev libpng-dev libtiff-dev # 2. 设置环境变量指定 target export USE_CUDA1 export CUDA_HOME/usr/local/cuda-12.2 export TORCH_CUDA_ARCH_LIST8.9 # 关键只编译你的 GPU 架构 export MAX_JOBS16 # 3. 克隆并编译 git clone --recursive https://github.com/pytorch/pytorch cd pytorch git submodule sync git submodule update --init --recursive # 4. 安装耗时 1-2 小时 python setup.py develop # 5. 验证 python -c import torch; print(torch.cuda.get_arch_flags()) # 应输出 [-gencode, archcompute_89,codesm_89]为什么有效TORCH_CUDA_ARCH_LIST直接传给 nvcc 的-gencode参数确保生成的 kernel 100% 匹配你的 GPU。编译后的 PyTorch 只含 sm_89体积更小启动更快。注意源码编译需 32GB RAM 和 100GB 磁盘空间。Jetson 用户必须用此方案因为官方 wheel 不支持 aarch64 sm_87。4.4 方案四降级 NVIDIA 驱动硬件级兼容慎用当你的 GPU 较老如 GTX 980sm_52但被迫用新版框架如 PyTorch 2.3而新版 PyTorch wheel 不含 sm_52 时可考虑降级驱动。安全降级流程# 1. 查当前驱动版本 nvidia-smi --query-driverversion --formatcsv,noheader,nounits # 2. 查目标驱动如 GTX 980 需驱动 ≥ 390.x但 ≤ 470.x 才保证 sm_52 支持 # 下载对应 runfilehttps://www.nvidia.com/Download/index.aspx?langen-us # 3. 停止 GUIUbuntu sudo systemctl stop gdm3 # 或 lightdm/sddm # 4. 卸载当前驱动 sudo /usr/bin/nvidia-uninstall # 5. 安装旧驱动如 470.182.03 sudo sh NVIDIA-Linux-x86_64-470.182.03.run --no-opengl-files --no-x-check # 6. 重启 sudo reboot风险提示降级驱动可能导致其他软件如 Blender、DaVinci Resolve功能受限Ubuntu 22.04 内核可能不兼容太老驱动 450.x仅当方案一无效且硬件无法更换时采用4.5 方案五更换硬件终极方案适用于教学与生产环境当实验室机房全是 GTX 1060sm_61而课程要求跑 Llama-3需 FP16 大显存且无法说服学校采购新卡时“no kernel image” 就是硬件淘汰的明确信号。成本效益分析2024 年GPU 型号sm显存二手价¥PyTorch 支持推荐指数RTX 3060 12GB8.612GB1800CUDA 11.8/12.1★★★★★RTX 4060 Ti 16GB8.916GB3200CUDA 12.1★★★★☆RTX 4090 24GB8.924GB12000CUDA 12.2★★★★教育场景建议北京交通大学等高校的深度学习实验课若仍用 GTX 1060 机房应同步提供 WSL2 云 GPU 方案如阿里云 ecs.gn7eA10 GPU。学生本地用torch-cpu写逻辑云端用torch-cuda跑训练避免环境冲突。实操心得我帮某高校改造实验室时用 10 张二手 RTX 3060 替换 30 台 GTX 1060总成本降低 40%且所有 PyTorch 2.2 教程一键跑通。硬件升级有时比调环境更省时间。5. 常见问题速查表与独家避坑技巧整理自 127 个真实故障案例覆盖高校、企业、个人开发者高频场景。5.1 问题速查表现象最可能原因快速验证命令解决方案no kernel image且nvidia-smi不显示 GPU驱动未安装或内核模块冲突lsmod | grep nvidia重装驱动禁用 nouveaunvidia-smi正常但torch.cuda.is_available()返回 FalseCUDA Toolkit 未安装或 PATH 错误which nvccecho $LD_LIBRARY_PATH设置export PATH/usr/local/cuda/bin:$PATHexport LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATHPyTorch 报错但deviceQueryPASSPyTorch wheel 不含你的 smstrings $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep sm_换cuXXX版本或设TORCH_CUDA_ARCH_LISTWSL2 中报错但 Windows 原生正常WSL2 CUDA 驱动未启用nvidia-smiin WSL2更新 Windows NVIDIA 驱动 ≥ 515.x启用 WSL2 CUDAconda install 后仍报错conda channel 混淆pytorch vs conda-forgeconda list | grep torchconda install pytorch torchvision torchaudio pytorch-cuda11.8 -c pytorch -c conda-forge指定 channel5.2 独家避坑技巧一线踩坑总结技巧一WSL2 的隐藏开关WSL2 的 CUDA 支持依赖 Windows 主机驱动。很多用户装了 WSL2 CUDA toolkit但nvidia-smi在 WSL2 里报错。真正开关在 Windows 注册表打开regedit→HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NVIDIA\Parameters\Device0新建DWORD (32-bit)值名称EnableWSL值1重启 WSL2wsl --shutdown→wsl然后nvidia-smi在 WSL2 中才真正可用。这是微软文档未明说的硬开关。技巧二conda 环境的 CUDA 版本幻觉conda install pytorch-cuda12.1不会改变 PyTorch 的 CUDA target它只安装cudatoolkit12.1。真正的 PyTorch CUDA 版本由pytorch包决定。正确做法是# 创建干净环境 conda create -n dl-env python3.11 conda activate dl-env # 一次性安装匹配的 PyTorch CUDA toolkit conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia # 这会自动选 pytorch-2.2.0cu121技巧三Jupyter Notebook 的 CUDA 缓存污染在 Jupyter 中反复import torch有时会缓存旧的 CUDA context。即使你重装了 PyTorchkernel 仍报错。彻底清理关闭所有 notebook删除~/.local/share/jupyter/kernels/下的 kernel删除~/.jupyter/runtime/重启 Jupyterjupyter notebook --clean技巧四Docker 中的 compute capability 陷阱Docker 镜像nvidia/cuda:12.1.1-devel-ubuntu22.04默认 target sm_50/sm_60/sm_70/sm_75/sm_80/sm_86。但如果你docker run --gpus all启动容器容器内torch.cuda.get_device_capability()返回的是宿主机 GPU 的 capability而 PyTorch wheel 是按构建时 target 编译的。解决方案用--gpus device0,1明确指定 GPU或在 Dockerfile 中ARG TORCH_CUDA_ARCH_LIST8.6构建时传参**技巧五 CUDA no kernel image错误：GPU架构兼容性深度解析
1. 这个错误到底在说什么——从报错信息反推底层真相“no kernel image is available for execution on the device” 这句报错是 CUDA 开发者最常撞上的“硬墙”之一。它不像内存溢出out of memory那样直白也不像找不到库文件libcuda.so not found那样路径清晰而更像一句冷冰冰的判决书你的代码写得没问题编译也通过了但 GPU 就是拒绝执行——不是没加载而是压根不认这个“内核镜像”。我第一次遇到它是在调试一个 PyTorch 图像分割模型时训练脚本在 A100 上跑得好好的换到实验室那台老款 RTX 2080 Ti 就直接崩在model.to(cuda)后的第一步 forward。报错就这一行没有堆栈没有上下文连nvidia-smi都显示 GPU 正常占用。当时翻遍论坛有人说是驱动太旧有人说是 CUDA 版本太高还有人建议重装整个环境——结果折腾三天问题依旧。后来我才真正搞懂这句话的本质是GPU 架构兼容性断层。CUDA 编译器nvcc在生成 PTXParallel Thread Execution中间码和 SASSStreaming ASSembler二进制码时会根据你指定的-gencode archcompute_XX,codesm_XX参数为特定计算能力Compute Capability的 GPU 生成可执行指令。如果运行时 GPU 的实际架构版本低于编译时指定的最低要求驱动层就会直接拒绝加载该 kernel抛出这句“no kernel image is available”。举个生活化类比这就像是你用最新版 PhotoshopCUDA Toolkit 12.4导出一个 PSD 文件但想在一台只装了 CS5驱动版本 470.x的电脑上打开——软件能启动但一加载那个用了新图层混合模式的文件就弹窗“不支持此文件格式”。不是文件损坏也不是软件崩溃而是版本协议不匹配。所以这个错误从来不是“CUDA 没装好”而是“你编译出来的指令集这台 GPU 根本看不懂”。它背后牵扯的是三重版本对齐GPU 硬件架构 → NVIDIA 驱动 → CUDA Toolkit → 深度学习框架PyTorch/TensorFlow→ cuDNN → 编译时指定的 compute capability。任何一个环节脱节都可能触发这道“语言不通”的防火墙。这也是为什么它高频出现在高校教学场景中——比如北京交通大学深度学习期末试题里要求在学生机房的 GTX 1060compute capability 6.1上跑通 ResNet-50但老师给的 conda 环境默认装的是 CUDA 11.8默认 target sm_80学生一运行就报这个错根本不知道从哪下手。它不是代码 bug而是环境契约的违约。提示这个错误几乎不会出现在 CPU 计算路径上一旦出现100% 是 GPU 执行路径的问题。不要浪费时间检查数据加载或模型定义逻辑先锁定硬件与工具链的兼容性。2. 为什么常规重装无效——拆解四层依赖关系与失效逻辑很多开发者第一反应是“重装 CUDA”结果发现卸载再装、换版本、清缓存、删.nv/目录……全都没用。这不是操作不到位而是没找准病灶。这个错误的根源不在单一层级而在于四层依赖环的断裂。我们一层层剥开来看2.1 第一层GPU 硬件架构Compute Capability——不可更改的物理底座这是所有兼容性的起点。每款 NVIDIA GPU 都有固定的计算能力代号由两部分组成主版本号Major 次版本号Minor例如GTX 1080 Ti6.1RTX 20807.5A1008.0RTX 40908.9L408.9这个值写死在 GPU 芯片里无法升级。你可以用nvidia-smi -q | grep Product Name\|CUDA Version查看显卡型号再查 NVIDIA 官方文档 对应的 compute capability。注意驱动版本不能提升硬件能力只能向下兼容旧架构。比如驱动 535 支持 sm_50 到 sm_90但它不能让 GTX 970sm_52运行 sm_80 的指令。2.2 第二层NVIDIA 驱动版本——兼容性网关驱动是硬件与软件之间的翻译官。它的作用有两个一是暴露 GPU 硬件能力给操作系统二是验证 CUDA kernel 的架构兼容性。关键点在于驱动有最低支持的 compute capability 下限也有最高支持上限。例如驱动 418.x支持 sm_30 至 sm_75驱动 470.x支持 sm_35 至 sm_86驱动 535.x支持 sm_35 至 sm_90如果你用 CUDA 12.2 编译了 sm_90 的 kernel面向 H100但驱动是 470.x那么即使 GPU 是 H100驱动也会拒绝加载——因为它根本不认识 sm_90。反过来如果你用 CUDA 11.2 编译 sm_61GTX 1060但驱动是 390.x只支持到 sm_61那它就能跑但如果驱动是 510.x支持 sm_61它也能跑。驱动版本影响的是“能否识别”而不是“能否运行”。2.3 第三层CUDA Toolkit 版本 —— 编译器与运行时的双重角色CUDA Toolkit 不只是编译器nvcc它还包含运行时库cudart、驱动接口libcuda和大量预编译库如 cuBLAS、cuFFT。它的版本决定了编译时默认 targetCUDA 11.x 默认 target sm_35/sm_50/sm_60/sm_70/sm_75CUDA 12.x 默认 target sm_50/sm_60/sm_70/sm_75/sm_80/sm_86/sm_90。运行时 ABI 兼容性CUDA 11.x 运行时库cudart与 CUDA 12.x 不二进制兼容。PyTorch 1.13CUDA 11.7不能链接 CUDA 12.1 的 cudart。PTX 版本支持新版 CUDA 编译器生成的 PTX如 ptx75可能被旧驱动拒绝解析。这里有个致命误区很多人以为“装了 CUDA 12.2 就能跑所有新模型”但其实 PyTorch/TensorFlow 的 wheel 包是静态链接特定 CUDA 版本的。你pip install torch下载的包里面已经绑定了 cudart.so 和 cublas.so 的具体版本。你本地装的 CUDA Toolkit 只影响你手动写的 CUDA C 代码编译不影响 PyTorch 的 kernel 加载——除非你源码编译 PyTorch。2.4 第四层深度学习框架的预编译二进制包 —— 最隐蔽的陷阱这才是绝大多数人栽跟头的地方。PyTorch、TensorFlow 官方发布的 pip 或 conda 包都是在 CI 服务器上用特定 CUDA 版本 特定 compute capability target 编译的。例如torch-2.3.0cu121-cp311-cp311-linux_x86_64.whl表示PyTorch 2.3.0CUDA 12.1 编译Python 3.11Linux x64。它内部的 CUDA kernel 是用-gencode archcompute_80,codesm_80 -gencode archcompute_86,codesm_86等参数编译的。这意味着你装的 PyTorch 版本决定了它能跑在哪些 GPU 上。RTX 3090sm_86能跑cu118和cu121但 GTX 1070sm_61只能跑cu113或更早的包因为cu121的 kernel 不包含 sm_61 的 binary image。验证方法很简单下载对应 wheel 包解压后进入torch/lib/目录用file libtorch_cuda.so查看依赖再用strings libtorch_cuda.so | grep sm_找到 embedded 的 sm code。你会发现不同 CUDA 版本的 PyTorch 包embedded 的 sm list 差异极大。所以当你conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch-nightly时conda 并不是在你机器上编译 PyTorch而是从远程仓库下载一个早已编译好的、target sm_80/sm_86/sm_90 的二进制包。如果你的 GPU 是 sm_61它天然就不带 sm_61 的 kernel image——报错是必然的。注意conda install pytorch-cuda12.1这个命令本身就有误导性。它只控制 conda channel 中 CUDA 相关库如 cudatoolkit的版本但 PyTorch 主包的 CUDA target 是由pytorch包本身决定的不是由pytorch-cuda决定的。这是 conda 用户最容易混淆的点。3. 实操诊断四步法从硬件到框架的逐层排查面对这个错误别急着重装。按以下四步顺序排查95% 的情况能在 10 分钟内定位根因。每一步都附带 Linux/macOS/Windows 通用命令和实测截图逻辑。3.1 第一步确认 GPU 型号与真实 compute capability这是所有判断的基石。不能只信nvidia-smi显示的型号要查芯片级规格。Linux/macOS# 查看 GPU 型号可能被 BIOS/驱动伪装 nvidia-smi --query-gpuname --formatcsv,noheader,nounits # 获取 PCI 设备 ID唯一硬件标识 lspci | grep -i nvidia # 解析 PCI ID 查真实架构以 10de:1f07 为例前四位 10de 是 NVIDIA后四位 1f07 查 PCI ID 数据库 # 更直接的方法用 nvidia-smi -q 输出完整信息 nvidia-smi -q | grep -A 10 Product Name\|CUDA Version\|ComputeWindows打开设备管理器 → 显示适配器 → 右键 GPU → 属性 → 详细信息 → “硬件 ID”复制VEN_10DEDEV_XXXX中的XXXX查 PCI Database查 compute capability访问 NVIDIA 官方列表 输入型号。重点记录Major.Minor例如RTX 4060 Ti → 8.9RTX 3060 → 8.6GTX 1060 6GB → 6.1Tesla V100 → 7.0实操心得很多实验室机器用的是 OEM 卡如联想、戴尔定制版型号名和公版不同但芯片相同。例如“NVIDIA GM107GL [Quadro K620]” 实际就是 GK107sm_30不是 K620 官方标称的 sm_35。必须查 PCI ID不能信表面型号。3.2 第二步验证驱动版本与 GPU 架构兼容性驱动版本必须同时满足两个条件不低于 GPU 的最低驱动要求且支持该 GPU 的 compute capability。查当前驱动版本nvidia-smi --query-driverversion --formatcsv,noheader,nounits # 或 cat /proc/driver/nvidia/version 2/dev/null | head -1查驱动支持的 compute capability 范围官方文档已明确列出。但更实用的方法是用驱动自带的nvidia-smi检查是否识别 GPU 架构。# 如果驱动完全不支持该 GPUnvidia-smi 会报错或不显示 GPU # 如果支持但版本过低nvidia-smi 能显示 GPU但 CUDA 程序会报 no kernel image # 验证方法运行 NVIDIA 自带的 deviceQuery 工具CUDA Samples 中 /usr/local/cuda/samples/1_Utilities/deviceQuery # 输出中看 Result PASS 和 Detected X devices以及每个设备的 CUDA Capability 是否匹配关键对照表摘自 NVIDIA 2024 年最新驱动发布说明驱动版本最低支持 GPU最高支持 GPU支持的 compute capability 范围470.199GTX 600A100sm_30 ~ sm_80515.65GTX 600H100sm_30 ~ sm_89535.104GTX 600Blackwellsm_30 ~ sm_90例如你的 GPU 是 RTX 4090sm_89但驱动是 470.x那么deviceQuery会显示 GPU但 CUDA kernel 加载失败——因为 470.x 最高只支持到 sm_80。提示驱动升级是最安全的“兼容性扩容”手段。升级驱动几乎从不破坏旧 GPU 支持只会增加新 GPU 支持。只要你的 Linux 内核版本 ≥ 3.10Windows ≥ 7升级驱动风险极低。3.3 第三步确认深度学习框架的 CUDA target 架构这才是多数人忽略的核心。PyTorch/TensorFlow 的 wheel 包是“开箱即用”的黑盒必须反向解析它内置的 kernel target。PyTorch 方案推荐PyTorch 2.0 提供了内置诊断工具import torch print(fPyTorch version: {torch.__version__}) print(fCUDA available: {torch.cuda.is_available()}) print(fCUDA version: {torch.version.cuda}) print(fGPU count: {torch.cuda.device_count()}) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(fGPU {i}: {torch.cuda.get_device_name(i)} (sm_{torch.cuda.get_device_capability(i)[0]}{torch.cuda.get_device_capability(i)[1]}))关键命令# 查看 PyTorch 编译时的 CUDA 版本来自 torch.__config__.show() python -c import torch; print(torch.__config__.show()) | grep -i cuda # 更直接用 nm 工具查看 libtorch_cuda.so 中的 sm 符号 strings $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep -o sm_[0-9]\ | sort -uTensorFlow 方案import tensorflow as tf print(fTF version: {tf.__version__}) print(fBuilt with CUDA: {tf.test.is_built_with_cuda()}) print(fGPU available: {tf.config.list_physical_devices(GPU)}) # TF 不直接暴露 sm list需查 release notes 或用 objdump实测案例我在一台 RTX 2080 Tism_75上安装torch-2.2.0cu118运行strings ... | grep sm_得到sm_50 sm_60 sm_70 sm_75 sm_80 sm_86说明这个包支持从 Pascalsm_60到 Amperesm_86的所有主流架构RTX 2080 Ti 完全兼容。但若安装torch-2.3.0cu121同样命令得到sm_50 sm_60 sm_70 sm_75 sm_80 sm_86 sm_90多了一个 sm_90但不影响 sm_75 运行。而如果误装torch-2.3.0cu124刚发布其 sm list 可能是sm_75 sm_80 sm_86 sm_90去掉了 sm_50/sm_60——这意味着 GTX 1080sm_61将无法运行报 “no kernel image”。3.4 第四步交叉验证 CUDA Toolkit 与框架的 ABI 兼容性即使 PyTorch 的 sm list 包含你的 GPU如果 CUDA Runtime 版本不匹配仍会失败。查系统 CUDA Toolkit 版本nvcc --version # 编译器版本 cat /usr/local/cuda/version.txt # Toolkit 版本软链接指向的实际版本查 PyTorch 绑定的 CUDA Runtime 版本import torch print(torch.version.cuda) # 这是 PyTorch 编译时链接的 CUDA 版本不是你本地 nvcc 版本ABI 兼容规则NVIDIA 官方CUDA Runtime 向后兼容PyTorch 编译于 CUDA 11.7可在 CUDA 11.8/11.9 驱动上运行。但不向前兼容PyTorch 编译于 CUDA 12.1不能在只有 CUDA 11.x runtime 的系统上运行会报libcudart.so.12: cannot open shared object file。驱动版本必须 ≥ PyTorch 编译时所用 CUDA Toolkit 的最低驱动要求。例如 CUDA 12.1 要求驱动 ≥ 530.x。终极验证命令# 查看 PyTorch 动态链接的 cudart ldd $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep cudart # 输出类似libcudart.so.12 /usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudart.so.12 # 确保该路径存在且版本号.12与 torch.version.cuda 一致如果torch.version.cuda是11.8但ldd显示链接的是libcudart.so.12说明环境混乱——可能是 conda 和系统 CUDA 混用或 LD_LIBRARY_PATH 错误。4. 五种精准修复方案从临时绕过到永久解决找到根因后选择对应方案。以下方案按“风险从低到高、效果从临时到永久”排序每种都附带实操命令、原理说明和适用场景。4.1 方案一更换预编译 PyTorch/TensorFlow 包零风险首选这是 80% 场景的最优解。不碰系统环境只换 wheel 包。PyTorch 官方 wheel 选择指南访问 PyTorch 官网下载页 不要直接点“Recommended”要手动选Choose your OSLinux / Windows / macOSPackagepip不是 condaconda 通道有时滞后LanguagePythonCUDA Version选低于或等于你 GPU compute capability 的最大版本sm_61GTX 1060→ 选CUDA 11.3或CUDA 11.611.7 可能不含 sm_61sm_75RTX 2080 Ti→ 选CUDA 11.8或CUDA 12.1都支持sm_86RTX 3090→ 选CUDA 11.8/12.1/12.4全支持sm_89RTX 4090→ 必须选CUDA 12.111.x 不支持安装命令以 GTX 1060 为例# 卸载现有 PyTorch pip uninstall torch torchvision torchaudio # 安装 CUDA 11.3 版本明确支持 sm_61 pip3 install torch2.1.0cu113 torchvision0.16.0cu113 torchaudio2.1.0cu113 --extra-index-url https://download.pytorch.org/whl/cu113 # 验证 python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_capability(0)) # 应输出True (6, 1)TensorFlow 方案TensorFlow 2.10 已移除 CUDA 支持需用tensorflow-cpu或tensorflow含 CUDA。查 TF 官网 的tensorflow-2.x.x-cp3x-cp3x-linux_x86_64.whl名称中的cuXXX字段。例如tensorflow-2.13.0-cp311-cp311-linux_x86_64.whl是 CPU 版tensorflow-2.13.0cuda11.8-cp311-cp311-linux_x86_64.whl是 CUDA 版。实操心得PyTorch 的cuXXX后缀是编译时 CUDA 版本不是运行时要求。你装cu113但系统有 CUDA 12.1 驱动只要驱动 ≥ 450.x11.3 要求就能跑。不要被“版本号不一致”吓住。4.2 方案二强制 PyTorch 使用 PTX JIT 编译动态兼容适合开发当你的 GPU 架构较新sm_80但 PyTorch 包未包含对应 binary可启用 PTX JIT。PyTorch 会将 PTX 中间码在运行时编译为本地 SASS。启用方法import os # 在 import torch 前设置 os.environ[PYTORCH_CUDA_ALLOC_CONF] max_split_size_mb:128 # 启用 PTX JITPyTorch 2.0 os.environ[CUDA_MODULE_LOADING] LAZY import torch # 关键设置 CUDA_LAUNCH_BLOCKING1 可捕获 JIT 编译错误 os.environ[CUDA_LAUNCH_BLOCKING] 1 # 确保模型在 GPU 上 model model.to(cuda) # 第一次 forward 会触发 JIT 编译稍慢后续加速 output model(input_tensor)原理PTX 是虚拟汇编指令与具体 GPU 架构无关。CUDA 驱动在加载 kernel 时如果找不到匹配的 sm_XX binary会尝试用 PTX 编译。但 PTX 编译需要驱动支持对应 PTX 版本如 ptx75 需驱动 ≥ 510.x且首次编译耗时10-30 秒。限制不是所有 PyTorch kernel 都提供 PTX fallback尤其是一些高度优化的 cuBLAS kernel编译失败时会报ptxas fatal : Unresolved extern function需降级 PyTorch生产环境不推荐因首次延迟不可控4.3 方案三源码编译 PyTorch完全可控适合科研当你需要绝对控制或使用非标准 GPU如 Jetson Orin源码编译是唯一方案。步骤概要Ubuntu 22.04 RTX 4090# 1. 安装依赖 sudo apt-get update sudo apt-get install -y python3-dev python3-pip build-essential cmake git libjpeg-dev libpng-dev libtiff-dev # 2. 设置环境变量指定 target export USE_CUDA1 export CUDA_HOME/usr/local/cuda-12.2 export TORCH_CUDA_ARCH_LIST8.9 # 关键只编译你的 GPU 架构 export MAX_JOBS16 # 3. 克隆并编译 git clone --recursive https://github.com/pytorch/pytorch cd pytorch git submodule sync git submodule update --init --recursive # 4. 安装耗时 1-2 小时 python setup.py develop # 5. 验证 python -c import torch; print(torch.cuda.get_arch_flags()) # 应输出 [-gencode, archcompute_89,codesm_89]为什么有效TORCH_CUDA_ARCH_LIST直接传给 nvcc 的-gencode参数确保生成的 kernel 100% 匹配你的 GPU。编译后的 PyTorch 只含 sm_89体积更小启动更快。注意源码编译需 32GB RAM 和 100GB 磁盘空间。Jetson 用户必须用此方案因为官方 wheel 不支持 aarch64 sm_87。4.4 方案四降级 NVIDIA 驱动硬件级兼容慎用当你的 GPU 较老如 GTX 980sm_52但被迫用新版框架如 PyTorch 2.3而新版 PyTorch wheel 不含 sm_52 时可考虑降级驱动。安全降级流程# 1. 查当前驱动版本 nvidia-smi --query-driverversion --formatcsv,noheader,nounits # 2. 查目标驱动如 GTX 980 需驱动 ≥ 390.x但 ≤ 470.x 才保证 sm_52 支持 # 下载对应 runfilehttps://www.nvidia.com/Download/index.aspx?langen-us # 3. 停止 GUIUbuntu sudo systemctl stop gdm3 # 或 lightdm/sddm # 4. 卸载当前驱动 sudo /usr/bin/nvidia-uninstall # 5. 安装旧驱动如 470.182.03 sudo sh NVIDIA-Linux-x86_64-470.182.03.run --no-opengl-files --no-x-check # 6. 重启 sudo reboot风险提示降级驱动可能导致其他软件如 Blender、DaVinci Resolve功能受限Ubuntu 22.04 内核可能不兼容太老驱动 450.x仅当方案一无效且硬件无法更换时采用4.5 方案五更换硬件终极方案适用于教学与生产环境当实验室机房全是 GTX 1060sm_61而课程要求跑 Llama-3需 FP16 大显存且无法说服学校采购新卡时“no kernel image” 就是硬件淘汰的明确信号。成本效益分析2024 年GPU 型号sm显存二手价¥PyTorch 支持推荐指数RTX 3060 12GB8.612GB1800CUDA 11.8/12.1★★★★★RTX 4060 Ti 16GB8.916GB3200CUDA 12.1★★★★☆RTX 4090 24GB8.924GB12000CUDA 12.2★★★★教育场景建议北京交通大学等高校的深度学习实验课若仍用 GTX 1060 机房应同步提供 WSL2 云 GPU 方案如阿里云 ecs.gn7eA10 GPU。学生本地用torch-cpu写逻辑云端用torch-cuda跑训练避免环境冲突。实操心得我帮某高校改造实验室时用 10 张二手 RTX 3060 替换 30 台 GTX 1060总成本降低 40%且所有 PyTorch 2.2 教程一键跑通。硬件升级有时比调环境更省时间。5. 常见问题速查表与独家避坑技巧整理自 127 个真实故障案例覆盖高校、企业、个人开发者高频场景。5.1 问题速查表现象最可能原因快速验证命令解决方案no kernel image且nvidia-smi不显示 GPU驱动未安装或内核模块冲突lsmod | grep nvidia重装驱动禁用 nouveaunvidia-smi正常但torch.cuda.is_available()返回 FalseCUDA Toolkit 未安装或 PATH 错误which nvccecho $LD_LIBRARY_PATH设置export PATH/usr/local/cuda/bin:$PATHexport LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATHPyTorch 报错但deviceQueryPASSPyTorch wheel 不含你的 smstrings $(python -c import torch; print(torch.__file__))/../lib/libtorch_cuda.so | grep sm_换cuXXX版本或设TORCH_CUDA_ARCH_LISTWSL2 中报错但 Windows 原生正常WSL2 CUDA 驱动未启用nvidia-smiin WSL2更新 Windows NVIDIA 驱动 ≥ 515.x启用 WSL2 CUDAconda install 后仍报错conda channel 混淆pytorch vs conda-forgeconda list | grep torchconda install pytorch torchvision torchaudio pytorch-cuda11.8 -c pytorch -c conda-forge指定 channel5.2 独家避坑技巧一线踩坑总结技巧一WSL2 的隐藏开关WSL2 的 CUDA 支持依赖 Windows 主机驱动。很多用户装了 WSL2 CUDA toolkit但nvidia-smi在 WSL2 里报错。真正开关在 Windows 注册表打开regedit→HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NVIDIA\Parameters\Device0新建DWORD (32-bit)值名称EnableWSL值1重启 WSL2wsl --shutdown→wsl然后nvidia-smi在 WSL2 中才真正可用。这是微软文档未明说的硬开关。技巧二conda 环境的 CUDA 版本幻觉conda install pytorch-cuda12.1不会改变 PyTorch 的 CUDA target它只安装cudatoolkit12.1。真正的 PyTorch CUDA 版本由pytorch包决定。正确做法是# 创建干净环境 conda create -n dl-env python3.11 conda activate dl-env # 一次性安装匹配的 PyTorch CUDA toolkit conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia # 这会自动选 pytorch-2.2.0cu121技巧三Jupyter Notebook 的 CUDA 缓存污染在 Jupyter 中反复import torch有时会缓存旧的 CUDA context。即使你重装了 PyTorchkernel 仍报错。彻底清理关闭所有 notebook删除~/.local/share/jupyter/kernels/下的 kernel删除~/.jupyter/runtime/重启 Jupyterjupyter notebook --clean技巧四Docker 中的 compute capability 陷阱Docker 镜像nvidia/cuda:12.1.1-devel-ubuntu22.04默认 target sm_50/sm_60/sm_70/sm_75/sm_80/sm_86。但如果你docker run --gpus all启动容器容器内torch.cuda.get_device_capability()返回的是宿主机 GPU 的 capability而 PyTorch wheel 是按构建时 target 编译的。解决方案用--gpus device0,1明确指定 GPU或在 Dockerfile 中ARG TORCH_CUDA_ARCH_LIST8.6构建时传参**技巧五