1. 为什么我还在用 Colab 跑深度学习实验1.1 一个免费 GPU 环境的真实定位先说结论Colab 不是用来替代本地工作站或云服务器的它更像是一个“随时能掏出来的临时算力口袋”。我平时主力机器是一台带 3060 的台式机但出门在外只带轻薄本的时候Colab 就是我的救命稻草。标题里提到的 K80 GPU虽然现在看已经是老将了但它的 12GB 显存放在今天依然能跑不少中等规模的实验尤其是那些不需要最新算子支持的传统模型。很多人第一次接触 Colab 是冲着“免费”两个字去的但用着用着就发现各种限制会话超时、显存被回收、磁盘空间不够。这些问题其实都有解只是官方文档不会明明白白告诉你。我前后用了大概两年多踩过的坑足够写一本小册子所以这次把关于 K80 环境下的使用记录整理出来重点放在那些真正影响效率的细节上。这篇文章适合谁看如果你正在用 Colab 做课程作业、跑论文实验、或者临时验证一个想法但总是被“运行时断开连接”搞得很烦躁那下面的内容应该能帮你省下不少重复劳动的时间。我不会讲太多 Colab 的基础操作比如怎么新建笔记本、怎么挂载网盘这些搜一下就有。我要说的是那些你用过一段时间之后才会遇到的问题以及我摸索出来的应对方式。1.2 K80 这个老伙计的真实性能表现先给不太熟悉硬件的朋友一个直观印象K80 是 2014 年发布的架构单精度浮点算力大约 8.7 TFLOPS显存 12GB GDDR5。对比一下现在一张 4060 的算力大概是它的十几倍。但算力不是唯一指标K80 的显存带宽有 480GB/s这个数字放到今天也不算太寒酸。实际跑起来是什么感觉呢我拿一个经典的 ResNet-50 在 ImageNet 子集上做迁移学习batch size 设到 64 的时候每个 epoch 大概需要 4 到 5 分钟。同样的任务在 3060 上大概是 40 秒左右。差距确实明显但如果你只是跑一个几十个 epoch 的小实验这个速度完全可以接受。关键问题在于 K80 的架构比较老它不支持一些新的混合精度训练特性。比如你如果直接用torch.cuda.amp做自动混合精度在 K80 上基本没有加速效果因为它的 Tensor Core 是后来才有的东西。所以用 K80 的时候我建议老老实实用 FP32 训练不要折腾 AMP省得遇到一堆莫名其妙的报错。另外 K80 的驱动版本在 Colab 上通常比较旧有些新版本的 PyTorch 可能已经不再支持它了。我实测下来PyTorch 1.13 左右的版本兼容性最好再新的版本可能会提示找不到兼容的 CUDA 架构。还有一个容易被忽略的点Colab 分配给 K80 的时候通常是一整张卡给你用但有时候也会出现两个人共享一张卡的情况。怎么判断跑一个简单的矩阵乘法看看耗时波动大不大。如果波动超过 20%大概率是有人在跟你抢资源。这时候可以尝试重新连接运行时直到分到一张相对空闲的卡为止。这个技巧听起来有点玄学但实测有效。2. 环境配置与依赖管理的实操细节2.1 首次连接后的必做检查清单每次新建一个 Colab 笔记本或者重新连接运行时之后不要急着跑训练脚本。先花两分钟做几个检查能避免后面很多莫名其妙的错误。我习惯在第一个代码单元格里放一段固定的检查代码直接复制粘贴就能用。import torch import sys print(Python version:, sys.version) print(PyTorch version:, torch.__version__) print(CUDA available:, torch.cuda.is_available()) if torch.cuda.is_available(): print(GPU name:, torch.cuda.get_device_name(0)) print(GPU memory:, torch.cuda.get_device_properties(0).total_memory / 1024**3, GB) print(CUDA version:, torch.version.cuda)这段代码跑完你就能确认三件事GPU 是不是真的挂上了、显存有多大、CUDA 版本是多少。我遇到过好几次torch.cuda.is_available()返回 False 的情况原因通常是运行时类型选错了。在 Colab 的菜单里代码执行程序-更改运行时类型硬件加速器要选 GPU这个大家都知道。但有时候选了 GPU 之后分配到的还是 CPU这时候只能断开重连多试几次。还有一个隐藏的坑Colab 的默认 PyTorch 版本可能和你代码里用的版本不一致。比如你的代码用了torch.compile但 Colab 预装的是 1.12 版本那就会直接报错。解决办法是在笔记本开头用!pip install torch1.13.1指定版本但要注意安装完之后需要重启运行时才能生效。重启之后之前安装的其他包可能也会丢失所以最好把所有依赖写在一个requirements.txt里一次性安装。2.2 依赖安装的加速与持久化策略Colab 的默认 pip 源在国外安装大包的时候速度很不稳定。我一般会换成国内的镜像源速度能快好几倍。具体命令是在 pip install 后面加-i参数指定源地址。比如安装 OpenCV 的时候!pip install opencv-python -i https://pypi.tuna.tsinghua.edu.cn/simple但这里有个问题Colab 的运行时是临时的你这次安装的包下次重新连接就没了。每次都要重新装一遍很浪费时间。我的做法是把所有依赖写进一个脚本文件放在 Google Drive 里然后每次连接后先挂载 Drive再运行安装脚本。这样至少不用每次手动敲命令。from google.colab import drive drive.mount(/content/drive) !pip install -r /content/drive/MyDrive/colab_env/requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simplerequirements.txt里我会把版本号写死比如numpy1.23.5、pandas1.5.3。为什么要写死因为 Colab 预装的包版本经常变有时候你昨天跑通的代码今天因为 numpy 升级到 2.0 就报错了。写死版本号能保证每次环境一致减少“昨天还好好的”这种情况。另外提醒一句不要随便升级 Colab 预装的核心包比如 torch、tensorflow、numpy。这些包之间有关联依赖升级一个可能会把另一个搞坏。如果确实需要新版本建议用虚拟环境但 Colab 上虚拟环境用起来比较麻烦我一般能忍则忍实在不行就换运行时。3. 数据管道的搭建与优化3.1 从 Google Drive 读取数据的正确姿势Colab 的本地磁盘只有几十 GB而且重启就清空。所以大部分人的数据都放在 Google Drive 里。但直接从 Drive 读取文件训练速度会非常慢因为 Drive 是网络挂载IO 延迟很高。我做过测试同样一个 1GB 的图片数据集从 Drive 直接读每个 epoch 要 3 分钟复制到本地磁盘再读只要 40 秒。所以正确的做法是先把数据从 Drive 复制到 Colab 的本地磁盘/content目录下然后再开始训练。复制命令很简单!cp -r /content/drive/MyDrive/datasets/my_dataset /content/data/但这里有个细节/content目录的空间有限如果数据集太大比如超过 20GB复制可能会失败。这时候可以考虑只复制一部分或者用tar压缩之后再复制用的时候再解压。我一般会把数据集打包成.tar文件放在 Drive 里复制过来之后用tar -xf解压这样比复制几万个小文件快得多。还有一个技巧如果数据集在 Kaggle 上可以直接用 Kaggle API 下载速度比从 Drive 复制快。Colab 里已经预装了 Kaggle 库你只需要上传kaggle.json密钥文件然后!kaggle datasets download -d username/dataset-name !unzip dataset-name.zip -d /content/data/3.2 DataLoader 的参数调优经验数据管道搭好之后DataLoader的参数设置直接影响 GPU 利用率。我见过很多人抱怨 GPU 利用率只有 30%一看代码num_workers设的是 0。在 Colab 上num_workers设成 2 到 4 比较合适设太多反而会因为进程切换开销导致变慢。from torch.utils.data import DataLoader train_loader DataLoader( dataset, batch_size64, shuffleTrue, num_workers2, pin_memoryTrue, drop_lastTrue )pin_memoryTrue这个参数在 Colab 上效果很明显它能把数据提前放到锁页内存里加速 CPU 到 GPU 的传输。但要注意如果num_workers大于 0pin_memory的效果才会充分发挥。另外drop_lastTrue在训练时建议打开避免最后一个 batch 太小导致 batch norm 层报错。还有一个容易忽略的点Colab 的 CPU 核心数不多通常只有 2 到 4 个。所以num_workers不要超过 CPU 核心数否则会互相抢资源。你可以用!nproc命令查看当前运行时的 CPU 核心数。我一般设成min(4, os.cpu_count())这样比较稳妥。4. 训练过程中的稳定性保障4.1 防止会话超时的几种手段Colab 最让人头疼的就是会话超时。免费版如果 90 分钟没有交互或者连续运行超过 12 小时就会被强制断开。训练到一半断开如果没保存 checkpoint那就白跑了。我试过几种防超时的方法下面说下效果。第一种是在浏览器控制台里跑一段 JavaScript定时点击页面上的某个元素模拟用户交互。这个方法网上流传很广但实测下来不太稳定因为 Colab 的页面结构会变而且浏览器标签页如果被切到后台定时器可能会被节流。第二种是用 Python 代码定时打印日志但打印日志不算“交互”该断还是断。我现在用的方法比较笨但有效把训练过程拆成多个小段每段跑 30 到 40 分钟然后主动保存 checkpoint 并断开重连。虽然麻烦一点但至少不会丢进度。具体做法是在训练循环里加一个计数器每跑 N 个 batch 就保存一次模型然后检查运行时间如果超过 40 分钟就主动raise SystemExit结束脚本。下次连接后从最新的 checkpoint 继续训练。import time start_time time.time() for epoch in range(start_epoch, num_epochs): for batch_idx, (data, target) in enumerate(train_loader): # 训练代码... if batch_idx % 500 0: torch.save(model.state_dict(), /content/drive/MyDrive/checkpoints/latest.pth) if time.time() - start_time 2400: # 40分钟 print(主动结束保存checkpoint) torch.save(model.state_dict(), /content/drive/MyDrive/checkpoints/latest.pth) raise SystemExit这样即使被强制断开最多也只损失几十个 batch 的进度。而且因为 checkpoint 存在 Drive 里重新连接后直接加载就行。4.2 显存不足的排查与缓解K80 的 12GB 显存说大不大说小也不小。跑一般的分类模型够用但如果输入分辨率高、batch size 大或者模型参数量多就容易 OOM。我遇到 OOM 的时候一般按下面的顺序排查。先看 batch size 是不是设太大了。这是最常见的原因。把 batch size 减半如果 OOM 消失那就是显存不够。但减 batch size 会影响训练效果所以可以配合梯度累积来模拟大 batch。比如原来 batch size 是 64现在改成 16然后每 4 个 batch 做一次参数更新效果接近。accumulation_steps 4 optimizer.zero_grad() for i, (data, target) in enumerate(train_loader): output model(data) loss criterion(output, target) / accumulation_steps loss.backward() if (i 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()如果减 batch size 没用那就检查是不是有中间变量没释放。比如在验证阶段忘了用torch.no_grad()导致计算图一直累积。或者在循环里不断把 tensor append 到列表里显存越用越多。这时候可以用torch.cuda.empty_cache()手动清理缓存但治标不治本还是要找到泄漏的地方。还有一个隐蔽的坑Colab 有时候会分配一张已经被占用的 K80你看到的 12GB 显存其实只有一部分可用。用nvidia-smi命令可以查看当前显存占用情况。如果发现还没跑代码就占了好几个 GB那说明这张卡不干净赶紧断开重连换一张。5. 常见报错与排查速查5.1 CUDA 相关错误的处理思路用 Colab 跑深度学习CUDA 报错几乎不可避免。我把遇到过的错误和解决办法整理成了一张表方便快速查阅。报错信息可能原因解决办法CUDA out of memory显存不够减小 batch size用梯度累积清理缓存no kernel image is availablePyTorch 版本与 GPU 架构不匹配降级 PyTorch 到 1.13 或更早device-side assert triggered标签越界或索引错误检查标签范围确保在 [0, num_classes-1]CUDA error: unknown error驱动或运行时异常断开重连换一个运行时RuntimeError: cuDNN errorcuDNN 版本不兼容设置torch.backends.cudnn.enabled False其中device-side assert triggered这个错误特别烦人因为它不会告诉你具体哪一行出错。我的经验是先检查分类任务的标签是不是从 0 开始连续编号。如果标签里有 -1 或者大于类别数的值就会触发这个错误。另外如果用了CrossEntropyLoss它的 target 必须是long类型不能是float。这些细节在本地跑可能没事但在 Colab 上因为环境差异有时候就会暴露出来。5.2 运行时断开的预防与恢复运行时断开是 Colab 的常态与其抱怨不如接受它然后设计一套恢复机制。我的做法是在训练脚本里加一个“断点续训”的逻辑每次开始训练前先检查 checkpoint 目录里有没有最新的模型文件如果有就加载并从对应的 epoch 继续。import os checkpoint_path /content/drive/MyDrive/checkpoints/latest.pth start_epoch 0 if os.path.exists(checkpoint_path): checkpoint torch.load(checkpoint_path) model.load_state_dict(checkpoint[model_state_dict]) optimizer.load_state_dict(checkpoint[optimizer_state_dict]) start_epoch checkpoint[epoch] 1 print(f从 epoch {start_epoch} 继续训练)保存 checkpoint 的时候除了模型参数最好把优化器的状态也存下来。因为像 Adam 这种优化器它内部有动量缓存如果不恢复训练曲线可能会出现波动。另外学习率调度器的状态也建议保存不然恢复之后学习率会从头开始。还有一个细节checkpoint 文件不要只存一个最好保留最近三个版本防止某个文件损坏。我一般用latest.pth、best.pth和epoch_{n}.pth三个文件轮换。best.pth存验证集上效果最好的模型latest.pth存最新的epoch_{n}.pth每 10 个 epoch 存一次归档。6. 一些让我少走弯路的实操心得6.1 关于 K80 的混合精度训练前面提过 K80 不支持 Tensor Core所以 AMP 基本没用。但我后来发现即使没有加速效果用torch.cuda.amp也能减少显存占用因为 FP16 的中间变量比 FP32 小一半。这对于显存紧张的情况还是有帮助的。不过要注意K80 对 FP16 的支持不完整有些算子可能会报错。我试过在 K80 上开 AMP 跑 ResNet前向传播没问题但反向传播的时候偶尔会出 NaN。所以如果你要用 AMP建议先跑几个 batch 看看 loss 是否正常如果出现 NaN 就赶紧关掉。6.2 用 TensorBoard 监控训练过程Colab 里可以直接用 TensorBoard 看训练曲线但需要一点小技巧。首先安装 tensorboard 包然后在代码里创建 SummaryWriter把日志写到 Drive 里。接着在笔记本里加载 TensorBoard 扩展%load_ext tensorboard %tensorboard --logdir /content/drive/MyDrive/logs这样就能在笔记本页面里直接看到 loss 曲线和准确率曲线。我习惯把学习率、梯度范数也记录下来方便判断训练是否稳定。如果梯度范数突然变得很大说明可能要梯度爆炸了这时候可以调小学习率或者加梯度裁剪。6.3 什么时候该放弃 Colab 换别的方案Colab 免费版适合做原型验证和小规模实验但如果你的任务需要跑好几天或者需要多卡并行那 Colab 就不合适了。我一般把 Colab 当作“第一轮筛选”的工具先用小数据集和少量 epoch 验证代码能不能跑通超参数大概在什么范围。等确定方案可行之后再放到本地机器或者付费算力上跑完整实验。这样能充分利用 Colab 的免费额度又不会因为它的限制影响最终结果。另外Colab 的 Pro 版本虽然能提供更好的 GPU但价格不算便宜。如果你的实验频率很高可以算一下账一个月 Pro 的费用可能够你租一台按量付费的云服务器跑几十个小时。所以不要盲目升级先评估自己的实际需求。6.4 一个提高效率的小习惯最后分享一个我养成的习惯每次在 Colab 上跑通一个实验就把完整的笔记本导出成.ipynb文件存到 Drive 里文件名带上日期和关键参数。比如20250115_resnet50_bs64_lr0.001.ipynb。这样过几个月回头看能快速找到当时用的配置不用重新试错。而且如果 Colab 的预装环境变了导致代码跑不通你还能对照旧笔记本里的版本号把环境还原回去。这个习惯看起来不起眼但积累下来就是一套属于自己的实验记录库。比起每次从头开始效率提升非常明显。我现在遇到类似任务先去翻以前的笔记本找到最接近的配置改几个参数就能跑省下的时间够多跑好几组对比实验了。