AutoDL GPU云实例实战指南：从选卡到环境配置的完整流程

刚把一台带 RTX 4090 的 AutoDL 实例关机，顺手看了一眼这次“炼丹”的账单：两天多点，跑了几个微调实验，总共花了不到一百块。这个价格放在三年前我想都不敢想——那时候租一张 V100 起步价就得按小时算，还得抢时段。现在 AutoDL 这类平台把 GPU 租赁的门槛拉到了“随开随用、按量计费”，基本成了国内学生党和小型团队跑深度学习的默认选择。

但我发现一个现实问题：平台注册、下单确实没什么难度，可真正卡住大部分人的反而是下单之后那一截——怎么把自己本地的代码、数据弄上去，怎么把 PyTorch 环境装对，怎么在关机重启之后还能让环境“原地复活”。这篇指南不打算讲泛泛的“云GPU概念”，就是围绕 AutoDL 这个平台，把我自己从零开始走到能稳定跑训练任务的完整流程，连同踩过的坑和补救方案都摊开讲清楚。无论是第一次接触租卡炼丹的新手，还是想把手上的实验流程迁移到云上的老手，这篇都值得花十分钟过一遍。

1. 为什么是 AutoDL：算力租赁的账本到底怎么算

先说结论：在“临时需要一块卡跑几天实验”这个场景下，AutoDL 的灵活性和单位成本确实比自购显卡、传统云厂商按包月包年计费的方式更适合个人用户。这个判断不是凭空来的，我算过一笔账。

1.1 自购显卡与租卡之间的真实差价

自己买一块 RTX 4090，目前二手卡行情也稳定在 1.2 万到 1.4 万之间。新卡更贵，而且还要考虑整机配套：电源要 850W 起步、散热要跟上、机箱要够大。一套下来小两万。如果按三年使用寿命折算，平均每个月是五百多块。听起来不算贵，但问题在于，深度学习训练负载是典型的“脉冲式”——你不可能天天 24 小时把一张 4090 跑满。更多时候是调代码调几天，然后集中训练一两天，再进入分析结果、调参的“空窗期”。这种节奏下，自购显卡的闲置成本非常高。

AutoDL 上 4090 的价格大概每卡时两块多，具体看时段和活动。就算按三块算，一个月跑满 100 小时，也才三百块。更关键的是：不开机不计费。哪怕你机器上存着几十 GB 的环境和数据，只要关机，就不会产生任何费用。对“阶段性训练”的科研场景来说，这个机制天然匹配。

1.2 AutoDL 相比传统云主机的核心差异

传统云厂商（比如阿里云、腾讯云）也都提供 GPU 云主机，但它们的计费逻辑和产品定位跟 AutoDL 有明显区别：

这个差异的核心在于“面向场景做了减法”。AutoDL 不用你自己装显卡驱动，不用自己配 CUDA，开机就能用，环境配置全部容器化。说白了，它把深度学习环境这件事封装到了一个比较舒适的状态，让租卡这件事回归到“我只是想跑个实验”的本质。

1.3 什么人不适合用 AutoDL

讲完优点，也得泼盆冷水。你如果符合下面几种情况，AutoDL 不一定是最优选：

• 需要长期稳定跑生产级推理服务，对网络延迟和 SLA 有要求，建议还是用大厂的包年机加负载均衡。
• 需要多机多卡做大规模分布式训练，AutoDL 虽然支持，但在高速互联网络的稳定性上不如专用集群。
• 公司财务流程要求走正式合同、专票、对公转账，个人版 AutoDL 的流程不一定能满足。

AutoDL 的定位就是“实验型算力”，不是“生产型算力”。搞清这点，后面很多选择就不会纠结。

2. 第一台 GPU 实例的选择：卡型、镜像、存储到底怎么配

打开 AutoDL 控制台，第一眼看到的是一张长长的 GPU 列表，从 RTX 3060 到 A100 80G，价格从几毛到十几块每小时都有。新手很容易在这里纠结。我给一个从实际需求出发的选卡思路，而不是直接给某个型号。

2.1 选卡三要素：显存、算力单价、库存

显存是第一位的。深度学习任务的 batch size、模型参数量、序列长度最终都会转换成显存占用。选卡时，先估算自己实验的显存需求，再往上留 20%~30% 的余量。我常用的估算方式：

• 加载 7B 参数模型（FP16 精度）做推理，光模型权重就要占 14GB 显存，加上 KV cache 和中间激活值，16GB 显存是及格线。
• 训练一个 1.3B 参数的模型，用 AdamW 优化器，显存需求大概是模型参数量的 16~18 倍，也就是需要 20GB 以上显存，这时 24GB 的 3090/4090 就是基础选择。
• 做视觉类的目标检测微调，大部分经典模型（YOLO、Faster R-CNN）在 12GB 以内可以跑通，但 batch size 会很受限制。

核心选卡逻辑就一句话：显存卡预算，算力卡时间。显存不够直接跑不起来，算力不够只是跑得慢。

2.2 不同型号卡的使用场景对照

AutoDL 上常年有几类“主力卡”，它们的定位非常清晰：

第一次注册，建议直接用 RTX 3090 或 4090。不要一上来就追求 A100。先用 24GB 显存把流程跑通，等真遇到显存瓶颈再换大卡。换卡在 AutoDL 上就是一个“变更实例配置”的操作，数据保留，环境无损。

2.3 镜像选择：框架镜像优先，别从零开始配

创建实例时最关键的选项是“镜像”。AutoDL 提供了很多现成镜像，分为基础镜像和框架镜像。基础镜像就是一个干净的 Ubuntu + Python，框架镜像则预装了 CUDA、PyTorch、TensorFlow 等。

第一次用，老老实实选官方 PyTorch 框架镜像。以 PyTorch 为例，镜像里已经装好了对应版本的 torch、torchvision、torchaudio，以及 cudatoolkit。选的时候注意三点：

• 选择 PyTorch 版本时，优先选 2.x 系列。1.x 版本太老，很多新特性不支持，而且后续装第三方库容易冲突。
• 关注 Python 版本。PyTorch 2.x 官方推荐 Python 3.8~3.11，镜像里一般默认 3.8 或 3.10，别选太低或太高的，否则 pip 安装包时容易找不到预编译的 wheel。
• 看清楚 CUDA 版本。现在 PyTorch 官方默认编译用的都是 CUDA 11.8 或 12.1 以上，镜像里标注的版本基本都能直接用。

提示：如果你要跑的是 Hugging Face 生态的模型（比如 LLaMA、Qwen、ChatGLM 的微调），直接搜对应模型社区里推荐的 AutoDL 镜像，比自己配省力得多。社区镜像一般已经装好了 transformers、peft、accelerate 这些配套库。

2.4 存储配置：系统盘、数据盘该买多大

AutoDL 的存储分两块：系统盘和数据盘。系统盘存操作系统和 /root 下的环境，数据盘专门挂载大数据集。

• 系统盘：默认买 30GB 就能覆盖大部分环境安装需求。但如果你打算在 /root 下装 big 模型文件、conda 环境装得多，建议直接加到 50GB，免得后面扩容还要关机操作。
• 数据盘：按数据量估算即可。如果数据集小于 100GB，买 100GB 的数据盘基本够用。AutoDL 的数据盘扩容很方便，在控制台直接操作，不用迁移数据。数据盘价格便宜，多买一点也不会成为账单大头。

我个人的习惯是：系统盘 50GB + 数据盘 200GB。前者给 conda 和 pip 缓存留足空间，后者用来放数据集和模型输出。千万不要把大数据集放进 /root，系统盘满了之后整个环境会变得非常诡异——pip 装包报错、数据库打不开、甚至 SSH 登录都会卡顿。

3. 从下单到真正能跑模型：登录方式和开发工具链打通

实例创建完成只是第一步。更影响后续使用体验的是“你怎么连上这台机器”。AutoDL 提供了三种登录方式：网页版 JupyterLab、命令行 SSH、以及通过第三方工具（PyCharm/VSCode）连接。三种我都在用，但适用场景完全不同。

3.1 JupyterLab：开箱即用的图形环境

开机后，在控制台找到“JupyterLab”入口，点击打开就是完整的交互式开发环境。浏览器里直接写 Python 代码跑 cell，对于快速验证脚本、调试数据预处理非常方便。

JupyterLab 会预装一些常用库（numpy、pandas、matplotlib），也支持直接开终端跑命令行。这里的终端本质上是容器内的 shell，可以正常使用 conda、pip。

不过，JupyterLab 不适合做重度开发——浏览器里写大工程的体验毕竟受限，而且长时间挂着的浏览器标签页偶尔会断开连接。我的建议是：JupyterLab 用于“快速实验”，比如加载数据集看看分布、调试一段数据处理管道、跑一个 quick demo。

3.2 SSH 直连：把远端当本地机器用

命令行重度用户一定要配好 SSH。AutoDL 控制台会提供一个 SSH 登录指令，类似：

bash复制ssh -p 12345 root@region-3.autodl.com

密码在控制台可以一键复制，也支持设置密钥对。我强烈建议设置 SSH 密钥登录，省去每次输密码的麻烦。方法也简单：

bash复制# 在本地生成密钥对（如果还没有）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 查看公钥内容，复制到 AutoDL 控制台的 SSH 公钥设置里
cat ~/.ssh/id_ed25519.pub

设置好之后，在本地配置 ~/.ssh/config，能极大简化登录：

code复制Host autodl
    HostName region-3.autodl.com
    Port 12345
    User root
    IdentityFile ~/.ssh/id_ed25519

之后直接 ssh autodl 就能登录，无需再查 IP 和端口。

SSH 登录之后，日常操作就跟本地 Linux 服务器没有任何区别。想传文件用 scp，想跑训练用 nohup 或 tmux 挂后台，这些习惯在这里全部适用。

3.3 从本地 IDE 远程连接：PyCharm 和 VSCode 的两种姿势

如果你习惯了 PyCharm 或 VSCode 的调试功能，直接在本地 IDE 里连接远端解释器是效率最高的方式。

PyCharm 远程解释器配置

• 打开 Settings（Mac 上是 Preferences）→ Project → Python Interpreter。
• 点击齿轮按钮，选择 Add Interpreter → On SSH。
• 填入 AutoDL 控制台给的 SSH 地址和端口，用户 root。
• 身份验证方式选密码或密钥，建议密钥。
• 指定远程解释器路径。如果是 conda 环境，路径类似 /root/miniconda3/envs/pytorch/bin/python。如果不确定，可以先 SSH 上去跑 which python 查看。
• 同步文件夹：把本地项目目录同步到远端指定路径，比如 /root/workspace/。

配好之后，本地写的代码保存时会自动同步到远端，PyCharm 的 Run/Debug 直接在远端 GPU 环境上执行。这个组合非常适合需要断点调试的场景。

VSCode Remote-SSH

VSCode 的远程开发插件（Remote-SSH）是我现在的主力方案。安装好扩展后：

• Ctrl+Shift+P 输入 Remote-SSH: Connect to Host。
• 选择刚才配置的 autodl 主机，或者手动输入 ssh root@地址 -p 端口。
• 连接后，VSCode 会打开远端的工作区。左下角显示 “SSH: autodl” 就代表成功了。
• 在扩展面板里装 Python、Pylance 等插件，选好远程解释器，就能像本地开发一样写代码、跑终端、开 Jupyter Notebook。

值得注意：VSCode 第一次连接会装一个服务端，需要点时间。如果等了很久进度条不动，多半是网络问题，可以断开重试。

3.4 传输大文件：网盘中转还是 scp 直传

数据迁移是很多新手崩溃的重灾区。AutoDL 提供了免费的“文件存储”功能，可以把本地文件传到网盘，再从网盘转存到实例。这个方法对集群间迁移数据特别有用，因为它走的是内网，速度快且稳定。

但如果是几十 GB 的大数据集，我更推荐先传到自己的网盘（比如阿里云盘、百度网盘），再从 AutoDL 里用命令行工具下载。具体方法：先在本地网盘客户端上传，然后 SSH 到实例里用对应的命令行工具下载。比如阿里云盘可以用 aliyunpan 命令行工具。这个路径实际体验下来比用网页上传稳，而且支持断点续传。

如果数据在另一台服务器上，也可以直接用 scp 或 rsync 传输。比如从本地把 data.zip 传到远端：

bash复制scp ./data.zip root@region-3.autodl.com:/root/autodl-tmp/

反正记住：/root/autodl-tmp 是数据盘，普通文件放这里。/root 是系统盘，环境相关的东西放这里。这个划分从一开始就要养成习惯。

4. 环境配置的底层逻辑：CUDA、PyTorch 和容器镜像的真实工作方式

这个章节是全文的重头戏。环境配置不顺利，99% 是没搞懂“CUDA 驱动、CUDA toolkit、PyTorch 的 CUDA 版本”这三者的关系。很多教程只是让你复制粘贴一段 pip install，但没告诉你为什么要这么装。我在这里把这层窗户纸捅破。

4.1 三个 CUDA 概念的本质区别

深度学习框架（PyTorch/TensorFlow）之所以能在 GPU 上运行，靠的是 CUDA 这一整套并行计算平台。但“CUDA”这个词在实际使用中指代了三层东西：

• NVIDIA 驱动（Driver）：操作系统层面的驱动，负责让系统识别 GPU。它自带一个 CUDA Driver API，版本通常向下兼容。
• CUDA Toolkit：完整的开发工具包，包含编译器（nvcc）、运行时库、数学库（cuBLAS、cuDNN 等）。PyTorch 源码编译时必须要这个。
• PyTorch 内置的 CUDA 运行时：PyTorch 发布时是预先编译好的二进制包，里面已经静态链接了它编译时用的 CUDA 运行时库。你 pip 装的 torch 里面就自带一套 CUDA runtime。

这三者的关系可以类比成：驱动是高速公路的路基，toolkit 是修车工具，PyTorch 是已经在路上跑的车。车跑不跑得起来，主要看它需要的路况（CUDA 版本）和路基（驱动）是否兼容。

4.2 为什么镜像里只需要关心 PyTorch 版本

AutoDL 的框架镜像已经把这个复杂的依赖关系处理掉了——驱动装好了，CUDA toolkit 也装好了，你需要做的仅仅是安装和这个环境匹配的 PyTorch。

有个简便的验证方法：先跑 nvidia-smi 看 Driver 版本，再跑 python -c "import torch; print(torch.cuda.is_available())" 验证当前 PyTorch 是否真的能调用 GPU。如果输出 True，说明整个链路是通的。

实际上，AutoDL 镜像里的驱动通常比较新，能兼容绝大多数 PyTorch 版本。所以遇到“torch.cuda.is_available() 返回 False”时，大概率不是驱动的问题，而是你 pip 装了一个 CPU 版本的 torch。这是新手最常踩的坑：

bash复制# 错误的做法：默认装了 CPU 版
pip install torch

# 正确的做法：指定 CUDA 版本安装
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

注意：如果是在 AutoDL 框架镜像里，PyTorch 已经预装好了，根本不需要重装。如果你需要换版本，用上面的命令指定 CUDA 版本重新装即可。安装前最好先 pip uninstall torch torchvision torchaudio 清一下旧的。

4.3 Conda 环境的正确使用姿势

AI 领域的现状就是：不同项目依赖不同版本的 PyTorch、transformers、CUDA。放一个环境里只会互相打架。所以一定要用 conda 把不同实验环境隔离。

AutoDL 的镜像一般自带 miniconda。创建一个新环境：

bash复制# 创建 Python 3.10 的环境，命名为 llm
conda create -n llm python=3.10 -y

# 激活环境
conda activate llm

# 在新环境里安装 PyTorch（以 CUDA 12.1 为例）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

装完之后，记得在 IDE 里把解释器指向这个新环境。PyCharm 是在远程解释器配置里选 /root/miniconda3/envs/llm/bin/python，VSCode 是在命令面板里选 “Python: Select Interpreter”。

4.4 常用依赖安装速查

除了 PyTorch 本体，以下这些库基本是深度学习项目的标配：

bash复制# 数据处理与科学计算
pip install numpy pandas scikit-learn

# 深度学习工具链
pip install transformers datasets accelerate peft

# 训练可视化
pip install tensorboard wandb

# 图像相关（如果需要）
pip install opencv-python pillow

# Jupyter 内核
pip install ipykernel

如果有 requirements.txt，直接 pip install -r requirements.txt 一条命令搞定。安装过程中如果遇到网络超时，可以考虑换 pip 源：

bash复制pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

4.5 保存镜像：让环境可复用、可迁移

AutoDL 对“环境管理”做得让我最舒服的一点是：环境快照就是镜像。你在实例里把该装的库都装好了，跑通了实验，可以在控制台“保存镜像”把这个装有全部依赖的环境打成一个快照。之后不管是换 GPU 实例类型，还是几个人协作共用一个环境，都能一键恢复到这个状态。

保存镜像的注意事项：

• 镜像保存的是整个系统盘（根目录环境），不是数据盘。所以大数据集别放在系统盘，否则镜像会很大，保存时间也长。
• 保存镜像需要关机。所以准备好之后，先停实验再保存。
• 镜像会占用一定的存储空间，可能会产生少量费用。不常用的镜像可以删掉。

我自己的习惯是：每个项目跑通后，保存一个干净的“基础环境镜像”，再在这个基础上迭代。这样即使哪天实例被释放，也能从镜像快速恢复，不心疼。

5. 让数据在几十 GB 级别平稳流转：数据盘、文件传输与常见坑

环境搞定之后，接下来就是数据。这一步看着简单，实际遇到的问题最多。因为很多人没想清楚数据放哪、怎么传、关机后数据去哪，结果训练到一半发现数据不见了，心态直接崩。这一节把这些问题全部都堵住。

5.1 数据盘和系统盘的分工红线

AutoDL 实例有一个数据盘目录，通常是 /root/autodl-tmp。很多教程会说“数据放这里”，但重要的是理解为什么。

• 系统盘（/root）：数据持久性最强，关机、重启、迁移实例都保留。但空间有限，且保存成镜像时会包含数据，导致镜像过大。
• 数据盘（/root/autodl-tmp）：容量大，适合存放数据集和模型输出。在你对该实例的操作周期内，数据盘的内容是安全的。

注意“操作周期”这个词：如果实例被释放（不是关机），数据盘里的数据也会随之删除。AutoDL 对释放实例后的数据会保留一段时间（具体时长以控制台提示为准），超时会彻底清空。所以重要数据要定期备份到网盘或者自己的机器。

5.2 同地域实例之间的数据拷贝

AutoDL 支持把数据盘从一台实例拷贝到另一台实例。如果只是想迁移数据集，不需要先把数据传到本地再传上去。在控制台的“数据盘管理”里，可以对数据盘做“跨实例迁移”或“制作数据盘镜像”，然后挂载到新实例上。这个功能对大文件迁移特别友好，走内网速度快。

换个实例类型时，我更推荐：先保存系统镜像，然后在新实例里挂载旧数据盘（数据盘支持从原实例卸载后挂载到新实例）。这样环境、数据、代码三件套完整搬移，实验一分钟不用等多。

5.3 垃圾箱和清理工具

AutoDL 有一个“垃圾箱”机制，类似于回收站。删除的文件不会立刻物理消失，而是进入垃圾箱。这个机制防止误删，但也会悄悄占用存储空间——而且垃圾箱里的文件同样计费。

清理方式：

• 在控制台的“文件管理”或“垃圾箱”入口清理。
• SSH 连进实例查看磁盘占用：

bash复制# 查看各目录占用空间
du -sh /root/* 2>/dev/null | sort -hr | head -20

# 清理 pip 缓存
pip cache purge

# 清理 conda 缓存
conda clean --all

实测下来，跑了几个项目之后，pip 缓存和 conda 缓存加起来轻松超过 5GB。定期清理能让系统盘在 30GB 的档位坚持更长时间。

5.4 训练日志和模型权重的导出策略

训练到一半的 checkpoint 放哪，是个值得提前设计的问题。我见过不少人把 checkpoint 写在 /root/autodl-tmp，然后实例被释放，几个通宵的成果说没就没。

我的做法是：最终模型和重要中间结果同步到网盘或者其他对象存储（比如阿里云 OSS、腾讯云 COS），同时在本地留一份备份。AutoDL 实例本身不保证永久存储，所有数据都需要自己负责备份。训练过程中写的 checkpoint，每隔一定步数自动上传到网盘，可以用脚本实现：

bash复制# 每 10 个 epoch 自动同步一次 checkpoint 到 /root/data/checkpoint_backup/
rsync -av --delete /root/autodl-tmp/output/checkpoint /root/data/checkpoint_backup/

先把结果备份到数据盘，等训练完了统一导出，这是兼顾速度和安全的折中方案。

6. 按量计费时代如何当个省心的炼丹师：关机策略、实例保存与救急技巧

AutoDL 虽然便宜，但如果使用习惯不好，账单照样能吓你一跳。这里分享几个我自己优化成本和控制风险的经验。

6.1 计费规则的精髓：关机和释放是两件事

• 关机：在控制台点击“关机”，实例停止计费，但系统盘、数据盘、IP 都保留。下次开机直接是上次的状态。
• 释放：删除这台实例，所有数据（除你保存的镜像）都会进入保留期，之后被清理。

这里有个非常反直觉的收费点：如果你在 AutoDL 上选择“无卡模式开机”，可以访问数据盘但不会借用 GPU，因此费用极低（几乎只收磁盘占用费）。这个模式很适合做数据整理、代码调试，或者把数据从网盘下载到实例里。

所以最省钱的流程是：

• 调代码阶段：用无卡模式开机（或者干脆不开机）。
• 需要训练时：正常开机用 GPU。
• 训练结束：立刻关机，数据留在实例里。

遇到需要长时间训练的，AutoDL 也支持定时开关机，可以在控制台设置，避免训练完忘记关机白白烧钱。

6.2 实例被释放或损坏时的紧急恢复路径

有一天我登录实例，发现 SSH 连接不上，控制台显示实例状态异常。这个情况虽然不常见，但遇到时别慌。AutoDL 提供了“救援模式”和“备份恢复”功能：

• 先尝试在控制台重启实例。
• 如果重启无效，使用“救援模式”（类似云主机的 VNC 登录），进去检查系统日志。
• 如果系统盘已经损坏，在控制台用最近的自动备份恢复。AutoDL 会定期给系统盘做快照，你可以选择恢复到某个时间点。

恢复路径依赖平时积累：

• 重要代码：放进 Git 仓库，本地和远端各一份。
• 关键数据：定期备份到网盘或对象存储。
• 环境配置：做成镜像，随时拉起。

6.3 如果 SSH 一直连不上的排查清单

SSH 连接失败是出现频率最高的问题。原因通常是以下几类，按概率从高到低排查：

1. 实例没开机。检查控制台状态是否为“运行中”。
2. 本机网络问题。尝试 ping 远程 IP，或者换手机热点测试。
3. SSH 端口被占用或变化。检查控制台显示的端口是否和你命令行里的一致。
4. 密钥和密码不匹配。如果设置了密钥登录，又用密码登录，容易被拒绝。
5. 安全组策略拦截。检查 AutoDL 控制台是否有防火墙设置，确保本地 IP 的访问未被拦截。

实际操作中，90% 的情况是第 1 条或第 4 条。如果你在本地配置文件里写死了端口，但实例重新分配了 IP 或端口，也会连不上。每次开机后，我都习惯去控制台重新确认一下 SSH 连接信息。

6.4 顺手给你一个开箱即用的初始化脚本

在多次重建实例之后，我把环境初始化写成了一套脚本，放一个文件里，新实例开机后直接跑一遍就能进入工作状态。这里列出核心部分，你可以按自己的需求扩展：

bash复制#!/bin/bash
# 初始化 AutoDL 实例后的常用操作

# 更新 apt 源并安装基础工具
apt-get update && apt-get install -y htop tmux git unzip

# 更换 pip 源（如果网络慢）
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

# 安装常用 Python 库（如果镜像里缺）
pip install numpy pandas scikit-learn transformers datasets accelerate peft

# 创建代码目录
mkdir -p /root/workspace /root/autodl-tmp/data

# 从 git 仓库拉取项目
# git clone https://github.com/yourname/yourproject.git /root/workspace/yourproject

echo "初始化完成"

这个脚本的核心价值在于：让“重建环境”从一件焦虑的事变成一件机械的事。配合镜像保存，双保险。

最后分享一个实验管理的经验

运行多个实验时，我强烈建议你提前规划好命名规则和目录结构。我自己使用的约定是：

code复制/root/workspace/
  project_a/          # 每个项目一个目录
    data/             # 小数据放这里
    code/             # 代码仓库
    logs/             # 训练日志
    checkpoints/      # 模型权重
    results/          # 实验输出

对应到 AutoDL：

• 数据集超过 10GB 一律放 /root/autodl-tmp。
• 代码永远用 Git 管理，远端仓库是权威版本。
• 每个实验组跑完，把最佳权重和日志同步到网盘备份。
• 每次打开机先看一眼当前 GPU 环境和磁盘空间。

养成这些习惯以后，你基本不会再有“我的环境呢”“数据怎么没了”“这钱怎么又没了”的焦虑。AutoDL 说到底只是个工具，真正决定效率的是你对待实验流程的态度。这篇文章把这些流程中常见的问题都拆开了，剩下的就靠你自己上手跑一遍了。