版本匹配为什么重要
深度学习框架的每个发布版本都绑定特定的 CUDA 构建：安装包里的算子库是针对某个运行时版本编译的。装错组合的典型症状是框架检测不到设备，或者导入阶段就报动态库找不到。用官方索引地址按目标 CUDA 版本安装能规避大部分问题，比手工拼装可靠得多。
验证与安装
验证与安装
# 一次打印版本组合与设备可用性
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"
# 用官方索引安装指定构建（cu 后缀表示 CUDA 版本）
pip install torch --index-url https://download.pytorch.org/whl/cu<版本号>
# 确认 pip 与 python 属于同一环境
python -c "import sys; print(sys.executable)"
pip -V判断顺序
| 第一步 | 先看设备可用性开关是否为真 |
|---|---|
| 第二步 | 再看框架报告的 CUDA 版本，与驱动上限比较 |
| 第三步 | 确认命令行与包管理器指向同一个环境 |
| 第四步 | 容器部署时以镜像内的版本为准，不参考宿主机 |
症状与原因
| 症状 | 常见原因 | 处置方向 |
|---|---|---|
| 设备可用性为假 | 装成 CPU 版构建 | 按索引地址装对应构建 |
| 导入即报库缺失 | 框架构建与运行时不一致 | 对齐驱动、运行时与框架构建 |
| 装好仍用旧版本 | 包管理器与解释器不在同一环境 | 统一虚拟环境后再装 |
| 容器内外表现不同 | 容器内版本由镜像决定 | 以容器内查询结果为准 |
典型使用场景
- 搭建开发环境：按显卡与驱动情况选择对应构建
- 排查设备不可见：先确认框架是不是 CPU 版，再查驱动
- 环境重建：把版本组合写进依赖文件，避免每次重新试
- 容器镜像升级：镜像内版本变化后重新验证一次
- 多环境共存：不同项目用各自环境，避免全局升级带来连锁影响
容器镜像里的框架与运行时已经配好：推理部署优先容器化，宿主机手工安装框架通常只用于开发验证。
包管理器与解释器不在同一环境是高频陷阱：包装到了别处，导入的仍是旧版本，排查时要先打印解释器路径。