本文是基于AI云智公坊的公众号文章整理而来如有侵权请联系作者删除。NVIDIA GPUDirect 是一系列旨在增强数据中心 GPU 间数据传输与访问能力的技术统称。其核心目标是减少 GPU 间数据传输过程中不必要的拷贝、提升通信链路带宽并降低通信延迟。按通信范围划分GPUDirect 技术可分为两大类1同一节点内 GPU-to-GPU 的通信如 GPUDirect Shared Memory、GPUDirect Peer-to-PeerP2P、NVLink、GPUDirect Storage 等技术。2不同节点间 GPU-to-GPU 的通信如 GPUDirect RDMARemote Direct Memory Access技术。节点内 GPU 通信GPUDirect Shared Memory这是最早且最传统的一种通信方式。GPU 之间的数据访问基于操作系统提供的共享内存Shared Memory机制——不同进程或 GPU 能够访问同一块物理内存。数据需先从源 GPU 显存拷贝至 CPU 可访问的系统共享内存再由目标 GPU 从系统内存中读取。整个过程需要 CPU 协调和内存中转数据需经过 2 次拷贝才能到达目标 GPU。这种方式通常仅在 GPU 因硬件或驱动限制无法有效利用 P2P 通信时作为备选方案。此时NCCLNVIDIA Collective Communications Library一般会退回到使用共享内存作为数据传输的中转站 [6]。可通过环境变量NCCL_SHM_DISABLE1来禁用 SHM 传输此时 NCCL 将转而使用网络传输如 InfiniBand 或 IP Socket[6]。提示 在 Docker 容器中运行 NCCL 时容器默认的共享内存和锁定内存资源非常有限建议设置--shm-size1g --ulimit memlock-1以保证 NCCL 正常工作 [6]。优点 灵活性和兼容性好在不支持 P2P 或 NVLink 的环境下仍能提供 GPU 间通信能力。缺点 需要经过 CPU 和系统内存中转受限于 PCIe 总线带宽、内存带宽及 CPU 负载等因素整体带宽低、延迟高、传输路径长。如下例所示受限于硬件条件无 NVLink、不支持 PCIe P2PGPU 0 的数据要发送给 GPU 1首先 GPU 0 的显存数据通过 PCIe 总线在 CPU 协调下写入系统共享内存Shared Memory随后 GPU 1 再通过 CPU 和 PCIe 将数据读取到自身显存中。GPUDirect Peer-to-Peer在共享内存方式之后NVIDIA 引入了 GPUDirect P2P 技术 [1]允许 GPU 之间直接交换数据而无需经过 CPU 和系统内存大幅提升了传输效率。该技术自 CUDA 4.0 起引入最初支持 Tesla 20 系列Fermi 架构及更新一代的 GPU [1][3]。GPU 直接绕过 CPU 和系统内存通过 PCIe 总线读写另一块 GPU 的显存仅需一次数据拷贝。性能仅受限于 PCIe 带宽和 GPU 显存带宽从而减少了数据拷贝次数、缩短了传输路径、提高了传输带宽并降低了传输延迟。GPUDirect P2P 依赖硬件的 DMA 技术。所幸现代硬件基本都已支持 DMA因此即使是仅通过 PCIe 互联的 GPU也能受益于 P2P 带来的性能提升。需要注意的是P2P 通信要求两块 GPU 位于同一个 PCIe Root Complex 下才能获得最佳性能若跨 CPU socket通过 QPI/UPI 互联性能可能大幅下降甚至无法工作 [3]。优点 相较于共享内存方式传输效率显著提升。缺点 需要硬件支持 PCIe P2P且受限于 PCIe 带宽上限。在 PCIe P2P 的加持下GPU 0 到 GPU 1 的数据传输直接通过 PCIe 完成不再需要系统内存和 CPU 的协调参与效率进一步提升。GPUDirect Storage随着 AI 和高性能并行计算规模的不断增长传统的存储访问方式逐渐成为性能瓶颈[5]GPU 之间的数据传输速率可达双向 1.8 TB/s第五代 NVLinkBlackwell 架构[7]然而即使是最先进的 NVMe SSD 也只能提供约 14 GB/s 的顺序读取带宽。传统的文件读写操作严重依赖 CPU 和系统内存的协助消耗大量 CPU 与内存资源。GPUDirect StorageGDS应运而生 [2][5]。它支持 GPU 显存与本地或远端存储设备之间的直接数据传输避免了 CPU 和系统内存的参与大幅提升了 GPU 与存储之间的数据吞吐。GDS 的核心是 cuFile 库libcufile.so作为 CUDA 工具包的一部分分发 [5]。同一节点内GDS 需要依赖硬件的 DMA 技术不同节点间则需依赖 NVMe-oF 等网络存储协议支持。GDS 支持多种存储后端包括本地 NVMe、NVMe-oF以及众多分布式文件系统DDN EXAScalerLustre、Amazon FSx for Lustre、IBM Spectrum Scale、WekaFS、BeeGFS、NetApp ONTAP、Dell EMC PowerScale 等 [5]。兼容性说明 GDS 要求数据中心级 GPUCompute Capability 6.0文件需以O_DIRECT模式打开CUDA 12.2 / GDS 1.7 之后的版本支持兼容模式自动回退到 POSIX read/write。仅支持 Linux x86-64 平台 [5]。如下图所示GPU 1 访问 NVMe SSD 数据时需要 CPU 和内存的参与延迟较大。若使用 GDS 技术数据直接完成点对点传输无需在系统内存中转读写效率大幅提升。NVLink NVSwitch随着科学计算和大语言模型的飞速发展GPU 之间的通信带宽和延迟面临更高要求。以一个采用半精度浮点数FP16的 70B 参数模型为例所需显存至少 280 GB单颗 GPU 无法加载完整模型权重。这就需要使用模型并行技术来解决单块 GPU 无法运行完整模型的问题。单机内常用的是张量并行Tensor Parallelism, TP技术它将模型切分到多个 GPU 上每块卡执行部分计算任务然后将计算结果发送给其他 GPU在 NCCL 中即 AllReduce 操作。这个过程涉及大量数据传输——例如 Llama 3.1 70B8K 输入 token 256 输出 token的单次查询需要从每个 GPU 传输多达 20 GB 的 TP 同步数据 [9]。因此对于大模型推理而言单机内 GPU 的数据传输速率需要更高模型训练对带宽的需求则更为苛刻。不论是共享内存还是 P2P均受限于 PCIe 带宽。根据 PCI-SIG 官方规范 [24]各代 PCIe x16 链路的双向带宽如下PCIe 代数每通道单向速率x16 双向总带宽PCIe 3.0~8 GT/s~32 GB/sPCIe 4.0~16 GT/s~64 GB/sPCIe 5.0~32 GT/s~128 GB/s显然PCIe 带宽已无法满足当前 GPU 通信需求成为性能瓶颈。为此NVIDIA 于 2016 年Pascal 架构时代发布了全新架构的 NVLink [7][8]。NVLink 是一种纵向扩展互联Scale-Up技术 [7]在节点内部提供 GPU 到 GPU 的高带宽通信链路支持直接点对点连接具有比传统 PCIe 更高的传输速度和更低的时延显著优化了模型训练与推理等场景的通信性能。NVIDIA NVLink 已历经多代演进 [7]代数架构单 GPU 带宽NVLink 链路数NVSwitch 聚合带宽第四代Hopper (H100/H200)900 GB/s187.2 TB/s (8 GPU)第五代Blackwell (B200)1,800 GB/s18130 TB/s (NVL72)第六代Rubin3,600 GB/s36260 TB/s (NVL72)由于 NVLink 技术无法将节点内所有 GPU 实现全互联NVIDIA 于 2018 年Volta 架构 / DGX-2 时代发布了 NVSwitch通过 NVSwitch 实现 NVLink 的全连接 [8]。NVSwitch 内部是一个全连接的交叉开关矩阵Crossbar任意端口之间可以无阻塞地以满速通信 [8]。以 NVIDIA Hopper 架构 GPU 为例第四代 NVLink 总带宽达 900 GB/s是 PCIe Gen5 带宽的 7 倍以上 [7][10]图片来源NVIDIA Hopper 架构官方页面 [10]对应的第三代 NVSwitch 芯片支持 GPU 间带宽 900 GB/s聚合带宽达 7.2 TB/s支持单节点 8 块 GPU [7]图片来源NVIDIA NVLink 官方页面 [7]以配置 8 块 H20 GPU 的服务器为例。NVIDIA H20 是基于 Hopper 架构、面向中国市场的数据中心 GPU配备 96 GB HBM3 显存带宽 4.0 TB/s支持第四代 NVLink 900 GB/s 全互联。若不使用 NVSwitch直接通过 NVLink 点对点连接每条链路带宽仅为 128 GB/s [9]图片来源NVIDIA Technical Blog [9]若配置 4 个第三代 NVSwitchNVSwitch 实现 NVLink 全连接GPU 到 GPU 之间可提供满速 900 GB/s 的带宽仅需约 22 ms 即可传输 20 GB 数据 [9]。下表展示了 NVSwitch 相比点对点连接的带宽优势 [9]通信 GPU 数量点对点带宽NVSwitch 带宽2 块128 GB/s900 GB/s4 块3 × 128 GB/s900 GB/s8 块7 × 128 GB/s900 GB/s图片来源NVIDIA Technical Blog [9]节点间 GPU 通信对于超大模型推理而言单台 8 卡 GPU 服务器已无法满足需求。以 DeepSeek-R1 671B 模型为例该模型采用混合专家Mixture of Experts, MoE架构总参数量 671B每个 token 仅激活 37B 参数 [22]。在未量化的情况下权重为半精度浮点型 float16所需显存约为 671 × 2 ≈ 1342 GB。若使用 H20 GPU每卡 96 GB 显存至少需要 14 块卡而单台节点通常最多 8 卡 NVLink NVSwitch 互联因此必须通过多机多卡来满足并结合分布式计算框架如 Ray与 TP、PP 等模型并行技术部署推理服务。实际部署参考 根据 NVIDIA 官方博客单台配备 8 块 H200 GPU每卡 141 GB HBM3e总计 1128 GB的服务器可在 FP8 精度下运行完整 DeepSeek-R1 模型吞吐量达 3,872 tokens/s [23]。AWS 实测数据表明DeepSeek-R1 在 FP8 精度下至少需要 800 GB HBM 显存 [23]。如前所述单机内使用第四代 NVLink NVSwitch 最多支持 8 卡互联显然无法满足 DeepSeek-R1 671B 这类超大模型的部署需求因此至少需要 2 台 8 卡 H20 服务器。单机内可通过 NVLink NVSwitch 等技术手段大幅优化 GPU 间通信的带宽与延迟那么多机多卡之间除了使用传统以太网 TCP/IP 之外是否还有其他能增强通信性能的技术答案是肯定的常用的方案包括 RoCE 和 InfiniBand RDMA。当然除了解决多机之间 GPU 的通信带宽问题之外还需要模型的配合即分布式推理技术张量并行TP、流水线并行PP和数据并行DP。一般而言机内选择张量并行TP多机之间选择流水线并行PP并结合分布式计算框架 Ray 来完成分布式推理。分布式训练通信路径典型的分布式训练通信路径如下图所示节点内部通过 NVLink NVSwitch 互联节点之间通过以太网或 IB 网络并结合 RDMA 技术互联传统以太网通信机器间以太网通信是指使用以太网卡如 25G 光口连接传统以太网交换机如 Cisco的 Leaf-Spine 架构网络实现 TCP/IP 数据传输。优点 成本低、兼容性好NCCL 也原生支持这种拓扑 [6]。缺点 传统以太网 TCP/IP 环境下多机之间的通信涉及多次数据拷贝、协议封装与解封需要 CPU 和内存的协调参与且带宽受限、网络稳定性欠佳。对于测试和 POC 场景可以采用这种方案但上生产环境不太建议。如下例所示Server 1 的 GPU 0 要将数据发送至 Server 2 的 GPU 0CPU 先将数据从 GPU 显存拷贝到系统内存。CPU 参与将数据进行 TCP/IP 封包经过内核协议栈处理后将封装好的数据包存入 Ring Buffer。数据包封装完成后交由网卡驱动处理将 Ring Buffer 中的数据包通过 DMA 传输到网卡缓存中进而发送数据包进入以太网。数据包在以太网中经过多层转发最终到达目标 MAC 地址对应的网卡。目标端网卡接收数据包放入缓存 Ring Buffer并向 CPU 发送中断。CPU 响应中断将数据包从 Ring Buffer 拷贝至进程所在的内存空间此过程涉及解包最终数据到达用户进程空间。CPU 将数据从系统内存拷贝至 GPU 显存。至此一个数据包的跨节点传输完成——共计经历了 4 次数据拷贝和 2 次协议封装/解封。基于以太网的 RDMARoCERoCERDMA over Converged Ethernet是一种在传统以太网上实现远程直接内存访问RDMA的网络协议 [11][14]。InfiniBand 行业协会IBTA负责 RoCE 规范的制定和维护RoCE 规范作为 InfiniBand 架构规范的一部分发布 [11]。RoCE 有两个版本 [14]RoCEv1基于以太网链路层Layer 2传输使用专用以太类型0x8915无法跨越 IP 子网。RoCEv2基于 UDP 封装目标端口4791在 IP 层Layer 3传输支持跨子网路由是目前主流的部署方案。与传统以太网通信相比其核心差异在于引入了 RDMA 能力需要网卡硬件和交换机共同支持 RDMA 协议。NVIDIA ConnectX 系列网卡如 ConnectX-7支持 400 Gb/s 带宽 [13]是主流的 RoCE 网卡选择。RDMARemote Direct Memory Access允许一台机器绕过远程主机的操作系统直接访问其内存中的数据。类似于 DMARDMA 同样需要硬件支持RDMA 网卡和交换机。但 DMA 针对的是本机内设备与设备之间绕开 CPU 和内存拷贝直接进行数据交换而 RDMA 技术主要解决的是两台机器之间通信过程中对 CPU 和内存的依赖问题从而提供低延迟、高吞吐的网络环境。RDMA 具有以下核心优势Zero-copy零拷贝 RDMA 允许应用程序直接在用户态将数据发送到网卡缓存无需内存拷贝。Kernel bypass绕过内核 绕过操作系统内核协议栈的封包/拆包过程应用程序直接与网卡通信。无损传输依赖以太网的附加机制——PFC优先级流量控制与 ECN DCQCN显式拥塞通知实现端到端拥塞控制保障传输可靠性。[!NOTE]防止丢包PFC 是基于优先级的流量控制机制由 IEEE 802.1Qbb-2011 标准定义 [15]。交换机将不同的流量划分为 8 个优先级队列优先级 0-7通常将 RDMA 流量分配至优先级 3。当交换机发现优先级 3 的缓存即将溢出时会立即向上游发送端发数据的网卡或上一级交换机发送一个 PAUSE 帧。上游收到 PAUSE 帧后立刻停止发送数据直到缓存水位下降。预防拥塞ECN DCQCNECNExplicit Congestion Notification由 RFC 3168 定义 [16]当交换机发现缓存开始堆积尚未溢出仅出现拥塞迹象它不会丢包也不会发送 PAUSE 帧。取而代之的是在经过的数据包的 IP 报头中设置 ECN 标记将 CE 位设为 1。接收端网卡收到带有 ECN 标记的数据包后立刻生成一个 CNPCongestion Notification Packet 反向发回给发送端网卡。发送端网卡收到 CNP 后启动 DCQCN 算法 [17]主动降低发送速率例如从 100 Gbps 降至 50 Gbps。DCQCNData Center Quantized Congestion Notification由微软研究院的 Yibo Zhu 等人在 SIGCOMM 2015 上发表结合了 DCTCP 和 QCN 的思想已在 Microsoft Azure 数据中心大规模部署。如果后续未再收到 CNP则逐步恢复发送速率。低延迟高吞吐 得益于直接内存访问和零拷贝机制数据包延迟可低至亚微秒级带宽逼近物理极限从而显著降低传输延迟并提升吞吐。如下例所示RoCE 技术在传统以太网上使用 RDMAGPU 直接与网卡设备通信无需内存拷贝、协议封装和 CPU 的协助效率大幅提高。但受限于以太网本身的带宽限制仍无法完全满足超大模型的训练和推理需求。基于 InfiniBand 网络的 RDMARDMA 同样可以应用于 InfiniBand 网络。与 RoCE 的区别在于底层网络不同——RoCE 是在传统以太网上承载 RDMA而 InfiniBand 网络原生即支持 RDMA 协议无需额外的无损以太网配置。InfiniBandIB是一种高性能网络互联技术由 IBTAInfiniBand Trade Association制定标准 [11]通常用于高性能计算和模型训练网络具有极高的吞吐量和极低的延迟。它需要专用的 IB 网卡HCAHost Channel Adapter和专用的 IB 交换机。IB 网卡 NVIDIA ConnectX-7 400 Gb IB 网卡支持 PCIe Gen5 接口提供 400 Gb/s 的满速 IB 连接 [13]。IB 交换机 NVIDIA Quantum-2 系列 QM9700 / QM9790采用 NDRNext Data Rate400 Gb/s 技术提供 64 个 NDR 端口聚合吞吐量达 51.2 Tb/s [12]。GPUDirect RDMA 是在 CUDA 5.0 中引入的一项技术 [4]支持 Kepler 架构及更新一代的 GPU。它允许第三方设备如网卡、视频采集设备、存储适配器通过 PCI Express 直接与 GPU 交换数据无需经过主机内存。但存在一定限制GPU 需要与 HCA 连接在同一个 PCIe Root Complex 下才能获得最佳性能 [4]。内核模块 GPUDirect RDMA 依赖nvidia-peermem内核模块CUDA 11.5替代了旧版nv_peer_mem[4]。对于 Mellanox InfiniBand/RoCE 网卡NCCL 需要此模块来实现 GPU 与网卡之间的直接内存访问。模块源码可从 GitHub 获取。图片来源NVIDIA GPUDirect RDMA 文档 [4]如下图所示与 RoCE 的区别在于底层网络为 InfiniBand。节点配置 400 G HCA IB 网卡交换机使用 NVIDIA QM9790 组网网络理论带宽达 400 Gb/s在大幅提升传输带宽的同时提供了极低的延迟。在实际环境中使用 IB 网络、主机 400 G HCA 网卡、NVIDIA QM9790 交换机一分二 400G 连接两台服务器之间的 IB RDMA 带宽压测结果为 371 Gb/s达成率约 93%。AWS EFAElastic Fabric Adapter在云环境中AWS 提供了自研的高性能网络方案——Elastic Fabric AdapterEFA。EFA 是一种可附加到 Amazon EC2 实例的网络设备专为 AI/ML 和 HPC 工作负载设计可实现高性能的节点间通信 [18]。EFA 采用了自研的 SRDScalable Reliable Datagram 协议 [20]与传统的 TCP 或 RDMA 可靠传输有本质区别特性AWS SRDEFA [20]路径选择多路径并发Multi-path Spraying。数据包同时沿多条路径发送充分利用网络带宽。顺序要求允许乱序。包 2 可以比包 1 先到达接收端的 AWS Nitro 卡硬件负责重新排序避免队头阻塞Head-of-Line Blocking。拥塞控制基于 RTT 的微秒级控制。由于数据包走了多条路径SRD 能够感知哪条路快、哪条路慢自动避开拥塞路径。SRD 技术细节 SRD 是一种可靠的、无连接的数据报传输协议 [20]。与传统的 Reliable DatagramRD不同SRD 不限制在途消息数量no limit on outstanding messages且不提供排序保证从而消除了队头阻塞问题。SRD 由 AWS 自研的 Nitro 硬件实现其内核驱动已开源在 amzn-drivers 仓库中。加速原理Kernel Bypass EFA 允许应用程序如 NCCL通过 LibfabricOpen Fabrics Interfaces直接与 EFA 设备通信User Space → EFA Device绕过操作系统内核延迟极低 [21]。NCCL 插件 NVIDIA 的通信库 NCCL 提供了专门的插件aws-ofi-nccl通过 Libfabric 的 EFA Provider 自动识别 EFA 并使用 SRD 协议传输数据 [21]。需要注意的是EFA 的 Kernel Bypass 功能只能被特定的库如 Libfabric调用普通应用仍走标准的 TCP/IP 协议栈 [18]。EFA 支持的库包括NCCL 2.4.2、Open MPI 4.1、Intel MPI 2019 Update 5、NVIDIA NIXL 1.0.0 以及 AWS Neuron SDK 2.3 [18]。[!TIP]nvidia-fabricmanager是 NVIDIA 数据中心级 GPU特别是基于 NVSwitch 架构的服务器的必备组件。NVSwitch 芯片实现了所有 GPU 之间的全互联All-to-All而 Fabric Manager 负责管理这一互联拓扑。初始化 NVSwitch 机器启动时Fabric Manager 负责配置 NVSwitch 芯片建立 GPU 之间的路由表。配置 NVLink 它告知每张 GPU 如何路由到其他 GPU例如要去 GPU 3请走第 5 条 NVLink 通道。管理拓扑 确保 8 张卡形成统一的 Fabric织网使显存可被统一寻址。处理故障 如果某条 NVLink 出现故障它负责重新路由或报错。驱动版本Driver Version 与 Fabric Manager 版本 必须完全一致。可通过以下命令检查 NVLink 拓扑矩阵中应当全是NV12A100或类似的高速标识nvidia-smi topo -mEFA 配置步骤安全组配置 EFA 需要一个自身引用Self-referencing 的安全组规则 [18]。因为 SRD 协议不使用标准的 TCP/UDP 端口它需要完全开放的内部通信权限。安全组的入站和出站规则都应允许来自自身的所有流量。EKS 集群配置 EKS 集群中需要安装 EFA Device PluginDaemonSet 方式用于发现并暴露节点上的 EFA 设备 [19]。对于 Kubernetes 1.34 版本推荐使用 EFA DRA DriverDRANET它支持拓扑感知调度可将 EFA 接口与就近的 GPU 或 Neuron 设备配对 [19]。AWS EKS 官方优化 AMIAL2023 NVIDIA AMI已自带 EFA 驱动无需手动安装。NCCL 环境变量配置export FI_PROVIDERefa export NCCL_DEBUGINFO # 查看日志确认是否真正使用了 EFA export NCCL_P2P_DISABLE1 # 某些跨节点场景可能需要禁用 P2P参考文献[1] NVIDIA,“NVIDIA GPUDirect™ Technology: Eliminating CPU Overhead”, GPUDirect Technology Overview Whitepaper, 2012. PDF[2] NVIDIA,GPUDirect Official Page, developer.nvidia.com/gpudirect[3] NVIDIA,CUDA Driver API — Peer Access Memory Management, docs.nvidia.com[4] NVIDIA,GPUDirect RDMA Documentation, docs.nvidia.com/cuda/gpudirect-rdma/[5] NVIDIA,GPUDirect Storage Overview Guide Design Guide (r1.16), December 2025. docs.nvidia.com/gpudirect-storage/[6] NVIDIA,NCCL User Guide (v2.29.7), March 2026. docs.nvidia.com[7] NVIDIA,NVLink NVLink Switch Official Page, nvidia.com/en-us/data-center/nvlink/[8] NVIDIA,NVSwitch Technical Overview, PDF[9] Brian Slechta,“NVIDIA NVLink and NVIDIA NVSwitch Supercharge Large Language Model Inference”, NVIDIA Technical Blog, 2024-08-12. Link[10] NVIDIA,Hopper Architecture, nvidia.com[11] InfiniBand Trade Association (IBTA),InfiniBand Architecture Specification (Vol. 1 Release 2.0), July 2025. infinibandta.org[12] NVIDIA,Quantum-2 QM9700/QM9790 InfiniBand Switch User Manual, docs.nvidia.com[13] NVIDIA,ConnectX-7 Ethernet/IB Adapter Specifications, docs.nvidia.com[14] NVIDIA,RDMA over Converged Ethernet (RoCE) Documentation, docs.nvidia.com[15] IEEE,IEEE 802.1Qbb-2011: Priority-based Flow Control, September 2011. standards.ieee.org[16] K. Ramakrishnan, S. Floyd, D. Black,“The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, IETF, September 2001. rfc-editor.org[17] Yibo Zhu et al.,“Congestion Control for Large-Scale RDMA Deployments”, ACM SIGCOMM 2015.[18] AWS,Elastic Fabric Adapter for AI/ML and HPC Workloads on Amazon EC2, docs.aws.amazon.com[19] AWS,Manage EFA Devices on Amazon EKS, docs.aws.amazon.com[20] AWS,SRD Protocol Specification, github.com/amzn/amzn-drivers[21] OFIWG,EFA Libfabric Provider Documentation, github.com/ofiwg/libfabric[22] DeepSeek-AI,DeepSeek-R1 Repository, github.com/deepseek-ai/DeepSeek-R1[23] NVIDIA,“DeepSeek-R1 Now Live with NVIDIA NIM”, NVIDIA Blog, 2025-01-30. blogs.nvidia.com[24] PCI-SIG,PCI Express FAQ — Speeds Feeds, pcisig.com/faq[25] G. Shainer et al.,“The Development of Mellanox-NVIDIA GPUDirect over InfiniBand”, osti.gov