调试手记：那个让我连夜迁移模型的训练任务

凌晨两点，监控告警又响了。本地服务器的3080显卡显存再次爆满，训练进度卡在87%一动不动。这已经是本周第三次因为显存不足导致训练中断，项目进度眼看就要延误。就在准备申请公司GPU服务器预算时，同事指了指屏幕：“试试Colab？免费的。”

为什么是Google Colab？

你可能也遇到过类似场景：学生党没有高性能显卡，创业团队预算有限，甚至在大厂里排队等GPU资源也要半天。Colab的出现直接打破了这些门槛——浏览器里直接跑PyTorch和TensorFlow，连环境都不用配。

关键优势很实在：完全免费层提供T4/P100/V100显卡（运行时随机分配），12-16GB显存足够跑大多数中等规模模型。更重要的是环境预配置，从TensorFlow到PyTorch，从CUDA到cuDNN，打开就能用，省去了至少半天的环境调试时间。

那些实际踩过的坑

免费资源自然有限制，但摸清规则后能玩得很转。最常遇到的是运行时断开——Colab的免费会话最多持续12小时，长时间空闲还会自动回收。

# 防止自动断开的技巧（每30分钟模拟一次交互）
import time, IPython.display as display

def keep_alive():
    for _ in range(48):  # 保持24小时（实际最多12小时）
        time.sleep(1800)  # 30分钟
        display.display(display.HTML('<div>Keep alive ping</div>'))
        # 这里踩过坑：单纯print不行，必须更新输出单元格

另一个坑是文件系统。Colab的临时存储会在会话结束后清空，重要数据得挂载Google Drive。但直接挂载整个Drive会拖慢IO，我的经验是只挂载必要目录：

from google.colab import drive
drive.mount('/content/drive')

# 别这样写：所有数据都扔根目录
# 应该创建专用项目目录
import os
proj_dir = '/content/drive/MyDrive/colab_projects/current'
os.makedirs(proj_dir, exist_ok=True)
os.chdir(proj_dir)  # 切换工作目录

算力提升的实战技巧

免费层用户也能通过一些技巧提升体验。首先是显卡选择，虽然不能指定型号，但可以通过重置会话“刷”到更好的卡。实测发现：下午时段更容易分到V100，凌晨则多是T4。

内存不够用？Colab提供高内存模式（虽然不总是可用）。在代码执行前点击“修改”→“笔记本设置”，将运行时形状改为“高RAM”。对于大batch训练，这个开关能增加近一倍的系统内存。

数据加载优化也很关键。从Drive读取大文件很慢，我的做法是先用压缩包传输，在Colab本地解压：

# 先在本地将数据集打包成zip
# 上传到Drive后，Colab里这样处理：
!cp "/content/drive/MyDrive/dataset.zip" "/content/"
!unzip -q "/content/dataset.zip" -d "/content/dataset"
# 后续直接从本地磁盘读取，速度提升明显

个人经验与建议

用Colab两年多，最大的体会是：把它当作开发调试环境，而非生产训练平台。适合做原型验证、小规模实验、教学演示。真要训练大模型，还是得用持久化资源。

几个实用建议：每周清理一次Drive上的临时文件，避免达到存储上限；重要代码和模型权重一定要定期备份到GitHub；复杂项目建议用Colab Pro，性价比其实很高，特别是需要长时间运行的任务。

最后提醒一点：敏感数据别往上放。虽然Google有安全措施，但把公司核心数据集放免费平台总归不合适。用合成数据或公开数据集做验证，本地训练最终模型——这是最稳妥的工作流。

下次遇到显存告警时，不妨先开个Colab临时顶上去。至少，它能让你在等公司资源审批时，不耽误调试代码。# 002、Colab入门第一步：账号注册、环境与界面详解

上周帮同事调试一个YOLO模型，他本地显卡是GTX 1060 6GB，跑训练时显存直接爆了。我让他把数据扔到Colab上试试，结果他折腾了一下午连环境都没配起来——不是账号登录出问题，就是找不到修改运行时类型的入口。这类问题其实特别典型，很多工程师习惯本地开发环境，初次接触云端环境时容易在基础环节卡壳。今天我们就拆解Colab的入门环节，这些细节决定了后续的开发效率。

账号注册的隐藏关卡

很多人以为Colab注册就是简单用谷歌账号登录，实际上有几个关键点需要注意。如果你用常规方式访问colab.research.google.com，可能会遇到“您所在的地区不支持此服务”的提示。这时候需要明确：Colab服务确实在某些地区受限，但通过科学上网切换节点到支持地区（如美国、日本）通常能解决。不过要注意，账号注册地和你当前IP地区最好保持一致，否则后期可能触发风控。

注册时建议使用教育邮箱（.edu后缀），虽然普通Gmail也能用，但教育账号在资源配额上略有优势。别用临时邮箱注册，后期模型训练到一半要是账号异常，几个小时的训练就白费了。注册完成后先去drive.google.com初始化一下谷歌云盘，这是Colab的持久化存储空间，后面会频繁用到。

环境选择的核心逻辑

登录成功后你会看到一个干净的Jupyter Notebook界面，这时候别急着写代码。看左上角菜单栏，找到“代码执行程序”——点击“更改运行时类型”，这个界面决定了你的计算资源。

运行时类型选择有个经验法则：如果你只是跑简单的Python脚本或数据处理，选CPU就够了；需要GPU加速时，优先选T4 GPU（Colab Pro用户可能看到V100或A100）。注意免费版Colab的GPU资源是动态分配的，连续使用超过一定时间（通常2-3小时）会被强制断开，重要实验记得设置检查点保存。

内存和磁盘大小很多人会忽略。免费版运行时内存大约12GB，磁盘空间约68GB。如果处理大型数据集，可以挂载谷歌云盘到/content/drive目录，但要注意云盘的读写速度比本地磁盘慢，建议把需要频繁读写的中间文件放在/content下。

界面布局的实战解读

Colab界面看起来就是个增强版Jupyter，但几个关键区域需要特别熟悉：

右上角的连接状态指示器是个重要信号。显示“已连接”表示分配到了后端虚拟机，“正在连接”说明在排队分配资源。免费用户高峰期可能需要排队几分钟，这时候别反复点击“连接”，会导致重新排队。如果显示“运行时已断开”，通常是长时间无操作导致的自动断开，代码和变量都会丢失——所以重要变量要及时保存到云盘。

