vLLM-Ascend部署DeepSeek-V3.2-W8A8时 EngineCore 与前端进程握手超时问题定位

作者​：昇腾实战派
​知识地图​：https://blog.csdn.net/Lumos_Lovegood/article/details/161601003

背景概述

在基于昇腾 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

服务启动失败，且无进一步的模型加载或推理日志输出。尽管所有配置（如--tensor-parallel-size、--data-parallel-rpc-port等）均符合官方推荐规范，问题仍反复出现。

故障排查过程

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：

iptables-Fkubectl delete pod kube-proxy-<node-name>-nkube-system

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

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

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

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

iptables-IINPUT-ptcp--dport13389-jACCEPT

该命令将新规则插入 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可关闭日志以提升性能，但调试阶段建议开启），便于快速定位通信异常。