评估在NVIDIA L40 GPU上解决VLLM NCCL P2P通信问题的方案：IOMMU与PCI ACS禁用的有效性、风险及替代策略

I. 执行摘要

本报告旨在全面评估一项针对在NVIDIA L40 GPU系统上运行VLLM（大规模语言模型推理与服务库）时遇到的NCCL（NVIDIA Collective Communications Library）点对点（P2P）通信问题的解决方案。该问题通常表现为VLLM启动挂起或多GPU性能严重下降。用户提出的解决方案核心在于在系统BIOS中禁用IOMMU（输入/输出内存管理单元）和PCI ACS（访问控制服务），并辅以操作系统层面的脚本来确保ACS的禁用状态。

分析表明，禁用IOMMU和PCI ACS确实是解决此类P2P通信障碍的常见且据报道有效的方法，尤其适用于裸金属（Bare-Metal）部署环境。然而，此方案伴随着显著的潜在风险。最主要的是，禁用IOMMU会移除关键的DMA（直接内存访问）保护，可能导致严重的安全漏洞，如DMA攻击，使得恶意或故障的PCIe设备能够访问任意系统内存。此外，IOMMU是实现虚拟化功能（如SR-IOV和安全的虚拟机设备直通）的基础，禁用它将导致这些功能无法使用。

考虑到NVIDIA L40 GPU缺乏NVLink高速互联技术 1，其多GPU通信完全依赖于PCIe总线的P2P效率，这使得解决P2P通信问题尤为重要。然而，鉴于禁用IOMMU和ACS所带来的风险，此方案应被视为在其他替代方法均无效后的最后选择，且仅适用于已进行彻底风险评估并能接受相关安全影响的裸金属环境。对于需要虚拟化功能的环境，此方案通常不可行。

本报告强烈建议优先探索和实施侵入性较低的替代方案和补充优化措施。这些措施包括但不限于调整NCCL环境变量、优化PCIe配置、确保软件栈（驱动、CUDA、NCCL版本）的兼容性与最新性，以及细致检查其他相关的BIOS设置。系统管理员和工程师在实施任何解决方案前，必须充分权衡性能增益与潜在的安全、稳定性风险。这种对底层系统特性与高性能计算需求的深入理解，是当前复杂计算环境中确保系统既高效又安全的关键。

II. NCCL P2P通信对L40 GPU上VLLM的关键作用

在现代大规模语言模型（LLM）的部署中，尤其是在多GPU环境下，高效的节点内和节点间通信至关重要。VLLM作为一款流行的LLM推理和服务框架，当配置为使用张量并行（Tensor Parallelism）等分布式策略时，其性能高度依赖于底层GPU间的通信效率。NVIDIA Collective Communications Library (NCCL) 在此扮演了核心角色。

NCCL与分布式工作负载基础

NCCL是一个为NVIDIA GPU优化的库，旨在实现可扩展的多GPU和多节点通信原语，如AllReduce、Broadcast、ReduceScatter等。这些原语是深度学习训练和推理过程中同步参数、分发数据和聚合结果的基础。对于VLLM这类应用，NCCL确保了模型权重、激活值和梯度（在训练场景中）能够在多个GPU之间高效传输。

P2P通信及其重要性

点对点（P2P）通信特指GPU能够直接访问另一GPU显存中的数据，而无需通过CPU或系统内存作为中介。这种直接路径显著降低了数据传输的延迟，并能更充分地利用硬件提供的带宽。高效的P2P通信是NCCL实现卓越性能的基石。当P2P可用且性能良好时，NCCL可以最大化GPU间的并行处理能力。

NVIDIA L40 GPU与P2P机制

NVIDIA L40 GPU是一款面向数据中心、针对AI、图形和计算密集型工作负载设计的高性能加速器。然而，一个关键的硬件特性是L40 GPU并不支持NVIDIA NVLink高速互联技术 1。NVLink为支持它的GPU提供了一条专用的、高带宽、低延迟的P2P通信通道。

由于L40缺乏NVLink，其GPU间的P2P通信完全依赖于PCI Express (PCIe) 总线。L40配备了PCIe Gen 4 x16接口，理论上能提供高带宽。因此，确保PCIe P2P通信路径的畅通和高效，对于在多L40 GPU系统上运行VLLM等应用的性能至关重要。研究表明，在L40 GPU集群中运行LLM推理时，通信开销可能非常显著，例如，在4卡L40配置下，通信时间可占到预填充（prefill）阶段总时延的50%以上，甚至高达65%。这进一步凸显了P2P通信性能的敏感性。

