Error executing method 'init_device'. This might cause deadlock in distributed execution. [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] Traceback (most recent call last): [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] File "/usr/local/lib/python3.10/dist-packages/vllm/worker/worker_base.py", line 601, in execute_method [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] return run_method(target, method, args, kwargs) [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] File "/usr/local/lib/python3.10/dist-packages/vllm/utils.py", line 2311, in run_method [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] return func(*args, **kwargs) [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] File "/usr/local/lib/python3.10/dist-packages/vllm/spec_decode/spec_decode_worker.py", line 355, in init_device [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] self.scorer_worker.load_model() [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/model_loader/loader.py", line 388, in load_model [repeated 90x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] self.model_runner.load_model() [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 17:09:26 worker_base.py:609] self.model = get_model(vllm_config=self.vllm_config) [repeated 30x across cluster] (RayWorkerWrapper pid=18360, ip=13.13.6.12) ERROR 04-02 1
时间: 2025-04-03 09:15:45 浏览: 100
### 可能的原因分析
在分布式执行环境中,`init_device` 方法引发的死锁问题通常与资源分配、通信框架配置以及底层硬件支持有关。以下是几个常见的原因及其对应的解决方案:
#### 1. **TensorFlow Server 创建错误**
如果 `tf.errors.OpError` 或其子类被抛出,则表明 TensorFlow 的服务器创建过程中出现了异常[^1]。这种情况下,可以尝试以下措施:
- 确保集群中的每台机器都已正确安装 TensorFlow 并且版本一致。
- 验证网络连接是否正常,特别是当使用多机环境时。
#### 2. **NCCL 安装或配置问题**
对于涉及 GPU 的分布式训练任务,NCCL 是实现高效设备间通信的核心库。如果 NCCL 版本不匹配或者未正确初始化,可能会导致死锁或其他同步问题[^2]。可以通过运行以下命令验证 NCCL 是否可用:
```bash
python -m torch.distributed.check_nccl_version
```
此外,设置一些调试相关的环境变量可以帮助定位具体问题所在:
```bash
export NCCL_DEBUG=INFO
export NCCL_P2P_DISABLE=1
export NCCL_SHM_DISABLE=1
```
这些变量的作用分别是启用详细的日志记录、禁用点对点传输模式以及关闭共享内存机制。通过调整它们能够有效规避某些特定场景下的兼容性隐患。
#### 3. **资源泄漏或权限不足**
根据描述,“resource_tracker” 提醒存在信号量泄露现象,这意味着可能存在未释放的系统资源占用情况;另外,在基于 NFS (Network File System) 这样的远程存储介质上操作文件时也容易遇到并发访问限制所引起的锁定争议。针对这类状况建议采取如下策略:
- 彻底排查程序逻辑是否存在遗漏 close() 函数调用的地方;
- 如果确实依赖外部挂载盘来保存临时数据的话,考虑改用本地磁盘路径作为工作目录以减少潜在干扰因素的影响程度。
#### 示例代码片段
下面给出一段简单的 Python 脚本来演示如何安全地管理资源生命周期从而避免上述提及的风险点之一——即防止因不当处理而造成句柄丢失的现象发生:
```python
import os
from contextlib import ExitStack
def safe_open_files(filepaths):
with ExitStack() as stack:
files = [stack.enter_context(open(fp)) for fp in filepaths]
# Perform operations on 'files'
pass
if __name__ == "__main__":
paths = ["file1.txt", "file2.txt"]
try:
safe_open_files(paths)
except Exception as e:
print(f"An error occurred: {e}")
```
此例子利用了 `ExitStack` 来自动跟踪所有打开的对象并在退出作用域之前逐一销毁它们,进而杜绝意外遗留的可能性。
---
###
阅读全文
相关推荐



