左侧的文件管理器分两块：/content是临时工作区，重启运行时会被清空；/content/drive是挂载的谷歌云盘，数据放这里才持久。新手常犯的错误是把数据集上传到/content，训练到一半运行时断开，数据就没了。正确做法是先把数据上传到谷歌云盘，然后在代码开头用from google.colab import drive; drive.mount('/content/drive')挂载。

代码单元格上方的工具栏里，有个“查看资源”按钮（显示RAM/磁盘使用情况），调试时建议一直打开。我遇到过内存泄漏导致运行时崩溃的情况，就是通过这个监控发现内存使用曲线异常上升的。

环境配置的坑点记录

新建笔记本默认环境是干净的Ubuntu系统，预装了主流深度学习框架，但版本可能不是最新的。第一件事通常是更新包和安装特定依赖：

# 别这样写：一次性安装所有包
# !pip install torch torchvision numpy pandas matplotlib scikit-learn
# 这样容易出依赖冲突，而且出错时难定位

# 建议这样分步安装
!pip install torch==2.0.1 --quiet  # 指定版本避免兼容性问题
!pip install torchvision --quiet
# 每个命令单独执行，能看到具体哪个包安装失败

安装完成后务必验证环境：

import torch
print(torch.__version__)  # 确认版本
print(torch.cuda.is_available())  # 必须返回True才能用GPU
print(torch.cuda.get_device_name(0))  # 看看分配了什么显卡

如果cuda.is_available()返回False，大概率是运行时没选GPU，或者运行时需要重启。Colab有个小坑：更改运行时类型后，需要重启运行时（运行时菜单->重启运行时）才能生效，很多人改了设置就直接跑代码，结果还在用CPU。

个人经验建议

免费版Colab适合做原型验证和小规模实验，不适合跑需要几天训练的大模型。我的工作流通常是：本地写好代码框架 -> Colab调试通过 -> 如果资源不够再考虑付费版或转其他平台。

数据管理上，建议在谷歌云盘建立固定目录结构，比如/ColabProjects/datasets/、/ColabProjects/checkpoints/。每次挂载后软链接到/content下，避免代码里写冗长的绝对路径。

遇到“无法分配后端”的错误时，可以尝试在浏览器隐身模式下打开Colab，或者换个谷歌账号登录。免费资源有限，高峰期（美国白天）确实难抢到GPU，可以调整工作时间到国内凌晨时段，资源相对充足。

最后提醒一点：Colab不是生产环境，重要实验一定要把关键结果和模型检查点自动同步到云盘。我写过自动备份脚本，每训练完一个epoch就同步一次，虽然有点IO开销，但比起运行时突然断开导致全天工作白费，这个代价值得。

下次我们聊如何用Colab Pro/Pro+的算力提升技巧，包括如何稳定获取A100实例、如何绕过空闲超时限制等实战经验。## 003、Colab核心操作：笔记本创建、文件管理与运行时连接

上周帮同事调试一个YOLO模型，他发来Colab链接说“跑不动了”。我点开一看，代码写得没问题，但数据集直接上传到了/content下，运行时断开后全丢了，重新训练又得从头下载。这其实是很多Colab新手都会踩的坑——没搞清这个云端环境的“脾气”。

笔记本创建：选对入口能省一半事

很多人第一次用Colab，习惯性点开网页就新建笔记本。但如果你要从GitHub导入已有项目，别在空白笔记本里硬克隆。看这里：

# 错误做法：在空白笔记本里手动敲git clone
!git clone https://github.com/xxx/xxx.git
# 这样也行，但每次打开都得重新克隆，麻烦

# 推荐做法：直接从GitHub导入
# 1. 在Colab主页选择“GitHub”标签页
# 2. 粘贴仓库URL或直接搜索
# 3. 关键步骤：勾选“包含.ipynb”
# （很多项目的训练代码在.py文件里，不勾选可能找不到入口）

更隐蔽的细节是内核选择。新建笔记本默认是Python 3，但有些老项目需要Python 2。别在运行时里硬切版本——Colab早就移除了Python 2支持。真遇到这种情况，要么改代码适配Python 3，要么考虑换平台。

文件管理：/content目录是个临时工棚

Colab的虚拟机生命周期从你连接运行时开始，到网页关闭或超时结束。所有上传到/content的文件都是临时存储。我见过有人把5GB的预处理数据放在这里，训练中断后欲哭无泪。

# 临时文件操作示例
from google.colab import files
uploaded = files.upload()  # 弹出本地文件选择框
# 注意：这里上传的文件只在当前会话有效！
# 刷新页面就没了

# 持久化存储得挂载Google Drive
from google.colab import drive
drive.mount('/content/drive')
# 这个授权流程得走一遍，给权限就行
# 挂载后你的Drive会出现在/content/drive/MyDrive

有个坑得特别注意：Colab默认工作目录是/content，但Drive挂载在子目录。很多人直接os.chdir('/content')，然后奇怪为什么找不到Drive里的文件。建议开工前先确认路径：

import os
print(os.getcwd())  # 看看自己在哪
# 通常需要：os.chdir('/content/drive/MyDrive/你的项目文件夹')

运行时连接：免费GPU不是随时待命

Colab最吸引人的是免费GPU，但它的分配策略有点“玄学”。有时候明明显示有T4可用，一连接却给了CPU。这时候别反复点“连接运行时”——容易触发限制。

试试这个顺序：

1. 先不选GPU，用默认设置连接运行时
2. 执行!nvidia-smi看看底层有没有GPU（有时显示CPU但实际有GPU资源）
3. 如果真是CPU，断开运行时，修改笔记本设置（“修改”->“笔记本设置”->选择GPU），等几分钟再重连

更头疼的是运行时自动断开。Colab在页面无操作约30分钟后会回收资源。长时间训练时，我习惯在代码里加个心跳：

# 简易防断线心跳（不能完全避免，但能延长寿命）
import time, requests

def keep_alive():
    while True:
        time.sleep(300)  # 5分钟一次
        # 随便执行个轻量操作
        _ = 1 + 1
        # 或者请求个无害的网页
        # requests.get('https://www.google.com')
        
# 放在后台线程运行
import threading
thread = threading.Thread(target=keep_alive)
thread.daemon = True
thread.start()

但注意：别用太频繁的请求，Colab会检测异常流量。有些开发者写循环不断输出日志，反而容易被判定为“空闲”（因为输出内容相似）。最好的防断线方式是——用付费版Pro，或者把长时间训练拆分成多个阶段，中间保存checkpoint到Drive。

个人经验包

Colab用久了，会发现它像个带限时免费套餐的咖啡馆。你得知道几点人少（欧美夜间亚洲白天资源多）、怎么占座（提前打开多个标签页）、东西放哪不会丢（Drive里建项目文件夹）。几个私人习惯：

• 数据集永远放在Drive，用软链接链到/content下，这样既满足代码的路径依赖，又保证数据安全
• 每节代码块开头加个路径检查，避免目录混乱导致的模块导入失败
• 免费用户遇到GPU排队时，试试切换Colab实例类型（“修改”->“笔记本设置”->“更改运行时类型”），有时T4没有但P100有空闲
• 关闭笔记本前，主动在“运行时”菜单点“管理会话”->“终止”，比直接关网页礼貌些，下次分配资源可能更顺利

最后说个真相：Colab的设计初衷是交互式学习和原型验证，不是7x24小时训练服务器。理解这个定位，用它做快速实验和演示，你会觉得这工具真香；硬要它当免费算力矿场，反而会陷入各种限制的烦恼。下次聊聊怎么用Colab配合GitHub做模型迭代——那才是它的正确打开方式。# 004、Colab算力基础：免费GPU/TPU资源申请与配置

昨天深夜调试一个YOLOv5模型，本地训练一轮要四十分钟，等到第三轮时风扇狂转的声音让我突然清醒——这种活怎么能交给笔记本硬扛？摸出收藏夹里落灰的Colab链接，十分钟后模型已经在Tesla T4上跑起来了，训练时间直接缩到七分钟一轮。今天咱们就聊聊怎么把Colab的免费算力真正用起来。

一、资源申请那些坑

很多人第一次打开Colab就急着点“修改-笔记本设置”选GPU，结果跑个简单打印语句就把配额用完了。这里有个关键细节：Colab的免费资源是动态分配的，新账号前几个小时通常只能用到Tesla K80，连续使用几天后系统才会分配T4甚至P100。我建议头两天先用小规模任务“养号”，比如跑个MNIST分类，让系统判定你是正常研究用户而非挖矿脚本。

申请GPU的位置藏在菜单栏“代码执行程序”-“更改运行时类型”里，注意这里还有个“运行时形状”选项，但免费用户只能选标准。TPU选项虽然亮着，但需要你的代码专门适配TensorFlow的TPU架构，新手建议先从GPU上手。

二、配置环境实战

连接成功后千万别急着跑模型，先执行这段诊断代码：

import tensorflow as tf
print("GPU数量:", len(tf.config.list_physical_devices('GPU')))
!nvidia-smi

我第一次用的时候没检查，结果代码实际跑在CPU上，还纳闷怎么比本地还慢。看到nvidia-smi输出T4/P100字样才算真正拿到显卡。

接下来是环境配置的经典问题：Colab每次重启都会重置环境。我的做法是在开头用shell命令一次性装完依赖：

# 别这样写：每个包单独pip install
# 应该这样：
!pip install torch torchvision --quiet
!pip install opencv-python pandas --quiet 2>/dev/null

那个2>/dev/null是吞掉警告信息，让输出更干净。记得所有安装命令放在同一个代码块里，避免多次触发环境检查。

三、持久化存储方案

Colab的临时存储空间会在运行时结束后清空，下载的数据集下次还要重新拉取。我的解决方案是挂载Google Drive：

from google.colab import drive
drive.mount('/content/drive')

# 挂载后创建软链接到工作目录
!ln -s /content/drive/MyDrive/colab_data /content/data

但要注意Drive的读写速度比本地慢，最好把需要频繁读取的数据先复制到/tmp下操作：

# 这样写速度慢
# train_data = load_from_drive('/content/data/dataset.h5')

# 应该先拷贝到内存盘
!cp /content/drive/MyDrive/dataset.h5 /tmp/
train_data = load_from_drive('/tmp/dataset.h5')

四、避开配额限制的技巧

免费用户最头疼的就是运行时断开。我观察到的规律是：连续空闲30分钟必断，高负载运行最多可持续12小时。有几个延长寿命的土方法：

1. 在代码里插入周期性输出，比如每训练完一个epoch就print时间戳
2. 用键盘快捷键Ctrl+F9（不是点按钮）重启并执行所有单元，比手动重连快
3. 夜间训练时可以在最后加个无限循环，保持有输出活动

但注意别用while True: time.sleep(60)这种，系统能检测到空转。更好的做法是训练完成后自动保存模型到Drive，然后主动断开连接。

五、性能调优细节

同样是T4，不同配置方式性能能差三成。关键在这几处：

# PyTorch用户加上这几行
import torch
torch.backends.cudnn.benchmark = True  # 让cuDNN自动找最优卷积算法
torch.cuda.empty_cache()  # 每个epoch开始前清下缓存

# TensorFlow用户注意这个
tf.config.optimizer.set_jit(True)  # 启用XLA编译加速

数据加载部分最容易拖后腿。如果用的是torch.utils.data.DataLoader，把num_workers设为2就够了，Colab的虚拟CPU核数不多，设大了反而触发进程切换开销。

个人经验包

最后给几个实战建议：第一，重要实验一定在本地保存完整的依赖版本列表（pip freeze > requirements.txt），Colab的系统镜像可能随时更新。第二，看到“无法连接到GPU”的提示时，别急着刷新页面，先去Colab官网查查配额状态页面，有时候是区域资源紧张，换个美国东部时间凌晨再试就好。第三，复杂项目建议用!git clone把代码拉到Colab环境里跑，别在网页编辑器里写大段代码——那个编辑器没自动保存，断连了就全丢。

最有用的一招：训练循环里加个异常捕获，把模型检查点自动同步到Drive。我写过这么个结构：

try:
    train_model()
except Exception as e:
    print(f"训练中断: {e}")
    save_checkpoint_to_drive()  # 保命函数
    raise

这样哪怕突然断连，也能保住最后一个epoch的成果。免费资源终究有限，但这些技巧足够支撑大多数中小型实验。下次我们聊聊怎么用Colab Pro的性价比方案。# 005、算力提升技巧（一）：延长运行时与规避空闲中断

昨天深夜调试一个YOLO模型，训练刚跑半小时，浏览器标签页切出去查个文档的功夫，回来就看见Colab弹了个“运行时已断开”的提示。进度全丢，还得从头开始。这种痛，用过免费GPU的兄弟都懂。

免费GPU的本质是资源调度，平台不可能让你无限制占着显卡。Colab的运行时限制主要来自两方面：连续空闲超时断开和最长连续使用限制。今天咱们不聊理论，直接上实战技巧。

一、别让浏览器标签页“睡着”

Colab通过前端页面活动状态检测是否“空闲”。很多人误以为只要代码在跑就安全，其实浏览器标签页隐藏或失焦都可能触发检测机制。

最简单的防断连技巧：让标签页保持活动状态。打开浏览器开发者工具（F12），在Console里贴这段：

// 每隔几分钟点一下页面，模拟活动
function ClickConnect(){
    console.log("保活心跳，防止空闲断开");
    document.querySelector("colab-connect-button").click();
}
setInterval(ClickConnect, 60 * 1000);

注意这里有个坑：Colab界面更新后按钮选择器可能变化，如果无效，手动点一下“连接”按钮，右键检查元素，看看现在的类名是啥。

更稳妥的方法是直接让页面自动滚动：

// 温和的自动滚动，别用太激进的方案
let scrollPosition = 0;
setInterval(() => {
    scrollPosition = (scrollPosition + 50) % 400;
    window.scrollTo(0, scrollPosition);
}, 30000);

二、后台运行的硬核方案

如果训练要跑好几个小时，总不能一直守着浏览器。这时候得让运行时在后台持续工作。

方案A：用Python保持活动状态

在notebook开头加个后台线程，定期输出点内容：

import threading
import time

def keep_alive():
    while True:
        time.sleep(300)  # 5分钟一次
        print(f"[保活心跳] {time.ctime()}")
        # 顺便清空输出，避免日志太长
        from IPython.display import clear_output
        clear_output(wait=True)

thread = threading.Thread(target=keep_alive, daemon=True)
thread.start()

这个方案有个缺点：clear_output()会把所有输出清掉，包括你想看的训练进度。慎用。

方案B：模拟键盘活动（需要前端）

有些老司机用pyautogui，但在Colab的虚拟机环境里不一定好使。更靠谱的是用JavaScript配合：

from IPython.display import display, Javascript

js_code = """
setInterval(() => {
    // 模拟轻微的用户活动
    document.dispatchEvent(new KeyboardEvent('keydown', {'key': 'Shift'}));
}, 30000);
"""
display(Javascript(js_code))

三、规避12小时强制重启

Colab Pro+用户有更长的运行时，但免费版通常最多12小时。快到限制时，可以尝试“软重启”来续命。

关键操作：保存状态再重启

1. 训练代码里必须加入检查点保存：

# 别相信运行时能永远不断，必须存检查点
checkpoint_path = "/content/drive/MyDrive/checkpoints/"
if not os.path.exists(checkpoint_path):
    os.makedirs(checkpoint_path)

# 每epoch都保存，虽然IO慢但安全第一
model.save(f"{checkpoint_path}/epoch_{epoch}.h5")
print(f"[检查点已保存] 丢了也能从这里恢复")

2. 在运行时间快到限制前（比如11小时左右），主动重启运行时：
   • 保存所有重要数据到Google Drive
   • 点击“运行时”->“重新启动运行时”
   • 重新挂载Drive，加载检查点继续训练

这个操作有风险，可能重启后分配不到GPU。所以建议在训练脚本开头加个恢复逻辑：

import os
from glob import glob

# 启动时先找有没有之前的检查点
checkpoints = glob("/content/drive/MyDrive/checkpoints/*.h5")
if checkpoints:
    latest = max(checkpoints, key=os.path.getctime)
    print(f"发现之前训练的检查点: {latest}")
    # 这里应该写你的模型加载逻辑
    # model.load_weights(latest)

四、那些容易踩的坑

1. 别用time.sleep(3600)这种粗暴方案——长时间没有输出会被判定为空闲。任何保活机制都要有“输出证据”。

2. Google Drive的挂载点可能失效——重启后要重新挂载，但脚本可能还在跑。建议在访问Drive的代码段加try-catch：

try:
    with open("/content/drive/MyDrive/data.txt", "r") as f:
        data = f.read()
except Exception as e:
    print("Drive访问失败，尝试重新挂载")
    from google.colab import drive
    drive.mount('/content/drive')
    # 重新尝试读取

3. 浏览器扩展可能干扰——有些广告拦截器会把Colab的保活请求拦掉。训练时最好用无痕模式或禁用扩展。

个人经验谈

免费GPU就像公共健身房的热门器材，你得遵守规则但也要会钻空子。我现在的习惯是：

• 开跑前先把所有保活代码放在第一个cell执行，确保运行时稳定了再开始训练。
• 训练脚本必须设计成“可中断恢复”模式，检查点保存频率根据任务调整：初期每epoch都存，稳定后可以放宽。
• 深夜跑长任务时，用旧手机开浏览器挂着Colab页面，设置屏幕常亮，比任何软件方案都可靠。
• 重要实验永远不要完全依赖免费资源，Colab只是调试和轻量训练用，真正的大任务还是得找稳定算力。

最后说句实话：这些技巧都是权宜之计。真正提升效率的方法是优化代码，减少单次实验时间，把大任务拆成可分段执行的小任务。下次咱们聊聊怎么优化显存使用，同样预算下能跑更大的batch size，那才是根本解决之道。

（下一篇预告：显存优化技巧——让Colab跑起你以为它跑不动的模型）# 006、算力提升技巧（二）：挂载Google Drive实现数据持久化

昨天在Colab跑一个模型训练，迭代了三个小时，浏览器标签页不小心被同事关掉了。重新打开Colab，工作区干干净净，模型权重和预处理的数据全没了——这种痛，搞过长时间训练的朋友都懂。Colab的运行时是临时的，一旦断开连接，本地磁盘上的所有文件都会消失。今天咱们就彻底解决这个问题：把Google Drive挂载到Colab，实现数据、代码、模型的持久化存储。

为什么必须挂载Google Drive

Colab提供的本地磁盘空间虽然读写速度快，但生命周期完全依赖于当前运行时。训练到一半断线、运行时间超过12小时、或者主动重置运行时，所有文件都会清零。而Google Drive提供15GB免费空间，文件永久保存，正好弥补这个缺陷。更妙的是，Drive里的文件可以在不同Colab笔记本间共享，团队协作时特别方便。

挂载Drive的两种姿势

最直接的挂载方式就是用官方提供的代码块：

from google.colab import drive
drive.mount('/content/drive')

运行这段代码，Colab会弹出一个授权链接，点击链接获取验证码，粘贴回来就挂载成功了。这时候你会看到/content/drive/MyDrive目录，里面就是你Google Drive的全部内容。

但每次都要点链接复制验证码，调试时很烦。我习惯用这个改良版：

from google.colab import drive
import os

# 检查是否已经挂载，避免重复操作
if not os.path.exists('/content/drive/MyDrive'):
    drive.mount('/content/drive')
    print("Drive mounted successfully!")
else:
    print("Drive already mounted.")

挂载后，建议立即建立工作目录的软链接，这样后续代码路径就不用改了：

# 在Drive里创建项目文件夹（如果不存在）
project_path = '/content/drive/MyDrive/colab_projects/your_project'
os.makedirs(project_path, exist_ok=True)

# 创建软链接，让/content/project指向Drive里的文件夹
!ln -s {project_path} /content/project

# 切换到项目目录
%cd /content/project

路径管理的坑与技巧

新手常犯的错误是直接读写/content/drive/MyDrive/...的深层路径。每次操作都要走网络IO，速度慢不说，还容易因路径拼写出错。我的做法是：训练前把需要的数据从Drive复制到本地，训练完再把结果同步回Drive。

比如处理图像数据集：

import shutil

# 数据在Drive里的路径
drive_data_dir = '/content/drive/MyDrive/datasets/cats_vs_dogs'

# 复制到本地（小数据集直接全量复制）
local_data_dir = '/content/data'
if os.path.exists(local_data_dir):
    shutil.rmtree(local_data_dir)  # 清理旧数据
shutil.copytree(drive_data_dir, local_data_dir)

# 现在用本地路径训练，速度快多了
train_dir = f'{local_data_dir}/train'

模型检查点保存也要讲究策略。别每个epoch都直接存到Drive，网络传输顶不住：

import torch

# 本地保存路径
local_checkpoint_path = '/content/checkpoints/model_epoch_{}.pth'

# Drive备份路径
drive_checkpoint_dir = '/content/drive/MyDrive/checkpoints'

for epoch in range(num_epochs):
    # ...训练代码...
    
    # 每5个epoch在本地保存一次
    if epoch % 5 == 0:
        torch.save(model.state_dict(), local_checkpoint_path.format(epoch))
        
    # 每20个epoch备份到Drive一次
    if epoch % 20 == 0:
        drive_path = f'{drive_checkpoint_dir}/model_epoch_{epoch}.pth'
        shutil.copy(local_checkpoint_path.format(epoch), drive_path)

大文件传输的优化

当数据集超过1GB时，直接复制可能会超时。这时候要用分块处理，我写过一个通用的分块复制函数：

def copy_large_file(src, dst, chunk_size=1024*1024*64):  # 64MB一个块
    """大文件分块复制，避免超时"""
    with open(src, 'rb') as f_src:
        with open(dst, 'wb') as f_dst:
            while True:
                chunk = f_src.read(chunk_size)
                if not chunk:
                    break
                f_dst.write(chunk)
    print(f"Copied {os.path.getsize(src) / 1024**3:.2f} GB file.")

对于超大数据集，更聪明的做法是直接用tar流式处理：

# 从Drive流式解压到本地
!tar -xzf /content/drive/MyDrive/datasets/large_dataset.tar.gz -C /content/data/

# 训练完成后，将结果打包传回Drive
!tar -czf /content/results.tar.gz /content/results
!cp /content/results.tar.gz /content/drive/MyDrive/backups/

环境配置的持久化

Colab每次重启都会重置环境，重装所有依赖包很耗时。我把环境配置也存到Drive：

# 第一次运行时，生成requirements.txt
!pip freeze > /content/drive/MyDrive/colab_configs/requirements.txt

# 以后每次启动Colab，先恢复环境
!pip install -r /content/drive/MyDrive/colab_configs/requirements.txt

对于自定义的Python模块，可以打包成wheel存到Drive：

# 本地打包
!python setup.py bdist_wheel

