企业官网建设流程全解析

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）在生成 PTX（Parallel Thread Execution）中间码和 SASS（Streaming ASSembler）二进制码时，会根据你指定的-gencode arch=compute_XX,code=sm_XX参数，为特定计算能力（Compute Capability）的 GPU 生成可执行指令。如果运行时 GPU 的实际架构版本低于编译时指定的最低要求，驱动层就会直接拒绝加载该 kernel，抛出这句“no kernel image is available”。

举个生活化类比：这就像是你用最新版 Photoshop（CUDA Toolkit 12.4）导出一个 PSD 文件，但想在一台只装了 CS5（驱动版本 470.x）的电脑上打开——软件能启动，但一加载那个用了新图层混合模式的文件，就弹窗：“不支持此文件格式”。不是文件损坏，也不是软件崩溃，而是版本协议不匹配。

所以，这个错误从来不是“CUDA 没装好”，而是“你编译出来的指令集，这台 GPU 根本看不懂”。它背后牵扯的是三重版本对齐：GPU 硬件架构 → NVIDIA 驱动 → CUDA Toolkit → 深度学习框架（PyTorch/TensorFlow）→ cuDNN → 编译时指定的 compute capability。任何一个环节脱节，都可能触发这道“语言不通”的防火墙。

这也是为什么它高频出现在高校教学场景中——比如北京交通大学深度学习期末试题里要求在学生机房的 GTX 1060（compute 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 Ti：6.1
• RTX 2080：7.5
• A100：8.0
• RTX 4090：8.9
• L40：8.9

这个值写死在 GPU 芯片里，无法升级。你可以用nvidia-smi -q | grep "Product Name\|CUDA Version"查看显卡型号，再查 NVIDIA 官方文档 对应的 compute capability。注意：驱动版本不能提升硬件能力，只能向下兼容旧架构。比如驱动 535 支持 sm_50 到 sm_90，但它不能让 GTX 970（sm_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_61（GTX 1060），但驱动是 390.x（只支持到 sm_61），那它就能跑；但如果驱动是 510.x（支持 sm_61+），它也能跑。驱动版本影响的是“能否识别”，而不是“能否运行”。

2.3 第三层：CUDA Toolkit 版本 —— 编译器与运行时的双重角色

CUDA Toolkit 不只是编译器（nvcc），它还包含运行时库（cudart）、驱动接口（libcuda）和大量预编译库（如 cuBLAS、cuFFT）。它的版本决定了：

• 编译时默认 target：CUDA 11.x 默认 target sm_35/sm_50/sm_60/sm_70/sm_75；CUDA 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.13（CUDA 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.0+cu121-cp311-cp311-linux_x86_64.whl表示：PyTorch 2.3.0，CUDA 12.1 编译，Python 3.11，Linux x64。
• 它内部的 CUDA kernel 是用-gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86等参数编译的。

这意味着：你装的 PyTorch 版本，决定了它能跑在哪些 GPU 上。RTX 3090（sm_86）能跑+cu118和+cu121，但 GTX 1070（sm_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-cuda=12.1 -c pytorch-nightly时，conda 并不是在你机器上编译 PyTorch，而是从远程仓库下载一个早已编译好的、target sm_80/sm_86/sm_90 的二进制包。如果你的 GPU 是 sm_61，它天然就不带 sm_61 的 kernel image——报错是必然的。

注意：conda install pytorch-cuda=12.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-gpu=name --format=csv,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\|Compute"

Windows：

• 打开设备管理器 → 显示适配器 → 右键 GPU → 属性 → 详细信息 → “硬件 ID”
• 复制VEN_10DE&DEV_XXXX中的XXXX，查 PCI Database

查 compute capability：
访问 NVIDIA 官方列表 ，输入型号。重点记录Major.Minor，例如：

• RTX 4060 Ti → 8.9
• RTX 3060 → 8.6
• GTX 1060 6GB → 6.1
• Tesla V100 → 7.0

实操心得：很多实验室机器用的是 OEM 卡（如联想、戴尔定制版），型号名和公版不同，但芯片相同。例如“NVIDIA GM107GL [Quadro K620]” 实际就是 GK107（sm_30），不是 K620 官方标称的 sm_35。必须查 PCI ID，不能信表面型号。

3.2 第二步：验证驱动版本与 GPU 架构兼容性

驱动版本必须同时满足两个条件：不低于 GPU 的最低驱动要求，且支持该 GPU 的 compute capability。

查当前驱动版本：

nvidia-smi --query-driver=version --format=csv,noheader,nounits # 或 cat /proc/driver/nvidia/version 2>/dev/null | head -1

查驱动支持的 compute capability 范围：
官方文档已明确列出。但更实用的方法是：用驱动自带的nvidia-smi检查是否识别 GPU 架构。

# 如果驱动完全不支持该 GPU，nvidia-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 是 RTX 4090（sm_89），但驱动是 470.x，那么deviceQuery会显示 GPU，但 CUDA kernel 加载失败——因为 470.x 最高只支持到 sm_80。

提示：驱动升级是最安全的“兼容性扩容”手段。升级驱动几乎从不破坏旧 GPU 支持，只会增加新 GPU 支持。只要你的 Linux 内核版本 ≥ 3.10，Windows ≥ 7，升级驱动风险极低。

3.3 第三步：确认深度学习框架的 CUDA target 架构

这才是多数人忽略的核心。PyTorch/TensorFlow 的 wheel 包是“开箱即用”的黑盒，必须反向解析它内置的 kernel target。

PyTorch 方案（推荐）：
PyTorch 2.0+ 提供了内置诊断工具：

