Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: vllm hanging on initializing #3644

Closed
megha95 opened this issue Mar 26, 2024 · 4 comments
Closed

[Bug]: vllm hanging on initializing #3644

megha95 opened this issue Mar 26, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@megha95
Copy link
Contributor

megha95 commented Mar 26, 2024

Your current environment


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 22.04.3 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.27.6
Libc version: glibc-2.35

Python version: 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-162-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 12.2.140
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA H100 80GB HBM3
GPU 1: NVIDIA H100 80GB HBM3
GPU 2: NVIDIA H100 80GB HBM3
GPU 3: NVIDIA H100 80GB HBM3
GPU 4: NVIDIA H100 80GB HBM3
GPU 5: NVIDIA H100 80GB HBM3
GPU 6: NVIDIA H100 80GB HBM3
GPU 7: NVIDIA H100 80GB HBM3

Nvidia driver version: 535.86.10
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.9.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.9.5
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
Address sizes:                      48 bits physical, 57 bits virtual
Byte Order:                         Little Endian
CPU(s):                             176
On-line CPU(s) list:                0-175
Vendor ID:                          GenuineIntel
Model name:                         Intel(R) Xeon(R) Platinum 8468V
CPU family:                         6
Model:                              143
Thread(s) per core:                 2
Core(s) per socket:                 44
Socket(s):                          2
Stepping:                           8
BogoMIPS:                           4800.00
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht
 syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm
pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpci
d_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpc
id avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16
 wbnoinvd arat avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid cldemot
e movdiri movdir64b md_clear arch_capabilities
Virtualization:                     VT-x
Hypervisor vendor:                  KVM
Virtualization type:                full
L1d cache:                          5.5 MiB (176 instances)
L1i cache:                          5.5 MiB (176 instances)
L2 cache:                           352 MiB (88 instances)
L3 cache:                           32 MiB (2 instances)
NUMA node(s):                       2
NUMA node0 CPU(s):                  0-87
NUMA node1 CPU(s):                  88-175
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:      Unknown: No mitigations
Vulnerability Retbleed:             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:      Mitigation; TSX disabled

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] onnx==1.14.0
[pip3] pytorch-quantization==2.1.2
[pip3] torch==2.1.2
[pip3] torch-tensorrt==0.0.0
[pip3] torchdata==0.7.0a0
[pip3] torchtext==0.16.0a0
[pip3] torchvision==0.16.0a0
[pip3] triton==2.1.0+e621604
[conda] Could not collectROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.3.3
vLLM Build Flags:
CUDA Archs: 5.2 6.0 6.1 7.0 7.2 7.5 8.0 8.6 8.7 9.0+PTX; ROCm: Disabled; Neuron: Disabled
CUDA Archs: 5.2 6.0 6.1 7.0 7.2 7.5 8.0 8.6 8.7 9.0+PTX; ROCm: Disabled; Neuron: Disabled

🐛 Describe the bug

I'm trying to run MPT-7B with tp_size=2 on H100 GPUs. Here is the code snippet I'm running:

from vllm import LLM, SamplingParams

# Create a sampling params object.
sampling_params = SamplingParams(temperature=0.8, top_p=0.95, max_tokens=300)

# Create an LLM.
model_name = "mosaicml/mpt-7b"
llm = LLM(model=model_name, trust_remote_code=True, tensor_parallel_size=2) #, enforce_eager=True)

# Generate texts from the prompts. The output is a list of RequestOutput objects
# that contain the prompt, generated text, and other information.
outputs = llm.generate(["Write a poem on spiders."], sampling_params)
print(outputs) 

The initialization step LLM() is just stuck and then shows a socket timeout error. Full trace here:

