nanami

1.1 Tensor Core 是初始化阶段的限制#

gpu-unlock-ada 并不是传统意义上的超频。它通过预先生成的 AD102 固件资产和 gpu_unlock.ko，在 NVIDIA 驱动接管 GPU 之前完成特定速率配置。正确的逻辑顺序是：

1
冷启动 → initramfs 内 gpu_unlock + AD102 资产
2
      → NVIDIA Open Kernel Modules → CUDA / cuBLAS / NCCL

普通系统运行后再加载模块，不等价于在 GPU 固件初始化前介入。固件资产的取得和再分发必须遵守上游项目与原始许可证。

1.2 P2P 是 GPU 显存映射与驱动能力问题#

RTX 4090 没有 NVLink。原始驱动即使枚举了四张卡，nvidia-smi topo -p2p r/w 仍可能全部显示 GNS。P2P 驱动补丁修改 NVIDIA Open 模块的 GPU peer mapping 支持；参考 作者关于 4090 48GB、动态 BAR1 的技术文章。

BAR1 是 PCIe MMIO 可映射窗口，不是额外显存。GPU 自身报告 ReBAR 最高支持 32GB，并不代表 BIOS 当时实际给它分配了 32GB。本次初始 current size 只有 256MB。

1.3 从 CPU 到 GPU：为什么 NUMA 位置决定通信上限？#

消费级 GPU 之间的 P2P 并不是虚拟的“GPU 私有高速总线”。它仍需走 GPU PCIe Endpoint → Root Port/PCIe Bridge → 对端 GPU 的物理路径。如果两卡落在不同 CPU Socket 的 Root Complex 后面，数据还会涉及处理器之间的互连；启用 P2P 能减少主机内存中转，但不能消除硬件跳数。

在我们的机器上，GPU0/1 和 GPU2/3 是两个相对接近的组合；GPU0→GPU2 属于跨 NUMA 通路。这一硬件结构解释了后面为什么同 NUMA 单向复制达到约 21 GiB/s，而部分跨 NUMA 方向约为 16–17 GiB/s。这里的图是拓扑示意而非真实机器的 PCI BDF/布线图。

1.4 为什么必须由两个独立机制组合？#

Tensor Unlock 发生在 NVIDIA 驱动加载之前，目的是更改特定运算速率配置；P2P 补丁则是 NVIDIA Open Kernel Modules 层的 peer mapping 能力。二者在不同层面工作，既不能互相代替，也不意味着理论加速比可以相乘。

这也是我们先用一张卡验证 Tensor，再在克隆镜像中升级 NVIDIA 615 和 P2P、最后检查 GPU 间 NCCL 的原因。按阶段验收能把“启动失败”“GPU 数值错误”“通信错误”定位到不同层。

3.1 驱动版本必须匹配#

目标分支为 615.71.09-p2p-48g。原环境的 610.57.04 用户态驱动不能直接混装 615 的内核模块。第二个 Warewulf 镜像从已通过 Tensor 验证的镜像复制，保留可回滚的旧镜像。

Fedora 44 的 NVIDIA 仓库提供 615.71.09 的用户态组件与 Open DKMS 包。先用精确版本做 dnf install --assumeno 事务预演，再安装同版的 nvidia-driver-common、nvidia-driver-cuda、nvidia-driver-cuda-libs、nvidia-kmod-common、kmod-nvidia-open-dkms、nvidia-modprobe、nvidia-persistenced。

这里曾踩过一个关键依赖坑：预演时为了避免官方 DKMS 覆盖补丁，排除了 kmod-nvidia-open-dkms，却使 nvidia-kmod-common 所需的 nvidia-kmod = 615.71.09 依赖缺失。解决方法是先完整升级官方 615.71.09 包组，再单独构建补丁模块。

另一个细节：RPM 安装成功后 dkms status 显示 nvidia/615.71.09: added，但 modinfo 查询不到 NVIDIA 模块。added 只是已注册源码，并不是已构建并安装。

3.2 在 Fedora 44 内核开发环境构建#

home 类型的管理端即使有网，也不能使用管理端 Rocky 内核头文件替 Fedora 44 编译模块。源代码先从管理端只读 bind 到镜像，再复制到镜像本地构建：

1
git clone https://github.com/Duanyll/open-gpu-kernel-modules.git
2
cd open-gpu-kernel-modules
3
git switch 615.71.09-p2p-48g
4
git rev-parse HEAD
5
cat version.mk
6

7
# 以下 make 在 Fedora 44 构建镜像内进行
8
KVER=6.19.10-300.fc44.x86_64
9
make -j16 modules SYSSRC="/usr/src/kernels/$KVER" SYSOUT="/usr/src/kernels/$KVER"

生成并核实版本的模块有：

1
nvidia.ko
2
nvidia-modeset.ko
3
nvidia-uvm.ko
4
nvidia-drm.ko
5
nvidia-peermem.ko

五个模块的 modinfo version 都是 615.71.09，vermagic 均匹配 6.19.10-300.fc44.x86_64。编译中存在 objtool 的 naked return 警告及缺少 vmlinux 导致的 BTF 生成跳过，但链接成功；是否运行正确仍以后续 GPU 实测为准。

本次首次验证把这些补丁模块安装到独立镜像的 /lib/modules/<KVER>/updates/dkms/，执行 depmod -a "$KVER"，再用 modinfo -k "$KVER" -F filename nvidia 验证最终模块优先路径。重新生成包含 wwinit 与 gpu_unlock 的 dracut initramfs，随后 wwctl image build，最后只切换两台已排空的节点。

不能忽视的运维技术债：P2P 模块最初是手工放入 updates/dkms，而官方 nvidia/615.71.09 DKMS 源码注册项可能仍存在。将来执行 dkms autoinstall 或升级驱动会有覆盖补丁的风险。真正长期维护应封装成版本固定、可重建的补丁 DKMS/RPM，而不是永久依赖一次性手工覆盖。

4.1 BAR1 扩容不是显存扩容#

CPU 可通过 PCIe MMIO 窗口访问 GPU 的部分设备/显存地址空间。BAR1 资源的“size”表示主机为这个 PCIe BAR 分配的地址窗口容量，而不是 GPU 搭载了多少显存。大 BAR1 对静态映射覆盖整卡显存非常关键，但它也占用平台的 PCIe MMIO 地址空间；四卡同时选择 32GiB BAR1，理论上需要约 128GiB 的窗口地址资源（还未计入其他 BAR）。

动态 BAR1 映射并非简单“开了 ReBAR 就变成动态”：它还依赖相应的驱动映射策略。我们这里的卡是标准 24GB，而原始研究重点包括 48GB 改装卡。24GB 容量小于已分配的 32GiB 窗口，因此不能仅凭本次结果证明 48GB 场景下的动态窗口回收算法已被充分验证。本文只声称本次 24GB 环境的 peer copy / NCCL 结果。

4.2 从能力位到实际映射有三层检查#

1. §lspci -vv§ 的 Resizable BAR supported sizes：GPU 宣称支持哪些窗口。
2. §lspci -vv§ 的 current size 与 §nvidia-smi -q§ 的 BAR1 Total：平台实际上分配了多少。
3. §nvidia-smi topo -p2p§、CUDA Peer Access 与数据一致性：驱动和上层运行时是否真正可用。

即便第三层返回 OK，也仍需要验证集合通信的数值和性能。

两台机器的 GPU 都报告 Physical Resizable BAR 支持 BAR1 最大 32GB；但刚开始 lspci -vv 的 current size 只有 256MB。

维护窗口使用带外控制台检查主板 BIOS/UEFI：

我们将节点内核 IOMMU 默认域切为 passthrough，实际日志为：

1
iommu: Default domain type: Passthrough (set via kernel command line)

安全提醒：iommu=pt 改变 DMA 隔离语义，不应不加评估地应用在多租户/不可信 PCIe 设备环境。也不要为“让拓扑好看”盲目设置 pcie_acs_override，它不会改变物理 PCIe 路径。

冷启动后，每张卡的 nvidia-smi -q 均显示 BAR1 Total: 32768 MiB，nvidia-smi topo -p2p r、w 中 12 个非对角有向卡对全部为 OK。这是能力枚举成功，尚需 CUDA 与 NCCL 数据验证。

MMA 指令吞吐（best TF/s）#

指令层基准特意保留未变化的 INT8、FP16/FP16 和普通 FP32 FFMA 作为负对照。如果所有模式都同幅度上升，就需要怀疑是频率、功耗或测试方法而不只是某个 Tensor 模式的限制被解除。

不是所有 Tensor 模式、所有精度都翻倍。

cuBLAS GEMM 中位吞吐（TF/s）#

GEMM 的实际吞吐包含 Kernel 实现、访存、矩阵维度与调度成本。特别是 BF16/FP32 4096² 只改善约 0.6%，提示这类任务可能不是被解锁的指令速率控制。

这里已经能看到：指令性能即便 2×，应用 GEMM 的吞吐提升也会受算子实现、访存和调度影响。

7.1 单机四卡，开启与关闭 P2P#

首轮 8–512MiB AllReduce，平均 busbw（GB/s）：

这组数字并未证明四卡 AllReduce 因 P2P 大幅加速。 某些配置甚至更慢，属于需要进一步分解 NCCL 运行策略的问题。

但开启详细初始化日志并设置 NCCL_P2P_LEVEL=SYS 后，两台的 NCCL 明确报告：

1
Check P2P Type isAllDirectP2p 1 directMode 1 isAllCudaP2p 1
2
Channel ... via P2P/direct pointer

证明该诊断实验里 NCCL 确实使用了 CUDA 直接 P2P 路径。SYS 是允许访问的最远拓扑级别，不是“一定选最快路由”的开关。

7.2 两卡的 P2P 收益很明显#

在其中一台服务器上，32–256MiB 双卡 AllReduce 平均 busbw（GB/s）：

全部 #wrong=0。跨 NUMA 禁用 P2P 的数据存在一次明显低值，+25.2% 可能有异常值放大效应，不能无条件外推。

7.3 三轮复测：AUTO 比强制 PHB / SYS 更快#

为何不把双卡的 21% 改善直接推广到四卡？因为 AllReduce 不是一次独立 Peer Copy，而是涉及同步、分块、通信环/树与不同拓扑边的集合操作；最慢链路、通道选择和 CPU Socket 间路径会影响总吞吐。强制扩大 P2P 允许距离，可能令 NCCL 不再采用其默认认为更好的组合。

因此我们固定消息大小与迭代数量，对 AUTO、PHB、SYS 各重复 3 次，并以所有轮次的平均 §busbw§ 讨论性能，而不是挑最快的一条数据。

32–256MiB 单机四卡 AllReduce，每策略 3 次，平均 busbw（GB/s）：

AUTO 比 PHB 快约 9.4%，比 SYS 快约 11.6%。全部 18 次测试正常结束，#wrong 均为 0，没有越界数据错误。AUTO 由 NCCL 自己选择拓扑和通道，不要把调试时的 NCCL_P2P_LEVEL=SYS 永久写到集群全局环境。但 AUTO 的详细底层路径仍需要针对具体任务诊断，不能仅凭总线带宽反推所有环节的传输方式。

推荐维持默认：

1
unset NCCL_P2P_LEVEL
2
unset NCCL_P2P_DISABLE
3
unset NCCL_ALGO
4
unset NCCL_PROTO

7.4 对性能指标的解释#

NCCL 的 §algbw§ 是算法层有效带宽；§busbw§ 是依据通信原语和卡数折算的总线带宽，不能直接与单向 CUDA Peer Copy 的 GiB/s 作数值等价比较。另外本次 §GB/s§ 为 NCCL 的十进制单位，Peer Copy 的 §GiB/s§ 为二进制单位，单位差异也是比较时必须说明的。

实验证据分四级：

这四级证据也是本文最希望提供的一套评估方法。

9.1 可回滚比“一次成功”重要#

维护期应先通过 Slurm drain 保护作业，保留原始 NVIDIA 610 镜像、仅 Tensor 解锁的已知可用镜像，以及 615+P2P 独立测试镜像。任何 boot 参数（尤其 IOMMU、GPU BDF）须在节点级设置并检查实际 §/proc/cmdline§；不要改共享 GPU profile 后让另一台不相关节点意外继承。

除冷启动恢复，还应把补丁源码提交哈希、目标内核 ABI、最终 §modinfo filename/version/vermagic§、NCCL 测试日志等收进可追踪的维护记录。

这次已实证完成：两个节点的 Tensor 解锁、32GiB BAR1、24/24 CUDA P2P 有向传输校验、NCCL 直接指针路径验证及短时 AllReduce 数值正确性。双卡 P2P 收益明显，四卡应保留 NCCL AUTO。

尚未完成的是长时间满载老化测试、跨节点八卡 NCCL 以及把手工补丁模块纳入正式 DKMS/RPM 的持久化管理。特别是驱动/内核自动升级可能覆盖 updates/dkms 的补丁模块；应固定镜像版本、保留可冷启动回滚的原镜像，并在实际科研或训练负载中继续记录温度、功耗、Xid 和 PCIe AER。

这次最大的经验不是某个跑分数字，而是要把四件事分别验收：驱动初始化成功、CUDA 能直接通信、NCCL 实际选择直接通信、应用端最终得到性能收益。没有这四层分离，就很容易把“能用”误写成“加速已经完成”。