概览主题状态当日结果Windows 10 WSL2 多机 vLLM / Ray 可行性验证验证完成使用win10WSL2 进行 局域网多机多卡部署vllm并不可取Windows 10 WSL2 局域网多机 vLLM / Ray 可行性验证1. 任务目标在不更换现有 Windows 10 系统、不使用 Linux 虚拟机或裸机 Linux、推理通信不经过公网的前提下验证以下双机分布式推理架构是否可落地Node0Windows 10 → WSL2 Ubuntu → Ray Head vLLM 主节点 → RTX 2080 Ti Node1Windows 10 → WSL2 Ubuntu → Ray Worker vLLM Worker → RTX 2080 Ti计划使用 Ray 管理跨主机 GPU由 vLLM 通过--distributed-executor-backend ray和 Tensor Parallel 调用两张显卡。本次验收条件两台 WSL2 之间存在稳定、双向、仅走局域网的节点通信路径。Ray 可长期保持2 nodes / 2 GPUWorker 不因健康检查失败退出。Ray 控制面、对象传输和 Worker/Actor 端口均可双向访问。后续 NCCL 能使用低延迟、可直连的局域网接口。以上条件成立后再进入 vLLM 多机 Tensor Parallel 启动与性能测试。2. 实际环境项目Node0Node1角色Ray Head、vLLM 主节点Ray Worker、vLLM WorkerWindows IP192.168.xxx.184/24192.168.xxx.243/24WSL2 IP172.22.xxx.216/20172.23.xxx.66/20WSL2 NAT 子网172.22.xxx.0/20172.23.xxx.0/20GPURTX 2080 TiRTX 2080 Ti原始 vLLM 镜像vllm/vllm-openai:latestvllm/vllm-openai:v0.24.0补充 Ray 后镜像vllm/vllm-openai:latestvllm/vllm-openai:v0.24.0网络关系如下Node0 WSL2 172.22.xxx.216/20 │ WSL2 NAT Node0 Windows 192.168.xxx.184/24 │ ├──────── 本地局域网 ────────┤ │ Node1 Windows 192.168.xxx.243/24 │ WSL2 NAT Node1 WSL2 172.23.xxx.66/20两台 Windows 位于同一个192.168.xxx.0/24局域网两台 WSL2 分别位于两段不同的私有 NAT 子网。3. 原部署流程复核原部署方案包括以下阶段Windows 10 安装 WSL2 Ubuntu。验证 Windows 和 WSL2 中的 NVIDIA 驱动。在 WSL2 内安装 Docker 与 NVIDIA Container Toolkit。验证 Docker GPU并部署 vLLM 镜像。在宿主 WSL2 Conda 环境安装 Ray。Node0 启动 Ray HeadNode1 使用 Node0 Windows IP 加入集群。设置VLLM_HOST_IP、NCCL_SOCKET_IFNAMEeth0。启动 vLLM Ray 后端和多机 Tensor Parallel。复核后确认多机部分存在一个需要先验证的前置条件Node1 虽然可以通过 Node0 Windows IP 主动访问 GCS但 Ray 向集群登记的节点地址仍是各自 WSL2 IP。Ray 和 NCCL 不仅需要 Worker 主动连接 Head还需要集群组件按登记地址进行反向、双向直连。因此不能仅用6379端口可访问或ray status短暂显示两个节点作为网络验收依据。4. 分层验证过程4.1 基础 GPU、Docker 与 vLLM 单机能力先验证与跨主机网络无关的基础链路Windows NVIDIA 驱动 → WSL2 GPU → Docker GPU → vLLM 单机推理验证结果Windows NVIDIA 驱动正常。WSL2 中可以识别 RTX 2080 Ti。Docker 可以访问 GPUNVIDIA Container Toolkit 正常。vllm/vllm-openai:v0.24.0单机启动成功。结论GPU、WSL2 GPU 支持、Docker GPU 映射和 vLLM 单机能力均可用不是本次多机验证的阻塞点。4.2 补齐 vLLM 容器内的 Ray 依赖vLLM 使用以下参数时--distributed-executor-backend ray容器报错No module named ray定位结果宿主 WSL2 的 Conda/Python 环境与 Docker 容器隔离在宿主机安装 Ray 不代表 vLLM 容器内存在 Ray。处理方式FROM vllm/vllm-openai:v0.24.0 RUN pip install ray构建得到vllm-ray:v0.24.04.3 Ray 集群初始联机与健康状态观察Node0 启动 Ray Headray start\--head\--node-ip-address172.22.xxx.216\--port6379Node1 加入ray start\--address192.168.xxx.184:6379\--node-ip-address172.23.xxx.66初始现象2 nodes 2 GPU几十秒后退化为1 node 1 GPUNode1raylet日志先显示服务正常启动ObjectManager server started NodeManager server started随后出现Received address and liveness notification for node, IsAlive 0最终退出[Timeout] Exiting because this node manager has mistakenly been marked as dead by the GCS: GCS failed to check the health of this node for 5 times.阶段结论Node1 Ray Worker 能启动并能主动访问 Node0 GCS。Node1 GPU 能短暂注册到集群。GCS 无法按 Node1 登记的172.23.xxx.66地址完成反向健康检查。ray status短暂出现2 nodes / 2 GPU不能作为集群稳定性验收结果。4.4 固定 Ray 关键端口排除随机端口干扰排查中观察到 Ray 随机使用过36935、39669、40791、46771等端口。为提高防火墙、代理和抓包的可诊断性将 Node1 关键端口固定ray start\--address192.168.xxx.184:6379\--node-ip-address172.23.xxx.66\--node-manager-port50101\--object-manager-port50102\--min-worker-port50110\--max-worker-port50120监听检查ss-lntp|grep-E50101|50102结果LISTEN *:50101 users:((raylet...)) LISTEN *:50102 users:((raylet...))Raylet 工作正常固定端口参数生效当前问题不是 Node Manager 或 Object Manager 未监听而是远端无法访问 Ray 登记的 WSL2 地址。4.5 Windows portproxy 验证在 Node1 Windows 建立 TCP 端口代理192.168.xxx.243:50101 → 172.23.xxx.66:50101 192.168.xxx.243:50102 → 172.23.xxx.66:50102已确认IP Helper服务运行正常。Windows 确实监听192.168.xxx.243:50101/50102。Node1 Windows 能访问本机 WSL2 对应服务。排查并清理了误绑定到 Node0 地址192.168.xxx.184的残留代理项。该方案没有解决 Ray 健康检查原因如下Node1 向 GCS 登记的仍是172.23.xxx.66:50101/50102其他 Ray 组件不会自动改为访问 Windows 地址192.168.xxx.243。portproxy是指定端口的 TCP 转发不是透明三层网络也不进行 Ray 服务发现地址改写。完整 Ray 通信还包括 Runtime Env Agent、Dashboard/Metrics、Worker/Actor 端口和对象传输端口。后续 NCCL 还需要 GPU 节点间的独立数据通道不能通过少量 TCP 端口代理替代。4.6 验证每台 Windows 与本机 WSL2 双向通信为排除单机 WSL2 网络异常先在两台主机分别验证 Windows 与本机 WSL2。Node1 Windows → Node1 WSL2Test-NetConnection172.23.xxx.66-Port 50999 curl.exe--connect-timeout5 http://172.23.xxx.66:50999/关键结果SourceAddress : 172.23.xxx.1 TcpTestSucceeded : TrueHTTP 请求成功返回 WSL2 临时服务的目录内容。Node1 WSL2 → Node1 Windowsping-c4172.23.xxx.1curl--connect-timeout5http://172.23.xxx.1:51000/均成功。Node0 也完成了相同方向验证。两台主机各自的 Windows ↔ 本机 WSL2 网络正常问题集中在“跨 Windows 主机访问另一台 WSL2 NAT 子网”。4.7 双向静态路由与 Windows 转发验证根据/20掩码计算两段 WSL2 子网Node0172.22.xxx.216/20 → 172.22.xxx.0/20 Node1172.23.xxx.66/20 → 172.23.xxx.0/20在 Node0 Windows 添加目标 172.23.xxx.0/20下一跳 192.168.xxx.243在 Node1 Windows 添加目标 172.22.xxx.0/20下一跳 192.168.xxx.184对应持久路由命令# Node0route-p add 172.23.xxx.0 mask 255.255.240.0 192.168.xxx.243 metric 5ifLAN接口索引# Node1route-p add 172.22.xxx.0 mask 255.255.240.0 192.168.xxx.184 metric 5ifLAN接口索引两台 Windows 的 LAN 接口开启 IPv4 Forwarding。两台 Windows 的vEthernet (WSL)开启 IPv4 Forwarding。设置全局IPEnableRouter1。配置对应防火墙规则。重启后复核 WSL2 地址、持久路由和接口 Forwarding 均保持正确。Node1 WSL2 的路由选择结果172.22.xxx.216 via 172.23.xxx.1 dev eth0 src 172.23.xxx.66说明 Linux 已将跨节点流量交给本机 Windows WSL 网关。但实际跨主机测试仍失败ping-c4172.22.xxx.216curl-v--connect-timeout5http://172.22.xxx.216:50998/结果4 packets transmitted, 0 received, 100% packet loss curl: (28) Failed to connect ... Timeout was reached4.8 目标 WSL2 抓包确定报文停止位置Node1 发起上述请求时在 Node0 WSL2 执行sudotcpdump-nieth0host 172.23.xxx.66 and (icmp or tcp port 50998)结果抓包无任何输出。这是本次验证的决定性证据源 WSL2 路由选择正确。两台 Windows 的局域网地址互通。Windows 持久路由、接口转发和全局转发均已配置。目标 WSL2 完全收不到请求报文。因此故障位置不在目标 Linux 应用监听、Ubuntu 防火墙、Linux 返回路由或 Ray 端口而是在 Windows 10 WSL/HNS NAT 的跨主机转发边界。当前环境没有形成 Ray/NCCL 所需的透明、双向三层网络。4.9 Tailscale 仅作为覆盖网络对照实验为验证“只要两个 WSL2 获得稳定的可达地址节点间即可互通”在两台 WSL2 上进行了 Tailscale 对照实验节点Tailscale IPNode0 WSL2100.125.171.86Node1 WSL2100.125.164.50双向tailscale ping成功但实际路径为via DERP(sin)延迟约95–99 msNode1tailscale netcheck关键结果UDP: true IPv4: yes, 23.129.164.114:51114 MappingVariesByDestIP: false PortMapping: 空 Nearest DERP: Singapore该实验验证了覆盖网络可以绕过 WSL2 NAT 的地址可达性问题但当前实际通信经过公网中继不符合“仅使用本地局域网”的约束同时该延迟也不适合 vLLM Tensor Parallel / NCCL 的高频通信。因此只保留为网络根因的对照证据不作为部署方案。4.10 其他路线评估在明确静态路由边界后还评估了以下替代方向路线判断本次处理继续扩展portproxy无法提供透明三层网络端口与地址维护成本高不继续投入本地 OpenVPN TCP 覆盖网络理论上可在局域网内创建共同地址空间配置复杂且 TCP-over-TCP 不适合优先承载 NCCL本次未实施Hyper-V Linux VM可能改善网络但会改变现有运行结构Windows 10 下 GPU 使用方式不满足当前目标未采用Windows 11 WSL mirrored networking有进一步验证价值需要升级系统超出本次约束原生 Linux网络与 GPU 分布式环境更直接会改变现有系统环境作为未来优先方案保留6. 当前约束下为什么不可行本次结论针对的是以下条件组合Windows 10 WSL2 NAT 两台独立 Windows 主机 纯局域网通信 不引入额外本地覆盖网络 Ray / NCCL 需要节点间双向直连在该组合下当前方案不能完成稳定、实用的多机 vLLM / Ray Tensor Parallel原因是两台 WSL2 位于彼此独立的 NAT 子网默认不能直接路由。Ray 向 GCS 注册的是 WSL2 地址Head、GCS、Raylet、Object Manager 和 Worker/Actor 需要按该地址双向通信。Windowsportproxy只能代理指定 TCP 端口不能把 WSL2 地址转换成整个集群共同可见的节点地址也不能替代 NCCL 数据网络。双向静态路由、接口 Forwarding、IPEnableRouter和防火墙均配置后目标 WSL2 仍完全抓不到报文说明 Windows 10 WSL/HNS NAT 没有提供所需的透明跨主机转发路径。覆盖网络可以建立可达性但本次 Tailscale 实际使用公网 DERP 中继不符合纯局域网要求。在保持现有 Windows 10 WSL2 NAT 环境、限定通信只走局域网、且不增加本地覆盖网络的前提下无法建立 Ray/NCCL 所需的稳定双向节点网络因此不继续进入 vLLM 多机 Tensor Parallel 与性能测试阶段。7. 可复用排查经验7.1 分布式推理应按层验收后续类似任务建议使用以下顺序Windows GPU → WSL2 GPU → Docker GPU → vLLM 单机 → 容器内 Ray 依赖 → Windows 与本机 WSL2 双向 TCP → 两台 WSL2 双向 L3/TCP → Ray 数分钟稳定健康 → Ray 远程任务与对象传输 → iperf3 / NCCL 带宽 → vLLM Tensor Parallel网络层未验收前不应把后续现象归因到 vLLM 或模型本身。7.2 地址比单个端口更重要分布式框架不仅需要一个“入口地址”还需要所有节点对服务发现中登记的地址形成一致视图。6379可访问只能证明 Worker 能发起一次连接不能证明 Head 能回连 Worker。7.3 抓包是路由排查的终止证据当路由表、转发和防火墙均已检查时应在目标 WSL2 抓包完全没有请求继续检查 Windows/HNS/NAT 或中间网络。有请求、没有回复检查 Linux 监听、防火墙、rp_filter和返回路由。请求与回复都有检查中间设备或源端返回路径。8. 后续边界建议本次可行性验证已完成现阶段不继续扩展逐端口portproxy。若未来重新启动该方向建议按以下优先级重新验证原生 Linux 节点与可路由局域网。升级到支持更合适 WSL 网络模式的系统后先单独验收两个 WSL2 的双向 L3 直连。若允许增加本地覆盖网络必须确保节点在局域网内直连不使用公网中继随后先执行iperf3和 NCCL 基准测试。只有 Ray 长时间稳定、远程任务和对象传输通过后再启动 vLLM Tensor Parallel。