2024-03-26 18:23:55,708 INFO worker.py:1752 -- Started a local Ray instance.
INFO 03-26 18:23:57 llm_engine.py:70] Initializing an LLM engine (v0.3.3) with config: model='mosaicml/mpt-7b', tokenizer='mosaicml/mpt-7b', tokenizer_mode=auto, revision=None, tokenizer_revision=None, trust_remote_code=True, dtype=torch.bfloat16, max_seq_len=2048, download_dir=None, load_format=auto, tensor_parallel_size=2, disable_custom_all_reduce=True, quantization=None, enforce_eager=False, kv_cache_dtype=auto, device_config=cuda, seed=0)
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
WARNING 03-26 18:23:57 llm_engine.py:181] The tokenizer's vocabulary size 50277 does not match the model's vocabulary size 50432. This might cause an error in decoding. Please change config.json to match the tokenizer's vocabulary size.
INFO 03-26 18:24:02 selector.py:15] Using FlashAttention backend.
(RayWorkerVllm pid=298519) INFO 03-26 18:24:03 selector.py:15] Using FlashAttention backend.
^[[E socket.cpp:922] [c10d] The client socket has timed out after 1800s while trying to connect to (172.27.21.224, 43115).
Traceback (most recent call last):
  File "/workspace/vllm-pvt/../vllm_run.py", line 11, in <module>
    llm = LLM(model=model_name, trust_remote_code=True, tensor_parallel_size=2) #, enforce_eager=True)
  File "/workspace/vllm-pvt/vllm/entrypoints/llm.py", line 111, in __init__
    self.llm_engine = LLMEngine.from_engine_args(engine_args)
  File "/workspace/vllm-pvt/vllm/engine/llm_engine.py", line 150, in from_engine_args
    engine = cls(*engine_configs,
  File "/workspace/vllm-pvt/vllm/engine/llm_engine.py", line 106, in __init__
    self.model_executor = executor_class(model_config, cache_config,
  File "/workspace/vllm-pvt/vllm/executor/ray_gpu_executor.py", line 62, in __init__
    self._init_workers_ray(placement_group)
  File "/workspace/vllm-pvt/vllm/executor/ray_gpu_executor.py", line 193, in _init_workers_ray
    self._run_workers("init_device",
  File "/workspace/vllm-pvt/vllm/executor/ray_gpu_executor.py", line 321, in _run_workers
    driver_worker_output = getattr(self.driver_worker,
  File "/workspace/vllm-pvt/vllm/worker/worker.py", line 100, in init_device
    init_distributed_environment(self.parallel_config, self.rank,
  File "/workspace/vllm-pvt/vllm/worker/worker.py", line 269, in init_distributed_environment
    torch.distributed.init_process_group(
  File "/usr/local/lib/python3.10/dist-packages/torch/distributed/c10d_logger.py", line 74, in wrapper
    func_return = func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/distributed/distributed_c10d.py", line 1141, in init_process_group
    store, rank, world_size = next(rendezvous_iterator)
  File "/usr/local/lib/python3.10/dist-packages/torch/distributed/rendezvous.py", line 196, in _tcp_rendezvous_handler
    store = _create_c10d_store(result.hostname, result.port, rank, world_size, timeout)
  File "/usr/local/lib/python3.10/dist-packages/torch/distributed/rendezvous.py", line 172, in _create_c10d_store
    return TCPStore(
TimeoutError: The client socket has timed out after 1800s while trying to connect to (xx.xx.xxx, xxxx).
@megha95 megha95 added the bug Something isn't working label Mar 26, 2024
@youkaichao
Copy link
Member

Does #3419 solve your problem? It seems somehow the code guess your ip is 172.27.21.224 but it is not reachable.

You can try the current code on main branch, and set HOST_IP .

Or you can try this docker image docker pull us-central1-docker.pkg.dev/vllm-405802/vllm-ci-test-repo/vllm-test:983243ea9941b4178c53ebc4631c13f21de5a624 . It has a new backend and should be more stable. Your feedback is warmly welcomed and would help our decision.

This was referenced Mar 27, 2024
@megha95
Copy link
Contributor Author

megha95 commented Mar 28, 2024

My IP is not 172.27.21.224. I had to manually set HOST_IP and then it worked. Why is it trying to connect to wrong IP? I wasn't facing such issues with last release. Would appreciate if this can be corrected with the new release.

@youkaichao
Copy link
Member

Yes #3419 will be included in the new release. Glad it helps :)

I have no idea why it tries to reach a strange ip 172.27.21.224 :(

@AloneGu
Copy link

AloneGu commented Nov 5, 2024

try

VLLM_HOST_IP=0.0.0.0 python3 xxx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants