企业官网建设流程全解析

1. 为什么值得折腾NVLink：从一张A100的互联瓶颈说起

手里有一台8卡A100的服务器，跑单卡推理的时候一切正常，一旦上多卡并行训练，GPU利用率就上不去，nvidia-smi里看到卡间通信把PCIe带宽吃满了，这时候就该考虑NVLink了。很多人拿到A100之后只装了驱动、装了CUDA，以为万事大吉，实际上NVLink这套东西需要单独确认状态、单独启动服务、单独测带宽，缺一步都可能让卡间通信悄悄退回PCIe，性能直接砍半。

这篇内容面向的是手里有NVLink-capable硬件（A100、H100、部分RTX 3090/4090桥接方案）的运维和算法工程师，也适合刚接手GPU服务器、需要把多卡互联调通的人。我会从驱动安装讲起，一路走到NVLink服务启动、拓扑确认、带宽实测，把每一步的意图和踩坑点都摊开说。核心关键词就几个：NVIDIA、NVLink、A100、驱动安装、带宽测试，全文围绕这几个词展开，不跑题。

需要先明确一个概念：NVLink不是装个驱动就自动生效的东西。它是一套物理互联加协议栈，物理层是卡与卡之间的高速桥或者板载链路，协议层由NVIDIA驱动和nvidia-fabricmanager这类服务来管理。A100的NVLink是第三代，单链路双向带宽50GB/s，一张A100有12条链路，理论总带宽600GB/s。但这是理论值，实际能不能跑满，取决于驱动版本、fabricmanager是否启动、拓扑是否被正确识别。我见过太多机器，nvidia-smi topo -m里显示NVLink是通的，但fabricmanager没起，实际通信还是走PCIe，白瞎了硬件。

所以整个流程的逻辑链条是：驱动装对→设备节点正常→fabricmanager服务起来→拓扑识别正确→带宽测试验证。任何一环断了，后面的性能都是假的。下面按这个顺序拆。

2. 驱动安装：版本选择与A100的兼容性坑

2.1 驱动版本怎么选才不翻车

A100是Ampere架构，计算能力8.0，对驱动版本有最低要求。太老的驱动认不出NVLink，太新的驱动又可能和现有的CUDA、容器运行时打架。我的经验是，先确定你要跑的CUDA版本，再反推驱动版本，而不是反过来。

NVIDIA官方有个兼容性矩阵，简单说：CUDA 11.x系列对应驱动450以上，CUDA 12.x对应驱动525以上。A100要跑NVLink，建议驱动版本不低于470，因为470之前的版本对fabricmanager的支持不完整。我实测下来，535和550这两个长期支持分支在A100上最稳，550系列对NVLink 3.0的拓扑识别也更准。

选版本的时候有个坑：Ubuntu的apt源里自带的nvidia-driver-xxx往往是阉割版，不带fabricmanager。你要么用NVIDIA官方runfile，要么用官方CUDA仓库的deb包。我推荐后者，因为apt管理依赖方便，卸载也干净。

# 添加NVIDIA官方CUDA仓库（以Ubuntu 22.04为例） wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update # 查看可用驱动版本 apt-cache search nvidia-driver | grep -E "535|550"

注意：不要同时装apt源和runfile的驱动，会冲突。如果之前用runfile装过，先用sudo ./NVIDIA-Linux-x86_64-xxx.run --uninstall卸干净，再走apt。

2.2 安装前的准备工作

装驱动之前有几件事必须做，否则装完重启黑屏的概率很高。第一，确认内核头文件和编译工具链齐全，DKMS需要它们来编译内核模块：

sudo apt install build-essential dkms linux-headers-$(uname -r)

第二，禁用nouveau开源驱动，它在的时候NVIDIA驱动装不上：

sudo bash -c "echo -e 'blacklist nouveau\noptions nouveau modeset=0' > /etc/modprobe.d/blacklist-nouveau.conf" sudo update-initramfs -u

第三，如果服务器开了Secure Boot，要么在BIOS里关掉，要么给驱动模块签名，否则模块加载会被拒绝。我一般直接关Secure Boot，省事。

2.3 实际安装与验证

# 安装驱动和fabricmanager（关键：fabricmanager必须一起装） sudo apt install nvidia-driver-550 nvidia-fabricmanager-550 # 重启 sudo reboot

重启后验证：

nvidia-smi

输出里要能看到所有A100，Driver Version对得上。然后确认NVLink设备节点存在：

ls /dev/nvidia*

应该能看到/dev/nvidia0到/dev/nvidiaN，以及/dev/nvidiactl、/dev/nvidia-uvm。如果缺了uvm节点，说明驱动模块没加载全，检查dmesg | grep -i nvidia。

这里有个常见问题：装完驱动nvidia-smi报"Failed to initialize NVML: Driver/library version mismatch"。这是内核模块和用户态库版本不一致，通常是装了新驱动但没重启，旧模块还在内存里。重启就好，别急着重装。

3. NVLink服务启动：fabricmanager才是关键

3.1 fabricmanager到底管什么

很多人不知道fabricmanager是干嘛的。简单类比：NVLink是卡之间的高速公路，fabricmanager就是交通调度中心。它负责发现NVLink拓扑、管理链路状态、处理错误恢复。没有它，NVLink链路虽然物理上连着，但系统不会把它当成可用的高速通道来调度。

A100的NVLink分两种模式：一种是板载的NVSwitch（比如DGX A100），卡之间通过NVSwitch全互联；另一种是桥接的NVLink（比如两张A100用桥连）。前者必须跑fabricmanager，后者在部分场景下也需要。不管哪种，先把fabricmanager起来再说。

3.2 启动与状态确认

# 启动fabricmanager sudo systemctl start nvidia-fabricmanager sudo systemctl enable nvidia-fabricmanager # 查看状态 sudo systemctl status nvidia-fabricmanager

状态要是active (running)。如果起不来，看日志：

sudo journalctl -u nvidia-fabricmanager -n 50

最常见的失败原因是驱动版本和fabricmanager版本不匹配。比如你装了550的驱动，却装了535的fabricmanager，它会直接拒绝启动。版本号必须严格对应。

启动成功后，用nvsm或者nvidia-smi确认NVLink状态：

nvidia-smi nvlink -s

这个命令会列出每张卡每条NVLink链路的状态。正常应该是Active，如果显示Inactive或者报错，说明链路没起来。

3.3 拓扑识别确认

nvidia-smi topo -m

这个输出是判断NVLink是否真正生效的核心依据。看卡与卡之间的连接标识：NV12表示12条NVLink全连，NV4表示4条，SYS表示走系统PCIe，PHB表示走PCIe Host Bridge。如果两张本该NVLink直连的A100显示的是SYS，那NVLink就没生效，得回头查fabricmanager和物理连接。

我踩过一次坑：8卡A100的机器，topo显示前4张卡之间是NV12，后4张之间也是NV12，但跨组是SYS。查了半天发现是NUMA绑定问题，BIOS里PCIe拓扑没配对。后来在BIOS里把PCIe bifurcation调对，重启后全互联正常。所以topo不对，先别怀疑驱动，查BIOS和物理插槽。

4. 带宽测试：用nvbandwidth和自定义程序验证真实性能

4.1 为什么不能只看nvidia-smi

nvidia-smi告诉你链路是Active的，但不告诉你实际能跑多少带宽。链路Active只代表物理层通了，协议层、驱动层的开销可能让实际带宽远低于理论值。要验证真实性能，必须跑带宽测试。

NVIDIA官方有个工具叫nvbandwidth，专门测GPU间带宽，支持NVLink和PCIe。另一个选择是自己写CUDA程序做P2P测试。我一般两个都跑，官方工具看整体，自定义程序看细节。

4.2 nvbandwidth的编译与使用

nvbandwidth需要从源码编译，依赖CUDA和CMake：

git clone https://github.com/NVIDIA/nvbandwidth.git cd nvbandwidth mkdir build && cd build cmake .. make -j$(nproc)

编译完会生成nvbandwidth可执行文件。跑全量测试：

./nvbandwidth -t device_to_device_memcpy_read_ce

这个测试测的是设备间内存拷贝的读带宽。A100 NVLink 3.0单链路理论50GB/s，12链路600GB/s，实际跑下来单向能到400GB/s以上就算正常。如果只有几十GB/s，那基本是走PCIe了。

nvbandwidth还支持指定GPU对：

./nvbandwidth -t device_to_device_memcpy_read_ce -d 0 -d 1

只测0号和1号卡之间的带宽，方便定位问题。

4.3 自定义P2P带宽测试

官方工具够用，但有时候我想看更细的指标，比如延迟和双向带宽，就自己写。核心是用cudaMemcpyPeer或者cudaMemcpyPeerAsync做P2P拷贝，计时算带宽：

// 简化版P2P带宽测试核心逻辑 cudaSetDevice(0); float* d_a; cudaMalloc(&d_a, size); cudaSetDevice(1); float* d_b; cudaMalloc(&d_b, size); // 启用P2P int canAccess; cudaDeviceCanAccessPeer(&canAccess, 0, 1); if (canAccess) { cudaSetDevice(0); cudaDeviceEnablePeerAccess(1, 0); } // 计时拷贝 cudaEvent_t start, stop; cudaEventCreate(&start); cudaEventCreate(&stop); cudaEventRecord(start); for (int i = 0; i < iters; i++) { cudaMemcpyPeer(d_b, 1, d_a, 0, size); } cudaEventRecord(stop); cudaEventSynchronize(stop); float ms; cudaEventElapsedTime(&ms, start, stop); double bw = (double)size * iters / (ms / 1000.0) / 1e9; printf("Bandwidth: %.2f GB/s\n", bw);

编译的时候记得加-lcudart。跑之前确认cudaDeviceCanAccessPeer返回1，返回0说明P2P没启用，NVLink白搭。

4.4 带宽数据怎么解读

A100 NVLink 3.0的实测数据参考：

实测值低于理论值是正常的，协议开销、ECC、时钟同步都会吃掉一部分。但如果只有理论值的十分之一，那肯定是走PCIe了，回去查topo和fabricmanager。

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

5.1 fabricmanager起不来怎么办

症状：systemctl status nvidia-fabricmanager显示failed，日志报"Failed to initialize NVML"或者"version mismatch"。

排查顺序：第一，确认驱动版本和fabricmanager版本号完全一致，nvidia-smi里的Driver Version和dpkg -l | grep fabricmanager的版本要对上。第二，确认nvidia-persistenced在跑，fabricmanager依赖它。第三，确认/dev/nvidiactl存在且权限正确。

# 检查persistenced systemctl status nvidia-persistenced # 检查设备节点权限 ls -l /dev/nvidiactl

5.2 topo显示NVLink但带宽上不去

这种情况最迷惑。topo显示NV12，但实测带宽只有PCIe水平。原因通常是P2P没启用。CUDA默认不开启P2P，需要显式调用cudaDeviceEnablePeerAccess。另外，如果用了MIG（Multi-Instance GPU），NVLink在MIG实例间是不通的，得关掉MIG再测。

# 检查MIG状态 nvidia-smi -i 0 --query-gpu=mig.mode.current --format=csv # 如果开了MIG，关掉 sudo nvidia-smi -i 0 -mig 0

5.3 重启后NVLink失效

有时候重启后fabricmanager没自动起来，或者起来了但topo变了。检查systemctl is-enabled nvidia-fabricmanager，确保是enabled。另外，如果BIOS里PCIe拓扑在重启后重置了，topo也会变。我一般把BIOS配置保存成profile，重启后确认一下。

5.4 常见问题速查表

5.5 几个独家避坑技巧

第一，装驱动之前先记录当前的nvidia-smi topo -m输出，装完对比，能快速定位是不是驱动导致的拓扑变化。

第二，fabricmanager的日志级别可以调，在/etc/nvidia/fabricmanager.cfg里把LOG_LEVEL改成INFO或DEBUG，排查问题时信息更全。

第三，带宽测试要跑多次取稳定值，第一次跑往往偏慢，因为GPU还在降频状态。跑之前先用nvidia-smi -lgc锁频，或者跑个热身kernel。

第四，如果是容器环境，fabricmanager要在宿主机跑，容器里只需要挂载/dev/nvidia*设备节点。容器里跑fabricmanager是跑不起来的。

第五，A100的NVLink桥接方案（两张卡用桥连）和板载NVSwitch方案在配置上略有不同，桥接方案对fabricmanager的依赖没那么强，但topo识别更容易出问题，建议优先用板载方案。

6. 性能调优与长期维护建议

6.1 锁频与功耗管理

A100默认会根据负载动态调频，带宽测试时如果GPU降频，测出来的数会偏低。做基准测试前建议锁频：

# 查看支持的频率 nvidia-smi -q -d SUPPORTED_CLOCKS # 锁定频率（示例） sudo nvidia-smi -lgc 1200

测完再解锁：sudo nvidia-smi -rgc。生产环境不建议长期锁频，功耗和散热压力大。

6.2 监控NVLink健康状态

长期运行的机器，NVLink链路可能因为温度、振动出现偶发错误。建议定期检查：

# 查看NVLink错误计数 nvidia-smi nvlink -e # 查看链路状态 nvidia-smi nvlink -s

错误计数持续增长说明链路有问题，可能需要重新插拔桥接或者检查散热。我一般写个cron脚本，每天记录一次错误计数，超过阈值就告警。

6.3 驱动升级的注意事项

升级驱动时，fabricmanager必须同步升级，版本号严格对应。升级顺序是先停fabricmanager，再卸旧驱动，装新驱动，装新fabricmanager，重启。不要在线升级，容易出玄学问题。

sudo systemctl stop nvidia-fabricmanager sudo apt remove nvidia-driver-550 nvidia-fabricmanager-550 sudo apt install nvidia-driver-560 nvidia-fabricmanager-560 sudo reboot

6.4 容器环境下的NVLink配置

如果用Docker跑训练任务，需要装nvidia-container-toolkit，并且启动容器时加--gpus all。NVLink在容器里是透传的，只要宿主机topo正常，容器里就能用。但要注意，容器里跑nvidia-smi topo -m看到的拓扑和宿主机一致，如果宿主机topo不对，容器里也不对。

# 安装nvidia-container-toolkit sudo apt install nvidia-container-toolkit sudo systemctl restart docker # 启动容器 docker run --gpus all -it nvidia/cuda:12.0-base nvidia-smi topo -m

6.5 我个人的经验体会

折腾NVLink这几年，最大的感受是：硬件没问题的情况下，90%的故障出在软件配置上，而软件配置里80%出在版本匹配上。驱动、fabricmanager、CUDA、容器运行时，这四个东西的版本要形成一个兼容的闭环，任何一个跳版本都可能出问题。我的做法是，选定一个长期支持分支（比如550），所有组件都用这个分支的版本，不追新，不混用。

另一个体会是，topo输出是判断NVLink是否生效的唯一可信依据，nvidia-smi nvlink -s显示Active不代表实际通信走NVLink。每次配置完，必须跑topo和带宽测试双重确认，缺一不可。

最后分享一个小技巧：如果手头没有nvbandwidth，可以用nvidia-smi nvlink -c看链路能力，再用nvidia-smi nvlink -gt d看链路吞吐的实时数据，虽然不如专业工具精确，但能快速判断链路是否在工作。这个命令在排查偶发问题时特别有用，能看到实时流量。