【vLLM-Ascend】vLLM-Ascend部署DeepSeek避坑指南：EngineCore握手超时完美解决

昇腾开发者社区活动入口背景概述在基于昇腾 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 within5minutes参考部署文档 Atlas 800 A2双机部署DeepSeek-V3.2-w8a8故障排查过程1. 检查防火墙状态首先确认系统防火墙状态避免因安全策略阻断通信systemctl status firewalld图1 firewalld 状态检查结果显示inactive即防火墙已关闭排除了 firewalld 的干扰。2. 检查 iptables 规则进一步排查网络层限制执行iptables-L图2 iptables 规则检查发现 INPUT 链末尾存在一条REJECT规则其默认行为为拒绝所有未明确允许的入站连接。该规则可能影响节点间通信。3. 端口连通性测试根据部署配置--data-parallel-rpc-port设置为13389用于主从节点间的数据并行通信。尝试从从节点 telnet 主节点的该端口telnet主节点IP13389返回结果为Trying主节点IP... telnet: connect to address主节点IP: Connection refused反向测试从主节点 telnet 从节点同样失败表明端口通信被阻断。问题根因iptables的 INPUT 链末尾存在一条默认REJECT规则其作用是拒绝所有未被显式允许的入站连接。由于 vLLM-Ascend 在双机部署中依赖13389端口进行节点间通信而该端口未被任何ACCEPT规则覆盖导致连接请求被拒绝从而引发 EngineCore 与前端进程握手超时。解决措施方案一临时清除 iptables 规则适用于测试环境为快速验证问题可临时清空所有 iptables 规则并重启 Podiptables-Fkubectl delete pod kube-proxy-node-name-nkube-system重启后服务恢复正常模型成功加载并对外提供推理服务。方案二精准修复推荐生产环境使用为避免安全风险应仅添加必要的允许规则而非清空全部规则。在REJECT规则前插入一条允许13389端口的规则iptables-IINPUT-ptcp--dport13389-jACCEPT该命令将新规则插入 INPUT 链头部确保在REJECT规则生效前优先匹配从而放行 vLLM 所需的通信端口。建议与总结避免盲目使用 iptables -F在生产或复杂网络环境中iptables -F会完全解除防火墙保护存在显著安全风险。应优先采用精准规则添加方式。部署前检查网络策略在部署分布式推理服务前建议检查节点间关键端口如--data-parallel-rpc-port、--host端口等的连通性可通过telnet或nc工具进行验证。推荐使用最小权限原则配置 iptables对于 vLLM-Ascend 等分布式推理框架应仅开放必要的端口如 13389、1025 等并配合ACCEPT规则明确放行避免使用默认拒绝策略。日志建议在部署过程中启用详细日志如--disable-log-requests可关闭日志以提升性能但调试阶段建议开启便于快速定位通信异常。