RHEL 8上DGX服务器深度学习环境搭建与训练调优实践

说实话，当某实验室的A同学跟我说，他们准备把刚到的 DGX 服务器刷成 RHEL 8，用来做大规模深度学习模型训练时，我的第一反应是"这组合有点折腾，但确实值得"。

原因很简单：DGX 这类一体机出厂预装的基本不是 Red Hat 系系统，而不少企业又要求统一使用企业级 Linux 发行版来满足合规与运维管理；另一方面，DGX 的多卡 NVLink 全互联、超大显存、高带宽网卡这套硬件，如果只是装上驱动跑单卡训练，那纯属浪费。写这篇文章，就是想把我这一路踩过的坑、验证过的做法完整拆开：从 RHEL 8 的系统初始化、NVIDIA 驱动与容器运行时，到混合精度、数据管道、多卡多机分布式训练的参数调优，再到性能监控和故障排查。适合正在做 CV、NLP、多模态大规模模型训练的工程师参考，也适合想把手上的 DGX 真正用满的同学。

1. 认识 DGX 与 RHEL 8 的组合：这问题解决什么

1.1 DGX 的硬件底子：不是多插几块 GPU 那么简单

很多人会把 DGX 理解成"一台插了 8 张卡的高配服务器"，这个理解太浅了。以 DGX 常见的 A100 配置为例，单机通常是 8 块 A100 80GB GPU，每块 GPU 的显存带宽接近 2TB/s，显存总量 640GB；更重要的是，8 块 GPU 之间通过 NVSwitch 实现 NVLink 全互联，通信带宽达到 600GB/s。这个数字意味着什么？普通服务器用 PCIe 4.0 x16 连接 GPU，双向带宽大概只有 64GB/s 上下，NVLink 几乎是它的 10 倍。也就是说，模型并行的通信开销、数据并行时的梯度同步开销，在 DGX 上都会被压缩到一个非常低的水平。

DGX 的 CPU 和内存配置也不弱，双路 AMD EPYC、1TB 系统内存、NVMe RAID、以及可选的 InfiniBand 高速网卡，这些不是堆料，而是为了让"数据供给"和"跨机通信"这两条链路不吃亏。训练时最容易出现的两个隐性瓶颈，一个是 GPU 在等数据，另一个是 GPU 在等别的 GPU，DGX 的整机设计针对的就是这两个问题。

所以，给 DGX 做环境配置，第一原则是：不要把它当普通 GPU 服务器用。所有配置决策都要围绕"如何让多卡通信带宽发挥出来、如何让显存和算力不被数据加载拖累"来展开。

1.2 RHEL 8 在训练集群里的定位

为什么要在 AI 服务器上用 RHEL 8，而不是更省事的 Ubuntu？这话题在社区里争论很多。单纯从"装驱动方便"这个角度，Ubuntu 确实占优，很多 NVIDIA 官方文档都默认 Ubuntu。但落到企业环境里，RHEL 8 有长期支持周期、系统级安全加固、SELinux、集中订阅管理，很多重资产组织和政企客户的安全基线就是红帽系。既然平台合规要求绕不开，那就必须在 RHEL 8 上把 AI 训练链路打通。

RHEL 8 本身不是为 AI 优化的操作系统，但它的内核稳定、包管理成熟、生态兼容性好。只要驱动、容器运行时和训练框架装对了，生产环境下的稳定性反而不错，尤其适合跑那种一训就是好几天的任务，不会因为某个驱动小版本更新导致重启后起不来。

需要提醒的是：RHEL 8 的内核、C 库和默认工具链跟 Ubuntu 有差异，很多"从网上抄来的安装命令"不能直接在 RHEL 8 上跑。例如，Ubuntu 上常见的apt驱动安装方式完全不适用，必须走 RPM 仓库；RHEL 8 默认的容器方案是 Podman，而分布式训练场景下大家更习惯 Docker。这些差异会在后面逐一说清楚。

1.3 一个常见误解：DGX 是不是必须用 Ubuntu

NVIDIA 官方为 DGX 预装的是 Ubuntu 系统，这没错，但硬件层面没有任何限制说不允许你改装其他发行版。DGX 的固件、BIOS 和 GPU 管理逻辑与操作系统无关，只要内核能识别硬件、驱动能正常加载，RHEL 8 完全可以用。

真正的问题是，改装系统时容易栽在几个细节上。第一个是 Secure Boot，如果 BIOS 里开着 UEFI Secure Boot，RHEL 8 默认的内核模块签名机制与 NVIDIA 第三方驱动模块不匹配，会导致驱动加载失败；第二个是fabricmanager，DGX 的 NVSwitch 需要单独的守护进程管理，否则 NVLink 通信速率达不到预期；第三个是仓库选择，NVIDIA 官方为 RHEL 8 提供独立的 CUDA 和驱动仓库，不能用其他系统的包硬装。这些问题后面会逐一给方案。

2. 环境搭建：驱动、CUDA、容器运行时一次到位

2.1 系统安装后的第一件事：对齐内核与固件

在 RHEL 8 最小化安装完成后，我习惯先做三件事：更新系统、确认内核版本、检查 BIOS 设置。

dnf update -y uname -r

为什么要先确认内核版本？因为 NVIDIA 驱动是以内核模块方式加载的，RHEL 8 内核包更新之后，必须保证kernel-devel和kernel-headers与当前内核版本完全一致，否则驱动编译会报错。不同版本的内核对应不同的模块路径，乱装包很容易出现"驱动装上了但模块加载失败"的尴尬局面。

检查内核版本后，安装基础编译工具：

dnf install -y gcc make dkms kernel-devel kernel-headers

dkms是个省心工具，它会在内核更新后自动重新编译第三方模块，减少"升级内核把驱动弄丢"的概率。实际生产环境里，我一般建议把内核版本锁在某个稳定的 patch 上，等明确测试过新内核没问题再统一升级，而不是随系统 update 自动拉新。

BIOS 方面，如果条件允许，建议先关闭 Secure Boot 或准备好 MOK 签名流程，然后在 BIOS 里确认 Above 4G Decoding、Resizable BAR 这些和 PCIe DMA 相关的选项是开启的。DGX 的 BIOS 默认配置通常没问题，但只要你拔插过 GPU、升级过固件，就值得再对一遍。

2.2 安装 NVIDIA 驱动与 CUDA 工具链

RHEL 8 上安装 NVIDIA 驱动，我推荐直接使用 NVIDIA 官方仓库，把仓库文件放到/etc/yum.repos.d/下，然后安装nvidia-driver包。不要从 NVIDIA 官网下载一个.run安装脚本去跑，因为 DGX 上有多个 GPU、NVLink 和底层固件需要和驱动配合，用 rpm 包管理方式能保证版本一致和卸载干净。

安装驱动之后，紧接着安装 CUDA 工具链。这里要严格区分两个东西：nvidia-driver负责让 GPU 工作起来，cuda-toolkit提供nvcc、CUDA 运行时库和头文件。训练框架大多使用容器镜像里自带的 CUDA，但宿主机上保留一份匹配的 toolkit 仍然有用，出问题排查时可以直接编译小的测试程序。

验证命令：

nvidia-smi nvcc --version

nvidia-smi能看到 GPU 数量、驱动版本和显存占用，是最基本的健康检查。nvcc --version确认 CUDA 编译器版本，注意它和驱动版本不一定完全一致，只要满足框架要求的 CUDA major 版本即可。

DGX 上还有一个容易被忽略的步骤：启动 NVLink Fabric Manager。对 A100 这类通过 NVSwitch 互联的机型，需要安装并运行nvidia-fabricmanager，否则 NVLink 链路可能只以降级模式工作，表现为多卡通信速率远低于预期。

systemctl enable --now nvidia-fabricmanager

装完驱动后看nvidia-smi -q -d NVLink，检查每条链路的状态是否正常。这一步在普通多卡服务器上不存在，但在 DGX 上是必须项，很多人改装系统后多卡训练变慢，最后发现就是没启动 fabricmanager。

2.3 容器运行时环境：Docker 与 NVIDIA Container Toolkit

为什么要在 RHEL 8 上坚持用容器？因为深度学习训练框架的编译链路太复杂，CUDA、cuDNN、NCCL、PyTorch/TensorFlow 之间的版本组合非常敏感。自己从源码编译不是不行，但会耗费大量时间，而且很难保证每台机器环境完全一致。用容器可以把"环境一致性"问题直接消掉。

RHEL 8 默认安装的容器工具是 Podman，但考虑到后续训练脚本、分布式通信和运维习惯，我更建议直接装 Docker CE。安装方式就是把 Docker 官方仓库挂进去，然后：

dnf install -y docker-ce docker-ce-cli containerd.io systemctl enable --now docker

接下来安装 NVIDIA Container Toolkit，这一步是打通"容器内使用 GPU"的关键：

dnf install -y nvidia-container-toolkit nvidia-ctk runtime configure --runtime=docker systemctl restart docker

配置完成之后，可以通过一个简单的容器测试：

docker run --rm --gpus all <某个nvidia镜像> nvidia-smi

里面能看到宿主机上的所有 GPU，说明容器运行时已经成功把 NVIDIA 设备透传进去。如果这一步失败，问题通常出在daemon.json的 runtime 配置，或者 SELinux 拦了挂载。

这里特别提醒一下 RHEL 8 上的 SELinux。SELinux 在 enforcing 模式下会对容器挂载目录做安全上下文检查，实际表现就是"目录明明有权限，但容器里读不了"。如果遇到这种情况，不要直接setenforce 0，而是针对数据目录设置正确的上下文：

chcon -Rt container_file_t /data

或者针对 NFS 等共享存储场景，打开需要的布尔值开关。这样能保留 RHEL 的安全能力，又能让容器正常访问训练数据。

2.4 用 NGC 容器把训练环境标准化

驱动和容器运行时搞定之后，训练框架本身我建议直接拉 NVIDIA NGC 容器镜像，例如 PyTorch 的官方容器。NGC 容器里已经预装了与 CUDA 版本匹配的 PyTorch、NCCL、cuDNN、Horovod 等组件，还带了一些 NVIDIA 的 profiling 工具，比如nsys和ncu，这比自己在裸系统上拼装环境靠谱得多。

实际操作时，先登录容器仓库：

docker login nvcr.io

登录之后根据自己的框架偏好选择镜像 tag。我之前用的是 PyTorch 1.13 到 2.x 的 NGC 容器，版本更迭到这里之后，torch.amp、torch.compile等接口都更稳定了，NCCL 的版本与 DGX 的 InfiniBand/网络驱动也更匹配。

启动训练容器的通用命令：

docker run -it --rm \ --gpus all \ --ipc=host \ --ulimit memlock=-1 \ --ulimit stack=67108864 \ -v /data:/data \ -v /code:/code \ <镜像名> bash

--ipc=host和 memlock 参数不是随意加的，多进程 DataLoader 和 NCCL 在容器里会用到共享内存和锁，默认限制太小容易导致连接失败。

3. 训练提速核心：数据管道、混合精度与分布式参数

3.1 数据加载：先把 GPU 喂饱，再谈模型

训练速度上不去，很多情况下不是因为 GPU 算力不够，而是 GPU 一直在等数据。这个问题在 DGX 上尤其明显，因为 GPU 计算太快，数据供给稍有波动就会被放大。

一个典型的失败案例：数据集放在 NFS 共享盘，DataLoader 默认用 2 个 worker，训练起来 GPU 利用率在 30% 到 90% 之间剧烈抖动，训练速度远低于预期。排查时通过nvidia-smi看，GPU 利用率并不是恒定的 100%，并且 CPU 进程占用很高。解决方式包括三部分。

第一，数据先落到本地 NVMe。DGX 自带的 NVMe 阵列读写速度非常快，训练前把原始数据集拷贝到本地，或者做一层本地缓存，能极大减少随机读的延迟。如果数据集太大无法全部放本地，至少要保证每个 epoch 读取的数据尽量连续，避免频繁网络往返。

第二，把 DataLoader 的参数调整到位。以 PyTorch 为例：

from torch.utils.data import DataLoader loader = DataLoader( dataset, batch_size=64, num_workers=8, pin_memory=True, prefetch_factor=4, persistent_workers=True, shuffle=True, )

num_workers并不是越大越好。worker 太多会带来 CPU 上下文切换和内存拷贝开销，一般每个 GPU 配 4 到 8 个 worker 就够，具体要以训练吞吐为准。pin_memory=True让 CPU 端的数据在锁页内存里，这样 GPU 拷贝更快；prefetch_factor=4让多个 batch 提前加载，掩盖 CPU 预处理和 GPU 计算之间的空隙；persistent_workers=True避免每个 epoch 结束都重新创建 worker 进程。

第三，检查 CPU 端的预处理逻辑。大量实时数据增强、解码、归一化如果全放在 CPU 端，很容易成为瓶颈。建议把能提前做的预处理全部提前做，存成内存映射格式或 TFRecord 类似格式，训练时就只做轻量操作。一个常用的做法是先把数据打包成mmap或lmdb，把随机读延迟降到极低，再配合足够多 worker，GPU 利用率就能稳定下来。

3.2 混合精度训练：让 Tensor Core 真正跑起来

很多人在 RHEL 8 上装了驱动之后，就用默认的 FP32 精度开始训练，这等于白白浪费了 A100 的 Tensor Core 算力。A100 的矩阵乘算力在 FP16/BF16 下比 FP32 高出一个量级，混合精度训练是必须开的基础优化。

PyTorch 2.x 里推荐使用torch.amp。以 FP16 为例：

from torch.amp import autocast, GradScaler model = model.cuda() optimizer = torch.optim.AdamW(model.parameters(), lr=1e-4) scaler = GradScaler() for batch in loader: x, y = batch x, y = x.cuda(), y.cuda() optimizer.zero_grad() with autocast(device_type="cuda", dtype=torch.float16): pred = model(x) loss = loss_fn(pred, y) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

FP16 的一个问题是数值范围较窄，容易梯度下溢，所以要用GradScaler在反向传播前把 loss 放大，更新权重前再缩回去。如果是 A100 这类支持 BF16 的 GPU，可以改用torch.bfloat16：

with autocast(device_type="cuda", dtype=torch.bfloat16): pred = model(x) loss = loss_fn(pred, y)

BF16 在很大范围内保持和 FP32 接近的数值稳定性，通常不需要GradScaler，所以很多大规模训练任务直接选 BF16。需要注意的是，不是所有算子都适合在低精度下跑，比如某些归一化层或者涉及数值稳定的自定义算子，autocast会自动让它们跑在 FP32。如果你在模型里写了不少自定义 CUDA 算子，请看下它的输入输出是否兼容低精度。

混合精度带来的收益很直接：显存占用降低，训练吞吐提高。以我在一个 7B 参数级模型上的实测为例，从 FP32 切到 BF16 后，单卡能装下的 batch size 翻倍，整体训练吞吐提升接近两倍。这个优化几乎零成本，应该第一个做。

3.3 多卡与多机训练：NCCL 和集合通信调优

DGX 的价值体现在多卡和多机协同。单机 8 卡用 PyTorch DDP 是最常见的方式。通过torchrun启动：

torchrun \ --nnodes=1 \ --nproc_per_node=8 \ --master_port=29500 \ train.py

在脚本里，用torch.distributed.init_process_group(backend="nccl")初始化，然后用DistributedDataParallel包装模型。关键点在于，DDP 每一次迭代结束都要做一次梯度同步，这个同步耗时直接由 GPU 之间的通信速度决定。DGX 单机内部 NVLink 通信很快，所以单机 8 卡时梯度同步通常不是瓶颈；但如果数据加载没做好，通信再怎么快也会被 CPU 预处理时间拖住。

多机训练时，通信链路变得非常关键。DGX 通常配有 InfiniBand 高速网卡，这是为多机 NCCL 通信准备的。启动方式要在主节点指定地址：

torchrun \ --nnodes=2 \ --nproc_per_node=8 \ --node_rank=0 \ --master_addr=主节点IP \ --master_port=29500 \ train.py

