ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

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_emailexample.com一路回车默认保存到~/.ssh/id_ed25519Windows上是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比如ubuntu192.168.1.100然后选一个SSH配置文件保存。这个配置文件在Windows下默认是C:\Users\用户名.ssh\configLinux/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 python3.10 conda activate myprojectPyTorch的安装最简单的方式是去官网用命令安装。比如CUDA 12.1对应pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121TensorFlow则直接pip install tensorflow装完之后在VSCode里按CtrlShiftP调出命令面板输入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_DEVICES0,1 python train.py代码里用torch.nn.DataParallel包一层框架会自动把batch拆分到每张卡上注意batch_size要适当扩大才能利用多卡优势否则每张卡分到的数据太少整体速度不仅不提升反而下降。如果项目规模更大需要DistributedDataParallelDDP我建议直接用PyTorch的torchrun启动它已经封装好了有效的多进程管理用法torchrun --nproc_per_node4 train.py代码里需要通过local_rank参数来区分每个进程的GPU编号同时注意DDP环境下数据集的采样器要用DistributedSampler否则每个进程拿到的数据重复训练等于白跑。这个坑我踩过不止一次后来是在一次多卡训练中accuracy曲线怎么都不对排查了一整天才发现问题出在数据分布上。4.4 持久化运行nohup与tmux的取舍训练任务通常要跑很久如果直接在一个VSCode终端里跑训练一旦关掉窗口或者网络闪断终端收到SIGHUP信号进程就会被杀掉。我之前跑一个48小时的训练任务跑到第30个小时网络波动断连结果训练直接中断损失惨重。有两种解决方式各有优劣nohup最简单一条命令搞定输出重定向到文件。tmux更灵活可以随时重新挂回会话适合长时间交互式的任务。nohup python train.py train.log 21 用tmux的话先启动一个新会话然后跑训练之后任何时候可以重新attach回来。我自己的习惯是交互式调试用VSCode终端正式跑长时间训练要么用tmux要么用后面的Docker容器方案。看日志直接用tail -f或者VSCode自带的日志插件非常方便。不过话说回来哪怕用了tmux进程还是会占着终端资源。到了后期我干脆把训练脚本做成服务或systemd unit交给系统托管日志统一管理但这种方式对普通用户不一定可用还是tmux最通用、最靠谱。5. 常见问题排查与经验速查表远程开发用得越久遇到的问题越千奇百怪。我把这些年踩过的大坑全部浓缩成一张速查表方便你遇到问题时快速定位。现象核心原因解决方案VSCode卡在下载VS Code Server网络原因连不上下载地址本地手动下载server压缩包scp到服务器解压到对应目录连接后终端没有conda环境非交互式shell没加载bashrc在VSCode设置里把终端类型改为bash或手动source ~/.bashrc代码能跑但GPU利用率为0%模型或数据没移到GPU检查model.cuda()和data.cuda()是否执行成功多卡训练loss正常但acc异常DistributedSampler未正确配置为每个进程初始化DistributedSamplershuffle设为TrueTensorBoard打不开端口未转发或防火墙拦截开启VSCode端口转发或检查服务器防火墙规则远程终端中文乱码locale环境不对在~/.bashrc里export LANGen_US.UTF-8或zh_CN.UTF-8运行训练脚本时报Permission denied代码或目录权限不够检查文件和目录属主chmod给当前用户添加读写权限pip安装包特别慢或超时网络原因或源太慢换国内pip镜像源pip config set global.index-urlconda创建环境特别慢默认源访问不稳定使用清华或中科大conda镜像源服务器磁盘占用率100%训练中断数据集或日志写满磁盘定期清理缓存和日志扩展磁盘或使用独立数据盘除了这个表有几个经验值得多写几句。第一个是环境变量问题。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-appspid,gpu_uuid,used_memory --formatcsv查看哪些进程在用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-size8g], workspaceFolder: /workspace, mounts: [ source/home/ubuntu/projects/myproject,target/workspace,typebind ], customizations: { vscode: { extensions: [ms-python.python] } } }这里重点说明几个配置--gpus all把宿主机所有GPU传给容器--shm-size8g是因为PyTorch的DataLoader多进程共享内存默认的64MB经常不够用导致报错mounts把宿主机项目目录绑定到容器里的/workspace这样代码和数据集都在宿主机上容器里直接读。配置完成后用命令面板执行Remote-Containers: Reopen in ContainerVSCode会自动拉镜像、启动容器、连接到容器内环境。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 -af6.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。一步步来这个组合会成为你以后科研或工作里最扎实的护城河。希望这篇长文对你有用也欢迎在实践中多踩坑、多总结。
返回列表