Linux配置TensorFlow GPU：驱动、隔离环境与三层验证

先区分宿主驱动与Python环境

NVIDIA驱动让操作系统访问GPU；TensorFlow及其用户态CUDA依赖属于项目环境。把驱动、系统级Toolkit、多个手工cuDNN副本和pip依赖混装，最容易产生动态库冲突。标准Linux安装优先遵循框架当前的官方pip方案。

第一层：驱动能够看见硬件

nvidia-smi

命令应列出GPU、驱动与进程。若失败，先修复硬件识别、内核模块、Secure Boot或驱动安装；此时反复重装 TensorFlow 没有意义。服务器升级内核后也要重新确认驱动模块加载。

第二层：在干净虚拟环境安装

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install 'tensorflow[and-cuda]'

当前官方pip安装页为Linux GPU用户给出 tensorflow[and-cuda] 路径，并把旧版兼容信息单独维护。不要把文章中的某组CUDA/cuDNN组合永久当成答案，安装当天以官方页面与目标框架发布版为准。

第三层：TensorFlow枚举设备

python -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

返回非空GPU列表说明框架完成初步加载。若为空，保存完整启动日志，查看是驱动库不可见、环境中库冲突、GPU架构不受支持，还是装到了另一个 Python 解释器。

设备可见后还要跑真实计算

import tensorflow as tf

gpus = tf.config.list_physical_devices('GPU')
for gpu in gpus:
    tf.config.experimental.set_memory_growth(gpu, True)

with tf.device('/GPU:0'):
    a = tf.random.normal((4096, 4096))
    b = tf.linalg.matmul(a, a)
print(b.device, float(tf.reduce_sum(b)))

运行时同时观察nvidia-smi中的显存和利用率。只打印设备列表不能证明训练算子成功，也不能证明性能优于CPU。

常见故障按边界定位

不要把显示的CUDA Version当成本地Toolkit版本

nvidia-smi顶部的CUDA值表示驱动支持能力，不等同于某个虚拟环境实际加载的运行库。排障时记录驱动、TensorFlow、Python、GPU型号与环境包清单，不用一行截图代替完整环境。

容器与WSL2是不同部署路线

容器需要宿主驱动与NVIDIA容器运行时，镜像内提供用户态依赖；Windows上的新发布版GPU支持走WSL2，原生Windows GPU只能使用较旧框架分支。不要把Linux、容器、WSL2和原生Windows命令混在同一安装流程。

安装验收还包括可复现

1. 导出 Python 依赖与系统驱动信息。
2. 保存设备枚举和矩阵计算日志。
3. 运行一个小模型的前向、反向与保存恢复。
4. 重启机器后再次验证。
5. 在升级前建立新环境，不原地覆盖可用环境。

GPU环境可靠的标志，是驱动、Python依赖和模型测试三层都能独立说明，而不是安装器最终显示“成功”。

先画兼容矩阵，再改变系统

矩阵至少包含 GPU 型号与计算能力、操作系统和内核、宿主驱动、Python 版本、TensorFlow 发行包及其官方支持范围。现代安装包通常自带需要的用户态 CUDA 库，是否还要系统级 Toolkit 取决于构建自定义算子等需求；不要把驱动工具显示的“最高支持 CUDA”误当成本机已安装的编译工具版本。

先确认宿主驱动能稳定识别设备，再创建干净虚拟环境安装一个明确版本。混用系统包、多个 Conda 环境与旧 LD_LIBRARY_PATH 很容易加载到错误动态库；发生冲突时，与其不断覆盖文件，不如重建环境并逐项记录。

三层验证缺一不可

1. 驱动层读取设备、温度、显存与进程；
2. 框架层列出物理 GPU，并说明为何可见或不可见；
3. 计算层运行矩阵运算或小模型，确认操作实际放在 GPU 且结果有限。

设备“可见”但速度更慢时，检查数据传输、批量、首次编译、CPU 输入管道和显存换页。基准包含预热、多次重复和同步点，并与 CPU 基线比较；小任务受启动开销主导，不应据此判断 GPU 无效。

容器与 WSL2 是两条不同边界

容器复用宿主驱动，在镜像内固定框架与用户态库，仍要验证宿主驱动满足镜像要求，并为 GPU 运行时设置最小权限。WSL2 使用 Windows 驱动向 Linux 环境暴露设备，不应在子系统里再按裸机方式安装另一套内核驱动。选择路线后按该路线的官方矩阵执行，避免教程片段交叉拼接。

记录安装命令、包锁定、驱动版本、验证输出和回滚方法。升级前复制可工作的环境定义，先在单独环境验证目标模型，再切换任务；不要为一个项目升级整台共享训练机。

上线训练还需监控显存、利用率、温度、功耗与错误，检查检查点能在中断后恢复。一次成功导入 TensorFlow 只是起点，可复现环境与真实计算证据才说明 GPU 路径可用。

安装过程也要守住系统安全

驱动与软件包只从可信发布渠道获取，核对签名和版本，不运行来源不明的一键脚本。共享服务器变更前通知使用者、停止作业并保存环境清单；不要在训练进行时替换驱动或系统库。安装账户使用必要的管理员权限，日常训练回到普通用户。

若旧环境必须移除，先列出由包管理器拥有的组件，再按官方步骤卸载；不要用广泛通配符删除系统目录。完成后检查其他项目环境是否仍能运行，并保留可启动的旧镜像或系统回滚点，直到新配置通过连续任务验证。