P2P故障的症状与诊断

当P2P通信出现问题时，VLLM或其他依赖NCCL的应用通常会表现出以下症状：

• 启动挂起：应用在NCCL初始化阶段卡住，日志可能停留在类似“Init COMPLETE”的消息处，但进程无法继续 2。
• 运行时崩溃：在执行涉及多GPU通信的操作时程序异常终止。
• 性能严重下降：即使程序能够运行，多GPU的性能远低于预期，甚至不如单GPU。

诊断P2P问题常用的工具和方法包括：

• p2pBandwidthLatencyTest：NVIDIA CUDA示例中提供的工具，用于测试GPU间的P2P带宽和延迟，是验证P2P硬件通路是否正常的标准方法。
• VLLM调试脚本：VLLM自身可能提供测试脚本（如test.py），用于在隔离环境中复现NCCL问题 2。
• 系统日志检查：查看dmesg或类似系统日志，寻找与IOMMU、PCI ACS或PCIe相关的错误信息。
• PCIe拓扑检查：使用lspci -tv命令可以显示系统中PCIe设备的连接拓扑，帮助理解GPU是如何通过PCIe交换机和根端口互连的。

L40 GPU作为数据中心级产品，却未配备NVLink，这反映了其在设计上可能更侧重于特定工作负载的成本效益、功耗或其他特性，而非追求极致的P2P带宽。这一决策使得用户在构建L40集群时，必须更加关注系统级的PCIe配置，以确保P2P通信的可靠性。任何对PCIe P2P路径的干扰，如不当的IOMMU或ACS设置，都将对L40上的LLM工作负载产生不成比例的负面影响，因为没有NVLink这样的备用高速通道。

下表总结了NVIDIA L40 GPU与P2P通信相关的关键规格和系统考量：

表1：NVIDIA L40 GPU P2P相关规格及系统考量

III. 评估建议方案：禁用IOMMU和PCI ACS

用户提出的解决方案核心在于禁用IOMMU和PCI ACS。本节将深入探讨这两项技术的原理，它们如何干扰GPU P2P通信，以及禁用它们作为解决方案的有效性证据和实施方法。

技术深潜：IOMMU (VT-d/AMD-Vi) 与GPU P2P干扰

IOMMU，即输入/输出内存管理单元（在Intel平台常称为VT-d，AMD平台则有AMD-Vi等实现），是一种硬件组件，其主要功能包括：

1. DMA重映射：将设备发出的DMA请求中的设备地址（IOVA）转换为主机物理地址（HPA）。
2. 设备隔离：限制设备只能访问其被明确授权的内存区域，从而防止恶意或故障设备破坏系统内存或其他设备的数据。
3. 支持虚拟化：允许虚拟机直接、安全地访问物理硬件设备（设备直通）。

然而，IOMMU的这些有益功能在特定情况下可能与GPU P2P通信产生冲突。默认情况下，为了执行地址转换和访问控制检查，IOMMU可能会拦截所有设备的内存访问请求，包括GPU之间尝试进行的P2P通信。这些请求可能被导向CPU的根联合体（Root Complex）进行处理和验证 2。这个额外的路径和处理步骤会显著增加P2P通信的延迟，降低有效带宽，甚至可能导致P2P传输失败或系统挂起。

NVIDIA的官方立场对此有明确说明：在裸金属Linux系统上，CUDA及其显示驱动程序不支持启用了IOMMU的PCIe P2P内存复制 4。因此，对于裸金属部署，建议禁用IOMMU。针对GPUDirect Storage（GDS）技术，NVIDIA的经验也表明，内核参数iommu=off（完全禁用IOMMU）在功能和性能上表现最佳，而iommu=on（完全启用IOMMU）则不保证能正常工作或达到预期性能 5。相比之下，AMD ROCm的文档有时会建议将IOMMU设置为iommu=pt（直通模式）作为配置步骤之一。

技术深潜：PCI ACS (Access Control Services) 与GPU P2P干扰

PCI ACS是一项PCIe规范中定义的功能，旨在控制P2P事务在PCIe交换结构（如交换机和桥）中的路由行为。ACS的关键作用在于，它可以阻止位于同一交换机下不同端口的PCIe设备之间直接进行P2P通信，而是强制这些P2P请求向上游路由到根端口（Root Port）或根联合体进行验证。这种机制的初衷是为了增强隔离性，防止一个设备未经授权访问另一个设备的资源或发起可能干扰系统的事务。

如果连接GPU的PCIe交换机上启用了ACS，它会有效地阻止GPU之间的直接P2P数据路径。所有P2P尝试都将被重定向，其效果类似于IOMMU的干扰，导致性能下降或通信挂起 2。系统MMU（SMMU，通常是IOMMU的一部分）在ACS验证过程中可能扮演角色，这显示了IOMMU和ACS在功能上的紧密关联。

有效性证据

大量用户报告和官方文档证实了禁用IOMMU和/或ACS对于解决NCCL P2P问题的有效性：

• 一篇博客文章详细记录了作者在启动VLLM时遇到因NCCL P2P问题导致的挂起，通过在BIOS中禁用IOMMU和PCI ACS后问题得到解决。作者还提到，在另一台机器上约六个月后遇到类似问题，再次检查发现ACS是症结所在 2。
• NVIDIA的NCCL故障排除指南明确指出，IO虚拟化（IOMMU/VT-d）和PCI ACS可能干扰GPU Direct P2P通信，并建议在BIOS中禁用它们，或针对特定设备（如Broadcom PLX交换机）通过操作系统命令禁用ACS 3。
• NVIDIA开发者论坛上关于P2P通信失败的讨论，经常会引导用户检查IOMMU和ACS的设置状态。
• AMD的GPU集群网络配置指南中，也将“禁用PCI ACS”列为一项前提条件。

实施指南（概念性）

1. BIOS修改：

• 在系统BIOS设置中查找与IOMMU相关的选项，如"IOMMU", "VT-d" (Intel), "AMD IOMMU", "SVM" (AMD Secure Virtual Machine, 有时与IOMMU设置关联) 或 "AMD-Vi"，并将其设置为"Disabled"（禁用）。
• 查找与PCI ACS相关的选项，可能标记为"PCI ACS", "ACS Control"或类似名称。这些设置可能按PCIe插槽提供，也可能是全局设置。如果存在，则将其禁用。有时，禁用IOMMU可能会间接影响ACS的行为，使其限制性降低，或者某些BIOS中没有独立的ACS开关。

2. 操作系统层面脚本禁用ACS（若BIOS设置不足或非持久性）：

• 运行此类脚本的需求源于BIOS中的设置可能未完全禁用ACS的所有方面，或者操作系统在启动过程中可能重新启用部分ACS功能。
• 脚本通常使用lspci命令来识别系统中的PCIe桥（特别是NVIDIA文档中提到的PLX交换机），然后使用setpci命令向特定PCIe设备的ACS控制寄存器写入值，以禁用ACS的某些功能。一个常见的命令是 sudo setpci -s <BDF> ECAP_ACS+0x6.w=0000，其中<BDF>是设备的Bus:Device.Function号 3。
• 这类脚本通常需要在每次系统重启后运行，因为setpci所做的更改可能不是持久的。NVIDIA的文档提供了一个此类脚本的示例逻辑。

IOMMU和ACS的设计初衷是为了增强系统的安全性和隔离性，但它们在实现这些目标时所采用的机制（如重定向流量、增加验证步骤）恰恰与高性能P2P通信所追求的直接、低延迟路径相冲突。这种根本性的架构张力是导致P2P问题频发的主要原因。操作系统层面脚本的必要性进一步表明，ACS的控制是多层级的，操作系统或驱动程序可能在系统启动或设备枚举期间重新配置ACS，使得仅靠BIOS设置可能无法彻底解决问题。

值得注意的是，尽管NVIDIA和AMD的文档都指出了IOMMU/ACS对P2P的潜在影响，但在具体建议上略有差异。NVIDIA通常建议在裸金属系统上完全禁用IOMMU (iommu=off)，而AMD的文档有时倾向于使用iommu=pt（直通模式）并另外禁用ACS。这可能反映了不同平台IOMMU实现（VT-d vs. AMD-Vi）与P2P交互的细微差别，或是厂商在平衡性能与保留部分基线系统功能上的不同考量。然而，核心问题——IOMMU/ACS干扰P2P——在两个平台上都是普遍存在的。

下表总结了IOMMU和PCI ACS的功能、对P2P的影响以及禁用方法：

表2：IOMMU与PCI ACS：功能、P2P影响及禁用方法

IV. 深入分析风险与缺陷

