vllm-project / vllm

A high-throughput and memory-efficient inference and serving engine for LLMs
https://docs.vllm.ai
Apache License 2.0
27.07k stars 3.98k forks source link

[Bug]: Obvious hang caused by Custom All Reduce OP(Valuable Debug Info Obtained) #8410

Open PYNing opened 1 week ago

PYNing commented 1 week ago

Your current environment

The output of `python collect_env.py` ```text PyTorch version: 2.4.0+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.30.1 Libc version: glibc-2.31 Python version: 3.10.14 (main, Apr 6 2024, 18:45:05) [GCC 9.4.0] (64-bit runtime) Python platform: Linux-5.4.0-125-generic-x86_64-with-glibc2.31 Is CUDA available: True CUDA runtime version: Could not collect CUDA_MODULE_LOADING set to: LAZY GPU models and configuration: GPU 0: NVIDIA A800-SXM4-80GB GPU 1: NVIDIA A800-SXM4-80GB GPU 2: NVIDIA A800-SXM4-80GB GPU 3: NVIDIA A800-SXM4-80GB GPU 4: NVIDIA A800-SXM4-80GB GPU 5: NVIDIA A800-SXM4-80GB GPU 6: NVIDIA A800-SXM4-80GB GPU 7: NVIDIA A800-SXM4-80GB Nvidia driver version: 525.105.17 cuDNN version: Could not collect 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): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 2 Core(s) per socket: 32 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 106 Model name: Intel(R) Xeon(R) Platinum 8358P CPU @ 2.60GHz Stepping: 6 Frequency boost: enabled CPU MHz: 900.000 CPU max MHz: 3400.0000 CPU min MHz: 800.0000 BogoMIPS: 5200.00 Virtualization: VT-x L1d cache: 3 MiB L1i cache: 2 MiB L2 cache: 80 MiB L3 cache: 96 MiB NUMA node0 CPU(s): 0-31,64-95 NUMA node1 CPU(s): 32-63,96-127 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable 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 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 pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_dea dline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 invpcid_single 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_occ up_llc cqm_mbm_total cqm_mbm_local wbnoinvd dtherm ida arat pln pts avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid md_clear pconfig f lush_l1d arch_capabilities Versions of relevant libraries: [pip3] flashinfer==0.0.9+cu121torch2.3 [pip3] mypy==1.11.2 [pip3] mypy-extensions==1.0.0 [pip3] numpy==1.26.4 [pip3] nvidia-cublas-cu12==12.1.3.1 [pip3] nvidia-cuda-cupti-cu12==12.1.105 [pip3] nvidia-cuda-nvrtc-cu12==12.1.105 [pip3] nvidia-cuda-runtime-cu12==12.1.105 [pip3] nvidia-cudnn-cu12==9.1.0.70 [pip3] nvidia-cufft-cu12==11.0.2.54 [pip3] nvidia-curand-cu12==10.3.2.106 [pip3] nvidia-cusolver-cu12==11.4.5.107 [pip3] nvidia-cusparse-cu12==12.1.0.106 [pip3] nvidia-ml-py==12.555.43 [pip3] nvidia-nccl-cu12==2.20.5 [pip3] nvidia-nvjitlink-cu12==12.5.82 [pip3] nvidia-nvtx-cu12==12.1.105 [pip3] pyzmq==26.0.3 [pip3] torch==2.4.0 [pip3] torchvision==0.19.0 [pip3] transformers==4.43.2 [pip3] triton==3.0.0 [conda] Could not collect ROCM Version: Could not collect Neuron SDK Version: N/A vLLM Version: 0.5.4@4db5176d9758b720b05460c50ace3c01026eb158 vLLM Build Flags: CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled GPU Topology: GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 NIC0 NIC1 NIC2 NIC3 NIC4 NIC5 NIC6 NIC7 CPU Affinity NUMA Affinity GPU0 X NV8 NV8 NV8 NV8 NV8 NV8 NV8 PXB PXB PXB NODE SYS SYS SYS SYS 0-31,64-95 0 GPU1 NV8 X NV8 NV8 NV8 NV8 NV8 NV8 PXB PXB PXB NODE SYS SYS SYS SYS 0-31,64-95 0 GPU2 NV8 NV8 X NV8 NV8 NV8 NV8 NV8 NODE NODE NODE PXB SYS SYS SYS SYS 0-31,64-95 0 GPU3 NV8 NV8 NV8 X NV8 NV8 NV8 NV8 NODE NODE NODE PXB SYS SYS SYS SYS 0-31,64-95 0 GPU4 NV8 NV8 NV8 NV8 X NV8 NV8 NV8 SYS SYS SYS SYS PXB PXB PXB NODE 32-63,96-127 1 GPU5 NV8 NV8 NV8 NV8 NV8 X NV8 NV8 SYS SYS SYS SYS PXB PXB PXB NODE 32-63,96-127 1 GPU6 NV8 NV8 NV8 NV8 NV8 NV8 X NV8 SYS SYS SYS SYS NODE NODE NODE PXB 32-63,96-127 1 GPU7 NV8 NV8 NV8 NV8 NV8 NV8 NV8 X SYS SYS SYS SYS NODE NODE NODE PXB 32-63,96-127 1 NIC0 PXB PXB NODE NODE SYS SYS SYS SYS X PIX PIX NODE SYS SYS SYS SYS NIC1 PXB PXB NODE NODE SYS SYS SYS SYS PIX X PIX NODE SYS SYS SYS SYS NIC2 PXB PXB NODE NODE SYS SYS SYS SYS PIX PIX X NODE SYS SYS SYS SYS NIC3 NODE NODE PXB PXB SYS SYS SYS SYS NODE NODE NODE X SYS SYS SYS SYS NIC4 SYS SYS SYS SYS PXB PXB NODE NODE SYS SYS SYS SYS X PIX PIX NODE NIC5 SYS SYS SYS SYS PXB PXB NODE NODE SYS SYS SYS SYS PIX X PIX NODE NIC6 SYS SYS SYS SYS PXB PXB NODE NODE SYS SYS SYS SYS PIX PIX X NODE NIC7 SYS SYS SYS SYS NODE NODE PXB PXB SYS SYS SYS SYS NODE NODE NODE X 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 NIC Legend: NIC0: mlx5_0 NIC1: mlx5_1 NIC2: mlx5_2 NIC3: mlx5_3 NIC4: mlx5_4 NIC5: mlx5_5 NIC6: mlx5_6 NIC7: mlx5_7 ```

Model Input Dumps

Not available at the moment.

🐛 Describe the bug

The problem I encountered was "NCCL hangs and causes timeout", which is similar to https://github.com/vllm-project/vllm/issues/5484

Before debugging, I have read https://docs.vllm.ai/en/latest/getting_started/debugging.html ,and add additional log in https://github.com/vllm-project/vllm/blob/7de49aa86c7f169eb0962b6db29ad53fff519ffb/vllm/_custom_ops.py#L825-L827

Here is the service launch code for debugging CUDA_LAUNCH_BLOCKING=1 python3 -m vllm.entrypoints.openai.api_server --served-model-name Qwen2-72B-Instrust --model /data/Qwen2-72B-Instruct --tensor-parallel-size 8 --port 8000 --max_model_len 4096 --trust-remote-code --max_num_seqs 32 --dytpe bfloat16 --enforce-eager

When the hang occurs, I see an obvious phenomenon, as shown in the picture below: 1726142733383

(1)Obviously, the root cause is that RANK2 is hanged. In my opinion they should end communication at the same time and print a log, when ‘CUDA_LAUNCH_BLOCKING=1’ was added. (2)‘--disable_custom_all_reduce’ seem to work. (3)This bug appears in both version 0.5.4 and version 0.6.0. I'd be happy to take more debugging guidance from you and provide more debugging information.

Before submitting a new issue...

youkaichao commented 1 week ago

thanks for the information! does it always hang when you run some input?

I think @kanghui0204 finds some race condition in the custom allreduce, it looks very relevant.

youkaichao commented 1 week ago

these debug information are indeed valuable 👍

PYNing commented 1 week ago

thanks for the information! does it always hang when you run some input?

I think @kanghui0204 finds some race condition in the custom allreduce, it looks very relevant.

@youkaichao Supplement: I used 4 A800s (with exactly the same configuration) for the test. For the same samples, 2 passed the test, while 2 failed, and the hang time was different. This seems to be more related to the slight differences in the hardware of the specific machine, such as NVLink latency.

youkaichao commented 1 week ago

cc @hanzhi713

hanzhi713 commented 1 week ago

Hard to say what caused the problem. Could you please try the following:

  1. Run the test with 2GPUs and see if you can reproduce the hang
  2. For the 4GPU test that hangs, delete the if statement but keep __threadfence_system() here https://github.com/vllm-project/vllm/blob/8f44a92d852935c8378eaab85bad47ef3174e02b/csrc/custom_all_reduce.cuh#L156, and then build vllm from source. I want to see if an unconditional __threadfence_system works.
HydraQYH commented 1 week ago

Hard to say what caused the problem. Could you please try the following:

  1. Run the test with 2GPUs and see if you can reproduce the hang
  2. For the 4GPU test that hangs, delete the if statement but keep __threadfence_system() here https://github.com/vllm-project/vllm/blob/8f44a92d852935c8378eaab85bad47ef3174e02b/csrc/custom_all_reduce.cuh#L156 , and then build vllm from source. I want to see if an unconditional __threadfence_system works.

@hanzhi713 I think using a weaker fence(release) can solve this reorder. That is my idea: https://github.com/vllm-project/vllm/commit/247829b4f805d75b6ba706faf5c1591bde9eb96d

But i try this with no performance gaining compare to __threadfence_system(). It seem like that stronger fence(__threadfence_system()) has same performance with weaker fence on A100 with NVLink.