把宿舍 Windows 主机改成可远程训练的 WSL 工作站

Date 2026-05-27 · Category blog · Status finished · Confidence likely
系统排障, 工程实践

为什么整理这套方案

远程训练架构总览

如果手头同时有一台日常办公笔记本和一台放在宿舍的高性能 Windows 主机，最稳妥的做法通常不是把主机当“远程桌面”，而是把它整理成一台长期在线的训练工作站。

这篇文章记录的是一套偏实用的个人方案：

  • 笔记本负责写代码、看日志、发起实验。
  • 宿舍主机负责持续开机、联网、提供 GPU。
  • WSL2 Ubuntu 负责深度学习环境。
  • SSH + VS Code Remote 负责远程开发。
  • tmux 负责断线后继续训练。

为了适合公开发布，文中的用户名、主机地址、项目路径和账户信息都已经替换为占位符。

目标架构

整套链路可以概括成下面这一条：

办公笔记本
  -> 远程网络接入
  -> 宿舍 Windows 主机
  -> WSL2 Ubuntu
  -> conda 环境
  -> tmux 后台训练

这套结构的关键不在“软件堆得多”，而在职责分离清楚：

  • Windows 主机 处理显卡驱动、开机、联网和日常兼容性。
  • Ubuntu 处理 Python、PyTorch、依赖安装和训练脚本。
  • tmux 解决“断开连接后任务不能停”。
  • VS Code Remote 解决“直接编辑远程代码，不靠来回传文件”。

日常工作流

日常远程训练工作流

真正稳定之后，每天的动作其实很少：

  1. 宿舍主机保持开机、联网、锁屏，不进入睡眠。
  2. 办公笔记本先接入远程网络。
  3. 通过 SSH 登录宿舍主机。
  4. 从 Windows 命令行进入 WSL2 Ubuntu。
  5. 进入项目目录，激活 conda 环境。
  6. 在 tmux 中启动或接回训练会话。
  7. 需要离开时直接断开，训练继续在后台运行。

如果一套方案需要频繁远程桌面、手工拷数据、重复配置环境，那它就不适合长期训练。

宿舍主机需要先准备什么

系统和环境

宿舍主机建议满足这些条件：

  • Windows 11 优先。
  • 已安装 NVIDIA 驱动。
  • 网络尽量稳定，能走有线更好。
  • 电源策略允许锁屏，但不允许自动睡眠。

然后在主机上安装 WSL2 和 Ubuntu 22.04 LTS。如果是首次启用，常见命令如下：

wsl --install

已经安装过的话，至少更新一次：

wsl --update

首次进入 Ubuntu 后，需要自己创建 Linux 用户名和密码。公开记录时，这类信息不要写真实值。

检查 GPU 是否能在 WSL 中使用

进入 Ubuntu 后先确认显卡是否可见：

nvidia-smi

如果这里都看不到显卡，后面的训练环境就没有继续搭的意义。

安装 Python 环境和基础工具

这类主机如果主要跑深度学习，建议直接把 Python 环境放在 Ubuntu 里维护。常见做法是安装 Miniconda，然后创建单独的训练环境：

conda create -n dl python=3.10
conda activate dl

基础开发工具也建议一次补齐：

sudo apt update
sudo apt install -y git tmux curl wget build-essential

之后再安装 PyTorch，并用最小脚本确认 CUDA 可用：

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

远程连接部分怎么搭

远程网络

不管使用哪种零信任网络或组网工具，原则都一样：

  • 笔记本和主机需要加入同一套远程网络。
  • 主机重启后，网络客户端要能自动可用。
  • 对外公开时，不要暴露组织名、网络名、真实接入地址。

SSH 服务

宿舍主机需要开启 OpenSSH Server，让笔记本可以直接登录。Windows 上常见的初始化方式如下：

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

之后从笔记本测试登录：

ssh <Windows用户名>@<主机地址或别名>

这里的两个占位符在公开文章里都应该保留占位状态，不要替换成真实信息。

从 Windows 进入 Ubuntu

成功登录主机后，再进入真正用于训练的 Linux 环境：

wsl

如果默认发行版就是 Ubuntu，这一步就会直接切进去。后续代码、依赖、训练脚本都建议在这里运行。

为什么推荐 VS Code Remote 和 tmux

VS Code Remote 解决的是“别传文件”

最省事的用法不是本地改完再同步，而是直接连接远端目录工作。这样有几个明显好处：

  • 你改的就是主机上的真实项目文件。
  • 不需要再维护一份本地和远端双副本。
  • 小改动、日志查看、配置更新都更顺手。

项目目录也建议直接放在 WSL 的 Linux 文件系统里，例如：

mkdir -p ~/projects
cd ~/projects

长期训练项目不建议主要放在 C: 盘再跨系统调用。

tmux 解决的是“断网也别停”

离开前检查清单

训练任务一定要放进 tmux 会话。最基础的用法只有三步：

tmux new -s exp1
conda activate dl
python train.py

想临时离开时，按 Ctrl+b 然后按 d，会话会留在后台继续跑。回来以后：

tmux ls
tmux attach -t exp1

这比直接把训练挂在普通终端里稳妥得多。普通终端断掉，训练往往也就一起没了。

文件、数据集和目录怎么放

一个适合长期使用的目录结构可以很简单：

mkdir -p ~/projects
mkdir -p ~/logs
mkdir -p ~/checkpoints
mkdir -p ~/datasets

含义分别是：

  • ~/projects 放项目代码。
  • ~/logs 放训练日志。
  • ~/checkpoints 放模型权重。
  • ~/datasets 放数据集。

数据集的原则尤其重要：尽量长期留在主机本地，不要每天来回搬。日常同步的应该只是代码、配置、小体积日志和结果图。

公开分享时哪些内容必须删掉

把这类个人环境说明改成博客时，最容易泄露的是环境细节而不是命令本身。发布前至少检查下面这些内容：

  1. 真实 Windows 用户名、Linux 用户名。
  2. 主机别名、远程网络地址、机器名。
  3. 本地绝对路径和桌面路径。
  4. 组织名、网络名、客户端截图里的账户信息。
  5. 密码、密钥、Token、指纹截图。
  6. 项目真实名称、私有仓库地址和内部目录结构。

更好的公开写法是只保留方法，不保留身份信息。例如：

  • 用 <Windows用户名> 替代真实账户名。
  • 用 <主机地址或别名> 替代真实可访问地址。
  • 用 ~/projects/<项目目录> 替代具体项目名。

这样读者仍然能复现流程，但不会获得你的私人环境信息。

一套足够稳定的最小方案

如果只保留最核心的判断，这套方案可以收敛成四句话：

  1. Windows 负责开机、联网和驱动。
  2. WSL2 Ubuntu 负责 Python 和训练环境。
  3. SSH + VS Code Remote 负责远程开发。
  4. tmux 负责让训练脱离连接状态继续运行。

对个人使用场景来说，这比长时间依赖远程桌面更稳，也更接近真正使用一台远程 Linux 训练机的体验。

只要主机保持开机、联网、锁屏且不睡眠，白天在别处也能比较稳定地继续做实验。

See also