Repository: vllm-project/vllm

Issue:
[Bug]: LLM is not getting loaded on multiple GPUs but works fine on a single GPU
### Your current environment

```
PyTorch version: 2.1.2
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.6 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Clang version: Could not collect
CMake version: version 3.29.1
Libc version: glibc-2.31

Python version: 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-94-generic-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 12.1.105
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA RTX 6000 Ada Generation
GPU 1: NVIDIA RTX 6000 Ada Generation
GPU 2: NVIDIA RTX 6000 Ada Generation
GPU 3: NVIDIA RTX 6000 Ada Generation

Nvidia driver version: 535.154.05
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.9.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      46 bits physical, 57 bits virtual
CPU(s):                             96
On-line CPU(s) list:                0-95
Thread(s) per core:                 2
Core(s) per socket:                 24
Socket(s):                          2
NUMA node(s):                       2
Vendor ID:                          GenuineIntel
CPU family:                         6
Model:                              143
Model name:                         Intel(R) Xeon(R) Gold 5418Y
Stepping:                           8
Frequency boost:                    enabled
CPU MHz:                            989.502
CPU max MHz:                        2001.0000
CPU min MHz:                        800.0000
BogoMIPS:                           4000.00
Virtualization:                     VT-x
L1d cache:                          2.3 MiB
L1i cache:                          1.5 MiB
L2 cache:                           96 MiB
L3 cache:                           90 MiB
NUMA node0 CPU(s):                  0-23,48-71
NUMA node1 CPU(s):                  24-47,72-95
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 invpcid_single cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

Versions of relevant libraries:
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.2
[pip3] onnxruntime==1.17.1
[pip3] torch==2.1.2
[pip3] torchaudio==2.1.2
[pip3] torchelastic==0.2.2
[pip3] torchvision==0.16.2
[pip3] triton==2.1.0
[conda] blas                      1.0                         mkl  
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] libjpeg-turbo             2.0.0                h9bf148f_0    pytorch
[conda] mkl                       2023.1.0         h213fc3f_46344  
[conda] mkl-service               2.4.0           py310h5eee18b_1  
[conda] mkl_fft                   1.3.8           py310h5eee18b_0  
[conda] mkl_random                1.2.4           py310hdb19cb5_0  
[conda] numpy                     1.26.2          py310h5f9d8c6_0  
[conda] numpy-base                1.26.2          py310hb5e798b_0  
[conda] pytorch                   2.1.2           py3.10_cuda12.1_cudnn8.9.2_0    pytorch
[conda] pytorch-cuda              12.1                 ha16c6d3_5    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                2.1.2               py310_cu121    pytorch
[conda] torchelastic              0.2.2                    pypi_0    pypi
[conda] torchtriton               2.1.0                     py310    pytorch
[conda] torchvision               0.16.2              py310_cu121    pytorchROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.4.0.post1
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    GPU2    GPU3    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      PIX     SYS     SYS     24-47,72-95     1               N/A
GPU1    PIX      X      SYS     SYS     24-47,72-95     1               N/A
GPU2    SYS     SYS      X      PIX     24-47,72-95     1               N/A
GPU3    SYS     SYS     PIX      X      24-47,72-95     1               N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks
```


### 🐛 Describe the bug

When I try to load the model by using the following command

```
from vllm import LLM
llm = LLM(model="./mistral/models--mistralai--Mistral-7B-Instruct-v0.2/snapshots/", tensor_parallel_size=2)
```
The model is not loaded at all, I get the following information on the CLI and that's it. The loading is never finished. 

![image](https://github.com/vllm-project/vllm/assets/60582874/ff525d46-5cba-409a-8836-1c086bcd570a)

I can see that the 2 GPU devices are occupied while the above message is displayed, but nothing else. The line of code is never fully executed.

When I try to load the model using only one GPU, the loading process is smooth.
```
from vllm import LLM
llm = LLM(model="./mistral/models--mistralai--Mistral-7B-Instruct-v0.2/snapshots/", tensor_parallel_size=1)
```

Below is the screenshot of the successfull loading message:
![image](https://github.com/vllm-project/vllm/assets/60582874/fad5269a-4137-4c12-bf2b-7764d440057b)

The llm inference is quite fast and everyhting works as expected. 

So the problem clearly lies with multiple GPUs. This issue happens with all the models and not particular to just one organisation. Can someone please help me in this regard? What am I doing wrong? Is it something due to nccl or is something mssing?
Any help is appreciated, thanks :)


Discussion:
@venki-lfc when stalled, what does nvidia-smi report for GPU %load and memory usage? 
This is how the GPU looks like during the stalling.
![Capture](https://github.com/vllm-project/vllm/assets/60582874/456f523e-fe6d-49bb-bf9c-9880d0670573)

This image shows the process names
![Capture2](https://github.com/vllm-project/vllm/assets/60582874/0dcb66c2-f069-460b-a1fd-960b0c67472b)

Same here. Both for 0.3.3 and 0.4.0
Thanks @venki-lfc  this matches my experience, 0.4.0-post1 on _only 4 specific GPUs_ on an 8x H100-PCIe system: 

![image](https://github.com/vllm-project/vllm/assets/11641117/4a149ab3-d54e-4fa0-97c9-ad67414cdb42)

I only see this behavior for these 4 specific GPUs on the system; other configurations (e.g. 1, 2, or 8 GPU) appear unaffected even when they utilize the same hardware.

I suspect there's some sort of NCCL race/deadlock occurring, triggered by differences in PCIe bus layout for (GPU 0/1/2/3, with 0/1 and 2/3 separated by multiple PCI hops) and (GPU 4/5/6/7, 3 of which share a common PCI switch).

```


	GPU0	GPU1	GPU2	GPU3	GPU4	GPU5	GPU6	GPU7	CPU Affinity	NUMA Affinity	GPU NUMA ID
GPU0	 X 	NV12	SYS	SYS	SYS	SYS	SYS	SYS	0-95	0		N/A
GPU1	NV12	 X 	SYS	SYS	SYS	SYS	SYS	SYS	0-95	0		N/A
GPU2	SYS	SYS	 X 	NV12	SYS	SYS	SYS	SYS	0-95	0		N/A
GPU3	SYS	SYS	NV12	 X 	SYS	SYS	SYS	SYS	0-95	0		N/A
GPU4	SYS	SYS	SYS	SYS	 X 	SYS	SYS	NV12	96-191	1		N/A
GPU5	SYS	SYS	SYS	SYS	SYS	 X 	NV12	PIX	96-191	1		N/A
GPU6	SYS	SYS	SYS	SYS	SYS	NV12	 X 	PIX	96-191	1		N/A
GPU7	SYS	SYS	SYS	SYS	NV12	PIX	PIX	 X 	96-191	1		N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks
```


```
-+-[0000:e0]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 +-[0000:c0]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 |           +-01.1-[c1-c8]----00.0-[c2-c8]--+-00.0-[c3]----00.0  NVIDIA Corporation GH100 [H100 PCIe]  GPU5 NVLINK 4
 |           |                               +-01.0-[c4]----00.0  NVIDIA Corporation GH100 [H100 PCIe]  GPU6 NVLINK 4
 |           |                               +-02.0-[c5]----00.0  NVIDIA Corporation GH100 [H100 PCIe]  GPU7 NVLINK 3
 |           |                               +-03.0-[c6]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
 |           |                               +-04.0-[c7]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
 |           |                               \-1f.0-[c8]----00.0  Broadcom / LSI PCIe Switch management endpoint
 +-[0000:a0]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 +-[0000:80]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 |           +-01.1-[81-87]----00.0-[82-87]--+-00.0-[83]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
 |           |                               +-01.0-[84]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
 |           |                               +-02.0-[85]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
 |           |                               +-03.0-[86]--+-00.0  Intel Corporation Ethernet Controller E810-C for QSFP
 |           |                               |            \-00.1  Intel Corporation Ethernet Controller E810-C for QSFP
 |           |                               \-04.0-[87]----00.0  NVIDIA Corporation GH100 [H100 PCIe]  GPU4 NVLINK 3
 |           \-07.1-[88]--+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14ac
 |                        \-00.5  Advanced Micro Devices, Inc. [AMD] Genoa CCP/PSP 4.0 Device
 +-[0000:60]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 +-[0000:40]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
 |           +-01.1-[41-48]----00.0-[42-48]--+-00.0-[43]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
 |           |                               +-01.0-[44]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
 |           |                               +-02.0-[45]--+-00.0  Intel Corporation Ethernet Controller E810-C for QSFP
 |           |                               |            \-00.1  Intel Corporation Ethernet Controller E810-C for QSFP
 |           |                               +-03.0-[46]----00.0  NVIDIA Corporation GH100 [H100 PCIe]   GPU2 NVLINK 2
 |           |                               +-04.0-[47]----00.0  NVIDIA Corporation GH100 [H100 PCIe]   GPU3 NVLINK 2
 |           |                               \-1f.0-[48]----00.0  Broadcom / LSI PCIe Switch management endpoint
 \-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14a4
             +-01.1-[01-07]----00.0-[02-07]--+-00.0-[03]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
             |                               +-01.0-[04]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
             |                               +-02.0-[05]----00.0  Broadcom / LSI Virtual PCIe Placeholder Endpoint
             |                               +-03.0-[06]----00.0  NVIDIA Corporation GH100 [H100 PCIe]   GPU0 NVLINK 1
             |                               \-04.0-[07]----00.0  NVIDIA Corporation GH100 [H100 PCIe]   GPU1 NVLINK 1
             +-05.1-[08]--+-00.0  Intel Corporation Ethernet Controller X710 for 10GBASE-T
             |            \-00.1  Intel Corporation Ethernet Controller X710 for 10GBASE-T
```

So far we're seeing this on AMD and Intel CPU and Ada/Hopper GPU's.   (My collect_env output is @ [#3892](https://github.com/vllm-project/vllm/issues/3892)).
@alexanderfrey what hardware are you using?

Testing various releases of the stock Docker containers with Llama2-70B, I see:

v.0.4.0:  Hangs (nvidia-nccl-cu12 2.18.1; ~~libnccl2 2.17.1-1+cuda12.1~~)
v0.3.3: OK (nvidia-nccl-cu12 2.18.1; ~~libnccl2 2.17.1-1+cuda12.1~~)
v0.3.2: OK
v.0.2.7:  OK

It was straightforward to test by swapping containers, but I won't have time to perform a full bisect/rebuild 0.3.3->0.4.0 for a few weeks.
@agt did you change nccl version via `VLLM_NCCL_SO_PATH` ? Normally people don't use `nccl 2.17.1` .
@youkaichao  That's the version shipped in [https://hub.docker.com/r/vllm/vllm-openai](https://hub.docker.com/r/vllm/vllm-openai) - happy to swap in a new version via VLLM_NCCL_SO_PATH, which would you suggest?

> @agt did you change nccl version via `VLLM_NCCL_SO_PATH` ? Normally people don't use `nccl 2.17.1` .

I just did a `pip intall vllm` on the `pytorch/pytorch:2.1.2-cuda12.1-cudnn8-devel` image. So nccl 2.17.1 came together.
I just found a solution that works!
I set the env variable as `export NCCL_P2P_DISABLE=1`

```
from langchain_community.llms import VLLM

llm = VLLM(model="./mixtral-8x7B-instruct-v0.1/snapshots/1e637f2d7cb0a9d6fb1922f305cb784995190a83", tensor_parallel_size=4, trust_remote_code=True, enforce_eager=True)
```

This works for me now :)
@venki-lfc glad to hear!  Disabling P2P will hurt performance, so I'd like to continue pursuing - want to keep this issue open, or should I create a new one?
> @venki-lfc glad to hear! Disabling P2P will hurt performance, so I'd like to continue pursuing - want to keep this issue open, or should I create a new one?

I guess we can keep the issue open :)  Obviously mine's just a work around and doesn't address the root cause of the issue. 
> @agt did you change nccl version via `VLLM_NCCL_SO_PATH` ? Normally people don't use `nccl 2.17.1` .

Ahh - 2.17.1 was the system NCCL installed under /usr/lib;    the PyPi version was hiding under 'libnccl.so.2', and is indeed NCCL version 2.18.1+cuda12.1 .  That's consistent with the Pytorch 2.1.2 requirements.
> I just found a solution that works!
> I set the env variable as `export NCCL_P2P_DISABLE=1`

Good job! nccl is quite a black box, and we have a hard time with it :(
> Thanks @venki-lfc this matches my experience, 0.4.0-post1 on _only 4 specific GPUs_ on an 8x H100-PCIe system:
> I only see this behavior for these 4 specific GPUs on the system; other configurations (e.g. 1, 2, or 8 GPU) appear unaffected even when they utilize the same hardware.
> 
> I suspect there's some sort of NCCL race/deadlock occurring, triggered by differences in PCIe bus layout for (GPU 0/1/2/3, with 0/1 and 2/3 separated by multiple PCI hops) and (GPU 4/5/6/7, 3 of which share a common PCI switch).

I've tested on both 8xH100 and 8xA100-40GB and cannot seem to load a model on even `tensor-parallel-size=1`. I've also tried disabling P2P, but that still doesn't help. Any suggestions? Here's my env:
```
PyTorch version: 2.1.2+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.6 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Clang version: Could not collect
CMake version: version 3.26.3
Libc version: glibc-2.31

Python version: 3.11.8 (main, Feb 25 2024, 16:41:26) [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-1048-oracle-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 12.1.105
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA A100-SXM4-40GB
GPU 1: NVIDIA A100-SXM4-40GB
GPU 2: NVIDIA A100-SXM4-40GB
GPU 3: NVIDIA A100-SXM4-40GB
GPU 4: NVIDIA A100-SXM4-40GB
GPU 5: NVIDIA A100-SXM4-40GB
GPU 6: NVIDIA A100-SXM4-40GB
GPU 7: NVIDIA A100-SXM4-40GB

Nvidia driver version: 535.129.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.9.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.9.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      48 bits physical, 48 bits virtual
CPU(s):                             256
On-line CPU(s) list:                0-254
Off-line CPU(s) list:               255
Thread(s) per core:                 1
Core(s) per socket:                 64
Socket(s):                          2
NUMA node(s):                       8
Vendor ID:                          AuthenticAMD
CPU family:                         25
Model:                              1
Model name:                         AMD EPYC 7J13 64-Core Processor
Stepping:                           1
Frequency boost:                    enabled
CPU MHz:                            2550.000
CPU max MHz:                        3673.0950
CPU min MHz:                        1500.0000
BogoMIPS:                           4900.16
Virtualization:                     AMD-V
L1d cache:                          2 MiB
L1i cache:                          2 MiB
L2 cache:                           32 MiB
L3 cache:                           256 MiB
NUMA node0 CPU(s):                  0-15,128-143
NUMA node1 CPU(s):                  16-31,144-159
NUMA node2 CPU(s):                  32-47,160-175
NUMA node3 CPU(s):                  48-63,176-191
NUMA node4 CPU(s):                  64-79,192-207
NUMA node5 CPU(s):                  80-95,208-223
NUMA node6 CPU(s):                  96-111,224-239
NUMA node7 CPU(s):                  112-127,240-254
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Vulnerable
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
Vulnerability Spectre v2:           Vulnerable, IBPB: disabled, STIBP: disabled, PBRSB-eIBRS: Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] torch==2.1.2
[pip3] torchvision==0.17.1+cu121
[pip3] triton==2.1.0
[conda] Could not collect
```
> > I suspect there's some sort of NCCL race/deadlock occurring, triggered by differences in PCIe bus layout for (GPU 0/1/2/3, with 0/1 and 2/3 separated by multiple PCI hops) and (GPU 4/5/6/7, 3 of which share a common PCI switch).
> I've tested on both 8xH100 and 8xA100-40GB and cannot seem to load a model on even `tensor-parallel-size=1`. I've also tried disabling P2P, but that still doesn't help. Any suggestions? `

~~Disabling CUDA graphs (--enforce-eager) seems to sidestep the problem for me, like NCCL_P2P_DISABLE=1 at the cost of reduced performance.~~ Lots of changes to Pytorch, NCCL, etc. since 0.4.0.post1, hope to build current code this week and test with cuda graphs enabled.   _Apparent functionality was a 1-time fluke; see next comment._
@youkaichao  Thank you for #4079 - throwing that into my 0.4.0.post1 container, I found that the 3 non-lead workers all were stuck within CustomAllreduce._gather_ipc_meta() despite the code's [intention to disable CustomAllReduce](https://github.com/vllm-project/vllm/blob/0003e9154bf1091d0de7ca7a6c7f1253df1eca5b/vllm/distributed/device_communicators/custom_all_reduce.py#L56) as  _"it's not supported on more than two PCIe-only GPUs."_.  

Last call logged across the various processes before the stall:  ( full @ [vllm_trace_frame_for_process.tgz](https://github.com/vllm-project/vllm/files/14984792/vllm_trace_frame_for_process.tgz) )
```
==> vllm_trace_frame_for_process_1_thread_139973314331072_at_2024-04-15_17:58:24.978956.log <==
2024-04-15 17:59:04.732274 Return from init_device in /workspace/vllm/worker/worker.py:104

==> vllm_trace_frame_for_process_1004_thread_139786598171072_at_2024-04-15_17:58:33.965163.log <==
2024-04-15 17:58:43.840296 Return from get_node_and_gpu_ids in /workspace/vllm/engine/ray_utils.py:53

==> vllm_trace_frame_for_process_1113_thread_140163469054400_at_2024-04-15_17:58:36.739553.log <==
2024-04-15 17:59:04.981153 Call to _gather_ipc_meta in /workspace/vllm/model_executor/parallel_utils/custom_all_reduce.py:222

==> vllm_trace_frame_for_process_1228_thread_139805130449344_at_2024-04-15_17:58:39.506931.log <==
2024-04-15 17:59:05.511878 Call to _gather_ipc_meta in /workspace/vllm/model_executor/parallel_utils/custom_all_reduce.py:222

==> vllm_trace_frame_for_process_1333_thread_140525308137920_at_2024-04-15_17:58:42.339446.log <==
2024-04-15 17:59:04.952552 Call to _gather_ipc_meta in /workspace/vllm/model_executor/parallel_utils/custom_all_reduce.py:222
```

Launching with ```--disable-custom-all-reduce``` has been solid now across dozens of restarts in various configurations, so for me the mystery is now why the workers end up using that code.

@venki-lfc  @nidhishs  would you mind checking whether adding that flag fixes things for you?  (I believe disabling custom AllReduce should impact performance less than disabling P2P alltogether.)


Resolving patch:
diff --git a/vllm/distributed/device_communicators/custom_all_reduce.py b/vllm/distributed/device_communicators/custom_all_reduce.py
--- a/vllm/distributed/device_communicators/custom_all_reduce.py
+++ b/vllm/distributed/device_communicators/custom_all_reduce.py
@@ -145,8 +145,10 @@ def _is_full_nvlink(rank, world_size):
     for i in range(world_size):
         if i != rank:
             try:
-                link_state = pynvml.nvmlDeviceGetNvLinkState(handle, i)
-                if not link_state:
+                peer_handle = pynvml.nvmlDeviceGetHandleByIndex(i)
+                p2p_status = pynvml.nvmlDeviceGetP2PStatus(
+                    handle, peer_handle, pynvml.NVML_P2P_CAPS_INDEX_NVLINK)
+                if p2p_status != pynvml.NVML_P2P_STATUS_OK:
                     return False
             except pynvml.NVMLError as error:
                 logger.info(


Test patch: