VSCode Remote-SSH远程连接服务器深度学习环境配置与调优指南

VSCode远程连接服务器做深度学习，这套流程我用了快四年，从最早的SFTP同步代码、到后来Remote-SSH全家桶、再到现在Dev Containers和云开发环境，可以说每一步都踩过不少坑。这篇文章我把目前最稳定、最顺手的方案完整梳理一遍，从环境准备到远程开发、Debug、训练监控，再到多卡调度和容器化实践，一次说清楚。不管你是刚接触深度学习的学生，还是想把开发环境从本地搬到服务器的工程老手，这套流程都能直接照着用。

在开始之前先明确一下，这套方案主要解决三个核心问题：一是代码和开发环境放服务器上，本地只当“遥控器”；二是训练过程中能看到实时loss曲线和GPU占用，像在本地一样方便；三是多人共用一台服务器时，不会互相踩踏环境和文件。VSCode的Remote-SSH解决前两个，虚拟环境和Docker解决第三个。

1. 核心思路：本地写代码、远端跑训练，为什么推荐这套方案

很多新手第一次用服务器跑深度学习，习惯的做法是先在自己电脑上装好Anaconda、装好PyTorch，把代码调通了再想办法传到服务器上去跑。这个思路本身没错，但会遇到一个很现实的问题：本地是Windows或者macOS，服务器是Linux，两个环境的依赖版本经常对不上。本地跑得好好的，传到服务器上import就报错，CUDA版本不对、gcc版本太老、缺libGL.so.1，各种问题搞得人想砸键盘。

VSCode Remote-SSH的思路刚好反过来，它在本地装一个VSCode作为客户端，通过SSH连到服务器后，在服务器端启动一个VSCode Server，这样你打开的文件、终端、调试器，实际上全部跑在服务器上，本地只负责显示界面。代码写在哪、环境装在哪、训练跑在哪，全部都在服务器端。比如你本地是Windows，服务器是Ubuntu 20.04，本地不需要装任何Python、CUDA、PyTorch，只要VSCode能启动、能连SSH，就能正常开发调试。

这个方案还有一个明显的好处：插件生态是通的。你在本地用的Python插件、Jupyter插件、Git插件，在远程模式下基本都能用。我在本地装了Python和Pylance，连上服务器后，代码补全、跳转定义、查看类型，全部基于服务器上的解释器工作，毫秒级响应，跟本地开发体感上几乎没有差别。

再一个就是多人协作场景。实验室或者公司一台服务器多人共用，每个人都可以通过Remote-SSH连上去，互不干扰。配合权限管理和虚拟环境，每个人在自己账户下建独立环境，谁都不会把谁的环境搞坏。

当然，这套方案也有短板，最大的一个就是初次连接时要下载VSCode Server，国内网络环境下有时会很慢甚至失败，后面我会给出手动下载安装的解决方式。另外，如果你的网络延迟很高（超过100ms），输入延迟和界面刷新会有点明显，但代码编辑这种轻量操作基本感知不到。

2. 环境准备：服务器端Linux基础配置与本地VSCode安装

开始连接之前，先把两边环境准备到位。服务器的Linux系统，不管是Ubuntu、CentOS还是Debian，都需要确保几个基本条件：能通过SSH连接、有Python环境、有GPU驱动和CUDA。这几个缺一个，后面都会卡壳。

2.1 服务器端基础检查与配置

拿到服务器第一件事，先确认SSH服务是否在运行，我用一条命令就能查：

systemctl status sshd

如果没启动，就装一下并开机自启。

sudo apt update sudo apt install openssh-server -y sudo systemctl enable ssh --now

然后查看SSH连接信息，找到IP和用户。我在Ubuntu上一般用ip addr查看IP，用户名用whoami看当前登录用户，或者提前在服务器管理面板里确认好账号和密码。

GPU这边的检查也很关键。用nvidia-smi看驱动是否正常。如果显卡驱动没装，会直接提示找不到命令或者报No devices were found，这时先在服务器端把驱动和CUDA装好，再做后面的开发环境。驱动版本和CUDA版本对应关系，以NVIDIA官方文档为准，这里不展开。

Python版本建议在服务器上用Anaconda或者Miniconda来管理，原因后面细讲。我一般用Miniconda，因为它够轻量，不用sudo，装在自己家目录，对多用户环境最友好。到官网下载对应Linux版本的安装脚本，然后bash执行。

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh

安装过程一路yes，最后source一下bashrc让conda生效。

2.2 本地VSCode安装与必装插件清单

本地VSCode直接去官网下载对应平台安装包，一路默认安装即可。需要注意一点：Windows下安装时，在“选择附加任务”页面，最好勾选“添加到PATH”，这样后面有些操作会更方便。

装完打开VSCode，在扩展市场搜Remote-SSH，装微软官方出的那一组，注意看发布者是Microsoft。我建议把这套全装上，因为部分功能插件之间有依赖关系：

• Remote - SSH：远程连接的核心插件，必装
• Remote - SSH: Editing Configuration Files：用于编辑SSH配置文件，装第一个时通常会自动装
• Remote Explorer：远程资源管理器，用来管理多个连接目标，必装

主插件装完后左侧会出现一个远程资源管理器图标，所有服务器连接都从那里管理。

其他非必须但强烈建议装的插件：Python（微软官方）、Pylance（代码智能）、Jupyter（需要跑notebook时用）、GitLens（看代码历史和多人协作时很有用）、Docker（后面容器化部分会用到）。这些插件都能在远程模式下正常工作，本地装一次，远程连接后自动在服务器端运行对应组件。

2.3 SSH密码连接改为密钥免密登录

密码登录虽然能连通，但有两个问题：一是每次连接都要输密码，开发体验很割裂；二是密码认证安全性差，公网服务器每天都会被各种脚本爆破。所以我对自己的服务器，一定改成密钥登录。

本地生成密钥对，Windows和macOS都支持：

ssh-keygen -t ed25519 -C "your_email@example.com"

一路回车，默认保存到~/.ssh/id_ed25519（Windows上是C:\Users\你的用户名.ssh\）。然后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把输出内容复制到服务器的~/.ssh/authorized_keys文件里，没有这个文件就创建一个：

mkdir -p ~/.ssh chmod 700 ~/.ssh echo "你复制的公钥" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

在VSCode里连接后，如果不再想用输密码的方式，可以修改服务器上的/etc/ssh/sshd_config，把PasswordAuthentication改为no，再重启sshd服务。注意改这个之前要确认密钥登录没问题，否则可能把自己关在门外。

3. 正式连接：VSCode Remote-SSH配置与远程开发环境

前面环境准备好之后，正式连接就是几个简单操作，但中间有几个小坑值得提前说清楚。

3.1 通过Remote Explorer配置并连接服务器

打开VSCode，点击左侧远程资源管理器图标，选择SSH Targets，点旁边的加号，输入用户名@服务器IP，比如ubuntu@192.168.1.100，然后选一个SSH配置文件保存。这个配置文件在Windows下默认是C:\Users\用户名.ssh\config，Linux/macOS是~/.ssh/config。

如果不喜欢每次输入IP，可以在config文件里给服务器起个别名，这样连接时直接选别名就行。我的config长这样：

Host deepserver HostName 192.168.1.100 User ubuntu Port 22 IdentityFile ~/.ssh/id_ed25519

保存后在SSH Targets列表里刷新，就能看到deepserver这个条目，点击连接。第一次连的时候会弹出选择平台（Linux/Windows/macOS），选Linux。接下来VSCode会在服务器上下载并启动VSCode Server，这一步在国内网络下可能卡很久，如果实在下不动，可以参考后面的离线安装方案。

连接成功后，窗口左下角会显示SSH: deepserver这样的绿色标识，此时你打开的终端、文件管理器、Git面板，全部都在服务器端工作。这里有个小技巧：点击左下角绿色区域，可以直接切换窗口、新建连接、在当前窗口或新窗口打开远端。

3.2 连接超时或无法下载VSCode Server的离线处理方案

我遇到最多的情况就是卡在“Downloading VS Code Server”这一步，尤其是公网服务器在国外的时候。其实解决办法很简单：本地用下载工具下载VSCode Server压缩包，传到服务器上手动解压。

先在本地通过SSH连接日志或者VSCode Server发布地址获取版本号，VSCode版本不同对应Server版本也不同，一个通用做法是直接看服务器端日志里请求的URL，把那个commit id记下来。然后在本地浏览器里访问：

https://update.code.visualstudio.com/api/commits/{commit_id}/server-linux-x64/stable

会自动下载一个tar.gz文件，把这个文件用scp传到服务器，放到~/.vscode-server/bin目录下解压，改名成对应的commit id目录。启动VSCode Server时就不会再走网络下载了。这个方法在校园网、服务器无外网环境下特别实用。

3.3 服务器上搭建Python虚拟环境与框架安装

远程连接通之后，第一件事就是在服务器上创建一个适合这个项目的Python环境。我强烈不建议直接在base环境里装包，深度学习项目依赖冲突太常见了，今天装TensorFlow，明天装PyTorch，互相覆盖依赖，最后环境崩了重建又浪费时间。

用conda创建独立环境：

conda create -n myproject python=3.10 conda activate myproject

PyTorch的安装，最简单的方式是去官网用命令安装。比如CUDA 12.1对应：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

TensorFlow则直接：

pip install tensorflow

装完之后，在VSCode里按Ctrl+Shift+P调出命令面板，输入Python: Select Interpreter，选择远端服务器上myproject环境里的python（路径一般在/opt/miniconda3/envs/或/home/用户名/miniconda3/envs/下）。这样代码补全和运行都会用这个环境。

还有一个容易被忽略的点：如果服务器上同时有多个人用，一定要确保虚拟环境创建在自己的用户目录或指定目录下，不要用sudo装系统级Python包，否则很容易破坏别人环境，也会遇到权限问题。我踩过一次坑：用sudo pip装了一个包，结果把系统Python搞崩了，服务器管理员差点让我写检讨。

3.4 同步本地代码到服务器的两种方式

代码怎么传到服务器？最简单的就是用VSCode的文件夹功能。在远程窗口里，打开服务器上的项目目录，然后直接把本地文件拖进去，VSCode会把文件上传上去。这种方式对单个文件或小批量文件很方便。

但如果你本地有完整的项目代码，Git更高效。在服务器上clone，在本地改完push，然后服务器上pull。这套配合VSCode自带的Git面板在远程模式下也能用，很方便。实在急的时候也可以在VSCode的集成终端里跑几条命令完成同步。

如果你还在用之前的一种老方案——FTP/SFTP插件同步，我只能说建议尽快迁移到Remote-SSH。本地SSH直连服务器才是真正的远程开发模式，SFTP那种编辑完本地再同步过去的流程，代码版本容易错乱，调试器也没法工作。

4. 远程训练核心实操：调试、日志、GPU监控与分发

连接和环境都准备好了，现在进入实战环节。这部分我用一个具体的深度学习训练场景来演示：本地VSCode连接远端GPU服务器，训练一个PyTorch图像分类模型，过程中涉及代码调试、训练日志、GPU监控和分布式训练启动。

4.1 远程调试：launch.json配置与断点调试

远程调试最大的好处就是断点、变量查看、单步执行全部在服务器端真实环境里进行，不存在“本地环境能运行但远端环境报错”的问题。

在远程窗口打开你的项目文件夹，切换到运行和调试面板，创建一个launch.json，配置如下：

{ "version": "0.2.0", "configurations": [ { "name": "Python: Current File", "type": "python", "request": "launch", "program": "${file}", "console": "integratedTerminal", "cwd": "${workspaceFolder}", "env": { "CUDA_VISIBLE_DEVICES": "0" }, "justMyCode": true } ] }

说明几个关键字段：program指运行当前打开的Python文件，cwd是工作目录，所有相对路径都会基于这个目录解析，env里可以设置环境变量，CUDA_VISIBLE_DEVICES指定只对0号GPU可见，后面介绍多卡分配时你会更理解这个变量的作用。

在需要调试的代码行左侧点击红点加断点，然后按F5启动调试。程序会在断点处停下，左侧可以查看所有变量的当前值，顶部的调试工具栏控制单步跳过、进入函数、继续执行等操作。这一步对代码异常排错非常高效，不用靠print瞎猜了。

有一点要特别注意：如果训练代码用到了DataLoader并且设置了num_workers大于0，调试时子进程会不断启动停止，体验会很差。我一般调试时把num_workers临时设为0，调试通过后再恢复，是为了避免子进程和调试器互相抢断点的问题。

4.2 训练日志输出与TensorBoard实时可视化

训练过程中的日志和可视化也是一个关键环节。最简单的方式是在终端直接跑训练脚本，实时看loss、acc的输出，但这种方式的问题在于没法方便地查看训练曲线，也不想开一堆终端窗口。

我在实践中用两种方式结合：训练脚本里用loguru或logging写日志文件，同时把TensorBoard的日志写到runs目录下；然后在VSCode远程环境下，用端口转发功能把TensorBoard直接映射到本地浏览器查看。

TensorBoard启动方式：

tensorboard --logdir runs --port 6006

启动后默认监听在服务器的6006端口，VSCode会自动检测到这个端口并弹窗提示“本地转发”，点一下“Open in Browser”就能在本地浏览器打开TensorBoard界面，跟本地跑的效果一模一样。如果没自动检测到，也可以手动在端口面板里添加端口转发。

这里有个经验：TensorBoard的更新延迟默认大概是几秒到十几秒，我在长时间训练时习惯开着它，隔一段时间瞄一眼loss曲线，比死盯终端输出舒服得多。如果你想更丝滑，还可以装TensorBoard插件或改用WandB在线记录，但对于常规训练任务，本地TensorBoard完全够了。

4.3 GPU利用率与资源分配：从nvidia-smi到多卡并行

训练跑起来了，怎么确认GPU真的被用上了？最简单的命令：

nvidia-smi

看几个关键信息：左侧列表能看到每张GPU的温度、利用率、显存占用，右侧能看到哪些进程在用GPU、占了多大显存。如果训练代码设置错误，GPU利用率显示0%，说明数据加载或者计算没有正确执行，这时候要检查模型和数据是否真的放到了GPU上：

model = model.to('cuda') data = data.to('cuda')

这两行写在什么位置、是否生效，是新手最容易出问题的地方。遇到GPU利用率偏低，还有一个常见原因是DataLoader的num_workers设太少或者batch_size太小，导致GPU算完一批数据要等很久CPU喂数据。

多卡训练时，我常用两个层面的方案。如果只有单机多卡，最简单的做法是在命令里指定可见GPU，用CUDA_VISIBLE_DEVICES控制：

CUDA_VISIBLE_DEVICES=0,1 python train.py

代码里用torch.nn.DataParallel包一层，框架会自动把batch拆分到每张卡上，注意batch_size要适当扩大才能利用多卡优势，否则每张卡分到的数据太少，整体速度不仅不提升反而下降。

如果项目规模更大，需要DistributedDataParallel（DDP），我建议直接用PyTorch的torchrun启动，它已经封装好了有效的多进程管理，用法：

torchrun --nproc_per_node=4 train.py

代码里需要通过local_rank参数来区分每个进程的GPU编号，同时注意DDP环境下数据集的采样器要用DistributedSampler，否则每个进程拿到的数据重复，训练等于白跑。这个坑我踩过不止一次，后来是在一次多卡训练中accuracy曲线怎么都不对，排查了一整天才发现问题出在数据分布上。

4.4 持久化运行：nohup与tmux的取舍

训练任务通常要跑很久，如果直接在一个VSCode终端里跑训练，一旦关掉窗口或者网络闪断，终端收到SIGHUP信号，进程就会被杀掉。我之前跑一个48小时的训练任务，跑到第30个小时网络波动断连，结果训练直接中断，损失惨重。

有两种解决方式，各有优劣：

• nohup：最简单，一条命令搞定，输出重定向到文件。
• tmux：更灵活，可以随时重新挂回会话，适合长时间交互式的任务。

nohup python train.py > train.log 2>&1 &

用tmux的话，先启动一个新会话，然后跑训练，之后任何时候可以重新attach回来。我自己的习惯是：交互式调试用VSCode终端；正式跑长时间训练，要么用tmux，要么用后面的Docker容器方案。看日志直接用tail -f或者VSCode自带的日志插件，非常方便。

不过话说回来，哪怕用了tmux，进程还是会占着终端资源。到了后期我干脆把训练脚本做成服务或systemd unit，交给系统托管，日志统一管理，但这种方式对普通用户不一定可用，还是tmux最通用、最靠谱。

5. 常见问题排查与经验速查表

远程开发用得越久，遇到的问题越千奇百怪。我把这些年踩过的大坑全部浓缩成一张速查表，方便你遇到问题时快速定位。

除了这个表，有几个经验值得多写几句。

第一个是环境变量问题。VSCode远程打开集成终端时，默认用的可能是非交互式shell，很多环境变量（比如conda初始化）跟普通SSH登录不一样。经常出现的现象：直接在系统终端里输入conda activate能用，在VSCode终端里却提示command not found。解决方式是检查~/.bashrc里的环境中是否有如果[ -f ~/.bashrc ]; then . ~/.bashrc; fi这样的逻辑，或者直接在VSCode的settings.json里把终端类型改成bash。

第二个是多GPU模式下乱杀进程问题。如果你是服务器管理员，有多个用户共用GPU，别在不知道别人任务的情况下直接kill -9某个python进程，很可能会把别人跑了好几天的训练干掉。我的经验是先用nvidia-smi --query-compute-apps=pid,gpu_uuid,used_memory --format=csv查看哪些进程在用GPU，确认是自己的任务再处理。如果是自己的任务但想停掉，怎么优雅停？在训练脚本里用信号处理，比如注册SIGTERM处理器，保存checkpoint后退出，而不是直接kill -9从头再来。

第三个是conda和pip混装导致的假失败。很多人环境里既有conda又有pip，两个包管理器的版本互相覆盖，会导致import报错。最佳实践是：平常只用conda创建环境、安装大型框架，其他依赖尽量用pip，但同一环境不要混用两种方式去装同一类包。如果不幸环境搞乱了，最快的办法是删掉重建，别浪费时间一个一个降级版本——这个原则治好了我多年的环境洁癖。

第四个是关于显存不够的排查思路。如果你的模型很大、batch_size又挺大，服务器报CUDA out of memory，先不要急着调小batch_size。看下是不是之前的训练进程没有完全退出，显存被别人占了，先查nvidia-smi看显存占用，够用再调代码。另外PyTorch里显存并非完全释放，进程结束后需要几十秒到几分钟才完全归还，这时候要是报显存不足，等一会儿就行。

6. 进阶玩法：Docker容器化训练与远程开发

基础的Remote-SSH已经能覆盖绝大多数场景，但当你的项目需要完全一致的运行环境、部署到不同机器、或者团队协作需要统一环境时，Docker容器化这一步是绕不开的。这一节我分享一下如何在VSCode里用Dev Containers插件做容器化深度学习开发。

6.1 为什么需要容器化，直接conda不行吗

conda环境只隔离Python包层面的依赖，但不隔离CUDA、系统库、系统配置这些层面。换一台机器，conda环境导过去可能因为CUDA版本不同、系统lib缺失而跑不起来。Docker容器则是整个文件系统级别的隔离，从CUDA驱动、系统库到Python包全在里面，同一个镜像在任何地方跑，结果完全一致。

对深度学习来说，Docker还有一个优势：可以精确锁定CUDA版本和cuDNN版本。比如你论文复现时，作者用的是CUDA 11.8 + TensorFlow 2.10，你直接拉对应镜像跑就行，不用在自己系统上折腾显卡驱动版本。

6.2 用VSCode Dev Containers连接远程容器

VSCode的Dev Containers插件（原名Remote - Containers）就是干这个的。它允许你将容器作为远程开发环境，本地或远端运行容器，VSCode直接连接进去，跟Remote-SSH一样流畅。

最简单的方式是用NVIDIA提供的深度学习容器镜像，例如：

docker pull nvcr.io/nvidia/pytorch:23.08-py3

然后在项目根目录放一个.devcontainer/devcontainer.json文件，配置文件可以指定基础镜像、挂载目录、需要暴露的端口、需要安装的扩展等基本信息。一个最简配置如下：

{ "name": "deeplearning-env", "image": "nvcr.io/nvidia/pytorch:23.08-py3", "runArgs": ["--gpus", "all", "--shm-size=8g"], "workspaceFolder": "/workspace", "mounts": [ "source=/home/ubuntu/projects/myproject,target=/workspace,type=bind" ], "customizations": { "vscode": { "extensions": ["ms-python.python"] } } }

这里重点说明几个配置：--gpus all把宿主机所有GPU传给容器，--shm-size=8g是因为PyTorch的DataLoader多进程共享内存，默认的64MB经常不够用导致报错；mounts把宿主机项目目录绑定到容器里的/workspace，这样代码和数据集都在宿主机上，容器里直接读。配置完成后，用命令面板执行Remote-Containers: Reopen in Container，VSCode会自动拉镜像、启动容器、连接到容器内环境。

6.3 Docker常用命令与管理实践

开发过程中，Docker命令用得最多的就那几个。启动/停止容器：

docker start/stop 容器名

进入正在运行的容器：

docker exec -it 容器名 /bin/bash

查看GPU能否在容器里被识别：

docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

训练出问题时，看容器日志比在里面硬看方便：

docker logs 容器名 --tail 100

容器化开发用完以后，注意及时清理停止的容器和悬空镜像，不然磁盘会被Docker默默吃掉，尤其大镜像。一条常用命令：

docker system prune -af

6.4 多容器策略：不同项目隔离到不同环境

实践做得多了，我形成了每一类任务一个专属容器镜像的习惯。例如：

• 基础PyTorch训练容器：nvcr.io/nvidia/pytorch基础镜像+项目依赖
• 多模态推理容器：自建镜像，安装mmcv、transformers、deepspeed等
• 老项目复现容器：锁死CUDA和TensorFlow版本，一劳永逸地避免依赖冲突

这样做的好处是，各个项目的依赖互相彻底隔离，再也不用担心一个项目升级了numpy导致另一个项目挂掉。而且任何一台新机器，只要把训练任务打包成镜像，拉起容器就能跑，这不就是大量复现实验的正确姿势？

7. 多人协作避坑：权限管理、环境隔离与资源公平

最后聊聊多人在一台GPU服务器上协作开发时会遇到的一些不省心的事。如果你只是一个人独享一台服务器，可以跳过这节；但如果你是实验室或团队里的一员，这些经验真的能帮你少挨骂、少背锅。

7.1 不做“环境破坏者”

多人共用一台服务器，最大的忌讳就是直接往系统环境里装东西。我之前遇到过一个同学，为了装一个包，直接sudo pip install到系统Python里，结果把系统自带的OpenSSL版本搞坏了，导致服务器的SSH服务都异常，最后管理员花了两个小时修复。这种事故一次就能把你的信誉败光。

正确做法还是：每个人都有独立账号，用conda管理Python环境，每个项目的环境都放在家目录下；需要系统级操作时，先征求管理员同意；实在需要系统软件时，优先用apt或者Docker容器化。一句话总结就是：能做用户态做到的事，绝不碰系统级。

7.2 GPU使用前先看占用，不要抢卡

多人共享GPU，最怕的就是两条：一是有同学不知道谁在用卡，直接跑起来把显存占满，导致别人的训练直接OOM崩溃；二是有同学把卡占着不用，也不kill。我自己的习惯是：

• 训练前先nvidia-smi，看看每张卡的显存占用和利用率
• 按需分配显存，尽量选利用率高但显存占用少的卡跑短任务，选显存够但利用率低的卡跑长任务
• 如果卡完全不够用，跟同学沟通，错峰使用，而不是偷偷抢

7.3 用Docker做用户级隔离

如果你们团队的技术沉淀已经上来了，且服务器支持Docker，建议直接给每个用户分配独立的容器。比如每个人创建自己的开发环境，docker run时指定用户：

docker run --gpus all \ -u $(id -u):$(id -g) \ -v /home/user1/projects:/workspace \ --name user1-dev \ nvcr.io/nvidia/pytorch:23.08-py3

用-u指定在容器里以宿主机用户身份运行，文件权限不会错乱，容器之间互相不干扰，配合docker commit还能把装好的环境保存成镜像给别人复用，既能干实事又不会惹麻烦。

7.4 磁盘空间管理要主动

服务器最容易被忽视的资源其实是磁盘。一个数据集几十GB，一个模型checkpoint几个GB，日志文件写着写着就是几十GB。多人共用服务器，磁盘满了是全员的灾难。

我的管理原则是：数据集统一放在共享目录，项目代码放自己家目录，模型保存路径单独设一个目录，定期清理旧checkpoint，损失比较小的阶段只保留最后的权重和最近几轮的。排查磁盘占用：

du -sh /home/*/ # 看每个用户占了多少 du -sh /datasets/* # 看数据目录

发现异常大文件时主动清理或归档到对象存储，别等问题出现才想对策。我通常在每周五花五分钟看一眼磁盘整体情况，顺手清掉不需要的临时文件，这个好习惯让服务器从来没有因为我写满磁盘出过问题。

做远程开发这几年，我的经验就是一条：环境越隔离越好，流程越自动化越好，习惯越规范越好。VSCode Remote-SSH解决了“本地开发、远端训练”的痛点，conda和Docker解决了“环境不一致、依赖互相污染”的痛点，tmux和端口转发解决了“长时间训练中断、可视化不方便”的痛点。把这套链路走通，你就能把精力从环境部署和工具折腾上拔出来，专心放到模型和实验本身。

如果你刚接触这套流程，我建议你这样走：先扛住第一周的不适，熟悉命令、熟悉环境、熟悉VSCode远程模式的节奏；第二周试着把TensorBoard和训练脚本完整跑通；第三周再上Docker。一步步来，这个组合会成为你以后科研或工作里最扎实的护城河。希望这篇长文对你有用，也欢迎在实践中多踩坑、多总结。