尽管禁用IOMMU和PCI ACS可能有效解决P2P通信问题，但这一操作并非没有代价。本节将详细审视由此带来的潜在风险和功能上的缺陷，以便用户做出充分知情的决策。

禁用IOMMU的安全影响

1. DMA保护丧失：IOMMU是抵御来自恶意或故障PCIe设备的DMA攻击的关键硬件防线。DMA攻击是指一个拥有总线主控能力（Bus Mastering）的PCIe设备，在未经授权的情况下读写系统内存。禁用IOMMU后，这种硬件层面的内存隔离和保护机制便失效了。一个被攻破的GPU（或任何其他具有总线主控能力的PCIe设备）理论上可以访问任意物理内存地址，可能导致敏感数据泄露、系统崩溃，甚至完整的系统控制权丧失。Intel的VT-d规范中详细描述了DMAR表（DMA Remapping table）如何限制设备访问特定内存区域；禁用IOMMU会绕过这一机制。
2. 系统弹性降低：即使设备本身并非恶意，其驱动程序或固件中的缺陷也可能导致错误的DMA操作。在有IOMMU保护的情况下，这类错误的影响范围通常会被限制在该设备被授权访问的内存区域内。若IOMMU被禁用，错误的DMA操作可能波及系统关键数据结构或代码区，从而引发更广泛的系统不稳定甚至崩溃。

禁用/覆写PCI ACS的安全影响

1. PCIe交换结构内隔离性减弱：PCI ACS旨在阻止PCIe总线树中一个分支上的设备对另一个分支上的设备发起非法的P2P访问。禁用ACS，特别是通过内核补丁（如pci_acs_override，虽然在文献中主要讨论其在虚拟化上下文中的应用，但其破坏隔离的原理是共通的）强制覆写ACS设置，会打破这种由硬件提供的隔离。这意味着，即使IOMMU在某种程度上仍然启用（例如处于直通模式），或者在同一IOMMU组内的设备，如果它们之间的PCIe交换机上的ACS被禁用，它们之间可能产生非预期的直接通信路径，增加了潜在的攻击面或干扰风险。文献明确指出，使用pci_acs_override因其安全顾虑而不被推荐。
2. 破坏纵深防御：虽然ACS提供的隔离不如IOMMU全面，但它仍是系统整体安全态势中“纵深防御”的一环。禁用ACS意味着减少了一层硬件安全机制。

对系统稳定性及其他功能的影响

1. 虚拟化功能不可用：IOMMU（VT-d、AMD-Vi）是实现安全高效的设备直通（将物理PCIe设备，如GPU，直接分配给虚拟机使用）以及SR-IOV（Single Root I/O Virtualization）等高级虚拟化功能的基石 4。如果在宿主机操作系统层面禁用了IOMMU，这些依赖于IOMMU的虚拟化特性将完全无法工作。文献明确指出，对于虚拟机环境，IOMMU应当启用，并使用VFIO驱动进行设备直通。文献讨论了AMD AVIC（高级虚拟中断控制器），该技术也依赖IOMMU进行虚拟化环境下的中断投递。
2. 硬件/软件兼容性问题：虽然NVIDIA针对其GPU在裸金属P2P场景下建议禁用IOMMU，但某些系统或外设可能在设计上依赖于IOMMU的激活状态以保证稳定运行，即使在非虚拟化环境中。禁用IOMMU可能导致未预期的行为或兼容性冲突。
3. 调试复杂性增加：IOMMU有助于隔离和限制设备故障的影响范围。没有IOMMU，一个设备的错误可能导致更广泛、更难以诊断的系统级问题。

裸金属部署 vs. 虚拟化部署的考量

• 裸金属系统：禁用IOMMU和ACS的方案主要在裸金属系统上被讨论，并且有时被推荐，特别是当追求极致P2P性能且不需要虚拟化功能时 4。这里的核心权衡是用安全性换取性能。
• 虚拟化环境：在宿主机（Hypervisor）上禁用IOMMU通常是不可接受的，如果需要GPU直通或其他依赖IOMMU的虚拟化功能 4。ACS问题可能在虚拟机内部出现（如果多个PCIe设备被直通到同一个虚拟机并且它们需要在虚拟机内部进行P2P通信），但宿主机层面的IOMMU必须保持激活状态以确保虚拟机间的隔离和设备分配的安全性。文献提到虚拟机需要ACS来正常运作，因此禁用ACS（可能指宿主机为虚拟机提供的ACS隔离）不是一个选项。

