1. 为什么远程训练离不开一个能挂住的会话窗口刚入行那会儿我在自己那台游戏本上跑一个语义分割的小模型风扇从晚饭一直吼到凌晨眼看着验证集指标一点点往上爬结果键盘不小心被猫踩了一下终端窗口一抖训练进程直接没了。那种感觉比丢文件还难受因为前面几个小时的电费和时间全白费了。后来开始租用云端算力用 screen 窗口在 Autodl 服务器上训练网络我才真正意识到会话持久化这四个字对做深度学习的人有多重要。这不是什么高深技术但它是把训练从人守着机器变成机器自己跑的分水岭。这篇东西写给两类人一类是刚接触算力平台、准备把自己的第一个训练脚本丢到远程机器上跑的新手另一类是已经会用 Autodl但每次断线就手忙脚乱、训练一挂就得从头再来的人。我会把 screen 的机制、Autodl 实例的特点、训练任务的日志与监控、以及我自己踩过的一堆坑都摊开讲。读完你至少能做到一件事合上电脑去睡觉第二天回来训练还在跑日志完整显存没被白占。核心工具就一个screen。核心平台就是 Autodl 这类按量计费的 GPU 算力云。核心场景就是把神经网络训练任务安全地托管在远程服务器上。听起来简单但每个环节都有讲究下面一点点拆。1.1 本地训练和云上训练到底差在哪先说清楚为什么要上云。本地训练最大的问题不是算力而是间断。你的笔记本要关机、要休眠、要断网、要挪到另一个房间任何一个动作都可能打断训练进程。而深度学习训练天然是长任务动辄几小时甚至几天中间还经常需要跑几十个 epoch 才能看出收敛趋势。让一个长任务去迁就一台会移动、会休眠、会没电的设备本身就违背常理。云上 GPU 实例把算力从设备上剥离出来你租的是一块 RTX 4090 或者 A100通过网络连进去操作。设备在哪、你人在哪理论上互不影响。但这里有个陷阱连接是靠 SSH 长连接维持的。你本地网络一断、笔记本一合盖SSH 通道就断了默认情况下SSH 通道上挂着的进程会收到挂断信号直接被杀掉。也就是说上云只解决了一半问题剩下那一半得靠 screen 这类会话管理工具来补。我见过太多人第一次用 Autodl 是这样的SSH 连上去敲python train.py看着日志刷刷往外冒心里美滋滋然后关掉终端去吃个饭。回来一开进程早没了模型 checkpoint 也没保存。这不是平台的错是没搞懂前台进程和会话的关系。1.2 算力平台实例的本质一台随时会被回收的远程主机把 Autodl 的实例想象成一台你按小时租的远程电脑这个类比虽然粗糙但很准。你开机创建实例的时候平台给你分配一块物理 GPU、一部分 CPU、内存和一块系统盘再挂一块数据盘。你关机停止实例的时候GPU 和计算资源被平台收回去给别人用按量付费的实例通常只对数据盘收很低的存储费GPU 计费停止。开机再开环境理论上还在但这中间如果有任务没跑完那就是断了。这里有个关键认知实例的生命周期和你的训练任务生命周期是两码事。你以为任务在跑其实任务只活在实例开机的那段时间里。一旦实例关机、或者平台因为欠费、维护把实例停掉任务就没了。screen 能做的是在你和实例之间建立一个命题持久的会话让你断开 SSH 后任务继续但它救不了实例本身被关机的情况。搞清楚这个边界后面很多坑就不会踩。另外Autodl 上实例的系统盘和数据盘容量有限默认数据盘一般是 50GB 左右。训练用的数据集、中间 checkpoint、日志文件全堆在这上面很快就会满。磁盘一满训练进程写 checkpoint 失败轻则报错退出重则把已有文件写坏。这跟 screen 没关系但和让训练稳定跑下去这件事直接相关后面我会单独讲。1.3 screen 到底解决了什么问题一句话概括screen 让你在断开 SSH 之后进程依然附着在一个虚拟终端上继续运行等你下次连回来还能重新贴回那个界面看到实时输出。它的原理是在服务器端启动一个独立于你当前登录会话的守护进程你的训练任务挂在这个守护进程管理的虚拟终端上而不是挂在你这次 SSH 登录的会话上。这就好比你在公司会议室开了个视频会议然后把会议托管出去自己先离开工位。会议照常进行你什么时候回来屏幕上还显示着当前的画面。而不用 screen 直接跑相当于会议全靠你的电脑直播你一锁屏会议就断了。对训练任务来说这个能力带来三个实际好处。第一不怕本地断网Wi-Fi 抖动、路由器重启都无所谓。第二可以同时开多个会话跑多个实验互相不干扰方便做对照。第三可以随时回来查看进度不用一直盯着。这三点看似平淡但真正做实验的人知道能一边跑着 A 实验一边调 B 实验的代码效率是翻倍的。2. screen 的核心机制与命令体系拆解很多人学 screen 是照着命令表背结果转头就忘。问题在于没理解它的会话—窗口—分离这套模型。我先把机制讲透再给命令记忆就牢了。2.1 会话分离把进程从终端上摘下来要理解分离先理解 Linux 的终端模型。你在 SSH 里敲的每一条命令都是当前登录会话的子进程。这个会话由登录 shell 管理当 SSH 断开shell 收到 SIGHUP挂断信号它会把信号传给所有子进程进程默认行为就是退出。所以你不加任何保护直接跑训练断线就死。screen 的做法是它先启动一个常驻后台的服务进程server然后你在里面创建会话。这个会话有自己的虚拟终端从登录 shell 的角度看你的训练任务是挂在 screen 的进程树下而不是挂在 SSH 会话下。SSH 断开时受到 SIGHUP 的是 screen 客户端而不是 screen server训练进程安然无恙。Ctrla d这个组合键就是主动分离把当前客户端从 server 上摘下来GUI 界面消失但 server 和里面的进程继续在后台活。你下次screen -r就是重新附着把客户端再贴回去。理解了这个客户端可插拔、server 常驻的模型所有命令都只是这对动作的变体。2.2 screen、nohup、tmux 三者怎么选新手经常纠结既然要后台跑nohup不就够了确实nohup python train.py log.txt 21 也能让进程在断线后存活而且更简单。但它有个硬伤你没法再回到这个进程的交互界面。nohup 把进程丢到后台输出重定向到文件你能看日志但没法在进程内部敲命令、没法看它当前占用的显存对应的实时曲线更没法在里面临时开个 Python 交互调试环境。tmux 是 screen 的现代替代品功能更强窗口切分更漂亮配置更灵活社区也更活跃。如果你是新项目、没有历史包袱我其实更推荐 tmux。但为什么这篇文章还是讲 screen因为 Autodl 的默认镜像里 screen 基本都预装了screen命令开箱即用不用额外装而且大量老教程、老脚本里用的都是 screen接手别人代码时你得看得懂。两者核心概念会话、分离、重连几乎一样学会一个另一个半小时就能上手。简单给个选型结论工具是否可重连交互上手难度预装情况适用场景nohup否只能看日志极低系统自带一次性、确定不用回来操作的任务screen是低Autodl 镜像基本自带常规训练、需要回来查看/调试tmux是中部分镜像需安装多窗口、复杂实验管理我的实际做法是日常训练一律 screen需要开一堆并排窗口对比多个实验时换 tmux。两者不冲突可以共存。2.3 必须刻进肌肉记忆的命令清单命令不用多下面这些覆盖了 95% 的使用场景。我按创建—操作—维护的顺序列并且标出容易记混的点。# 创建并进入一个名为 train_exp1 的新会话 screen -S train_exp1 # 查看当前所有会话尤其是它们的状态是 Attached 还是 Detached screen -ls # 恢复附着到指定会话 screen -r train_exp1 # 当会话显示为 Attached说明别处还连着时的强制接管 screen -d -r train_exp1 # 单独分离一个别处的会话让它变成 Detached screen -d train_exp1 # 直接在外部杀掉一个会话不用进去 screen -S train_exp1 -X quit会话内部的操作全靠Ctrla前缀这个前缀叫命令键默认是CtrlaCtrla然后按d分离回到普通终端。Ctrla然后按k杀当前窗口会二次确认。Ctrla然后按c新建一个窗口。Ctrla然后按n/p切换到下一个 / 上一个窗口。Ctrla然后按列出所有窗口让你选。提示Ctrla在别的地方比如某些编辑器的行首跳转也被用进 screen 后偶尔会误触。习惯了就好或者自己改成Ctrlb写在~/.screenrc里。命名这件事值得单独强调。我强烈建议每个会话都用有意义的名字screen -S exp_lr3e4_bs32这种别用默认的12345.pts-0.xxx。等你同时跑五六个实验满屏无名会话时你会感谢当初那个起名字的自己。命名规范本身就是一种实验管理后面第 5 章还会展开。3. 从开实例到跑通训练的完整实操理论讲完进入实操。我按全新开始的顺序走一遍每一步都说明为什么这么做你照着抄基本不会出问题。3.1 实例创建与镜像、数据盘的选择创建实例这一步几个选择直接影响后面好不好跑。第一是 GPU 型号看你模型大小和预算小模型 4090 性价比高大模型上 A100/H800 这类。第二是镜像Autodl 提供了预装好 PyTorch、CUDA、conda 的基础镜像选一个和你代码依赖匹配的版本能省掉大量配环境的时间。第三是数据盘默认一般够用但如果你的数据集几十上百 GB记得在创建时就把数据盘调大事后扩容麻烦。实例起来之后第一件事我会把 conda 环境确认一下然后装缺失的依赖。Autodl 有个很实用的学术网络加速跑source /etc/network_turbo之后 pip 安装会快很多。这一步和 screen 无关但装依赖动辄十几分钟如果中途断线装一半的包很容易出问题。所以我的习惯是装依赖这种短任务也用 screen 跑或者至少保证网络稳定。数据盘路径通常挂在/root/autodl-tmp之类的位置注意不要把大数据集塞系统盘系统盘满了实例会出各种诡异问题。训练脚本里所有输出路径、日志路径我都会显式指到数据盘目录下。3.2 用 screen 拉起第一个训练任务环境准备好进入正题。假设脚本叫train.py我用屏幕会话把它拉起来# 1. 创建会话 screen -S train_exp1 # 2. 在会话里激活环境并启动训练-u 关闭 Python 输出缓冲让日志实时落盘 python -u train.py --epochs 100 --batch-size 32 --lr 3e-4 21 | tee /root/autodl-tmp/logs/exp1.log # 3. 看到日志正常刷起来后按 Ctrla 再按 d 分离这里有几个细节必须解释清楚不然容易翻车。python -u里的-u是关掉标准输出的缓冲。Python 默认会把打印内容攒在缓冲区里等缓冲区满了或者程序结束才落盘结果就是你cat日志文件半天没动静以为程序卡死了。加了-u每一行 print 都立刻写出去方便实时监控。21 | tee这一串的意图是把标准错误合并到标准输出21然后用tee同时输出到屏幕和文件。这样既有实时画面又有持久日志。如果只重定向到文件 log.txt你在 screen 里就看不到进度了心里没底。双通道输出是我强烈推荐的做法。日志路径我显式写到数据盘避免系统盘被撑爆。另外建议提前mkdir -p建好日志目录不然tee会因为目录不存在直接失败。3.3 分离、回看、杀会话的完整动作分离之后你就可以放心关终端、关电脑了。下次回来SSH 重新连上先看有哪些会话在跑screen -ls输出大概是这个样子There is a screen on: 12345.train_exp1 (Detached) 1 Socket in /run/screen/S-root.看到Detached就说明它好好活着。然后恢复screen -r train_exp1如果这时提示There is a screen on ... (Attached)说明这个会话在别的地方还连着可能是你上一个 SSH 会话没释放。用screen -d -r train_exp1强行接管它会先分离原来的连接再把你接上去。训练跑完或者要主动结束进去之后按Ctrla再按k确认一下当前窗口是否是你的训练窗口多窗口时容易杀错然后再确认退出。或者干脆在会话里敲exit会话里最后一个窗口退出后会话自动结束。要是不想进去用前面给的screen -S train_exp1 -X quit外部杀。注意杀会话之前一定确认 checkpoint 已经存好。screen 被杀里面所有进程都会被清掉正在写的模型权重文件可能损坏。3.4 日志与监控的配套做法screen 解决不断线但训练稳不稳还得看监控。我日常用的三板斧第一是看日志尾部tail -f /root/autodl-tmp/logs/exp1.log实时刷 loss 和指标。-f会持续跟踪文件新增内容配合前面-u的实时输出体感很接近在前台跑。第二是看 GPU 状态watch -n 1 nvidia-smi每秒刷新一次观察显存占用和 GPU 利用率。如果显存占得很满但 GPU-Util 长期接近 0说明数据加载是瓶颈可能是 dataloader 的num_workers设得太小。第三是看 CPU 和内存htop直观能看出是不是内存爆了导致进程被系统杀掉。这种情况往往表现为主进程突然消失、日志无报错终止很容易被误判成平台问题。这三样我都会在新会话或新终端里跑主训练会话保持干净不被监控输出污染。整套组合下来一个人管三四个并行实验完全不慌。4. 训练场景里那些真正会咬人的坑命令会敲只是入门真正拉开差距的是对什么时候会出事的预判。下面这些坑我基本都亲自踩过。4.1 显存、数据盘与缓存目录显存这块最常见的翻车是没估准 batch size。你以为显存够跑到某个 epoch 数据 shape 一变OOM 直接把进程干掉。规避做法是先小 batch 跑几个 step 探路或者用 PyTorch 的torch.cuda.empty_cache()加梯度累积来降低峰值。但更根本的是第一个 epoch 一定要在 screen 里盯着确认稳定了再分离。很多人急着分离去睡觉结果它二十分钟后 OOM白睡一觉。数据盘满是我见过最隐蔽的故障。表现是训练跑到一半突然报No space left on device或者更糟——checkpoint 写了一半文件损坏下次加载失败。我的习惯是定期df -h看数据盘余量同时给 checkpoint 做轮转只保留最近 N 个旧的删掉。日志文件也会膨胀尤其是开了 verbose 的训练tee输出的 log 几天就能到几个 G记得配 logrotate 或者手动清理。缓存目录也容易被忽视。Hugging Face 的模型缓存默认在~/.cache也就是系统盘。你要下载预训练模型系统盘很容易被撑满。我的做法是提前设export HF_HOME/root/autodl-tmp/hf_cache把它指到数据盘。这类环境变量最好写进.bashrc一劳永逸。4.2 实例关机、断线、超时的应对前面说过screen 救不了实例本身。Autodl 的按量付费实例如果长时间空闲或者你主动关机GPU 会被释放。所以关键动作是训练没结束之前别关实例。有些平台有闲置检测机制所以哪怕训练在跑也尽量别让实例进入奇怪状态。SSH 连接超时也很常见。你开着 screen 的会话但本地 SSH 客户端因为长时间无操作被服务端踢掉这个不影响 screen 里的任务下次重连继续。但如果你在里面正跑一个交互式命令比如手动调参那就被打断了。解决方法是配置~/.ssh/config加ServerAliveInterval 60之类的保活参数让连接定期发心跳。还有种情况是实例被平台迁移或重启。Autodl 偶尔会因为物理机维护需要重启你的实例如果没提前通知或者你没注意训练就断了。应对策略是养成随时可恢复的习惯定期保存 checkpoint脚本支持--resume从断点继续日志里记录清楚当前 epoch。这样即使断了重开实例、重进 screen、加--resume就能接着跑损失可控。4.3 常见问题速查表把高频问题整理成表出事了直接对号入座现象可能原因排查与解决分离后进程消失没在 screen 里跑被 SIGHUP 杀掉确认是在 screen 会话内启动screen -ls看会话是否还在screen -r报 Attached旧连接未释放用screen -d -r 名字强制接管日志文件不更新Python 输出缓冲启动加-u或设PYTHONUNBUFFERED1训练中途 OOMbatch size 过大 / 数据 shape 变化降 batch、开梯度累积、盯首个 epoch报 No space left数据盘或系统盘满df -h定位清理日志和旧 checkpoint进程莫名消失无报错内存被系统 OOM killer 干掉看dmesg降 dataloader workers 或内存占用GPU 利用率长期很低数据加载瓶颈增大num_workers检查磁盘 IO提示排查问题时先看日志尾部的报错栈再nvidia-smi看显存最后df -h看磁盘。这三步能定位绝大多数训练突然挂了的问题。5. 把训练任务管起来的一点工程化经验跑通一个实验不难难的是同时管好一批实验还能在几周后复盘清楚。这部分是我做项目攒下来的一些习惯谈不上标准但确实省事。5.1 多任务并行与命名规范当你要对比超参数时最少是五六个实验同时跑。我的命名约定是exp_日期_关键参数比如exp_0512_lr3e4_bs64。会话名、日志文件名、checkpoint 目录名共用同一套后缀做到看名字就知道这组实验在测什么。这样screen -ls一列出来一眼能分清哪个是哪个不用担心串台。多任务并行时最忌讳的是显存不够硬上。一块 24G 的卡你同时跑三个各占 10G 的任务第三个必然 OOM。所以开新任务前先nvidia-smi看余量算清楚再开。理想状态是每个实验的显存占用留出 20% 余量给数据加载和峰值波动留空间。会话数量也别贪多。我一般同时最多三个 screen 会话在跑超过这个数就容易顾此失彼监控也看不过来。真正的效率不是同时跑得多而是每个都能顺利收敛、有结论。5.2 从 screen 到脚本化用久了你会发现每次开机、建会话、激活环境、跑命令动作是重复的。这时候就该脚本化。我写了一个run_exp.sh把环境激活、目录创建、日志重定向、随机种子设置都包进去最后一句是启动训练。然后启动就变成了screen -S exp_0512_lr3e4_bs64 -dm bash run_exp.sh注意这里的-dm它的意思是创建会话并直接分离不在前台打开。这样我一条命令就能拉起一个新实验不用手动进去敲。脚本里我把所有路径参数化换数据集、换模型只改几行配置非常省事。脚本化还有个隐性好处可复现。半年后你回头看某个实验怎么跑的脚本就是最忠实的记录比脑子靠谱得多。日志、脚本、checkpoint 三件套放在同一个实验目录下归档时整体打包清清楚楚。最后分享一个我自己一直在用的习惯每天收工前花两分钟做三件事——screen -ls确认所有会话状态df -h看磁盘余量nvidia-smi看有没有异常占用。这三分钟能挡掉八成第二天回来发现训练挂了的情况。踩过的坑够多了之后你会发现真正让训练稳的不是多高深的工具而是这些细碎但坚持下来的动作。