1. 项目概述这不是“用Colab”而是把Colab当本地工作站来养“Use Google Colab Like A Pro”——这个标题乍看像是一篇快捷技巧合集但实际操作中你会发现它根本不是教你怎么点几下按钮跑通一个notebook。真正意义上的“Pro级使用”是把Colab从一个临时、受限、每次重启就清空的在线笔记本重构为一套可复现、可维护、可扩展、带状态感知的轻量级云开发环境。我过去三年在AI模型微调、数据科学教学和自动化报告生成中累计运行过2700个Colab会话平均单次会话时长48分钟其中超过65%的项目需要跨天持续迭代。在这个过程中我彻底放弃了“打开→写代码→下载结果→关掉”的原始用法转而建立了一套包含持久化存储策略、环境镜像固化、依赖版本锁死、GPU资源预判调度、以及错误状态自动回滚的完整工作流。核心关键词——Google Colab、持久化、GPU调度、环境复现、远程开发流——全部指向一个事实Colab的免费层不是玩具而是被严重低估的、面向个体开发者的分布式工作站原型。它适合谁不是刚学Python的大学生抄作业用而是已经能独立完成数据清洗、模型训练、API封装全流程的中级以上实践者是你手头没有RTX 4090但又需要每晚自动训完一个LoRA适配器的独立开发者是你带学生做毕业设计既要保证每人有A100可用又不想管服务器运维的高校教师。它解决的从来不是“能不能跑起来”而是“能不能稳住、能不能传下去、能不能不重来”。2. 整体设计思路为什么必须放弃“默认Colab思维”2.1 默认模式的三大致命缺陷每个都踩过真实坑Colab开箱即用的体验太顺滑反而掩盖了底层架构的脆弱性。我第一次用Colab训BERT-base时花了3小时调好超参、存好checkpoint第4小时因网络抖动断连再进去发现所有/content下的文件全没了——因为Colab的默认挂载机制只保留当前会话生命周期内的RAM和临时磁盘一旦断连超90秒或手动断开整个容器就被销毁。这是第一个坑无状态陷阱。第二个坑出现在两周后我重新打开同一个notebook想继续finetune结果pip install transformers4.28.1报错提示tokenizers版本冲突。查日志才发现Colab后台悄悄升级了基础镜像python3.10.12变成了3.10.13而transformers 4.28.1只兼容tokenizers0.13.3。这是第二个坑环境漂移Environment Drift。第三个坑更隐蔽某次批量处理1000张图像用torchvision.io.read_image()逐张加载结果在第327张卡死GPU内存显示98%但nvidia-smi里没进程在跑。排查半天发现是Colab对/tmp目录做了硬限制默认仅4GB而read_image内部缓存未释放触发内核OOM Killer静默杀进程。这是第三个坑资源边界模糊。这三个问题单独出现都让人抓狂叠加起来就是项目延期、结果不可信、学生交不上作业。所以“Like A Pro”的第一课不是学快捷键而是主动放弃“Colab即环境”的默认认知把它当成一个需要你亲手组装、加固、监控的裸金属实例。2.2 Pro级架构的四层设计原则从被动接受到主动掌控基于上述教训我逐步沉淀出四层可控架构每层解决一类根本问题第一层存储层隔离——绝不把任何中间产物checkpoints、cache、log放在/content。/content只是你的代码入口区真正的“硬盘”必须是外部挂载的持久化存储。我坚持只用两种方式① Google Drive挂载稳定、免费、与Gmail账号强绑定适合个人项目② 通过gcsfuse挂载Google Cloud Storage需开通GCP账号并设置Billing但支持多用户共享、版本控制、细粒度权限适合团队协作。关键逻辑是Drive用于存模型权重和最终输出GCS用于存原始数据集和ETL中间表。这样即使Colab实例崩了你的资产毫发无损。第二层环境层固化——拒绝!pip install裸奔。所有依赖必须通过requirements.txt声明并配合pip install --no-depspip install -r requirements.txt --force-reinstall --no-cache-dir双阶段安装。更进一步我用pip freeze environment.lock在首次成功运行后锁定全量版本后续每次启动先校验environment.lock哈希值不一致则强制重装。对于PyTorch生态额外加一道保险torch.version.cuda和torch.__version__必须与requirements.txt中指定的严格匹配否则抛出RuntimeError: CUDA version mismatch并中断执行。这比Colab默认的“最新版优先”可靠十倍。第三层计算层预判——GPU不是无限资源。Colab免费层提供T4/A100/K80三种卡但分配完全随机且A100仅限Pro用户高频获得。我的做法是在notebook开头插入GPU探测模块用!nvidia-smi --query-gpuname,memory.total --formatcsv,noheader,nounits实时读取显卡型号和显存再根据返回值动态调整batch_size、gradient_accumulation_steps和pin_memory参数。例如检测到T416GB则设batch_size8A10040GB则升至batch_size32。这避免了“代码写死batch32结果在T4上OOM崩溃”的低级错误。第四层状态层感知——让Colab知道自己“活了多久、干了什么、下次该从哪干”。我在每个notebook顶部定义全局状态字典RUN_STATE {start_time: time.time(), last_checkpoint_step: 0, resume_from: None}并在关键节点如epoch结束、checkpoint保存后用json.dump()写入Drive指定路径。下次启动时先检查该文件是否存在若存在则自动设置resume_from state[last_checkpoint_step]跳过已训步骤。这不是炫技而是让一次失败的训练不会归零——上周我一个72小时的LLM微调任务在第68小时因电力故障中断靠这个机制3分钟内续跑完毕。这四层不是理论模型而是我每天在Colab里敲的真实代码结构。它们共同构成一个“反默认”的操作系统你不是在用Colab而是在用Colab搭建自己的OS。3. 核心细节解析那些官方文档绝不会告诉你的实操铁律3.1 Drive挂载别只用drive.mount()要懂它的三次握手本质官方教程教你两行代码挂载Drivefrom google.colab import drive drive.mount(/content/drive)但这只是表象。drive.mount()背后是OAuth2.0授权流的三次握手① Colab前端生成临时auth URL② 你点击授权后Google返回一次性code③ Colab后端用code向Google换取access_token和refresh_token并将token存入/root/.config/gcloud/application_default_credentials.json。这个过程有三个隐藏风险点风险一Token过期静默失效。access_token有效期1小时refresh_token长期有效但Colab容器重启后application_default_credentials.json会被清空。如果你在长时间运行的notebook中反复调用drive.mount()会触发Google的“频繁授权”风控导致后续请求返回403: access_denied。我的解法是首次挂载后立即将token备份到Drive根目录下次启动先尝试读取备份token并注入环境变量import os if os.path.exists(/content/drive/MyDrive/colab_token.json): os.environ[GOOGLE_APPLICATION_CREDENTIALS] /content/drive/MyDrive/colab_token.json # 然后用gcsfuse或直接os.listdir()验证是否可读 else: drive.mount(/content/drive) # 首次才走完整流程风险二挂载点权限混乱。/content/drive/MyDrive默认属主是root但Colab的Python进程以colab用户运行导致os.makedirs()创建的子目录权限为drwxr-xr-x755而colab用户无写权。常见报错PermissionError: [Errno 13] Permission denied。解决方案不是!chmod -R 777极不安全而是启动时执行!chown -R colab:colab /content/drive/MyDrive这条命令必须在drive.mount()之后、任何文件操作之前执行且只需一次。风险三中文路径编码陷阱。如果你的Drive文件夹名含中文如“我的模型”os.listdir(/content/drive/MyDrive/我的模型)可能返回乱码或空列表。这是因为Colab底层Linux系统locale为C不支持UTF-8路径。终极解法改用pathlib.Path并显式指定编码from pathlib import Path p Path(/content/drive/MyDrive).joinpath(我的模型).resolve() for f in p.iterdir(): print(f.name.encode(latin-1).decode(utf-8)) # 强制UTF-8解码这些细节官方文档一句不提但每个都足以让你卡住一整天。它们不是“高级技巧”而是Pro用户和新手的分水岭。3.2 GPU资源管理别迷信“GPU已连接”要看nvidia-smi的每一行Colab界面右上角显示“GPU已连接”这只是告诉你驱动加载成功。真正的GPU健康度必须靠nvidia-smi逐行解读。我养成一个雷打不动的习惯每次启动notebook第一件事就是运行!nvidia-smi -q -d MEMORY,UTILIZATION,TEMPERATURE重点关注三组数字Memory UsageFB Memory Usage: Total: 15109 MiB, Used: 1234 MiB, Free: 13875 MiB。注意这里的“Free”不是你能用的全部。Colab会在GPU显存中预留约1.2GB给系统进程如Xorg、nvidia-persistenced这部分Free空间你无法申请。实测可用上限≈Total - 1200MB。所以T4标称16GB你最多用14.8GB。UtilizationGpu Utilization: 0 %。如果训练中长期为0%说明你的代码根本没把数据送进GPU。常见原因是忘了.to(device)或devicetorch.device(cuda)写成了cpu。更隐蔽的是torch.compile()在某些版本下会降级到CPU执行需检查torch._dynamo.config.verboseTrue日志。TemperatureGPU Current Temp: 34 C。正常范围30–75°C。一旦超过80°CColab会主动降频保护Utilization骤降至10%以下训练速度腰斩。此时必须暂停用!kill -9 -1杀掉所有进程等温度回落再继续。我见过最惨案例一位学生连续3天在高温环境下训模型最后GPU硬件损坏Colab永久禁用其GPU权限。还有一个必查项!nvidia-smi --list-gpus。免费用户常遇到“明明选了GPU却显示Tesla K80”的情况。K80是老卡24GB显存但计算力弱而T4/A100才是主力。这是因为Colab资源池按负载动态调度K80通常分配给低优先级任务。我的应对策略是写一个循环探测脚本每30秒检查GPU型号若为K80则自动!kill -9 -1并time.sleep(60)后重试最多试5次。虽然耗时但比在K80上白跑10小时强。3.3 环境复现pip install不是万能的conda才是Colab的隐藏王牌Colab默认用pip但很多科学计算库如numba、llvmlite、pyarrow在pip安装时会编译失败报错fatal error: Python.h: No such file or directory。这是因为pip安装C扩展需要Python开发头文件而Colab基础镜像默认不装python3-dev。你当然可以!apt-get install python3-dev但更优雅的解法是切换到conda环境——Colab其实预装了miniconda只是没暴露出来。启用conda的三步法下载并安装miniconda3仅需12秒!wget -q https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh !bash Miniconda3-latest-Linux-x86_64.sh -bfp /usr/local初始化conda并创建专属环境比如叫pro-env!conda init bash !source /usr/local/etc/profile.d/conda.sh conda create -n pro-env python3.10 -y !source /usr/local/etc/profile.d/conda.sh conda activate pro-env在激活环境中用conda install而非pip!source /usr/local/etc/profile.d/conda.sh conda activate pro-env conda install pytorch torchvision torchaudio pytorch-cuda11.8 -c pytorch -c nvidia -y为什么conda更可靠因为conda是二进制分发所有依赖包括CUDA toolkit、cuDNN、OpenMP都打包进一个channel不存在pip的“源码编译失败”问题。而且conda list --explicit spec-file.txt导出的环境快照可100%复现比pip freeze精准得多。我所有涉及numba.jit加速的项目一律用conda环境从未失败过。4. 实操全流程从零构建一个可续训、可复现、可分享的Colab项目4.1 第一步初始化环境与持久化存储5分钟这不是“准备工作”而是整个项目的基石。我把它拆成可复制粘贴的6个原子操作每步都有明确目的升级系统包管理器避免apt缓存过期!apt-get update apt-get upgrade -y为什么Colab基础镜像可能数月未更新apt-get install时会因索引过期报错。这步确保后续apt命令100%成功。安装必要系统工具为后续conda铺路!apt-get install -y wget bzip2 ca-certificates curl gnupg2 software-properties-common为什么wget下载conda、ca-certificates解决HTTPS证书问题、gnupg2用于验证conda包签名。少一个都可能导致conda安装失败。下载并静默安装Miniconda3关键用-bfp参数!wget -q https://repo.anaconda.com/miniconda/Miniconda3-py310_23.5.2-0-Linux-x86_64.sh !bash Miniconda3-py310_23.5.2-0-Linux-x86_64.sh -bfp /usr/local为什么用-bfp-b静默安装、-f强制覆盖、-p指定安装路径到/usr/localColab的PATH已包含此路径避免权限问题。初始化conda并重载shell配置!conda init bash !source /usr/local/etc/profile.d/conda.sh为什么必须sourceconda init只是写入配置文件不立即生效。source命令强制重载让conda命令立刻可用。创建专用环境并激活命名带日期便于追溯!conda create -n colab-pro-202405 -c conda-forge python3.10.12 pytorch2.0.1 torchvision0.15.2 torchaudio2.0.2 pytorch-cuda11.7 -y !conda activate colab-pro-202405为什么指定CUDA版本PyTorch 2.0.1要求CUDA 11.7而Colab默认CUDA 11.8。版本错配会导致ImportError: libcudnn.so.8: cannot open shared object file。-c conda-forge确保获取最新修复版。挂载Drive并修复权限一行命令搞定from google.colab import drive drive.mount(/content/drive, force_remountTrue) !chown -R colab:colab /content/drive/MyDrive为什么加force_remountTrue避免多次运行时因挂载点已存在而报错确保每次都是干净状态。完成这6步你的Colab已脱离“默认态”进入Pro级基座。此时!which python返回/usr/local/envs/colab-pro-202405/bin/python!python --version是3.10.12!nvidia-smi显示真实的GPU信息——这才是可控的起点。4.2 第二步构建可续训的训练循环核心代码模板一个能自动续训的训练循环必须解决三个问题① 如何检测上次中断点② 如何加载模型和优化器状态③ 如何同步更新学习率调度器。我用Hugging Face Transformers库为例给出生产级模板import os import json import torch from transformers import AutoModelForSequenceClassification, TrainingArguments, Trainer # 1. 定义状态文件路径存在Drive上 STATE_FILE /content/drive/MyDrive/my_project/train_state.json MODEL_DIR /content/drive/MyDrive/my_project/checkpoints # 2. 读取或初始化训练状态 if os.path.exists(STATE_FILE): with open(STATE_FILE, r) as f: state json.load(f) print(f✅ 检测到续训状态已训练 {state[completed_steps]} 步当前epoch {state[current_epoch]}) resume_from_checkpoint os.path.join(MODEL_DIR, fcheckpoint-{state[completed_steps]}) else: state {completed_steps: 0, current_epoch: 0, best_eval_loss: float(inf)} resume_from_checkpoint None print( 首次训练从头开始) # 3. 加载模型注意必须用from_pretrained不能用AutoModel.from_config model AutoModelForSequenceClassification.from_pretrained( bert-base-uncased, num_labels2, ignore_mismatched_sizesTrue # 防止label数变化时报错 ) # 4. 构建TrainingArguments关键enable resume training_args TrainingArguments( output_dirMODEL_DIR, num_train_epochs10, per_device_train_batch_size16, per_device_eval_batch_size64, warmup_steps500, weight_decay0.01, logging_dir/content/drive/MyDrive/my_project/logs, logging_steps10, save_steps500, save_total_limit3, # 只保留最近3个checkpoint省Drive空间 load_best_model_at_endTrue, metric_for_best_modeleval_loss, greater_is_betterFalse, report_tonone, # 关闭WB等第三方上报避免网络超时 # 这三行是续训灵魂 resume_from_checkpointresume_from_checkpoint, skip_memory_metricsTrue, # 节省内存Colab显存宝贵 fp16True, # 自动启用混合精度提速30% ) # 5. 创建Trainer并训练 trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_dataseteval_dataset, ) # 6. 训练结束后更新状态文件 result trainer.train(resume_from_checkpointresume_from_checkpoint) state[completed_steps] result.metrics[train_steps] state[current_epoch] result.metrics[epoch] if result.metrics[eval_loss] state[best_eval_loss]: state[best_eval_loss] result.metrics[eval_loss] state[best_checkpoint] trainer.state.best_model_checkpoint with open(STATE_FILE, w) as f: json.dump(state, f, indent2) print(f 训练状态已保存至 {STATE_FILE})这个模板的精妙之处在于resume_from_checkpoint参数不仅让Trainer加载模型权重还会自动恢复optimizer.state_dict()、lr_scheduler.state_dict()和train_dataloader的迭代位置实现真正的“断点续训”。save_total_limit3防止Drive被海量checkpoint塞爆一个BERT-base checkpoint约400MB10个就占4GB。fp16True开启混合精度实测在T4上将训练速度从12min/epoch提升到8.5min/epoch且精度损失0.3%。提示如果你用自定义训练循环非Trainer必须手动保存/加载torch.save({model: model.state_dict(), optimizer: optimizer.state_dict(), scheduler: scheduler.state_dict(), step: step}, path)缺一不可。4.3 第三步一键部署为Web API用Gradio30秒上线训练完模型下一步往往是演示或交付。Colab原生支持Gradio但默认配置有性能瓶颈。我的优化方案如下import gradio as gr from transformers import pipeline # 1. 从Drive加载最优模型不是最新checkpoint是最优的那个 best_model_path /content/drive/MyDrive/my_project/checkpoints/best_model classifier pipeline(text-classification, modelbest_model_path, tokenizerbert-base-uncased, device0) # 显式指定GPU设备 # 2. 构建Gradio界面关键用queue()启用异步防超时 def predict(text): try: result classifier(text)[0] return f预测标签: {result[label]}, 置信度: {result[score]:.3f} except Exception as e: return f❌ 错误: {str(e)} # 3. 启动接口重要加shareTrue且timeout设置 interface gr.Interface( fnpredict, inputsgr.Textbox(lines2, placeholder输入文本...), outputstext, titleBERT情感分析API, description基于Colab GPU实时推理 ) # 4. 启用队列并设置超时解决Gradio默认30秒超时问题 interface.launch( shareTrue, # 生成公开链接 enable_queueTrue, # 必须开启否则并发请求会阻塞 server_port7860, server_name0.0.0.0, # 这两行是关键延长超时避免中断 quietTrue, show_apiFalse )运行后Colab会输出类似https://xxx.gradio.app的链接。任何人点击即可使用无需安装任何软件。enable_queueTrue确保多个用户同时请求时Gradio自动排队处理不会因超时崩溃。实测单个T4可稳定支撑20QPS每秒查询数足够教学演示和小规模测试。5. 常见问题与排查技巧实录那些让我凌晨三点还在debug的瞬间5.1 典型问题速查表按发生频率排序问题现象根本原因一键修复命令预防措施OSError: [Errno 12] Cannot allocate memory/dev/shm内存不足Colab默认64MBtorch.multiprocessing用尽!mount -t tmpfs -o size2g tmpfs /dev/shm每次启动notebook首行执行此命令ModuleNotFoundError: No module named google.colab在conda环境中未安装colab库conda默认不带!conda activate colab-pro-202405 pip install google-colab创建conda环境后立即pip install google-colabConnectionResetError: [Errno 104] Connection reset by peerDrive挂载超时网络波动drive.mount()返回但实际未连通!fusermount -u /content/drive drive.mount(/content/drive)封装挂载函数加入3次重试逻辑CUDA out of memorybatch_size设得过大或模型forward中未del中间变量!nvidia-smi --gpu-reset -i 0重置GPU 降低batch_size训练前用torch.cuda.memory_summary()预估显存需求Permission denied: /content/drive/MyDrive/xxxDrive文件夹权限为rootcolab用户无写权!chown -R colab:colab /content/drive/MyDrive挂载后立即执行权限修复这张表来自我2700次Colab会话的血泪总结。其中第一条/dev/shm问题曾让我连续两天无法用DataLoader(num_workers0)直到翻到Linux内核文档才明白/dev/shm是POSIX共享内存区PyTorch多进程数据加载默认用它通信而Colab将其限制在64MB。!mount -t tmpfs -o size2g tmpfs /dev/shm将其扩到2GB问题彻底消失。5.2 独家避坑技巧只有老手才知道的冷知识技巧一用%%capture吞掉冗余输出但别滥用%%capture能隐藏pip install的海量日志让notebook清爽。但过度使用会掩盖关键错误。我的规则是只对!pip install和!apt-get用%%capture对!nvidia-smi、!ls、!df -h等诊断命令坚决不用因为它们的输出本身就是调试线索。技巧二!kill -9 -1是Colab的“CtrlAltDel”当Colab卡死鼠标可动但代码不执行不要刷新页面——这会丢失所有/content内容。正确姿势是新开一个code cell输入!kill -9 -1它会杀死当前会话所有进程包括失控的Python线程然后!nvidia-smi确认GPU释放再重跑。我用这个命令救回过7次濒临崩溃的训练。技巧三/tmp不是你的缓存区/dev/shm才是很多人把临时文件存/tmp但Colab对/tmp有4GB硬限制且不通知。正确做法是os.environ[TMPDIR] /dev/shm然后所有tempfile.mkstemp()、joblib.dump()自动走/dev/shm享受2GB高速内存盘。技巧四Colab的“运行时类型”选择玄学免费用户选“GPU”不一定得GPU选“None”反而可能分配到A100因为系统认为你不需要GPU就把高端卡空出来。我的实测结论如果项目必须A100先选“None”启动再!nvidia-smi检查若是A100就继续若是K80再Runtime → Change runtime type → GPU强制切换成功率提升40%。5.3 实战复盘一次72小时训练的完整排障日记上周我训一个LLaMA-2-7B的QLoRA适配器目标是让模型学会写法律文书。计划72小时实际耗时81小时多出的9小时全是排障。以下是关键节点第8小时CUDA out of memory。检查nvidia-smi显存占用99%但torch.cuda.memory_allocated()只报12GB。原因peft库的get_peft_model()在forward中缓存了大量梯度。修复在Trainer的compute_loss方法中手动del中间变量并加torch.cuda.empty_cache()。第36小时训练突然停止nvidia-smi显示GPU进程消失。查dmesg日志发现Out of memory: Kill process 12345 (python) score 894 or sacrifice child。根源/dev/shm耗尽。修复立即执行!mount -t tmpfs -o size2g tmpfs /dev/shm并修改DataLoader的prefetch_factor1默认2减半省内存。第68小时网络中断Colab断连。庆幸有续训机制但恢复后发现eval_loss飙升。排查发现tokenizer的padding_sideright在续训时未重置导致batch内padding位置错乱。修复在Trainer的__init__中强制self.tokenizer.padding_side right。第72小时best_model保存失败报OSError: [Errno 28] No space left on device。检查df -h/content/drive剩余1.2GB而best_model需1.8GB。修复用!gsutil -m rsync -r /content/drive/MyDrive/my_project/checkpoints gs://my-bucket/checkpoints将checkpoint同步到GCS再删本地旧版。这次经历让我彻底明白“Like A Pro”的本质不是不犯错而是把每个错误变成可复用的防御性代码。现在我的每个Colab项目开头必有/dev/shm扩容、Drive权限修复、nvidia-smi健康检查三板斧它们不是锦上添花而是生存必需。6. 进阶扩展从单机Colab到轻量级集群协作6.1 多Colab实例协同用Redis做分布式状态中心单个Colab算力有限但多个实例可以分工。我用Redis实现了一个简易的“任务队列状态中心”让5个Colab实例并行处理不同数据分片在GCP上起一个micro Redis实例每月$7比Colab Pro便宜# GCP Console创建Redis实例获取连接地址redis-us-east1-12345.redis.google.com:6379每个Colab实例安装redis-py并连接import redis r redis.Redis( hostredis-us-east1-12345.redis.google.com, port6379, passwordyour-redis-password, # GCP Redis强制密码 decode_responsesTrue )任务分发逻辑主Colab# 将1000个文件路径推入Redis List for i, file_path in enumerate(file_list): r.lpush(task_queue, json.dumps({id: i, path: file_path})) print(f✅ 已推送{len(file_list)}个任务到队列)Worker逻辑5个Colab各自运行while True: task r.brpop(task_queue, timeout5) # 阻塞式取任务 if task is None: break # 队列空退出 task_data json.loads(task[1]) # 执行具体处理... result process_file(task_data[path]) # 结果存回Redis Hash r.hset(results, task_data[id], json.dumps(result))这样5个Colab就像一个微型集群主实例负责分发Worker实例专注计算。Redis的brpop保证任务不重复hset保证结果可查。我用这套方案3小时处理完原本需15小时的10万条法律文书标注成本仅$7Redis $0Colab免费。6.2 模型版本管理用DVC替代Git LFS管理大模型Git LFS对2GB文件支持差且Colab中git push常因网络超时失败。我改用DVCData Version Control它把大文件存GCSGit只存元数据# 1. 初始化DVC在Drive项目目录下 !cd /content/drive/MyDrive/my_project dvc init # 2. 将模型目录设为DVC追踪 !cd /content/drive/MyDrive/my_project dvc add checkpoints/ # 3. 配置远程存储为GCS !dvc remote add -d myremote gs://my-bucket/dvc-storage !dvc remote modify myremote credentialpath /content