另一个节点把node_rank换成 1，命令其余部分相同。

这时候需要设置 NCCL 环境变量，否则 NCCL 可能选错通信网卡。我踩过最典型的一个坑是：多机训练时 NCCL 默认选了管理网口，带宽就只有千兆，训练速度比单机还慢。正确做法是指定业务网卡：

export NCCL_SOCKET_IFNAME=ib0,ib1 export NCCL_IB_HCA=ib0,ib1 export NCCL_DEBUG=INFO

NCCL_DEBUG=INFO在初次调试时非常有用，启动日志里会打印使用的网卡、端口和带宽。如果看到通信集中在非预期网卡，就说明环境变量设置有问题。排查无误后，正式训练时把NCCL_DEBUG关掉，避免日志刷屏拖慢整体速度。

多机训练的网络层还有不少细节可调，比如NCCL_TIMEOUT。默认值在节点较多、网络波动的情况下偶尔会因为握手超时而报错，适当调大，例如：

export NCCL_TIMEOUT=1800

能减少集群偶发中断。

3.4 批大小、学习率、梯度累积怎么配合

分布式训练中一个常见的误区是：为了提升 GPU 利用率，把 global batch size 憋得特别大，却不调整学习率，最后 loss 曲线疯涨或震荡。这里有两个经验规律。

第一个是线性缩放规则：如果 batch size 从 256 变成 1024，相当于梯度估计的方差变小了，学习率也可以近似放大 4 倍。公式写出来就是：

new_lr = old_lr * (new_batch_size / old_batch_size)

第二个是 warmup。学习率放大之后，训练初期的参数离最优解较远，梯度更新不够稳定，需要先从一个较小的学习率慢慢升到目标值。Transformer 类模型尤其敏感，我在实践中一般配 2000 到 4000 步的 warmup，配合 cosine 衰减。

如果单卡显存放不下目标 batch，可以用梯度累积来"模拟"更大的 batch：

accum_steps = 4 optimizer.zero_grad() for step, (x, y) in enumerate(loader): loss = loss_fn(model(x), y) / accum_steps loss.backward() if (step + 1) % accum_steps == 0: optimizer.step() optimizer.zero_grad()

梯度累积的核心是把多个小 batch 的梯度累加后再更新，等效于扩大了 batch size，但显存占用不变。需要注意，BatchNorm 层的统计量在小 batch 下会不准，如果模型里用了 BatchNorm，建议开启同步 BN：

model = torch.nn.SyncBatchNorm.convert_sync_batchnorm(model)

这样 BN 的统计量会在所有 GPU 之间同步，效果更接近大 batch 训练。

3.5 训练脚本层面的其他提速细节

除了数据、精度、分布式参数，训练脚本本身还有几个容易被忽略的点。

第一，checkpoint 保存一定要克制。如果每个 epoch 都保存一份完整的模型文件，而模型有好几十 GB，则磁盘写入耗时会占掉可观的有效训练时间。常规做法是只保留历史最优和最新两份，并用独立线程或进程异步写盘。分布式训练时，只在 rank 0 上做保存，其他 rank 不重复写。

第二，避免在每个 step 里调用torch.cuda.synchronize()。它会把 GPU 的异步执行变成同步执行，强制等待所有kernel结束，严重打断流水线。很多人在调试时习惯加一句 synchronize 看显存，正式训练前一定要删掉。

第三，用 profiling 工具定位热点。NGC 容器里通常自带 Nsight Systems，nsys profile能抓出每一步在 CPU、GPU 和通信上的耗时分布，能看到是数据加载、kernel 计算还是 NCCL 通信占了主要时间。先 profiling 再优化，远比自己盲调参数有效。

4. 性能监控与故障排查：让训练瓶颈现出原形

4.1 别被 nvidia-smi 骗了：真正的忙闲看什么

很多人打开nvidia-smi，看到Util%是 100% 就觉得 GPU 完全跑满了，这是一个常见误区。nvidia-smi的利用率只表示"采样周期内是否有 kernel 在 GPU 上执行"，不表示 GPU 的计算资源真的处于饱和状态。一个 kernel 可能只用了很少的 SM 单元，但它的存在就能让利用率显示为 100%。