# 保存到Drive
!cp dist/*.whl /content/drive/MyDrive/my_packages/

# 其他Colab笔记本中直接安装
!pip install /content/drive/MyDrive/my_packages/my_module-0.1-py3-none-any.whl

几个实战建议

第一，Drive的读写速度比本地磁盘慢10-50倍，IO密集型操作一定要先在本地进行。我习惯在本地/content/tmp做数据预处理，结果存到/content/output，最后批量同步到Drive。

第二，Colab偶尔会挂载失败，提示“重试次数超限”。这时候别慌，等几分钟再试，或者换个Google账号。我准备了两个备用账号，专门应对这种情况。

第三，重要数据一定要有双重备份。除了Drive，我还会把关键结果发到自己的Gmail。曾经遇到过Drive同步出bug，文件损坏的情况，邮件备份救了一命。

第四，团队协作时，在Drive里建立清晰的目录结构。我现在的项目模板是这样的：

MyDrive/
├── colab_projects/
│   ├── project_a/
│   │   ├── datasets/    # 原始数据
│   │   ├── scripts/     # 共享代码
│   │   └── results/     # 各成员结果
│   └── project_b/
├── colab_configs/       # 环境配置
└── colab_utils/         # 通用工具函数

最后说个细节：Colab默认的Drive挂载点有时候会权限不足。如果你遇到Permission denied错误，试试这个：

# 重新挂载并设置权限
!fusermount -u /content/drive
drive.mount('/content/drive', force_remount=True)

挂载Drive看似简单，但用好了能省下大量重复劳动。下次训练时，放心地去喝杯咖啡吧——数据都在Drive里，断线了也能接着跑。# 007、算力提升技巧（三）：安装自定义依赖与系统包

昨天在Colab上跑一个老项目，刚导入模型就报错：“libGL.so.1: cannot open shared object file”。典型的系统库缺失问题，在本地开发机上apt装一下就好，但Colab环境重启就重置，每次手动安装太耽误训练时间。这种场景在Colab里太常见了——项目依赖特定版本的Python包、需要编译工具链、甚至要修改系统配置。今天我们就聊聊怎么在Colab里“固化”这些自定义环境。

环境重置是Colab的默认行为

Colab每次重启运行时都会恢复到基础镜像，默认只预装主流深度学习框架和常用库。如果你需要特定版本的PyTorch、或者项目依赖某个小众的C++库，就得在笔记本开头主动配置环境。很多人习惯在代码第一段写一堆!pip install，这思路没错，但细节上容易踩坑。

比如直接这样装系统包：

!apt install libgl1-mesa-glx

重启后还得重装，而且如果包名记错了，每次重启都得重复试错。更麻烦的是，有些包安装时需要交互确认（比如时区选择），直接运行会卡住整个单元格。

静默安装与版本锁定技巧

对付需要交互确认的安装，加上DEBIAN_FRONTEND=noninteractive环境变量：

!DEBIAN_FRONTEND=noninteractive apt-get install -y libgl1-mesa-glx

-y参数自动确认，这个组合拳能避免大部分卡住的问题。

Python包安装更讲究些。很多人习惯!pip install torch==1.9.0，但Colab默认可能已经装了更高版本，直接覆盖有时会引发依赖冲突。我习惯先检查现有版本：

import torch
print(torch.__version__)  # 看看预装了什么

如果必须降级，用--force-reinstall强制重装，但要注意连带依赖：

!pip install torch==1.9.0 torchvision==0.10.0 --force-reinstall

别单独装torch不装torchvision，版本不匹配的话import时可能报隐晦的错误。

编译工具链的临时部署

有些项目需要从源码编译C扩展。Colab默认没装g++，得现装build-essential：

!apt-get update && apt-get install -y build-essential

这里有个细节：apt-get update和install写在同一个!命令里，确保用最新的源索引。分开写的话，如果之前有人跑过update，缓存可能已经过期了。

编译安装Python包时，如果遇到依赖的头文件缺失，比如Python.h，得装python3-dev：

!apt-get install -y python3-dev

记住Colab用的是python3，别装成python2的开发包，那是另一个坑。

持久化存储的“土办法”

Colab虽然重启会清空环境，但挂载的Google Drive能保留文件。利用这点，可以把编译好的二进制文件存到网盘，下次运行时直接加载，避免重复编译。

比如安装一个需要编译的复杂包：

import os
if not os.path.exists('/content/drive/MyDrive/cache/my_package'):
    !cd /content && git clone https://github.com/xxx/my_package
    !cd /content/my_package && python setup.py build
    !cp -r /content/my_package /content/drive/MyDrive/cache/
else:
    !cp -r /content/drive/MyDrive/cache/my_package /content/

虽然每次复制有点慢，但比重新编译节省时间，尤其对那些依赖复杂C++库的项目。

环境配置的模块化封装

我习惯把环境配置写成一个函数，放在笔记本最前面：

def setup_environment():
    import sys
    import subprocess
    
    # 检查并安装系统包
    required_apt_packages = ['libgl1-mesa-glx', 'libsndfile1']
    for pkg in required_apt_packages:
        result = subprocess.run(['dpkg', '-l', pkg], capture_output=True)
        if result.returncode != 0:
            !apt-get install -y {pkg}
    
    # Python包列表
    required_pip_packages = [
        'albumentations==0.5.2',
        'wandb==0.12.0'
    ]
    for pkg in required_pip_packages:
        !pip install -q {pkg}

这样结构清晰，还能加版本检查逻辑。-q参数让pip安静些，少刷屏。

个人经验建议

在Colab里搞环境，记住三个原则：幂等性、静默安装、缓存优先。幂等性就是你的配置代码跑一遍和跑十遍效果一样，不会因为重复执行就报错；静默安装避免交互阻断；能用缓存就别重新下载编译。

另外，别在Colab里追求完美的生产环境——它本质是个临时工作台。特别复杂的依赖（比如要改内核参数的）建议放弃，换个预装镜像更全的平台。对于中小型项目，把依赖明确写在笔记本开头，配合Drive缓存二进制文件，已经能覆盖90%的场景了。

最后留个心眼：长时间训练前，先跑完所有环境配置单元格，确认没有缺失依赖再启动训练。半夜跑到一半报缺库，那才叫绝望。## 008、高级应用实战：在Colab中运行PyTorch/TensorFlow项目

昨天帮同事调试一个在Colab上跑崩的PyTorch模型，问题很有意思：本地训练正常的ViT模型，在Colab上跑了半小时突然显存爆炸。查看日志发现，错误提示是CUDA out of memory，但batch_size已经设到8了，按理说T4的16GB显存不该这么吃紧。最终定位到问题——他在数据预处理里偷偷加了个实时数据增强，每轮迭代都在CPU上生成新图像，GPU等着CPU传数据，显存里的旧数据没释放，新数据又不断进来，活活把显存撑爆了。

这个案例让我觉得，是时候写写Colab里跑深度学习项目的实战细节了。很多人把Colab当个“能白嫖GPU的Jupyter”，但真要跑正经项目，有几个坎必须得迈过去。

环境配置的坑比想象中深

刚连上Colab别急着import torch，先看看给你的什么硬件。我习惯在开头加这么几行：

# 查看硬件配置，T4/P100/V100策略不同
import tensorflow as tf
print("GPU型号:", tf.test.gpu_device_name())
!nvidia-smi -L  # 这个更直接

# 关键！检查CUDA版本和PyTorch是否匹配
!nvcc --version
import torch
print("PyTorch CUDA可用:", torch.cuda.is_available())
print("CUDA版本:", torch.version.cuda)

遇到过好几次Colab自动安装的PyTorch版本和CUDA驱动对不上，torch.cuda.is_available()返回False。这时候得手动重装：

# 如果CUDA不可用，就执行这个（2024年5月实测有效）
!pip uninstall torch torchvision -y
!pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118

别迷信!pip install直接装最新版，Colab的CUDA驱动更新没那么快。我有个项目用PyTorch 2.1就报CUDA error 209，退回1.12反而稳如老狗。

数据加载得有点讲究

Colab的磁盘IO性能其实一般，特别是读取大尺寸图像数据集时。不建议用ImageFolder直接读压缩包，解压过程巨慢。我的做法是：

# 先把数据传到Google Drive，然后这样挂载
from google.colab import drive
drive.mount('/content/drive')

# 但别直接从Drive读数据！复制到运行时内存
!cp -r /content/drive/MyDrive/dataset.zip /content/
!unzip -q /content/dataset.zip -d /content/data  # -q参数避免输出刷屏

# 用DataLoader时num_workers别设为0
from torch.utils.data import DataLoader
loader = DataLoader(dataset, batch_size=32, 
                   num_workers=2, pin_memory=True)  # pin_memory加速CPU到GPU传输

注意那个num_workers，在Colab里设成2就够了，设高了反而容易触发内存限制。pin_memory=True是必须的，能提升20%左右的加载速度。

模型训练时的显存监控

Colab最烦人的是显存泄露不报错，跑着跑着就崩了。我习惯每训练100个batch就检查一下：

def print_gpu_memory():
    """打印显存使用情况，这个函数救过我无数次"""
    total = torch.cuda.get_device_properties(0).total_memory / 1e9
    used = torch.cuda.memory_allocated(0) / 1e9
    cached = torch.cuda.memory_reserved(0) / 1e9
    print(f"已用显存: {used:.2f}GB / 总显存: {total:.2f}GB")
    print(f"缓存显存: {cached:.2f}GB")
    
# 在训练循环里调用
for epoch in range(epochs):
    for i, batch in enumerate(loader):
        # ...训练代码...
        if i % 100 == 0:
            print_gpu_memory()

如果发现显存只增不减，大概率是计算图没释放。检查loss.backward()后面有没有optimizer.zero_grad()，验证时用with torch.no_grad()包起来。

TensorFlow用户的特殊待遇

用TF的朋友注意，Colab默认装的是TF 2.x，但有些老项目需要TF 1.x的API。别急着改代码，试试兼容模式：

import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()  # 切回1.x风格

# 但这样用不了新GPU，得加配置
config = tf.ConfigProto()
config.gpu_options.allow_growth = True  # 允许显存增长，避免一开始占满
sess = tf.Session(config=config)

TF 2.x里有个坑：默认会占满所有显存，哪怕你模型很小。所以开头一定要设allow_growth，或者用set_memory_growth。

项目保存与恢复策略

Colab运行时最长12小时，而且可能随时被回收。我吃过亏——训练了8小时的模型没保存，浏览器崩溃全没了。现在我的策略是：

1. 每epoch保存一次到Drive
2. 保存optimizer和scheduler状态
3. 记录最好的5个checkpoint，自动删除旧的

# 保存时带上时间戳
import time
from google.colab import files

def save_checkpoint(model, optimizer, epoch, accuracy):
    path = f"/content/drive/MyDrive/checkpoints/model_{epoch}_{accuracy:.3f}.pt"
    torch.save({
        'epoch': epoch,
        'model_state_dict': model.state_dict(),
        'optimizer_state_dict': optimizer.state_dict(),
    }, path)
    print(f"Checkpoint saved: {path}")
    
# 别用files.download()下大文件，超过2GB会失败
# 直接挂载Drive复制更靠谱

个人经验几条

Colab的T4其实比很多人想象的要强，但得会“哄着用”。batch_size别设太大，16-32通常最稳；混合精度训练(torch.cuda.amp)能省30%显存，速度还能提升；如果遇到CUDA illegal memory access，大概率是数据维度不对齐，检查dataset的__getitem__返回值形状。

最后说个玄学问题：Colab分配到的GPU型号和你的账号活跃度有关。新注册账号经常只给P100，老账号反而容易拿到V100。有个偏方——在代码开头加个!nvidia-smi并多运行几次，系统可能会认为你在监控资源使用，分配好硬件的概率高些（这招不一定每次都灵，但值得一试）。

真正要在Colab跑完整项目，得按它的脾气来：小步快跑、频繁保存、随时准备从头再来。把它当成一个不稳定的实验环境，而不是生产服务器，心态会好很多。## 009、性能监控与调试：资源使用情况查看与常见问题排查

上周有个同事跑过来问我：“我在Colab上训模型，跑着跑着就断了，日志也没留全，这怎么搞？” 我让他打开资源监控看一眼，结果发现内存早就爆了，GPU显存也一直在临界值徘徊。这种问题太典型了——很多人在免费GPU上跑代码，光盯着loss曲线看，压根没注意资源这回事。今天咱们就聊聊怎么在Colab里做性能监控和问题排查。

资源监控三板斧

Colab界面上方菜单栏有个“运行时”下拉菜单，点开“更改运行时类型”能看见当前分配的GPU型号（比如T4、P100），但更实用的信息藏在别处。执行这段代码看硬件详情：

# 看硬件全家福
!nvidia-smi
# 这个命令输出信息量大，重点看两个地方：
# 1. GPU-Util 那列，百分比太低说明你的代码可能没充分利用GPU
# 2. Memory-Usage，如果接近上限（比如T4的15GB），离崩溃就不远了

# 再看内存情况
import psutil
print(f"内存占用：{psutil.virtual_memory().percent}%")
# 超过85%就要警惕了，Colab后台进程可能会被系统清理

监控要动态地看。我习惯在训练循环里加个定时打印：

import pynvml
import time

pynvml.nvmlInit()
handle = pynvml.nvmlDeviceGetHandleByIndex(0)

for epoch in range(epochs):
    # ...训练代码...
    
    if epoch % 10 == 0:
        mem_info = pynvml.nvmlDeviceGetMemoryInfo(handle)
        print(f"[DEBUG] 显存使用：{mem_info.used//1024**2}MB / {mem_info.total//1024**2}MB")
        # 这里踩过坑：记得除两次1024才是MB，直接除1000会算错

常见问题排查清单

问题一：训练突然中断，提示“运行时已断开连接”。
先别急着怪Colab不稳定，大概率是你的内存炸了。Colab有个隐藏机制——如果内存使用超过一定阈值，后台会直接重启内核。这时候去看日志没用，得在出问题前设预警。我通常会在代码开头加个内存监控线程：

import threading
import psutil
import sys

def memory_watcher(threshold=0.9):
    while True:
        if psutil.virtual_memory().percent > threshold * 100:
            print(f"[警报] 内存使用超过{threshold*100}%，当前{psutil.virtual_memory().percent}%")
            # 可以在这里保存检查点
            # torch.save(checkpoint, 'emergency_save.pt')
        time.sleep(30)

# 开个后台线程盯着
thread = threading.Thread(target=memory_watcher, daemon=True)
thread.start()

问题二：GPU利用率忽高忽低，像心电图。
这通常是数据加载瓶颈。检查你的DataLoader是不是设了num_workers=0（Colab默认值）。改成2或4试试：

# 别这样写
loader = DataLoader(dataset, batch_size=32, num_workers=0)

# 改成这样
loader = DataLoader(dataset, batch_size=32, num_workers=2, 
                    pin_memory=True)  # 这个参数加速GPU传输

但注意：Colab里num_workers别设太大，2-4足够，开多了反而会因为进程竞争拖慢速度。

问题三：显存慢慢增加，最后OOM（Out Of Memory）。
典型的显存泄漏。先检查是不是每轮循环里累积了计算图：

# 错误示范
loss.backward()
optimizer.step()
# 忘了写 optimizer.zero_grad() 的话，梯度会一直累积

# 更隐蔽的情况：在列表里存了中间变量
cache = []
for data in loader:
    output = model(data)
    cache.append(output)  # 这些output还带着梯度历史！
    # 应该用 cache.append(output.detach().cpu())

用这个命令看更详细的显存分配：

# PyTorch的显存分析
import torch
print(torch.cuda.memory_summary(abbreviated=False))
# 重点看“Allocated memory”的增长趋势

几个经验之谈

第一，Colab的GPU是虚拟化的，和你本地机器的表现可能有差异。同一个模型，在本地跑得好好的，上Colab可能就OOM。遇到这种情况，先把batch_size砍半试试。

第二，免费版本有资源限制，但不会明确告诉你上限是多少。我的观察是：连续运行超过8-9小时，系统可能主动断开；GPU内存超过13GB（对于T4），风险大增。重要实验一定要设检查点，我见过有人训了一夜没保存，早上起来内核重启了。

第三，调试时多用“增量验证”。先跑一个小batch，监控资源；再跑10个batch；最后跑完整epoch。别一上来就扔进去训练100轮，等发现问题时，已经浪费了几小时额度。

最后分享个小技巧：Colab的终端其实比想象中强大。点开左侧面板的“文件”图标，右上角有个三点菜单，选“打开终端”，就能用命令行工具如htop、nvidia-smi -l 1（每秒刷新）。这个终端和笔记本内核是隔离的，即使你的代码把内核搞崩了，终端还能活着，可以看最后的错误信息。

免费资源的代价就是不确定性。把监控代码写成习惯性模板，每次开新notebook先贴进去，能省下大量调试时间。记住：在Colab上跑代码，你得比系统更清楚资源是怎么没的。# 010、总结与展望：Colab使用最佳实践与更多免费资源指引

昨天深夜调试一个YOLOv5模型时，Colab突然断连了。训练日志停在epoch 23/50，GPU内存曲线在断线前十分钟就开始剧烈波动——我知道，又遇到那个经典的“闲置回收”陷阱了。这不是第一次，也不会是最后一次。但这次我决定把这些年用Colab踩过的坑、攒下的经验系统整理出来，毕竟免费GPU这顿饭，得学会优雅地吃。

Colab的脾气你得懂

很多人把Colab当成本地GPU用，这是第一个认知偏差。它本质是Google为推广AI教育提供的有限资源池，所有使用行为都在后台评分系统监控下。我见过有人开多个账号挂长期训练，结果三天内全部降级到T4。这里有个不成文的规则：连续GPU使用时间超过8小时，闲置检测阈值会明显收紧。

内存管理是另一个重灾区。默认环境里一堆用不上的库占着内存，我习惯在第一个cell里写：

# 先清理门户，别让这些吃内存的家伙赖着
import os, sys, gc, torch
def clean_memory():
    if 'torch' in sys.modules:
        torch.cuda.empty_cache()  # PyTorch的缓存清一下
    gc.collect()  # Python垃圾回收，聊胜于无

别小看这几行，有时候能多撑出1GB显存空间。

持久化策略：与断线共舞

Colab断线是必然事件，关键是如何让训练可恢复。我现在的标准操作流程：

1. 初始化时必挂Google Drive

from google.colab import drive
drive.mount('/content/drive', force_remount=True)  
# force_remount参数很重要，避免权限缓存问题

2. 检查点保存路径放在Drive里

checkpoint_dir = '/content/drive/MyDrive/colab_checkpoints'
# 别用/content/下的路径，断线就全没了
# 目录名带时间戳，避免覆盖
import datetime
timestamp = datetime.datetime.now().strftime('%m%d_%H%M')
os.makedirs(f'{checkpoint_dir}/{timestamp}', exist_ok=True)

3. 训练循环里加断点续传逻辑

# 加载最新检查点的函数
def load_latest_checkpoint(model, optimizer):
    checkpoints = sorted(glob.glob(f'{checkpoint_dir}/*/*.pth'))
    if checkpoints:
        latest = checkpoints[-1]
        state = torch.load(latest)
        model.load_state_dict(state['model'])
        optimizer.load_state_dict(state['optimizer'])
        start_epoch = state['epoch'] + 1
        print(f'从检查点 {latest} 恢复，从epoch {start_epoch}开始')
        return start_epoch
    return 0

