---
title: vLLM-Ascend部署DeepSeek时 EngineCore 与前端进程握手超时问题-官方技术文章-昇腾社区
description: 在基于昇腾 Atlas 800I A2 硬件，使用vLLM-Ascend部署 DeepSeek-V3.2-W8A8 模型时，用户在双机集群环境下遇到 EngineCore 与前端进程握手超时的问题的排查过程、根因分析到最终解决方案。
keywords: LLM,Ascend,DeepSeek,部署,EngineCore,与前端进程握,手超时问题,官方技术文章
url: https://www.hiascend.com/developer/techArticles/20260528-1
section: (其他)
---

# vLLM-Ascend部署DeepSeek时 EngineCore 与前端进程握手超时问题-官方技术文章-昇腾社区

URL: https://www.hiascend.com/developer/techArticles/20260528-1
描述: 在基于昇腾 Atlas 800I A2 硬件，使用vLLM-Ascend部署 DeepSeek-V3.2-W8A8 模型时，用户在双机集群环境下遇到 EngineCore 与前端进程握手超时的问题的排查过程、根因分析到最终解决方案。
关键词: LLM,Ascend,DeepSeek,部署,EngineCore,与前端进程握,手超时问题,官方技术文章

官方技术文章 [了解详情](https://www.hiascend.com/zh/developer/techArticles)

vLLM-Ascend部署DeepSeek时 EngineCore 与前端进程握手超时问题

vLLM-Ascend部署DeepSeek时 EngineCore 与前端进程握手超时问题

DeepSeek模型推理vLLM

发表于: 2026/05/29

1.8k

1

## 背景概述

在基于昇腾 Atlas 800I A2 硬件，使用vLLM-Ascend部署 DeepSeek-V3.2-W8A8 模型时，用户在双机集群环境下遇到 EngineCore 与前端进程握手超时的问题，该问题导致服务无法正常启动，影响推理任务的调度与执行。本文将从问题现象、排查过程、根因分析到最终解决方案进行系统性梳理，为类似场景提供可复用的排查思路与应对策略。

## 问题现象

在双机部署架构下，使用 vLLM-Ascend 0.13.0 版本启动 DeepSeek-V3.2-W8A8 模型时，主节点启动后，从节点无法成功建立通信连接，日志中持续报错：

```
RuntimeError: Did not receive response from front-end process within 5 minutes
```

参考部署文档：Atlas 800 A2双机部署DeepSeek-V3.2-w8a8 [了解详情](https://docs.vllm.ai/projects/vllm-ascend-cn/zh-cn/latest/tutorials/models/DeepSeek-V3.2.html)

## 故障排查过程

### 1. 检查防火墙状态

首先确认系统防火墙状态，避免因安全策略阻断通信：

```
systemctl status firewalld
```

结果显示`inactive`，即防火墙已，排除了 firewalld 的干扰。

### 2. 检查 iptables 规则

进一步排查网络层限制，执行：

```
iptables -L
```

发现 INPUT 链末尾存在一条`REJECT`规则，其默认行为为拒绝所有未明确允许的入站连接。该规则可能影响节点间通信。

### 3. 端口连通性测试

根据部署配置，`--data-parallel-rpc-port`设置为`13389`，用于主从节点间的数据并行通信。尝试从从节点 telnet 主节点的该端口：

```
telnet <主节点IP> 13389
```

返回结果为：

```
Trying <主节点IP>...
telnet: connect to address <主节点IP>: Connection refused
```

反向测试（从主节点 telnet 从节点）同样失败，表明端口通信被阻断。

## 问题根因

`iptables`的 INPUT 链末尾存在一条默认`REJECT`规则，其作用是拒绝所有未被显式允许的入站连接。由于 vLLM-Ascend 在双机部署中依赖`13389`端口进行节点间通信，而该端口未被任何`ACCEPT`规则覆盖，导致连接请求被拒绝，从而引发 EngineCore 与前端进程握手超时。

## 解决措施

### 方案一：临时清除 iptables 规则（适用于测试环境）

为快速验证问题，可临时清空所有 iptables 规则并重启 Pod：

```bash
iptables -F
kubectl delete pod kube-proxy-<node-name> -n kube-system
```

重启后服务恢复正常，模型成功加载并对外提供推理服务。

⚠️ 注意：iptables -F 会清除所有规则，解除网络防护，仅建议在测试或受控环境中使用。

### 方案二：精准修复（推荐生产环境使用）

为避免安全风险，应仅添加必要的允许规则，而非清空全部规则。在`REJECT`规则前插入一条允许`13389`端口的规则：

```bash
iptables -I INPUT -p tcp --dport 13389 -j ACCEPT
```

该命令将新规则插入 INPUT 链头部，确保在`REJECT`规则生效前优先匹配，从而放行 vLLM 所需的通信端口。

## 建议与总结

1. 避免盲目使用 iptables -F在生产或复杂网络环境中，`iptables -F`会完全解除防火墙保护，存在显著安全风险。应优先采用精准规则添加方式。
2. 部署前检查网络策略在部署分布式推理服务前，建议检查节点间关键端口（如`--data-parallel-rpc-port`、`--host`端口等）的连通性，可通过`telnet`或`nc`工具进行验证。
3. 推荐使用最小权限原则配置 iptables对于 vLLM-Ascend 等分布式推理框架，应仅开放必要的端口（如 13389、1025 等），并配合`ACCEPT`规则明确放行，避免使用默认拒绝策略。
4. 日志建议在部署过程中启用详细日志（如`--disable-log-requests`可日志以提升性能，但调试阶段建议开启），便于快速定位通信异常。

点赞 1

本页内容

背景概述 [了解详情](https://www.hiascend.com/#id-1)

问题现象 [了解详情](https://www.hiascend.com/#id-2)

故障排查过程 [了解详情](https://www.hiascend.com/#id-3)

问题根因 [了解详情](https://www.hiascend.com/#id-4)

解决措施 [了解详情](https://www.hiascend.com/#id-5)

建议与总结 [了解详情](https://www.hiascend.com/#id-6)