企业官网建设流程全解析

折腾了整整一天，总算把 WSL2 里的 Ubuntu 22.04 配上 CUDA 11.8 了。中间最大的坑不是 CUDA 本身，而是那个看起来莫名其妙的 libtinfo5 缺失。网上搜到的回答要么语焉不详，要么让你下载源码折腾半天，越搞越乱。这篇文章把完整过程梳理一遍，尤其是 libtinfo5 的处理方式，希望后来人别再在这上面浪费时间。

这篇文章适合谁看？就是那些在 Windows 上用 WSL2 跑深度学习、做 CUDA 编程，或者想复用 Linux 环境又不想装双系统的朋友。我默认你已经装好了 WSL2 和 Ubuntu 22.04，如果还没有，文章里也会有快速过一遍的步骤。核心内容是 CUDA 11.8 的极简安装思路，以及那个隐藏很深的 libtinfo5 报错到底怎么解决。全文基于我自己的实际操作，命令和路径都验证过，你可以直接照搬。

1. 为什么在 WSL2 里装 CUDA 反而更省心？

1.1 WSL2 下 CUDA 的架构：绕开了 Linux 驱动的大坑

很多人第一次听到“在 WSL2 里装 CUDA”都会奇怪：Windows 下的 WSL2 不是虚拟机吗？虚拟机里怎么访问 GPU？这里必须把 WSL2 的图形和计算支持说清楚。

WSL2 现在的 GPU 支持走的是 GPU 半虚拟化（GPU-PV）接口，微软和 NVIDIA 合作搞的。实际上 WSL2 里不需要安装 NVIDIA 的 Linux 驱动，而是通过 Windows 上的 NVIDIA 驱动将请求转发到物理 GPU。你在 Windows 上装好驱动后，WSL2 里直接就能看到/dev/nvidia0这些设备节点，nvidia-smi也能跑起来。所以，在 WSL2 里只有一个需要安装的 NVIDIA 组件，就是 CUDA Toolkit 本身。驱动是共享 Windows 的，这个设计让 WSL2 里的 CUDA 环境比物理 Linux 机器还干净。

这带来的最大好处是：不会再出现“驱动装错导致整个系统卡死”之类的惨案。如果你试过在双系统的 Linux 下安装 NVIDIA 驱动，一定经历过黑屏、循环登陆、内核模块编译失败这些破事。WSL2 把这些麻烦全部隔离在 Windows 侧，Linux 侧只需要处理用户态的 CUDA 库和工具。这也是我推荐在 WSL2 里做 CUDA 开发的一个重要原因。

1.2 为什么选 CUDA 11.8 而不是 12.x

选择 11.8 是因为生态兼容性。很多深度学习框架、推理引擎、编译工具链的预编译版本还在用 CUDA 11.8 作为标准配置，比如一些 Transformer 加速库、TensorRT 的某些版本，甚至在 PyTorch 的轮子里，CUDA 11.8 版本是覆盖率最高、踩坑最少的一个稳定版本。CUDA 12.x 虽然新，但如果你有三方库的源码需要编译，依赖的 CUDA 版本很可能还停留在 11.x，这时候硬上 12 只会自找麻烦。

另外，11.8 对 GPU 的架构支持也比较宽。Ampere、Ada Lovelace、Hopper 以及更早的 Turing 架构都能正常使用。如果你的显卡是 RTX 30 系或 40 系，11.8 完全够用，甚至性能表现跟 12.x 没有明显差别。对于大多数跑实验、做推理的人来说，稳定能跑比盲目追新重要得多。

2. 先把 WSL2 和 Ubuntu 22.04 准备好

2.1 检查 Windows 版本和 WSL2 状态

在安装 CUDA 之前，先确认 WSL2 本身是正常的。用了很久的老版本 WSL，建议升级到最新版，因为老的 WSL1 或者旧版 WSL2 里面的 GPU 支持不完整。

打开 PowerShell（管理员权限），跑几个命令：

wsl --status wsl --set-default-version 2

如果wsl --status输出里不是 WSL2 版本，就需要手动切换。Windows 10 需要安装“适用于 Linux 的 Windows 子系统”可选组件，Windows 11 则简单很多，直接wsl --install就能装好。

如果你的电脑上已经跑着 WSL1 的发行版，可以用wsl --set-version Ubuntu-22.04 2把它转换到 WSL2。转换过程比较慢，可能要几分钟，耐心等就行。

2.2 安装或升级 Ubuntu 22.04 镜像

在 PowerShell 里执行：

wsl --install -d Ubuntu-22.04

如果执行后提示找不到这个发行版，说明你的 WSL 版本太老，先去 Windows Update 更新，或者用wsl --update --web-install更新内核。也可以从微软商店直接搜索 Ubuntu 22.04 LTS 安装。发行版名称不一定都是 Ubuntu-22.04，有时候是 “Ubuntu” 或 “Ubuntu-22.04”，看商店里的实际名称。

装好后打开 Ubuntu 终端，设置用户名和密码。第一件事是更新软件源并安装基础工具：

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential gcc make dkms

build-essential一定要装，后面编译 CUDA 示例程序的时候会用到 gcc、g++ 和 make。不装的话，即使 CUDA Toolkit 装好了，测试驱动也各种别扭。

2.3 环境初检：显卡、驱动和 nvidia-smi

在 Ubuntu 终端里输入：

nvidia-smi

如果能看到类似下面的输出，说明 Windows 侧驱动已经被 WSL2 正确透传了：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 525.85.05 Driver Version: 525.85.05 CUDA Version: 12.0 |

注意，这里显示的CUDA Version是 Windows 驱动支持的最高 CUDA 版本，并不代表 WSL2 里已经装了 CUDA Toolkit。这个数字可能会是 12.0、12.1，甚至更高，但完全不影响你在 WSL2 里安装只支持 11.8 的 Toolkit。WSL2 给用户的自由度就在这里，驱动是“向上兼容”的。

如果nvidia-smi提示找不到命令，先检查 Windows 侧的驱动是否安装完整，然后在 PowerShell 里升级 WSL：

wsl --update

重启 WSL 后再试。千万不要尝试在 WSL 里自行安装 NVIDIA Linux 驱动，这属于典型的误区，装了反而可能破坏 /dev/nvidia0 的转发。

确认nvidia-smi正常后，就可以开始安装 CUDA 11.8 了。

3. 极简安装 CUDA 11.8 的完整过程

3.1 下载 runfile 安装包

CUDA Toolkit 官方提供两种安装方式：deb (network)和runfile (local)。我强烈推荐用 runfile local 版，原因有三个：

• 不需要折腾 apt 源，覆盖路径可控。
• 不会自动安装 driver，完全符合 WSL2 的特性。
• 卸载干净，直接删除/usr/local/cuda-11.8目录就行。

进入 NVIDIA 官方归档页找到 CUDA Toolkit 11.8.0（注意是 11.8.0），Linux 平台选择 x86_64 / WSL-Ubuntu。生成下载链接后，在 WSL2 里用 wget 直接下载：

cd ~ wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run

这个安装包大约 4GB，下载时间看网速。如果网络条件一般，建议用支持断点续传的下载工具先下载到 Windows 侧，再通过/mnt/c/路径拷进 WSL2，避免终端里中断重下。

3.2 安装命令的取舍

下载完成后，先不要急着运行。CUDA Toolkit 的 runfile 默认会尝试安装显卡驱动，而在 WSL2 里这是大忌。安装时一定要加上--toolkit参数，只安装 CUDA Toolkit，不碰驱动。

我的建议是用无交互的静默安装，减少意外：

chmod +x cuda_11.8.0_520.61.05_linux.run sudo sh cuda_11.8.0_520.61.05_linux.run --toolkit --silent --override

--silent表示静默模式，--override是保证即使检测到一些系统库不满足也能继续安装（后面 libtinfo5 缺失不会在这里报错，因为主安装过程不依赖 libtinfo5）。如果你想手动指定安装位置，默认就好，别乱改路径，否则后续环境变量会很麻烦。

静默安装很快，大概一两分钟就能完成。安装完后，CUDA 目录会在/usr/local/cuda-11.8，同时/usr/local/cuda会作为软链接指向它。检查一下：