禁用IOMMU和ACS的决策，并非简单的技术调整，而是对系统安全架构和功能能力的根本性改变。它意味着为了追求性能而牺牲了由硬件强制执行的强大隔离机制。这种权衡揭示了当前系统设计在满足高性能直接硬件访问需求与维持严格安全隔离模型之间的内在矛盾。目前通用的解决方案往往是“全有或全无”式的，缺乏细粒度的控制机制来允许受信任的P2P通信，同时为其他设备和场景保留IOMMU/ACS的保护。

NVIDIA等厂商为追求裸金属P2P/GDS性能而建议禁用IOMMU的做法，虽然有效，但也无形中将理解和接受相关安全风险的重担转移给了系统管理员。这些风险在性能导向的文档中可能未被充分强调。

下表总结了禁用IOMMU和PCI ACS相关的主要风险：

表3：禁用IOMMU与PCI ACS的相关风险摘要

V. 替代及补充策略以保障P2P通信

在考虑禁用IOMMU和ACS这类高风险操作之前，或作为其补充，存在一系列侵入性较低的方法和优化手段，可用于改善或诊断NCCL P2P通信问题。

利用NCCL环境变量

NCCL提供了多个环境变量，用于调试和调整其行为：

• NCCL_P2P_DISABLE=1：此变量显式禁用P2P通信，强制NCCL通过系统内存（CPU内存）作为GPU间数据传输的中介。

• 影响：如果P2P硬件或配置存在无法解决的问题，设置此变量可能允许VLLM等应用启动并运行，但代价是性能会显著下降。文献指出这是一个“临时变通办法”，性能会受影响。文献2提到，在某个案例中，它允许模型加载，但在推理时失败，表明它并非万能。
• 诊断价值：如果设置此变量后应用能运行（即使缓慢），则强烈暗示问题出在P2P路径上。

• NCCL_P2P_LEVEL：此变量用于控制NCCL尝试使用的P2P传输的“局部性”级别，例如NVL代表NVLink，PXB代表通过PCIe交换机，PHB代表通过PCIe主机桥（通常意味着经过CPU）。

• 对L40的影响：由于L40没有NVLink，NVL级别无效。理解PXB（PCIe eXchange Bridge - 跨越一个或多个PCIe交换机）与PHB（PCIe Host Bridge - 经由CPU）的区别至关重要。如果ACS强制流量走向PHB，理论上尝试显式使用PXB（如果拓扑允许且ACS能以某种方式被绕过）可能是一个选项，但仅靠此变量不太可能覆盖ACS的强制路由。其主要用途可能是通过限制路径进行调试。

• NCCL_DEBUG=INFO 或 NCCL_DEBUG=TRACE：启用NCCL的详细日志输出，可以显示NCCL选择的通信路径、遇到的错误等信息。这对于故障排除至关重要。文献建议使用 NCCL_DEBUG=TRACE torchrun... test.py 进行测试。
• NCCL_DEBUG_SUBSYS=ALL：与NCCL_DEBUG配合使用，可为NCCL的特定子系统提供更详尽的日志。
• NCCL_CUMEM_ENABLE=0：VLLM默认设置此环境变量，以规避一个与NCCL的cuMem分配器相关的已知bug。希望与VLLM进程建立NCCL连接的外部进程也应设置此变量，以避免因环境设置不一致导致的挂起或崩溃。这是VLLM特定的考量，但对该场景下的NCCL稳定性很重要。
• CUDA_LAUNCH_BLOCKING=1：此环境变量使CUDA核心的启动变为同步阻塞模式，有助于在发生CUDA错误时精确定位到具体是哪个核心出了问题。如果NCCL问题最终表现为CUDA错误，此选项对调试有帮助，但会影响性能。

优化PCIe配置（ACS/IOMMU之外）

