先讲一段我自己最痛的经历。去年做一个小型目标检测项目本地显卡撑不住就把训练脚本搬到了Google Colab上挂机跑去睡觉。第二天凌晨五点醒来习惯性打开页面一看——运行时断开连接训练了十八个小时的loss曲线永远停在最后一个step。那一刻我意识到搞不定“colab自动断开连接”这件事再强的免费算力也只是镜花水月。后来我花了整整两个星期把网上能找到的防断连方法全试了一遍。从键盘压硬币让屏幕常亮到写循环模拟按键再到浏览器插件自动点击各方案实测下来差别非常大。这也是为什么我想把这几套方法整理出来有些确实稳定有效有些纯属心理安慰还有一些不但没用反而会把你的运行时搞得更脆弱。这篇内容不讲虚的只讲我亲自验证过、并且在不同场景下连续运行超过数小时的方案原理、代码、配置一次配齐。适合在Colab上跑深度学习训练、做数据清洗、挂机下载文件的人参考。1. 断连的真相可不止“90分钟没人动”很多人以为Colab断连就是因为“太久没操作”只要让页面保持一点动静就行。这个理解只对了三分之一。真正常见的断连原因有三层而且每一层的触发条件都不一样。1.1 空闲计时器只是最表层的原因Google官方文档里写得很明确免费版的Colab在“空闲”状态下大约90分钟后会被回收实例。但这个“空闲”的定义非常微妙它不是你屏幕上有没有人操作而是Colab的前端有没有收到“交互事件”。我实际测试下来纯挂机、不开任何代码、鼠标也不碰大概70到100分钟就会弹出一个“您已闲置较长时间”的确认框要求确认是否还在使用。如果不去点它再过几分钟就直接断开。这里有个很多人不知道的细节鼠标在页面上移动不会重置计时器真正的交互事件是点击按钮、在代码单元里输入内容、执行单元、或者在终端里敲命令这类操作。这也是网上很多“模拟鼠标移动”脚本根本无效的原因。你让鼠标在页面上画圈Colab的判定逻辑根本不认这种动作。1.2 运行时回收机制才是真正的大手第二种断连和你的操作频率完全无关。即便你的脚本一直在跑、GPU利用率飙到90%以上Google依然可能从你手里把实例收走。这本质上是一个资源池调度策略当GPU资源紧张时免费用户的实例优先级最低最先被抢占。我实测中遇到过最离谱的一次训练进行到第9个小时loss还在稳定下降没有任何空闲迹象突然就Runtime Disconnected了。重新连接进去之后原来的运行时已经不存在等于所有内存态的东西全部归零。这种情况没有任何防断连脚本能解决因为它根本不看你是否活跃。1.3 内存和磁盘失联后到底丢什么搞清楚断连后丢什么是制定防断连策略的前提。Colab的运行时从启动开始所有pip安装的包、系统库、加载到内存的数据变量全部存在云端的临时机器里。一旦断开且运行时被回收这些东西全部蒸发。挂在/content/目录下的临时文件也会丢。唯一能幸存的是你主动挂载到/content/drive/的Google Drive文件以及Drive的缓存。也就是说每次断连后你都需要重新装依赖、重新下载数据、重新加载模型权重——除非你从一开始就把这些工作做成了自动化脚本。这三个真相叠加起来结论其实很清晰单纯的“防断连”只能解决空闲断线这一种问题对于资源抢占型断连唯一的出路是让每一次中断都付出最小代价。后面的方案我们都围绕这个前提来展开。2. 控制台JS心跳最基础的防断连手段网上流传最广的防断连方案就是在浏览器开发者工具里贴一段JavaScript脚本定时让页面自己点击“连接”按钮。这套方案便宜、直接也是我所有实测的起点。2.1 这套脚本到底在“骗”谁Colab页面运行时会维持一个长连接页面右上角有一个连接状态按钮。在前端层面频繁点击这个按钮会触发Colab认为“用户还在操作”的事件从而刷新空闲计时器。JS脚本做的事情就是模拟这个点击以固定的时间间隔让页面认为自己一直有用户交互。理解了这一点你就会明白为什么原版脚本这么简洁function ClickConnect() { const btn document.querySelector(colab-connect-button); if (btn) { btn.click(); console.log(Colab heartbeat at, new Date().toLocaleTimeString()); } } setInterval(ClickConnect, 60000);执行之后控制台每分钟会输出一条日志说明脚本在跑。核心原理就是通过DOM查询找到Colab页面上的连接按钮然后模拟点击。2.2 实际操作步骤与新版适配细节在Colab页面按F12打开开发者工具切到Console标签页粘贴上述代码回车就完事了。但这里有一个非常大的坑Colab的前端DOM结构不断在变。以前网上流传的脚本用document.querySelector(colab-toolbar-button)或者document.querySelector(paper-button)在2024年之后的很多Colab页面上已经失效了。挂载后你光看见日志在打印实际上按钮压根没被点到。我的建议是不要盲目抄代码先花一分钟定位当前页面真实的连接按钮。// 在Console里执行列出页面上所有可见按钮 Array.from(document.querySelectorAll(button, paper-button, colab-connect-button)).map( (el) ${el.tagName} | ${el.textContent.trim()} | ${el.className} ).join(\n);执行后观察输出找文本带有“重新连接”“连接”“Connect”字样的按钮把对应的CSS选择器填进querySelector里。我目前实测可用的选择器就是colab-connect-button但如果你遇到新版界面用上面这段定位并不难。2.3 实测效果它能稳多久单靠控制台JS心跳我在正常工作网络下实测的平均稳定时长大约6到10小时。如果只是做数据处理、少量训练这个时长基本够用。但有两个致命缺陷。第一个是浏览器层面的如果你用的是Chrome且开启了“内存节省程序”标签页在后台停留一段时间后会被冻结setInterval直接停摆防断连随之失效。第二个是Colab偶尔弹出的“是否仍在运行”确认对话框它出现时JS脚本不一定能找到对应的按钮去点一旦没人响应照样断开。所以我的结论是控制台JS脚本是防断连的地基但绝不能只靠它。想长时间稳定挂机必须叠加其他层级的方案。3. 从Python侧保活两种代码方案实测既然前端JS有冻结风险很多人自然想到“直接在notebook里用Python写一个保活循环”。这条路我也走了一遍但实验结果比想象中复杂。3.1 后台心跳线程与“伪计算”保活网上常见的Python保活代码大致长这样import time while True: time.sleep(60) print(keep-alive)我一开始也这么干实测结果是——没用。单纯sleep一个线程然后往notebook输出一段文字并不能稳定重置空闲计时器。Colab对“是否空闲”的判断关注的是CPU/GPU是否真的有计算任务在执行而不是有没有print。而且print太多还会导致notebook的输出缓冲区膨胀拖慢前端响应。后来我改成让线程做一点轻量计算情况立刻不同import threading import time def _keep_alive(): while True: time.sleep(20) # 轻量计算避免CPU完全空闲 _ sum(i * i for i in range(100000)) print(heartbeat, time.time()) def start_keep_alive(): t threading.Thread(target_keep_alive, daemonTrue) t.start() print(Keep-alive thread started) start_keep_alive()这个线程每20秒做一次10万次整数平方求和计算量本身很小CPU占用率几乎可以忽略但足够让运行时处于非空闲状态。配合WebSocket的活跃刷新实测稳定运行时长从6小时提升到12小时以上。需要注意的是不能让保活线程变成CPU大户。如果线程里跑高密度循环很容易触发Colab的系统负载告警反而被提前回收。3.2 训练循环内嵌保活的正确姿势比独立线程更可靠的方式是直接把“保活动作”融入你的训练代码里。你的深度学习脚本本身就在跑GPU计算这已经让运行时非常活跃唯一要补的是“定期向前端汇报进度”。经验做法是每10个batch或者每个epoch用清晰的格式打印一次loss和learning rateimport torch for epoch in range(epochs): running_loss 0.0 for batch_idx, (inputs, labels) in enumerate(dataloader): optimizer.zero_grad() outputs model(inputs) loss criterion(outputs, labels) loss.backward() optimizer.step() if batch_idx % 10 0: print(f[Epoch {epoch}] step {batch_idx:5d} loss {loss.item():.6f})这样做的逻辑很简单训练循环本身是“活动”print又让Colab前端每几分钟收到一次新的单元输出双管齐下。实测中只要代码不直接把notebook的输出端内部缓冲写爆这种方式能撑很长时间我的记录是连续运行22小时没有掉线。3.3 为什么有人写循环还是断我在不同讨论区看到过一些反例有人照着写了循环还是断了。仔细看他们的代码和场景能总结出几个共同原因。第一个是循环体里只有sleep和print没有实际计算。第二个是输出频率太低比如每30分钟才输出一次在长时间运行的场景下这个间隔太长了还是容易被判定为空闲。第三个则是整个训练进程已经在后台崩溃了循环打印的是异常堆栈这种自然保不了活。另外必须强调一项容易被忽略的现实无论你的保活逻辑写得多完美Colab Pro免费版在长任务运行到12小时左右时有时也会遭遇资源抢占导致的强制回收。这属于平台策略层面的事脚本插进去也拦不住。所以我一直说保活的终极答案不是“不让它断”而是“断了也能无损续跑”。4. 浏览器扩展与系统层面配合如果你不希望在代码里加保活逻辑或者你的任务只是下载数据、整理文件那么浏览器扩展是更好的选择。但选择扩展和配置系统的过程中有几个细节我会逐一说明。4.1 自动点击类扩展的选型与风险Chrome网上应用店里有不少标注“Colab Auto Reconnect”之类的扩展它们做的事情本质和第一节的JS脚本一样定时伪造点击事件。区别在于扩展运行在浏览器层即使标签页被切到后台只要标签页不被冻结定时器依然生效。选型时重点关注三点是否开源、更新日期是否足够新、权限范围是否合理。Colab的DOM结构会变一个长期不更新的扩展基本等于废品。另外有些扩展会要求“读取和更改所有网站上的数据”这类宽泛权限这种我直接不碰风险大于收益。我的做法是优先选那些GitHub上有源码、Chrome商店页面标注了最近更新时间在一两个月内的扩展。如果你不会判断那就退回到手动JS脚本反正效果没有本质区别。4.2 系统与浏览器的几个关键设置浏览器扩展和脚本能否稳定工作取决于系统是否允许页面持续运行。以下几个设置我建议在挂机前全部过一遍。第一关闭Chrome的“内存节省程序”。Chrome默认会把后台标签页冻结以节省内存冻结后setInterval和扩展定时器都会停摆。在地址栏输入chrome://settings/performance把“内存节省程序”关掉或者至少把Colab站点加入排除名单。第二操作系统不要休眠也不要锁屏。Windows笔记本在“设置-系统-电源和睡眠”里把接通电源后的睡眠设置为“从不”macOS在“系统设置-锁定屏幕”里把“不操作后关闭显示器”调到最长时间同时保持系统不休眠。第三合上笔记本盖子之前一定要把“合盖操作”改成“不采取任何操作”。不然你合盖的瞬间网络中断Colab页面连同你的运行时连接一起断掉。第四有条件的话把Colab页面单独放在一个浏览器窗口里而不是和其他几十个标签页挤在一起。这样可以降低浏览器对标签页做后台资源回收的概率。这些系统配置看着琐碎却是很多人“明明挂了脚本还是断”的原因。我帮朋友排查时发现十次里有五次问题出在笔记本锁屏后断网而不是Colab层面的回收。5. 真正的底牌断点续训与云端落盘我现在越来越觉得“防断连”这个词本身就是伪命题。与其花费精力对抗平台的资源回收不如把工作流设计成“断了也不怕”。这才是让你在Colab上长期训练的最优解。5.1 权重定时保存让训练进度永不归零断点续训的核心就一句话把训练状态周期性写入Google Drive。训练状态不仅包括模型权重还包括optimizer的状态、当前epoch、当前step、学习率调度器状态、以及loss值。实操中我通常在训练循环里加这样的逻辑from google.colab import drive import torch import os drive.mount(/content/drive) CKPT_DIR /content/drive/MyDrive/checkpoints os.makedirs(CKPT_DIR, exist_okTrue) def save_checkpoint(epoch, step, model, optimizer, scheduler, loss): ckpt { epoch: epoch, step: step, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict() if scheduler else None, loss: loss, } path os.path.join(CKPT_DIR, latest.pth) torch.save(ckpt, path) print(fCheckpoint saved at epoch {epoch}, step {step}) for epoch in range(epochs): for batch_idx, (inputs, labels) in enumerate(dataloader): # ... 训练逻辑 ... if batch_idx % 500 0: save_checkpoint(epoch, batch_idx, model, optimizer, scheduler, loss.item())每500个batch保存一次写入Google Drive的频率大概每几分钟一次不会对训练速度造成明显影响。一旦断连重新挂载运行时后加载latest.pth从保存的step恢复即可。这里提醒一个常见坑频繁向Google Drive写入大文件可能会触发同步限流。所以保存时不要每个epoch都写控制在5到10分钟一次并且只保留最新的一份配合偶尔的“best”版本即可。5.2 环境依赖和数据持久化断连后最浪费时间的另一个环节是环境重建。如果每次重装torch、transformers、numpy光pip install就能耗掉十几分钟。我的做法是在每次任务开始时先检查关键模块是否能导入不能导入才执行安装import importlib def ensure_module(module_name, pip_nameNone): try: importlib.import_module(module_name) print(f{module_name} already installed) except ImportError: !pip install -q {pip_name or module_name} print(f{module_name} installed) ensure_module(torch, torch torchvision torchaudio) ensure_module(transformers)还可以把训练用的数据集提前打包上传到Google Drive每次启动时解压到/content/临时磁盘。虽然占了一些启动时间但比从外部网盘慢速下载稳妥得多。若数据必须外部下载务必用支持断点续传的下载工具并将下载任务设计成可重入的。把这一层做完断连对你的影响就只剩下“重启运行时执行两三个单元格”的时间成本。心态完全不一样了。6. 按场景组合我的配置清单与实测记录方法多了之后最大的问题变成“什么时候用哪套”。不同任务类型对防断连的需求完全不同我把自己的配置清单整理成表格方便你直接“抄作业”。场景保活方案数据持久化实测稳定时长深度学习长训练GPU训练循环 每10 batch打印 每500步存Drive权重/优化器状态存Drive环境自动检查安装20小时以上最高22小时大文件下载到Drive控制台JS心跳 浏览器扩展 后台wget/aria2断点续传下载文件直接落Drive8~14小时数据预处理/批处理Python心跳线程轻量计算 修改系统不锁屏处理结果分批写入Drive12~16小时只做交互式实验不需要额外防断连手动保存正常90分钟会断下面几条是我多次实测后的详细记录。纯JS方案在2024年10月的Colab新界面上稳定运行了9小时16分钟最终断连原因是Chrome自动更新导致浏览器重启。这个案例侧面说明系统层面的稳定性有多重要。JS Python线程稳定运行了15小时41分钟断连发生在一次Google Drive同步占用大量带宽之后。我怀疑频繁的IO操作对实例不太友好所以后续下载任务我都让保活线程保持更低的计算频率。JS 训练打印 断点续训这就是破纪录的22小时案例。那次训练从早上9点跑到了第二天早上7点中间没有任何断连。但说实话也有运气成分因为那时候是工作日清晨Google整个平台的负载不算高。还有一次反面教训我一度开了多个保活手段同时运行——浏览器扩展、Python心跳线程、每2个batch打印一次日志。结果训练脚本的输出缓冲区爆炸前端页面卡死我眼睁睁看着页面失去响应最后运行时崩溃了。后来我再也不用多个保活线程叠加一套核心方案轻量辅助就足够了。6.1 长训练的最终配置清单最后分享我目前最常用的长训练配置已经稳定跑过十几次长任务断连不再是影响心态的事。Google Drive挂载权重每5分钟保存一次训练代码内嵌每10步打印loss控制台JS心跳设置为90秒一次浏览器关闭内存节省固定Colab标签页操作系统接通电源后永不休眠笔记本合盖前将合盖操作改为不采取任何操作首次启动自动检查并安装缺依赖。这套组合不需要额外装插件纯靠页面脚本加代码逻辑完成稳定性是最高的。而且即便哪天真的被平台回收资源我也只需要重启运行时mount一下Drive加载latest.pth继续训练。6.2 关于Colab Pro的看法如果你财力允许Colab Pro或者Pro确实能把空闲超时从90分钟放宽到数个小时也能获得优先使用T4/A100这类高级GPU的权利。但它不等于“永远不会断”。我见过Pro账号在凌晨高峰期照样被断开的情况。所以不要把订阅当成防断连的终极答案断点续训的功课无论用免费版还是付费版都该做。6.3 我的最终建议我的总体观点很明确免费的算力本身就意味着不稳定过度追求“不断连”性价比很低。把心思花在心跳脚本上不如把心思花在“如何让每次重启成本最低”上。我自己的训练脚本现在已经做到从断连到恢复训练全程只需要手动执行三个单元格剩下的全是自动化。这套思路不仅适用于Colab放在任何云端GPU实例上都成立。真正成熟的深度学习工作流从来不应该依赖某个实例的稳定存活。你只需要保证它活着的每一秒都在产生有效产出剩下的交给时间就好。