The Edit That Fixed It: Applying NCCL_P2P_DISABLE=1 to a Production SGLang Service

Message 6223 is, on its face, one of the most unremarkable messages in the entire conversation: a single line confirming that an edit tool applied changes to a systemd service file. The message reads in full:

[assistant] [edit] /home/theuser/glm-kimi-sm120-rtx6000bw/sglang-qwen.service Edit applied successfully.

This brief confirmation represents the culmination of a deep and methodical diagnostic journey. It is the moment when a root cause analysis crystallizes into a concrete, production-applied fix.

The Diagnostic Trail

To understand why this edit matters, one must trace the events that led to it. The session had reconfigured the GPU topology on a Proxmox host, splitting 8× RTX PRO 6000 Blackwell GPUs between an LXC container running SGLang (4 GPUs) and a SEV-SNP confidential VM (4 GPUs). When the assistant attempted to launch SGLang with the new TP=4 configuration serving Qwen3.5-122B-A10B BF16, the server hung during init_torch_distributed — NCCL's distributed initialization deadlocked without completing.

The user provided a critical clue: IO_PAGE_FAULT events logged by AMD-Vi (the IOMMU) for the NVIDIA GPUs, showing addresses like 0x24000000000 and 0x34000010000 — these are GPU BAR addresses, indicating that the GPUs were attempting peer-to-peer DMA transfers and the IOMMU was blocking them. The assistant recognized this immediately as a symptom of IOMMU being in full translation mode rather than passthrough mode.

The root cause traced back to the SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) configuration. SEV-SNP requires amd_iommu=on in full translation mode — it cannot use the iommu=pt (passthrough) mode that had likely been in effect before. The kernel command line confirmed this: amd_iommu=on mem_encrypt=on kvm_amd.sev=1. With full IOMMU translation, every DMA transfer from a GPU must go through the IOMMU page tables, and the NVIDIA driver's P2P DMA mechanism — which bypasses the host memory and directly accesses peer GPU BARs — was generating addresses the IOMMU couldn't translate, causing page faults and corrupted data.

Confirming the Hypothesis

The assistant ran a series of targeted tests to isolate the failure. First, a simple single-GPU tensor operation confirmed basic CUDA functionality was intact. Next, torch.cuda.can_device_access_peer(i, j) returned True for all GPU pairs — the driver-level P2P capability flag was set. But when the assistant actually performed a GPU-to-GPU copy and compared the data, every single transfer produced a mismatch. All 12 directed pairs (4 GPUs × 3 peers each) returned corrupted data. The IOMMU was silently corrupting P2P DMA without raising a fatal error — a particularly insidious failure mode because the driver believed P2P was functional while the data was silently wrong.

The assistant then wrote a dedicated NCCL test script (nccl_test.py) and ran it with NCCL_P2P_DISABLE=1. This time, all four ranks completed all_reduce successfully, each computing the correct sum 10.0 (1+2+3+4). The fix was confirmed: disabling NCCL's P2P transport forced it to use SHM (shared memory) instead, which routes data through host memory via the IOMMU-compatible path.

The Layered Application Strategy

With the root cause confirmed, the assistant applied the fix in two layers, each serving a different purpose. The first layer was the global Python environment: it updated /usr/lib/python3.12/sitecustomize.py to set NCCL_P2P_DISABLE=1 along with other NCCL tuning parameters (protocol LL, Ring algorithm, 16 channels, 16 MB buffer size, 512 threads). This ensured that any Python process using NCCL would automatically inherit the P2P-disabled configuration, covering ad-hoc scripts and interactive testing.

The second layer — the one recorded in message 6223 — was the systemd service file. The assistant read the existing sglang-qwen.service file and applied an edit to add NCCL_P2P_DISABLE=1 and CUDA_DEVICE_MAX_CONNECTIONS=1 to the service's Environment directives. This is the production deployment path: the systemd service is what launches SGLang on boot or restart, and it must carry the fix independently of the Python environment. The edit was applied to the local copy of the service file at /home/theuser/glm-kimi-sm120-rtx6000bw/sglang-qwen.service, which is the source of truth for deployment.

Assumptions and Trade-offs

The fix carries an important assumption: that the performance cost of disabling P2P is acceptable. P2P DMA allows GPUs to read each other's memory directly over the PCIe bus without involving host memory, which is critical for high-throughput all-reduce in multi-GPU inference. By disabling it, NCCL falls back to SHM transport, which copies data through host memory and adds latency. However, the assistant had already established that for PCIe-connected GPUs (as opposed to NVLink-connected ones), the performance difference is manageable — and correctness is non-negotiable. The benchmarks that followed this fix confirmed the approach: the server achieved 108 tok/s single-stream and up to 2,800 tok/s at high concurrency, demonstrating that the workaround was viable.

The assistant also assumed that no BIOS-level fix was immediately available to restore P2P DMA under IOMMU translation. It investigated options like PCIe ACS (Access Control Services), ARI (Alternative Routing-ID Interpretation), and IOMMU coverage settings, but these would require a coordinated host reboot that was impossible with another tenant active on the machine. The software fix was the only practical path.

Output Knowledge Created

This message produced a corrected systemd service file that encodes the NCCL P2P workaround as a production configuration. It is the final link in a chain that began with IO_PAGE_FAULTs in dmesg, passed through CUDA P2P corruption tests, and ended with a working distributed inference server. The knowledge created is both specific (this particular service file) and generalizable: the pattern of diagnosing IOMMU-related P2P corruption by comparing actual GPU-to-GPU data transfers, and the workaround of NCCL_P2P_DISABLE=1 for systems where IOMMU passthrough is unavailable due to SEV-SNP requirements.

The edit in message 6223 is a single line of tool output, but it represents the successful conclusion of a complex debugging process — the point where understanding becomes action, and a production service is made to work correctly despite the constraints of its hardware and security configuration.