ls -l /usr/local/cuda

如果看到软链接存在，说明安装成功。

有些教程推荐用交互式安装，然后在界面里手动取消 Driver 选项。但交互式界面在 WSL2 里显示可能有问题，而且新手容易误选，还是直接用静默参数更稳妥。

3.3 配置环境变量并验证 nvcc

CUDA 安装完成后，需要把bin和lib64加入 PATH 和 LD_LIBRARY_PATH。编辑~/.bashrc：

echo '# CUDA 11.8' >> ~/.bashrc echo 'export PATH=/usr/local/cuda-11.8/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

然后验证：

nvcc -V

正常会输出：

nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2022 NVIDIA Corporation Built on Wed_Nov_16_14:16:20_PST_2022 Cuda compilation tools, release 11.8, V11.8.89 Build cuda_11.8.r11.8/compiler.31833944_0

到了这一步，CUDA 核心工具链就绪了。但注意，CUDA Toolkit 里还有很多辅助组件，比如nsight-compute、nsight-systems、cuda-gdb，以及支持多架构的 GPU 计算库，这些组件在某些版本里依赖旧的 ncurses 库。这正是 libtinfo5 报错的来源。

4. 高频报错：libtinfo5 缺失的完整解法

4.1 这个报错到底是谁在报？为什么 Ubuntu 22.04 会缺？

安装完 CUDA 11.8 之后，我尝试运行nsight-compute和ncu来 profile 程序，结果马上报错：

/usr/local/cuda-11.8/nsight-compute-2022.3.0/ncu: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

类似的还会发生在cuda-gdb上：

/usr/local/cuda-11.8/bin/cuda-gdb: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

这里的libtinfo是终端处理库，ncurses 的子库，专门负责终端输入/输出的底层控制。很多黑底白字的命令行程序都要用它。Ubuntu 20.04 及更早版本默认提供libtinfo.so.5，而 Ubuntu 22.04 升级到了libtinfo.so.6，且不再自带.so.5版本的兼容包。结果就是，那些基于 Ubuntu 20.04 编译的 NVIDIA 工具，拿到 22.04 上来就找不到老符号。

注意，这个报错不影响nvcc编译 CUDA 代码，也不影响运行时加载libcudart。所以很多人一开始觉得“CUDA 装好了啊”，直到运行 profiler 或者 debugger 才栽跟头。如果你的需求只是编译和跑模型，可能根本遇不到。但只要你想用完整的 CUDA Toolkit 功能，libtinfo5就是绕不过去的坎。

4.2 手动安装 libtinfo5 的两种方法

最正规的做法是从 Ubuntu 20.04 的官方仓库下载libtinfo5的 deb 包安装。Ubuntu 20.04 的 main 仓库里有现成的 amd64 包，直接下载安装即可：

cd ~ wget http://archive.ubuntu.com/ubuntu/pool/main/n/ncurses/libtinfo5_6.2-0ubuntu2_amd64.deb sudo dpkg -i libtinfo5_6.2-0ubuntu2_amd64.deb

装完之后再检查：

dpkg -l | grep libtinfo

输出里应该同时看到libtinfo6（系统自带）和libtinfo5（手动安装）。两者的版本号不同，可以共存，不会互相覆盖。

还有另一种比较野的路子，就是创建一个符号链接，把libtinfo.so.6软链成libtinfo.so.5：

sudo ln -s /lib/x86_64-linux-gnu/libtinfo.so.6 /lib/x86_64-linux-gnu/libtinfo.so.5

这种方案能骗过大部分程序，因为libtinfo.so.6的接口在绝大多数函数上是向后兼容的。但毕竟不是原生 ABI，极少数依赖特定行为的程序会崩。我自己实测下来，NVIDIA 的nsight-compute和cuda-gdb用软链方案也能跑，但心里总不踏实，所以最后还是改成 deb 包安装。这里明确给个倾向：优先用 Ubuntu 20.04 的 deb 包，而不是软链接。原因很实在，正式维护的二进制包会带上正确的符号版本和依赖关系，出问题也好排查。