• 验证PCIe链路速度和宽度：确保所有L40 GPU及其所连接的PCIe交换机都以其支持的最大速度（如Gen4）和宽度（如x16）运行。可以使用 sudo lspci -s <BDF> -vvv | grep LnkSta 和 grep LnkCap 来检查当前链路状态（LnkSta）和链路能力（LnkCap）。不理想的链路配置会严重降低P2P带宽。
• PCIe拓扑感知：使用lspci -tv了解GPU如何连接到PCIe交换机和根端口。不均衡的拓扑结构，或者多个GPU共享有限的上游带宽，都可能造成瓶颈。
• PCIe最大有效载荷（Max Payload Size, MPS）和最大读请求大小（Max Read Request Size, MRRS）：这些参数可以影响PCIe通信效率。虽然文献中未具体针对GPU详细说明，但文献在讨论网卡和通用PCIe调优时提到了它们。可能需要通过BIOS设置或setpci命令进行调整。
• 宽松排序（Relaxed Ordering）：文献提到为Mellanox网卡启用PCI宽松排序，并在BIOS中也启用此设置。这有时可以改善PCIe设备的性能。

确保软件栈的协同性

• NVIDIA驱动、CUDA工具包和NCCL版本兼容性：版本不匹配是CUDA和NCCL错误的常见原因。文献提供了一个针对unhandled cuda error, NCCL version X.Y.Z错误的通用排查清单，强调了驱动/CUDA/NCCL的兼容性。文献中一个用户案例显示，特定驱动版本（545.）下出现P2P问题和NCCL挂起，而其他版本（535., 550.*）则报告没有P2P能力（这反而通过回退到较慢路径使得程序“能用”），这突显了驱动程序的敏感性。
• 操作系统和内核：确保操作系统和内核版本受当前NVIDIA驱动程序版本的支持，并且是HPC工作负载已知的稳定版本。内核版本会影响IOMMU/ACS的行为以及PCIe设备的管理。

探索其他相关的BIOS设置

• "Above 4G Decoding" / "Memory Mapped I/O Above 4GB"：此设置允许PCIe设备（如具有大BAR空间的GPU）被映射到4GB以上的地址空间。

• 影响：对于拥有多个GPU或显存较大的GPU（L40拥有48GB显存）的系统至关重要。如果禁用，系统可能无法启动，或者GPU无法被正确寻址。这通常是启用Resizable BAR的前提。

• "Resizable BAR" / "Smart Access Memory"：允许CPU访问整个GPU帧缓存，而不仅仅是一个小窗口。可以在某些工作负载中提升性能。需要启用"Above 4G Decoding"。它对GPU间P2P的直接影响尚不明确，但有助于提升整体系统效率。文献注意到，当IOMMU禁用且4G解码启用时，NVIDIA GPU由于寻址能力限制可能会遇到问题，这暗示了它们之间的相互作用。
• NUMA配置：对于多CPU插槽的系统，确保访问特定GPU的进程/线程绑定到离这些GPU最近的NUMA节点（CPU亲和性）。虽然不直接影响P2P，但它影响CPU-GPU交互性能，如果P2P降级导致流量经由CPU，这一点就变得重要。文献提到禁用NUMA平衡（kernel.numa_balancing=0）。

硬件健康诊断的重要性

• 故障的GPU、PCIe插槽或线缆可能表现为P2P通信问题。应运行硬件供应商提供的诊断工具。
• 文献提到，如果VLLM的test.py脚本挂起或崩溃，“通常意味着硬件/驱动在某种意义上损坏了”。
• 文献也将硬件问题列为CUDA/NCCL错误的一个罕见但可能的原因。

NCCL_P2P_DISABLE=1作为一个常见的诊断步骤的存在，暗示了P2P路径故障的发生频率足以让NCCL自身包含一个专用的“关闭开关”。这标志着在多样化的硬件环境中P2P设置的脆弱性。此外，VLLM特定的NCCL_CUMEM_ENABLE=0设置 表明，即使NCCL本身功能正常，应用层面或特定库与NCCL的交互也可能引入额外的复杂性或触发潜在的bug。这意味着故障排除不能仅仅孤立地关注NCCL。最后，“Above 4G Decoding”、Resizable BAR和IOMMU状态之间的复杂相互作用 指出了内存寻址方面存在一个依赖关系网。不正确地配置其中一个，可能会对其他设置以及GPU的可访问性/性能产生连锁反应。

下表总结了用于P2P故障排除和调优的关键NCCL环境变量：

表4：用于P2P故障排除和调优的关键NCCL环境变量

VI. 针对L40 GPU系统上VLLM的可行建议

基于前述分析，本节为用户提供一套结构化的、可操作的建议，旨在解决NVIDIA L40 GPU系统上运行VLLM时遇到的NCCL P2P通信问题。建议采用迭代的故障排除方法，从侵入性最小、风险最低的操作开始。

迭代故障排除方法论

1. 基线检查与初步诊断：

