背景概述

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

故障排查过程

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 -F
kubectl delete pod kube-proxy-<node-name> -n kube-system

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

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

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

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

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