如果你所在的网络环境访问archive.ubuntu.com比较慢，也可以从国内一些镜像站下载同一个包。注意，必须选择对应 amd64 架构的文件，不要下载源码包。下载来源要确认，最好是官方或知名镜像站。

4.3 安装后验证：nsight、nvcc、示例程序

装好 libtinfo5 后，先测试 NSight Compute 能不能起来：

/usr/local/cuda-11.8/nsight-compute-2022.3.0/ncu --version

如果能看到版本号，说明运行库依赖已经解决。

再测试 cuda-gdb：

cuda-gdb --version

另外，还可以编译一个官方示例程序来验证完整工具链。先下载 CUDA samples 并编译（注意对应 11.8 版本）：

git clone -b v11.8 https://github.com/NVIDIA/cuda-samples.git cd cuda-samples/Samples/1_Utilities/deviceQuery make ./deviceQuery

如果编译过程中提示找不到某些头文件，先确认cuda-samples分支是对应 11.8 的，并且把/usr/local/cuda-11.8/samples里的 Makefile 环境变量设置好。最简单的做法是直接解压/usr/local/cuda-11.8/samples目录里的 tarball。

deviceQuery运行后，能看到类似Detected 1 CUDA Capable device(s)的输出，说明 CUDA 编译器、运行时库、GPU 访问全部正常。

5. 踩坑实录：常见问题与排查技巧

5.1 nvidia-smi 报错或找不到

在 WSL2 里最常见的诡异现象是：明明 Windows 装好了驱动，但 Ubuntu 终端里nvidia-smi说找不到。先不要怀疑驱动装错了，按下面顺序排查：

• 确认 WSL 版本确实是 2：wsl -l -v查看发行版版本号。
• 确认 Windows 侧nvidia-smi可以正常输出。
• 在 PowerShell 里执行wsl --shutdown，然后重新打开 Ubuntu。
• 检查是否误装了 Linux 版本的 NVIDIA 驱动：dpkg -l | grep nvidia-driver。如果有，用sudo apt purge nvidia-driver-*卸载干净。

WSL2 的 GPU 透传对驱动版本有最低要求，老驱动可能不支持，尽量把 Windows 驱动升级到最新稳定版。另外，直接从 Windows 侧访问/mnt/c/Windows/System32/nvidia-smi.exe也能应急，但那样输出的通常是 Windows 驱动的状态，不能代表 Linux 环境内的 CUDA 运行时。

5.2 nvcc 与驱动版本不一致

很多人看到nvidia-smi顶部显示CUDA Version: 12.0，而nvcc -V显示 11.8，就慌了。其实这是正常的。nvidia-smi里的 CUDA Version 表示当前驱动驱动对于 CUDA 运行时的最大兼容版本，而nvcc的版本表示编译工具链的版本。前面说过，WSL2 的驱动是 Windows 侧的，所以只要驱动版本大于等于 11.8 所需的最低版本，就能正常工作。

怎么判断驱动最低版本？CUDA 11.8 要求 Linux 驱动版本不低于 520.61.05。你可以在nvidia-smi输出的 Driver Version 列确认，比如525.85.05就满足要求。只要驱动版本够新，nvcc和驱动版本不一致就不是问题。

唯一要注意的是，如果你同时装了多个 CUDA Toolkit 版本，环境变量PATH里的nvcc可能指向旧版本。用which nvcc确认当前生效的路径。如果发现自己不小心装了多个版本，用update-alternatives管理nvcc是个好办法，但更推荐的做法是只在~/.bashrc中保留你打算长期使用的那一个 CUDA 版本的PATH，其他版本通过软链接访问。

5.3 跑 PyTorch 等框架时的 CUDA 可用性

如果 CUDA Toolkit 本身装好了，但你在 Python 里执行torch.cuda.is_available()依然返回 False，大概率是 PyTorch 自带的 CUDA 运行时与你的 Toolkit 不匹配或者缺少必要的系统库。

我遇到过的场景是：Python 里 import torch 没问题，但torch.cuda.is_available()是 False。用nvidia-smi能看到显卡，nvcc -V也正常，但 PyTorch 就是找不到 GPU。后来发现是 PyTorch 安装的是 CPU 版本，pip install torch默认在某些索引源上可能装成 CPU 版本。解决方案是用官方命令安装特定 CUDA 版本的 PyTorch，比如：

pip install torch --index-url https://download.pytorch.org/whl/cu118

还要确认系统有 CUDA 运行所需的libcuda.so或libcudart.so。正常情况下，CUDA Toolkit 装在/usr/local/cuda-11.8/lib64下，PyTorch 自己的轮子会带运行时，所以一般不需要把 CUDA 库加入LD_LIBRARY_PATH，但如果你手动编译扩展模块，就需要确保LD_LIBRARY_PATH包含了正确路径。

另一个坑是权限问题。WSL2 中访问 GPU 设备节点需要当前用户加入video组吗？通常不用，因为设备文件的权限已经放开。但如果出现权限拒绝，可以检查/dev/nvidia0的权限：

ls -l /dev/nvidia*

如果 owner 是 root，而你的用户没有访问权限，可以将用户加入video组再重新登录。不过绝大多数情况下，WSL2 默认配置不需要这一步。

6. 一些实测后的心得

6.1 不要把 CUDA 装在 WSL 外的 Windows 里

有过一个很天真的想法：Windows 上也装一个 CUDA Toolkit，然后在 WSL2 里直接调用 Windows 的二进制。结果发现完全没必要，而且容易搞乱环境。WSL2 里的 Linux 用户态需要的是 Linux 版本的 CUDA 库，Windows 版本的库和 Linux 程序通过/proc/sys/fs/binfmt_misc互操作，不能直接链接。所以老老实实把 CUDA Toolkit 装进 WSL2 的 Linux 文件系统里，不要尝试跨系统调用。

另外，WSL2 的 Linux 文件系统访问效率远高于挂载的 Windows 盘（/mnt/c/）。CUDA Toolkit 默认装在/usr/local/cuda-11.8，位于 Linux 原生文件系统内，性能没有问题。千万不要把 CUDA 安装目录放到/mnt/c/下面，否则大量小文件读写会让你怀疑人生。

6.2 保持纯净：不要用 apt 随便装 cuda

Ubuntu 的 apt 源里也有nvidia-cuda-toolkit包，直接sudo apt install nvidia-cuda-toolkit确实能装上 CUDA，但它会是某个特定的旧版本，而且不是 NVIDIA 官方推荐的部署方式。它会带来一堆系统的限制，还可能与你自己从官网下载的 toolkit 冲突。我在早期踩过这个坑，apt 装的 CUDA 11.5 和之后的深度学习框架版本不兼容，想切回 11.8 时还要清理一堆依赖。

我的建议是，永远不要用 apt 安装 CUDA Toolkit。用 NVIDIA 官方的 runfile，配合/usr/local/cuda软链接切换版本，才是 WSL2 下的最优解。如果你已经用 apt 装了，卸载时也要小心，最好在卸载后手动删除/usr/local/cuda*目录，否则残留的二进制和库会让后续安装变得一团糟。

6.3 留下环境变量备份

环境变量写进~/.bashrc后，一旦后面想要切换 CUDA 版本，就得记得去改那两行 export。我自己的做法是，在~/.bashrc里写一个注释块，标明当前使用的 CUDA 版本和切换方式：

# CUDA_VERSION = 11.8 # switch: change the version number in paths below export PATH=/usr/local/cuda-11.8/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH

另外，如果以后需要安装 cuDNN 或者其他依赖 CUDA 的库，尽量使用与 CUDA 11.8 对应的版本。CUDNN 对版本敏感，libcudnn.so的版本号和 CUDA 版本必须匹配，否则可能报出莫名其妙的加载错误。

最后再多说一句关于 libtinfo5 的事。这个包本质上是一个系统库的旧版兼容层，不只是 CUDA 需要，一些老款的分析工具、交叉编译器也会碰到同样的问题。学会手动安装单独的 deb 包而不是无脑软链接，能省下很多以后的麻烦。我用了几天下来，nsight、cuda-gdb 这些工具都正常，没再出现其他异常。如果你也按这条路径安装成功了，可以在评论区告诉我你遇到的其它坑，我后续再补充进来。