• 确保安装了与VLLM兼容的最新稳定版NVIDIA驱动程序、CUDA工具包和NCCL库。详细记录所有相关软件的版本号。
• 运行nvidia-smi命令，确认所有L40 GPU均被系统正确检测到且状态健康。
• 使用lspci -tv命令，了解系统中PCIe设备的拓扑结构，特别是GPU之间的连接方式。
• 运行NVIDIA官方提供的p2pBandwidthLatencyTest工具（包含在CUDA Samples中），对所有GPU对之间的P2P通信能力进行基准测试。记录任何测试失败或带宽远低于预期的GPU对。
• 使用VLLM提供的测试脚本（如test.py），并设置NCCL_DEBUG=TRACE环境变量 2，以捕获VLLM启动或运行失败时的详细NCCL日志。

2. 软件层面检查与变通方案（侵入性最小优先）：

• 确认VLLM进程运行时已设置NCCL_CUMEM_ENABLE=0环境变量。
• 临时设置NCCL_P2P_DISABLE=1环境变量。如果VLLM能够在此设置下启动并运行（即使性能较低），则强烈表明问题与P2P硬件路径或其配置有关。在后续步骤中，除非P2P问题无法修复，否则应恢复此变量为默认值（或不设置）。
• 检查系统日志（如dmesg、/var/log/syslog或journalctl），查找与IOMMU、ACS或PCIe相关的错误或警告信息。

3. BIOS配置审查（侵入性中等）：

• 确保"Above 4G Decoding"（或类似名称的选项，如"Memory Mapped I/O Above 4GB"）已启用（ENABLED）。此设置对于拥有大显存GPU的系统至关重要。
• 如果主板支持且"Above 4G Decoding"已启用，可以考虑启用"Resizable BAR"（或AMD平台的"Smart Access Memory"）。
• 在BIOS中检查并确认所有L40 GPU及其连接的PCIe交换机（如果适用）的PCIe链路速度和宽度设置是否为最优（例如，Gen4速率，x16宽度）。这些设置应与lspci命令的输出结果一致。
• 对于多CPU插槽的系统，检查NUMA相关的BIOS设置。可以考虑在操作系统层面禁用内核的NUMA自动平衡功能（如设置kernel.numa_balancing=0）。

4. 针对性的ACS/IOMMU调整（高风险 - 仅限裸金属系统）：

• 步骤A (ACS脚本)：首先，使用命令 sudo lspci -vvv | grep ACSCtl 检查相关的PCIe桥（特别是连接GPU的桥）是否启用了ACS。如果ACS被启用，可以尝试在操作系统层面运行一个脚本，在每次系统启动后禁用ACS。测试VLLM是否能正常工作。如果此方法有效，其风险通常低于完全禁用IOMMU。
• 步骤B (在BIOS中禁用IOMMU)：如果仅调整ACS不足以解决问题，并且系统是裸金属部署、不需要虚拟化功能、且已充分理解并接受相关安全风险，则可以考虑在BIOS中禁用IOMMU（VT-d/AMD-Vi）2。禁用后，彻底重启系统并测试VLLM。
• 步骤C (在BIOS中禁用ACS)：如果在禁用IOMMU后问题依旧存在，确保BIOS中任何明确的PCI ACS控制选项也已禁用 2。再次测试VLLM。

风险缓解策略（若已禁用IOMMU/ACS）

如果最终选择禁用IOMMU和/或ACS，必须采取额外的措施来降低由此增加的安全风险：

• 物理安全：对服务器进行严格的物理访问控制，防止未经授权的物理接触。
• 网络隔离：将该服务器部署在受信任的网络环境中，限制不必要的入站和出站网络连接。
• 仅使用受信任软件：仅从官方和可信来源安装和运行软件及驱动程序。
• 定期监控与审计：实施强健的系统日志记录机制，并定期审计系统活动，以发现任何可疑行为。
• 专用系统：如果条件允许，将该系统专门用于VLLM工作负载，以最小化攻击面和潜在泄露事件的影响范围。
• 不使用虚拟化：明确该系统无法再支持依赖IOMMU的虚拟化功能。

何时寻求供应商支持

如果尝试了所有文档化的步骤后问题仍未解决，或者怀疑存在硬件故障，应及时联系系统（主板/服务器）供应商或NVIDIA技术支持。问题可能特定于主板固件、GPU VBIOS版本，或者是某个硬件组件的缺陷。

长期考量

• 详细记录变更：对所有在BIOS和操作系统层面所做的配置更改进行细致的记录。
• 警惕更新影响：操作系统更新、驱动程序更新或内核更新可能会重新引入P2P通信问题，或改变IOMMU/ACS的行为，可能需要重新验证或应用之前的设置。
• 保持信息同步：关注NCCL、NVIDIA驱动程序和VLLM的更新发布，这些更新可能包含与P2P通信相关的修复或行为变更。

故障排除流程本身就体现了一种层级化的风险管理：从软件层面开始，逐步过渡到可能影响系统核心安全特性的BIOS更改。这种方法旨在优先尝试低风险方案，避免不必要的安全暴露。同时，如果选择禁用IOMMU/ACS，必须认识到这并非一劳永逸的“修复”，而是需要持续的安全关注和补偿性控制措施。系统的动态性也意味着，今日的解决方案可能因未来的软件更新而失效，因此保持对P2P通信稳定性的持续关注是必要的。

VII. 结论

NVIDIA L40 GPU由于缺乏NVLink技术，其在多GPU配置下（如VLLM服务所需）的性能高度依赖于通过PCIe总线实现的NCCL P2P通信效率。当此P2P路径受阻时，用户常会遇到VLLM启动挂起或性能不达预期的严重问题。

本报告的分析表明，禁用IOMMU（输入/输出内存管理单元）和PCI ACS（访问控制服务）是解决此类P2P通信障碍的一种被广泛报道且通常有效的方法，尤其适用于裸金属部署环境。然而，这一方案的代价是显著的：它移除了关键的硬件级DMA攻击防护，并使得依赖IOMMU的虚拟化功能无法使用。这些安全和功能上的权衡必须得到极其审慎的评估。

因此，禁用IOMMU和ACS应当被视为在所有其他侵入性较低的替代方案均告失败后的最后手段，并且仅应在裸金属系统上考虑实施，前提是用户已完全理解并能接受由此带来的安全风险，并已部署相应的缓解措施。对于需要虚拟化支持的环境，此方案通常是不可行的。

强烈建议优先探索和实施替代及补充策略，包括：

• 细致调整NCCL环境变量以诊断或规避问题。
• 严格管理和验证NVIDIA驱动程序、CUDA工具包及NCCL的版本兼容性。
• 全面优化系统BIOS中与PCIe链路、内存寻址（如"Above 4G Decoding", "Resizable BAR"）和NUMA相关的设置。
• 进行彻底的硬件健康检查。

核心挑战在于如何在最大化直接硬件访问带来的性能与通过隔离机制维护系统安全及稳定性之间取得平衡。当前常见的解决方案往往迫使在这两者之间做出妥协。用户的具体问题是HPC/AI领域更广泛挑战的一个缩影：随着系统日益复杂和性能需求不断攀升，各组件间的交互变得愈发精细和微妙，也更容易出现难以排查的故障。

最终，实现稳定、高性能的多GPU VLLM运行，需要一种整体性的方法，包括细致的系统配置、严谨的故障排除流程，以及对硬件、固件、驱动程序和应用软件栈之间复杂相互作用的深刻理解。在追求极致性能的同时，绝不能忽视系统的稳定性和安全性。

引用的著作

1. NVIDIA L40 GPU for Data Center | NVIDIA, 访问时间为 五月 8, 2025， https://www.nvidia.com/en-us/data-center/l40/
2. VLLM启动时NCCL遇到显卡P2P通信问题- 活在梦里, 访问时间为 五月 8, 2025， https://huo.zai.meng.li/p/vllm%E5%90%AF%E5%8A%A8%E6%97%B6nccl%E9%81%87%E5%88%B0%E6%98%BE%E5%8D%A1p2p%E9%80%9A%E4%BF%A1%E9%97%AE%E9%A2%98/
3. Troubleshooting — NCCL 2.26.5 documentation - NVIDIA Docs, 访问时间为 五月 8, 2025， https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html
4. simpleP2P verification failed on a VM with 2 L40S GPUs with P2P ..., 访问时间为 五月 8, 2025， https://forums.developer.nvidia.com/t/simplep2p-verification-failed-on-a-vm-with-2-l40s-gpus-with-p2p-enabled/316967/2
5. 1. NVIDIA GPUDirect Storage Installation and Troubleshooting ..., 访问时间为 五月 8, 2025， https://docs.nvidia.com/gpudirect-storage/troubleshooting-guide/index.html