因此，监控时除了看利用率，更要看功耗、显存带宽、温度和时钟频率。命令：

nvidia-smi dmon -s pucmet

这个命令会持续输出 GPU 的功耗、显存利用、温度等指标。如果利用率高但功耗明显低于 TDP，大概率是 kernel 太小或者访存密集，没有真正打满算力。

在 DGX 上更推荐用 NVIDIA 官方 DCGM 工具：

dcgmi dmon -e 1001,1004,1007,1009

它能采集到更细粒度的 GPU 状态，比如 Tensor Core 利用率、NVLink 带宽、SM 占用率。通过这个数据，才能判断瓶颈到底是在计算、显存还是通信。

4.2 高频问题排查速查表

整理一份我在 RHEL 8 + DGX 环境下经常遇到的问题列表，按现象、原因和解决方式排列。

这里单说一下 CUDA OOM 的处理思路。遇到 OOM，不是简单调小 batch 一个问题。混合精度是最优先的，其次是梯度累积或 gradient checkpointing，再次是 ZeRO/FSDP 把优化器状态和梯度分片。RHEL 8 上这些技术改造和 Ubuntu 上没有区别，关键是要有顺序：先低成本，再高成本。

4.3 一次完整的瓶颈定位过程

讲一个实际案例。某次训练一个 Transformer 类模型，8 卡 DGX A100，NCCL 单机模式，训练吞吐只有预期的一半。nvidia-smi显示各卡利用率忽高忽低，功耗也没拉满。直觉告诉我大概率是数据加载。

首先跑一次短 profile：

nsys profile --trace=cuda,nvtx,osrt -o train_profile python train.py

生成报告后，用 Nsight Systems 打开，很明显看到每个 step 里 GPU kernel 执行结束到下一个 kernel 开始之间存在大段空白，而这些空白对应的 CPU 侧都在等地板数据。这就解释了功耗上不去的原因。

针对这个现象，我把 DataLoader 的num_workers从 2 提到 8，prefetch_factor设置成 4，数据集按样本做预取缓存。再跑一轮，GPU 功耗和吞吐都有明显改善。随后继续 profile，发现 kernel 执行时间已经连续，但整体吞吐仍在缓慢下降。进一步查发现是 CPU 端数据预处理里有部分计算没打满多核，继续把它优化掉之后，训练吞吐才真正稳定下来。

整个过程不难，但如果不做 profiling，很容易盲目调大batch_size或者换更复杂的模型并行策略，浪费大量时间。先定位瓶颈再动手，是训练性能优化最核心的工作习惯。

4.4 监控面板与长期稳定性

训练任务跑起来之后，不能看一眼吞吐就撒手不管。长时间训练最容易出现的问题是节点过热降频、NCCL 通信退化、磁盘写入耗尽空间。建议部署一个简单的监控脚本，定期采集dcgmi和系统负载数据，并设置告警。RHEL 8 本身自带sysstat、cockpit等工具，结合 DCGM 基本够用。

还要注意日志轮转。训练脚本和容器日志如果无限增长，很快会把 NVMe 空间占满。我遇到过训练到第三天因为/var/lib/docker被日志撑爆而整体挂掉的惨痛经历，之后都会在启动命令里把日志落到专门目录并加 logrotate 策略。

写在最后

以前我也觉得训练优化是模型侧的事，等真正在 RHEL 8 上把一台 DGX 从头开始配置完才发现，系统环境短腿一点，后面的性能优化全部白搭。尤其是 NVSwitch 的 fabricmanager、SELinux 和容器 runtime 这几个坎，都是文档里不显眼却要命的地方。

个人体会是：不要盲目照搬网上装机的命令，先弄清楚每一步在干什么；不要一上来就分布式、模型并行，先用 profiling 看到瓶颈，再针对性做优化。这套基本功补上之后，在 RHEL 8 上用 DGX 训练大规模模型，速度与效率的提升不是靠运气，而是靠一条条可验证、可复用的配置实践。