import torch print(f"PyTorch version: {torch.__version__}") print(f"CUDA available: {torch.cuda.is_available()}") print(f"CUDA version: {torch.version.cuda}") print(f"GPU count: {torch.cuda.device_count()}") if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(f"GPU {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 -u

TensorFlow 方案：

import tensorflow as tf print(f"TF version: {tf.__version__}") print(f"Built with CUDA: {tf.test.is_built_with_cuda()}") print(f"GPU available: {tf.config.list_physical_devices('GPU')}") # TF 不直接暴露 sm list，需查 release notes 或用 objdump

实测案例：
我在一台 RTX 2080 Ti（sm_75）上安装torch-2.2.0+cu118，运行strings ... | grep sm_得到：

sm_50 sm_60 sm_70 sm_75 sm_80 sm_86

说明这个包支持从 Pascal（sm_60）到 Ampere（sm_86）的所有主流架构，RTX 2080 Ti 完全兼容。

但若安装torch-2.3.0+cu121，同样命令得到：

sm_50 sm_60 sm_70 sm_75 sm_80 sm_86 sm_90

多了一个 sm_90，但不影响 sm_75 运行。

而如果误装torch-2.3.0+cu124（刚发布），其 sm list 可能是：

sm_75 sm_80 sm_86 sm_90

去掉了 sm_50/sm_60——这意味着 GTX 1080（sm_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”，要手动选：

1. Choose your OS：Linux / Windows / macOS
2. Package：pip（不是 conda，conda 通道有时滞后）
3. Language：Python
4. CUDA Version：选低于或等于你 GPU compute capability 的最大版本
   • sm_61（GTX 1060）→ 选CUDA 11.3或CUDA 11.6（11.7+ 可能不含 sm_61）
   • sm_75（RTX 2080 Ti）→ 选CUDA 11.8或CUDA 12.1（都支持）
   • sm_86（RTX 3090）→ 选CUDA 11.8/12.1/12.4（全支持）
   • sm_89（RTX 4090）→ 必须选CUDA 12.1+（11.x 不支持）

安装命令（以 GTX 1060 为例）：

# 卸载现有 PyTorch pip uninstall torch torchvision torchaudio # 安装 CUDA 11.3 版本（明确支持 sm_61） pip3 install torch==2.1.0+cu113 torchvision==0.16.0+cu113 torchaudio==2.1.0+cu113 --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.0+cuda11.8-cp311-cp311-linux_x86_64.whl是 CUDA 版。

实操心得：PyTorch 的+cuXXX后缀是编译时 CUDA 版本，不是运行时要求。你装+cu113，但系统有 CUDA 12.1 驱动，只要驱动 ≥ 450.x（11.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 JIT（PyTorch 2.0+） os.environ['CUDA_MODULE_LOADING'] = 'LAZY' import torch # 关键：设置 CUDA_LAUNCH_BLOCKING=1 可捕获 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_CUDA=1 export CUDA_HOME=/usr/local/cuda-12.2 export TORCH_CUDA_ARCH_LIST="8.9" # 关键！只编译你的 GPU 架构 export MAX_JOBS=16 # 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', 'arch=compute_89,code=sm_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 980，sm_52），但被迫用新版框架（如 PyTorch 2.3），而新版 PyTorch wheel 不含 sm_52 时，可考虑降级驱动。

安全降级流程：

# 1. 查当前驱动版本 nvidia-smi --query-driver=version --format=csv,noheader,nounits # 2. 查目标驱动（如 GTX 980 需驱动 ≥ 390.x，但 ≤ 470.x 才保证 sm_52 支持） # 下载对应 runfile：https://www.nvidia.com/Download/index.aspx?lang=en-us # 3. 停止 GUI（Ubuntu） 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 1060（sm_61），而课程要求跑 Llama-3（需 FP16 + 大显存），且无法说服学校采购新卡时，“no kernel image” 就是硬件淘汰的明确信号。

成本效益分析（2024 年）：

教育场景建议：
北京交通大学等高校的深度学习实验课，若仍用 GTX 1060 机房，应同步提供 WSL2 + 云 GPU 方案（如阿里云 ecs.gn7e，A10 GPU）。学生本地用torch-cpu写逻辑，云端用torch-cuda跑训练，避免环境冲突。

实操心得：我帮某高校改造实验室时，用 10 张二手 RTX 3060 替换 30 台 GTX 1060，总成本降低 40%，且所有 PyTorch 2.2+ 教程一键跑通。硬件升级有时比调环境更省时间。

5. 常见问题速查表与独家避坑技巧

整理自 127 个真实故障案例，覆盖高校、企业、个人开发者高频场景。

5.1 问题速查表

5.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
• 重启 WSL2：wsl --shutdown→wsl
• 然后nvidia-smi在 WSL2 中才真正可用。这是微软文档未明说的硬开关。

技巧二：conda 环境的 CUDA 版本幻觉
conda install pytorch-cuda=12.1不会改变 PyTorch 的 CUDA target，它只安装cudatoolkit=12.1。真正的 PyTorch CUDA 版本由pytorch包决定。正确做法是：

# 创建干净环境 conda create -n dl-env python=3.11 conda activate dl-env # 一次性安装匹配的 PyTorch + CUDA toolkit conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia # 这会自动选 pytorch-2.2.0+cu121

技巧三：Jupyter Notebook 的 CUDA 缓存污染
在 Jupyter 中反复import torch，有时会缓存旧的 CUDA context。即使你重装了 PyTorch，kernel 仍报错。彻底清理：

• 关闭所有 notebook
• 删除~/.local/share/jupyter/kernels/下的 kernel
• 删除~/.jupyter/runtime/
• 重启 Jupyter：jupyter 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 '"device=0,1"'明确指定 GPU
• 或在 Dockerfile 中ARG TORCH_CUDA_ARCH_LIST="8.6"，构建时传参

**技巧五：