这套组合拳让我上周成功恢复了跑了47小时的StyleGAN训练，省下的电费够喝一周咖啡了。

算力压榨技巧：别让GPU闲着

免费用户分到的可能是T4、P100甚至V100，但很多人只用到30%算力。问题常出在数据管道上：

# 糟糕的数据加载方式
for images, labels in dataset:
    model(images)  # GPU等数据，大量空闲时间

# 改进方案
dataloader = DataLoader(dataset, 
                       batch_size=32,
                       num_workers=2,  # Colab最多给2个worker
                       pin_memory=True,  # 这个很重要！
                       prefetch_factor=2)  # 提前准备数据

监控工具不能少，我习惯在notebook里开个系统监控：

!nvidia-smi -l 5  # 每5秒刷新一次GPU状态

看到GPU-Util长期低于70%，就该检查数据加载或模型并行度了。

资源分配的潜规则

经过多次测试，我发现了些规律：新注册账号通常有更好的GPU配额；连续使用后突然断开，等15-30分钟再连可能分配到更新鲜的机器；周末的可用资源比工作日多——估计是学生用户少了。

环境清理也有讲究：

# 断开前主动清理
import IPython
IPython.Application.instance().kernel.do_shutdown(True)
# 这比直接关页面好，后台会标记为“正常退出”

当Colab不够用时：其他免费资源地图

Colab只是起点，其他选择各有特点：

Kaggle Kernels：每周30小时P100，数据集集成做得极好，适合数据探索阶段。但环境定制性弱，适合跑notebook而不是长期训练。

GitHub Codespaces：教育版每月免费额度，本质是云端VS Code，适合开发调试而非纯计算。

国内平台：有些AI竞赛平台会提供短期免费算力，比如FlyAI、AI Studio，通常需要参加活动或完成任务。

我的策略是多平台轮转：Kaggle做数据预处理，Colab跑中等规模训练，本地机器做最终微调。这样没有单点依赖，也不会触发任何平台的滥用检测。

写给工程师的真心话

免费资源就像公共图书馆——大家都能用，但得遵守规则。我见过有人写脚本自动点击“连接GPU”按钮，结果账号直接被封。也见过有人老老实实用了一年，跑了十几个毕业设计项目。

几个核心建议：用量上留有余地，别把Colab当生产环境；行为上透明合规，别用自动化脚本规避限制；技术上做好容灾，假设随时会断线；心态上保持感恩，这些资源本质是科技公司的教育投入。

最后分享我的工作流：早上开工先启动Colab，把检查点保存间隔设为30分钟，中午吃饭时保存一次模型状态到Drive，下午继续。如果遇到断线，就切换到Kaggle跑数据分析，两边都不耽误。

免费GPU的黄金时代或许正在过去，但学会高效利用有限资源，本身就是工程师的必修课。毕竟，未来我们面对的约束只会更多——算力约束、能耗约束、成本约束。在Colab上学到的这些生存技巧，某种程度上，是在为那个受约束的未来做准备。