企业官网建设流程全解析

显卡租赁这件事，说白了就是把别人机房里的 GPU 按小时切开租给你用，AutoDL 就是这么一个面向深度学习场景的算力租赁平台。我第一次用它是为了跑一个图像分割的模型，本地那张 6G 显存的卡连 batch size 调到 2 都爆显存，换成租一张 24G 的卡，同样的代码一行没改就跑起来了。从注册、登录到真正把显卡租到手跑起训练，整个链路其实不长，但中间有几个参数和计费规则如果没搞明白，很容易出现“钱花了、机器开了、活没干成”的尴尬局面。这篇内容我会把 AutoDL 的使用方法从头到尾拆一遍：账号怎么注册和登录、显卡怎么挑、镜像怎么选、实例怎么创建、远程怎么连、环境怎么配、钱怎么省，以及那些官方文档里不会写、只有自己踩过才知道的坑。适合刚接触云端训练的新手，也适合已经用过但总觉得账单偏高、环境老是要重配的中级用户。

1. 租卡之前先算账：什么情况下该用 AutoDL

1.1 买卡、租卡、用免费算力，三条路各自的边界

在动手注册之前，我建议先把这笔账算清楚，因为这决定了你后面是把它当主力工具还是当应急备胎。自己买一张消费级显卡，整机成本大概在一万五到两万之间，按三年折旧、每年有效使用 300 天、每天满载 8 小时来算，总可用时长约 7200 小时，光硬件折旧就是每小时两块八左右；再加上整机功耗四百多瓦带来的电费，商业电价下每小时还要再加四五毛；如果机器放在家里，夏天散热和噪音也是真实成本。这样算下来，自购卡的隐性单价其实在每小时三元以上，而且前提是你真的能用满 7200 小时——绝大多数人一年能用满 500 小时就算勤快了，那么真实单价会被抬到十几块甚至几十块一小时。

租卡则完全相反，按小时计费，不用就关，边际成本为零，代价是单价略高、数据要放在远端、环境需要自己维护。用免费算力（各类限时赠送的额度、临时体验环境）适合验证想法，但不适合长任务，因为时长限制和排队机制会让你的训练随时中断，一个跑十小时的实验被砍在第 8 小时，那种感觉比自己掏钱还难受。

所以判断标准很简单：如果你的 GPU 使用是突发式、项目式的（做课题、赶论文、跑一次性的实验、验证一个开源模型），租卡几乎永远比买卡划算；如果你是每天都要跑推理、长期在线服务、对数据合规有强要求，才考虑自建。AutoDL 这类平台的核心价值，就是把“算力的持有成本”变成“算力的使用成本”，你只为真正跑起来的那几个小时付费。

1.2 AutoDL 的产品形态与它最适配的人群

AutoDL 的产品形态其实很朴素：给你一台带 GPU 的 Linux 云主机，配好 CUDA 和常用框架的镜像，通过网页终端、JupyterLab 或者 SSH 接进去用，按小时扣费。它不像某些平台提供完整的可视化训练流水线，也不做模型托管，本质上就是“远程开发机 + GPU”。这种朴素反而好用，因为你本地能跑的命令，在上面基本都能跑，不需要为了适配平台去改代码。

它最适配的人群画像很清晰：在校做课题的研究生、独立开发者、小团队做算法验证的工程师、以及需要临时补算力跑一次大规模实验的人。这些人共同的特点是——懂一点 Linux 命令，会用 conda 和 pip，能看懂显存占用，但不想为了几张卡去折腾机房、运维和驱动。如果你连cd和ls都没用过，前期会有点痛苦，因为云主机没有图形界面，所有操作都得靠命令行或者网页文件管理器，这一点要有心理准备。

另外要提一句，平台上的显卡型号覆盖从消费级到数据中心级，价格跨度可能达到十倍以上。新手最容易犯的错就是一上来就选最贵的那张卡，觉得“贵的肯定快”，结果发现自己的模型根本吃不满算力，纯属浪费。后面第 3 节我会专门讲怎么按任务挑卡。

2. 注册与登录：把账号这关一次性过干净

2.1 从注册到实名的完整链路

注册本身没什么技术含量，手机号加验证码，设置密码，几分钟就能完成。真正需要注意的是后面的实名认证环节。按现行要求，使用算力租赁服务基本都需要完成实名，这一步通常要提交身份信息并进行人脸核验，审核时间从几分钟到几小时不等。我的建议是不要在急着跑实验的当天才去注册，因为实名审核可能卡住，而你手上又有一个 deadline，那种焦虑完全没必要。

注册完成后一般还要绑定一个支付方式，主流是扫码支付。这里有个细节：不少平台区分“账户余额”和“押金”两个概念，押金在你不主动申请退还时会一直挂在账户里，余额则是实际扣费用的。第一次充值时建议只充小额，比如 20 到 50 元，够你跑几个小时验证流程；等确认整个链路顺畅、镜像能用、数据能传上去，再按项目需要充值。我见过有人一上来直接充五百,结果发现自己选的镜像 CUDA 版本和代码不兼容，折腾半天没跑起来，钱倒是没浪费，但心态已经崩了。

还有一类优惠值得留意：部分平台针对在校学生和科研用户提供认证通道，认证通过后单价会有折扣。这个认证通常需要提供学籍或在职相关的证明材料，流程比普通实名长一些，如果你符合条件，建议在正式开跑之前就办好，长期下来省的钱相当可观。

2.2 登录方式、账号绑定与安全设置

登录方式通常有两种：手机号加密码，或者手机号加验证码。日常用验证码比较省事，但如果你打算在本地编辑器里配置远程开发（后面 4.3 会讲），那就必须有一个固定密码，因为 SSH 登录和很多工具都是走密码或者密钥认证的。所以我的习惯是：注册时就设一个强密码记在密码管理器里，日常网页登录用验证码，远程连接用密码。

账号安全这块容易被忽视。云主机本质上是一台暴露在公网的 Linux 机器，如果你的 SSH 密码设得很简单，被暴力破解的概率并不低。虽然平台层面一般有防护，但自己该做的还是要做：密码长度至少十二位，包含大小写字母和数字；不要在多个平台复用同一个密码；如果平台支持 SSH 密钥登录，优先用密钥而不是密码。我在早期图省事用了六个纯数字的密码，结果某天发现机器上多了一堆莫名其妙的进程，虽然最后确认是误报，但从那以后我就老老实实用密钥了。

另外建议把账号绑定一个常用的通知渠道。很多平台在实例余额不足、实例即将被自动关机、或者机器出现异常时会推送提醒，这些提醒非常关键——余额耗尽导致训练在半夜中断，是所有云端训练里最让人心痛的事故之一，而它本来完全可以避免。

2.3 充值与账户余额：押金、代金券、发票

充值页面看起来简单，但里面的门道值得说三句。

第一，明确“计费单位”是小时还是分钟。多数平台按小时计费、按秒或按分钟结算，也就是说你开机 10 分钟关机，扣的是 10 分钟的钱，而不是一小时。但也有一些资源（比如某些高配机型或者存储空间）是按天或者按整小时扣的。这一点在创建实例的页面上一般会写清楚，创建之前扫一眼，能避免很多“我明明只开了十分钟怎么扣了一小时”的困惑。

第二，代金券和余额的扣减顺序。一般是有代金券先扣代金券，但代金券往往有使用范围限制，比如只能抵扣 GPU 费用不能抵扣存储费用，或者只对特定机型有效。如果你的代金券快过期了，优先用它去跑那些价格高的实验，别拿它去跑无卡模式。

第三，发票与报销。如果你是学生或者公司用户需要报销，注意平台通常要求消费完成后才能开票，而且开票信息一旦提交修改起来很麻烦。建议在第一次充值前就把开票信息填好，避免后期一堆消费记录要一张张处理。

关于充多少的问题，我的经验是分档：探索期充 30 元（够跑十来个实验小时），项目期按预估卡时充，比如预计要跑 100 卡时、单价 2 元，就充 250 元留点余量。不要一次性充太多，一是资金占用，二是余额多了容易放松警惕，关机不及时。

3. 显卡租赁的核心决策：选卡、选镜像、选计费

3.1 显卡型号怎么挑：显存优先还是算力优先

这是整个流程里最影响体验和成本的决策。我先给结论：先看显存够不够，再看算力快不快，最后看价格能不能接受。显存是硬门槛，不够就是跑不起来，没有折中余地；算力是软指标，慢一点可以等，但爆显存连等的机会都没有。

下面这张表是我根据常见任务整理的选卡思路，具体型号和价格会随平台供给变化，创建页面上的实时标价才是准的：

新手最常见的两个误区：一是拿 A100 去跑一个 ResNet 分类任务，训练速度确实快，但你可能只需要跑二十分钟，花的是 4090 的五倍价钱，纯浪费；二是拿 12G 的卡硬跑 7B 模型的全参微调，各种 offload 技巧堆上去，训练速度慢到一天跑不完一个 epoch，最后算下来比直接租 24G 更贵。

有个实用的估算方法：模型参数量 × 精度字节数 × 4，大致就是训练时显存的粗估下限（4 倍是给梯度、优化器状态和激活值留的余量）。比如 7B 参数、半精度 2 字节，7×2×4 ≈ 56G，这就说明单张 24G 卡做全参微调是绝对不够的，必须上量化或者 LoRA 这类参数高效方法。如果换成 LoRA，只训练百分之一左右的参数，显存需求能降到十几 G，那 24G 卡就绰绰有余了。这个计算不需要精确，但它能帮你在选卡页面上一眼排除掉明显不合适的选项。

3.2 镜像的四种来源与选择顺序

镜像决定了你开机之后是什么环境，选错了要么版本冲突，要么白跑一趟。平台上的镜像一般分四类，我按推荐顺序说：

第一类是框架镜像，比如预装了 PyTorch、TensorFlow 加对应 CUDA 版本的官方镜像。这是绝大多数人的首选。选的时候注意两点：一是 CUDA 版本要和你要用的框架版本匹配，二是 Python 版本要和你代码的依赖兼容。经验上，选一个“稍微旧一点但稳定”的版本比追最新版靠谱，因为最新版的 CUDA 往往和某些第三方库还没适配。

第二类是基础镜像，只有操作系统和驱动，什么都没有。适合你对自己要装什么非常清楚、想完全从零搭建的情况。我一般在需要严格控制依赖版本时用这个，比如复现某篇论文的代码，它对 numpy 和 scipy 的版本有硬要求，用预装镜像反而要降级一堆包。

第三类是自定义镜像，也就是你自己把配好的环境保存成镜像，下次直接开机就是那个状态。这个功能是省时利器，后面第 5 节会详细讲怎么用。

第四类是社区镜像，其他用户分享的、已经配好某个具体项目环境的镜像。这类镜像能省掉大量配置时间，但风险是他人的环境里可能包含你不认识的脚本或者不安全的配置。我的建议是：可以用，但用之前先看一眼它的启动脚本和目录结构，别一开机就往里面塞重要的数据。

3.3 三种计费模式的适用边界

平台一般提供三种开机模式，用对了能省下一半的钱。

按量计费是标准模式，随开随用，按实际运行时长扣费。适合绝大多数训练任务。

竞价或者低优先级模式，单价明显低，但资源紧张时可能被回收，而且回收往往没有太多提前通知。这类模式适合“可中断、可续跑”的任务，比如你在代码里做了 checkpoint 定期保存，被中断了从断点继续就行。不适合那种跑了六小时才有结果的单次推理。

无卡模式（仅 CPU 低费率开机），这是最被低估的功能。它让你在不开 GPU 的情况下把机器启动起来，费率极低，通常只有 GPU 模式的几十分之一。所有不需要显卡的工作——传数据、装环境、调代码、解压数据集、下载模型权重——都可以在这个模式下完成。我现在的标准流程是：无卡模式开机 → 配环境 → 传数据 → 调试通 → 关机 → 切 GPU 模式开机 → 直接跑。这一套下来，配置阶段的花费几乎可以忽略。

4. 创建实例与接入：从点击“开机”到跑起第一行代码

4.1 创建页面上每个参数到底在说什么

创建实例的页面信息密度很高，我按重要性逐个拆。

显卡型号与数量：型号按上一节的方法选，数量这一栏新手建议填 1。多卡不是简单的“两张卡两倍速度”，它需要你的代码支持分布式训练，否则第二张卡就是纯烧钱。我曾经天真地开了双卡跑单卡代码，结果只有一张卡在跑，另一张在空转，白花了一倍的钱。

镜像：按 3.2 的方法选。这里有个细节——镜像选定后，开机再改就只能重开实例，所以创建前多花三十秒确认一下 CUDA 和框架版本。

数据盘：这是你要重点关注的。系统盘一般只有几十 G，装完系统和框架就所剩无几；数据盘可以单独挂载，容量从几十 G 到几百 G，而且数据盘的内容在实例释放后通常可以保留（具体规则以平台说明为准），系统盘则不一定。所以规矩是：代码、数据集、模型权重全部放数据盘，系统盘只放环境。

计费模式：按 3.3 选。如果只是配置环境，直接选无卡模式；如果要跑训练，选按量计费。

其他还有地域、可用区之类的选项，一般选默认或者延迟低的就行。如果你要和别人协作，记得选同一个地域，否则内网不通，传数据会非常痛苦。

4.2 JupyterLab 接入：最省事的方式

实例开机后，控制台会给出几个入口，最直观的是 JupyterLab。点进去是一个网页版的文件管理加笔记本环境，左边是目录树，右边是编辑区，下面可以开终端。对新手来说这是最友好的入口，因为它不需要你配置任何本地环境，浏览器打开就能用。

JupyterLab 里我最常用的三个功能：一是文件上传，直接把本地几十兆的小数据集拖进目录树；二是终端，网页终端和 SSH 终端功能完全一样，可以在里面跑nvidia-smi看显卡状态；三是notebook，适合做交互式的调试，比如分步加载数据、看中间结果。

不过 JupyterLab 有两个明显的局限。第一，浏览器标签页一关，跑在前台的任务就断了。所以任何长任务都必须用nohup或者tmux挂到后台，这一点后面 5.3 会详细讲。第二，大文件上传很慢，网页上传走的是浏览器，几十 G 的数据集用它传会让你怀疑人生，这种时候要用命令行工具或者网盘中转。

4.3 SSH 与本地编辑器远程开发

如果你要写稍微复杂一点的代码，我强烈建议放弃网页版，改成在本地编辑器里远程连接。体验差距非常大——本地的代码补全、跳转、调试、git 集成全都能用，改一行代码按快捷键就同步到远端执行，效率是网页编辑器的好几倍。

配置步骤大致是这样：

1. 在实例详情页找到 SSH 登录指令，一般格式是ssh -p 端口号 root@主机地址。
2. 复制这串指令，在本地终端里执行，第一次连接会提示确认指纹，输入 yes，然后输入实例密码。
3. 连上之后确认一下环境，nvidia-smi看卡，python -V看版本。
4. 在本地编辑器里安装远程开发插件，新建一个 SSH 连接，填入同样的主机、端口、用户名，选择密码认证或者配置密钥。

这里有几个实操细节。端口号不是固定的 22，每个实例分配到的端口不同，复制指令的时候一定要连-p参数一起复制，漏了就连接超时。主机地址在实例重启后可能会变，所以不要把配置写死在脚本里。连接超时通常是实例没开机或者网络问题，先确认实例状态是运行中，再检查本地网络。

用密钥替代密码会舒服很多，配置一次之后免密登录，本地编辑器的远程连接也更稳定。生成密钥对、把公钥上传到实例的~/.ssh/authorized_keys，这套操作网上教程很多，不展开。

4.4 数据进出：上传、下载与网盘中转

数据搬运是云端训练里最耗时间也最容易出问题的环节，我总结了三条路径，按数据量选：

小于 100M：直接用 JupyterLab 的拖拽上传，简单直接。

100M 到几个 G：用命令行工具。在实例里执行带下载功能的命令拉取远端文件，或者在本地用支持 SSH 传输的工具推上去。速度取决于带宽，一般能跑到几十兆每秒。

几十 G 以上：走网盘中转。先把数据传到网盘，再在实例里用网盘客户端或者直链下载工具拉下来。这条路径看起来绕，但实际往往最快，因为网盘的下载带宽通常比你自己上传的带宽高得多。注意有些网盘需要客户端才能满速，纯命令行拉取可能被限速。

还有一个反向的需求：训练完的模型权重怎么拿回来。如果你只需要推理结果，可以在实例里跑完推理、只下载输出文件；如果确实要拿权重，先看看大小——一个 7B 模型的半精度权重就有十几个 G，下载时间不短。这种情况下更划算的做法是把权重存在数据盘里，下次开机直接复用，而不是每次都下载一遍。

5. 环境与数据：让实例随时可以扔掉重开

5.1 系统盘与数据盘的分工

这一节讲的是习惯问题，但这个习惯直接决定了你是在云端高效工作，还是在反复重装环境。

核心原则一句话：系统盘是临时的，数据盘是相对持久的。系统盘里放的是操作系统、驱动、你通过 pip 装的各种包；数据盘里放的是你的代码、数据、模型、日志。为什么这么分？因为实例一旦“释放”（不是关机，是释放），系统盘大概率被清空重建，而数据盘可以挂载到新实例上继续用。

所以我的目录结构是这样的：

/root/autodl-tmp/ ← 数据盘挂载点（路径以平台实际为准） ├── code/ ← 代码仓库 ├── data/ ← 数据集 ├── ckpt/ ← 模型权重与检查点 └── logs/ ← 训练日志

每次开新实例，第一件事是cd到数据盘目录，确认之前的东西还在。如果不在，说明挂载出了问题或者数据盘被清理了，这时候再考虑从本地重传。

还有个细节：conda 环境默认装在系统盘，一个环境几个 G，装三四个就把系统盘塞满了。解决办法有两个，一是用conda的-p参数把环境装到数据盘指定目录，二是定期清理不用的环境和 pip 缓存。我吃过一次系统盘满的亏，训练跑到一半报 “No space left on device”，日志写不进去，白跑三小时。从那以后我养成了开机先看df -h的习惯。

5.2 conda 与 pip 的实操顺序

环境配置的顺序很重要，顺序错了会出现一堆奇怪的依赖冲突。我固定的流程是：

第一步，确认基础环境。开机先跑python -V、nvidia-smi、nvcc -V，确认 Python 版本、显卡驱动、CUDA 版本。这三个信息决定了你后面能装什么版本的框架。

第二步，建独立环境。哪怕镜像里已经预装了 PyTorch，我也建议conda create -n myproj python=3.10建一个干净环境。原因是预装环境里往往有一堆你不需要的包，版本也未必合你的要求，直接在它上面装东西，很容易把原环境搞坏。建独立环境多花两分钟，省下的是后面几小时的排查时间。

第三步，装框架。这里的关键是版本对齐。CUDA 11.8 对应哪个 PyTorch 版本、cuDNN 要不要单独装，这些在框架官网上有明确的对应表，照着装就行。千万别pip install torch不带版本号，那样装到的最新版很可能和你的 CUDA 不匹配，跑起来报 “CUDA driver version is insufficient” 之类的错。

第四步，换源加速。默认源在境外，装大包会慢到想砸键盘。换成国内镜像源之后，速度能从几十 K 提升到几兆每秒。注意换源要换全套，包括 conda 的源和 pip 的源，只换一个的话装依赖时还是会卡。

第五步，装项目依赖。先pip install -r requirements.txt，装完跑一遍 import 测试，确认没有冲突。如果有冲突，逐个降级解决，不要试图一次性全装上。

提示：装完环境之后立刻把它保存成自定义镜像。这一步花三分钟，但下次开新实例就能省半小时的配置时间，而且是完全一致的环境，排除了“上次能跑这次不能跑”的变量。

5.3 训练过程中的监控与自保措施

云端训练和本地训练最大的区别是：你看不见机器，机器出事了你也不知道。所以必须建立一套自保机制。

第一，所有长任务必须挂后台。用tmux开一个会话，在里面跑训练，然后Ctrl+B D脱离。这样即使你关掉浏览器、断网、笔记本合盖，训练照样跑。我早期不知道这个，用网页终端跑训练，去泡了杯咖啡回来发现标签页被浏览器休眠了，任务断了，进度全丢。

第二，日志必须落盘。训练脚本的输出重定向到数据盘里的日志文件，比如python train.py 2>&1 | tee /root/autodl-tmp/logs/run1.log。这样出问题时你有完整的现场记录，而不是只看到终端上最后几行。

第三，定期存 checkpoint。每个 epoch 或者每 N 步保存一次，并且保存到数据盘。这样即使实例被回收或者余额耗尽强制关机，你也能从最近的检查点续跑。ckpt 的保存策略要平衡，存太频繁 IO 开销大，存太稀疏丢的进度多，我的经验是每半小时到一小时存一次。

第四，盯着余额和显卡状态。训练开始后每隔一段时间看一眼nvidia-smi，确认显存没爆、GPU 利用率正常。如果利用率长期低于 30%，说明瓶颈在数据加载或者代码逻辑上，这时候加显卡是没用的，得先优化 dataloader 的 worker 数量。

第五，设个闹钟。如果预估训练要跑五小时，而你充的余额只够六小时，那就设个四小时半的闹钟。听起来很土，但这是最有效的防断供手段。

6. 成本控制：把每小时单价压下去的几个实操动作

6.1 用无卡模式做所有不需要显卡的事

前面提过一次，这里展开讲，因为这是省钱幅度最大的一个动作。

无卡模式的费率通常只有 GPU 模式的几十分之一，也就是说你在 GPU 模式下配环境的每一分钟，都在以几十倍的价格付费。而配置环境这件事，恰恰是最不需要显卡的——装包、传数据、改代码、跑单元测试、下载预训练权重，全是 CPU 的活。

我现在的标准流程是这样的：租好数据盘 → 无卡模式开机 → 挂载数据盘、配置 conda 环境、上传数据集、把训练脚本完整跑通一遍（用小样本，几个 batch 就行）→ 保存自定义镜像 → 关机 → 切 GPU 模式开机 → 直接执行训练命令。整个配置阶段可能花了一两个小时，但因为是无卡模式，成本可能只有几毛钱。

这个流程还有个隐藏好处：它强迫你把环境和数据准备好再开 GPU。很多人习惯先开 GPU 再慢慢想，结果一边思考一边烧钱。流程化之后，GPU 开机就是纯计算时间，利用率自然就上去了。

6.2 关机、释放、休眠的区别与选择

这三个操作看起来差不多，实际差别很大，用错了要么丢数据，要么白扣钱。

关机：实例停止，GPU 费用停止计算，但系统盘和数据盘还占着，可能继续收少量存储费。下次开机环境还在，能接着用。适合当天任务结束、第二天还要继续的情况。

释放：实例彻底删除，存储资源回收。系统盘清空，数据盘看平台规则（有些能保留，有些一起清）。适合任务彻底结束、不想再交存储费的情况。释放前一定要确认重要数据已经下载或者存在能保留的数据盘里。

休眠或者保留实例：有些平台提供这种模式，把实例状态保存下来但暂时不占 GPU，下次恢复很快。适合短暂离开的情况。

我踩过的坑是：任务跑完直接关浏览器，以为没事，结果实例还在运行，后台进程还在占着 GPU，费用一直在扣，直到第二天收到余额不足提醒才发现。从那以后我每天都习惯性看一眼控制台的实例列表，确认没有不该跑的实例。

6.3 容易被忽略的计费细节

几个容易被忽略的点，都是我事后对着账单复盘才发现的。

存储也在计费。数据盘按容量收费，虽然单价低，但如果你挂了一个几百 G 的盘，长期不用也不释放，一年下来也是一笔钱。建议任务结束就清理，或者把数据下载到本地后释放实例。

上传下载流量可能有限制。大部分平台对常规的进出流量不额外收费，但如果你反复大量传输，还是要注意规则说明。

不同地域、不同时段的供给价格可能不同。热门机型在晚间时段更容易被抢空，如果发现某个型号一直开不了机，不是你的账号有问题，而是资源紧张。这时候换一个同等档次的型号或者换个地域，通常就能解决。

多卡不等于线性加速。两张卡的价格是两倍，但训练速度可能只快 1.6 倍（因为通信开销）。做多卡之前先算一下性价比，如果单卡跑八小时、双卡跑五小时，双卡反而更贵，那老老实实单卡就好。

7. 常见问题速查与排查实录

7.1 开机与显存相关的问题

问题一：点了开机一直显示“创建中”，等了很久没反应。这种情况大概率是资源紧张，也就是那个型号的卡被租光了。解决方法：换一个型号，或者换一个地域，或者稍等再试。不是你的账号问题，不用去改密码。

问题二：开机成功但nvidia-smi报错或者看不到卡。先确认你开的是不是无卡模式。无卡模式下确实没有显卡，这不是故障。如果确定是 GPU 模式还看不到卡，重启一次实例，多数情况能恢复；如果还不行，提交工单。

问题三：训练跑到一半报 CUDA out of memory。这是最常见的错误，排查顺序是：

1. 看 batch size，先减半试试。
2. 看图片输入分辨率，有没有被设得过大。
3. 看是不是有残留进程占着显存，nvidia-smi看进程列表，用kill -9清掉。
4. 如果用了验证集或者多模型并行加载，确认它们没有同时占显存。
5. 最后才考虑换更大的卡，因为前三步往往就能解决。

问题四：显存占用看着正常，但训练速度很慢。看 GPU 利用率。如果一直在 20% 到 40% 之间跳，说明瓶颈不在计算，在数据加载。把 dataloader 的 worker 数调大（比如num_workers=8），把数据预处理放到 GPU 上（用 DALI 之类的库），或者把数据集转成更适合顺序读取的格式（比如把几千张小图打包成大文件），速度能提升好几倍。

7.2 连接与网络相关的问题

问题一：SSH 连接超时。排查顺序：实例是否处于运行中状态 → 端口号是否带上了 → 主机地址是否因为重启变了 → 本地网络是否有限制。多数是端口号漏了。

问题二：JupyterLab 打不开，一直转圈。先换个浏览器或者用隐身模式试试，排除缓存问题；再确认实例状态；最后看是不是实例刚开机还没启动完成，等一两分钟。

问题三：pip 安装特别慢或者超时。换成国内镜像源，检查是不是只换了一个源。另外大包安装失败往往是网络抖动，重试一次通常就好了。

问题四：下载模型权重时连接被中断。大文件下载要支持断点续传，用带续传功能的命令，中断后重试会从断点继续。不要每次都从头下，浪费时间也浪费流量。

7.3 环境与数据相关的问题

问题一：系统盘满了。df -h看一下哪个目录占得多，通常是 conda 环境和 pip 缓存。清理~/.cache/pip，删掉不用的 conda 环境，把新环境装到数据盘。

问题二：重开实例后代码和数据不见了。说明你把东西放在了系统盘。这是新手最常踩的坑，也是损失最大的一类。重新传一遍，然后按 5.1 的目录结构重新组织。

问题三：昨天能跑的代码今天报依赖错误。如果你没保存镜像，重开实例后环境是镜像的初始状态，你之前 pip 装的东西全没了。这就是为什么一定要保存自定义镜像。

问题四：训练日志显示进程被 killed。最常见的原因是内存不足而不是显存不足。Linux 的内存溢出保护会杀掉占用内存最多的进程。解决方法是减小 dataloader 的 worker 数、减小 batch size、或者换内存更大的机型。

下面这张表把最常遇到的问题做了汇总，方便快速对照：

8. 几个只有踩过坑才会养成的习惯

用了一段时间之后，我发现自己形成了一套固定的动作序列，几乎每次开机都会不假思索地执行，这些动作没有一条写在官方文档里，但每一条都来自真实的损失。

第一个习惯是开机先看三样东西：df -h看磁盘、nvidia-smi看显卡、free -h看内存。这三个数字决定了这台机器能干什么。有次我拿到一台内存只有 16G 的实例，数据集一加载就把内存撑爆，进程被系统杀掉，报错信息还不明显，查了半小时才发现是内存问题。从那以后这三个命令成了我的开机仪式。

第二个习惯是任何跑超过十分钟的命令都先进 tmux。这个习惯是从一次“跑了五小时的训练因为网络抖动断连而中止”的事故里养成的。现在我甚至连pip install大包都放进 tmux，因为有些包编译起来要十几分钟，断一次就得重来。

第三个习惯是配置文件和数据全部用绝对路径。云端的环境变量、工作目录和你本地不一样，用相对路径经常会出现“在我电脑上好好的，上去就找不到文件”。统一用绝对路径写在配置文件里，虽然看着啰嗦，但迁移的时候一份配置就能跑遍所有实例。

第四个习惯是每次任务结束写一行备注。在数据盘里放一个notes.md，记下这次用了什么镜像、什么卡、跑了多久、遇到什么问题、怎么解决的。听起来很麻烦，但当你三个月后要复现一个实验时，这一行备注能救你一整天。我现在翻自己早期写的备注，还能看到“某次因为忘了保存镜像导致环境全丢”的记录，每次看到都提醒我别偷懒。

第五个习惯是先用小样本跑通全流程，再上全量数据。云端最贵的不是卡，是你的时间。一个两小时的训练如果因为在第 100 步才暴露出的 bug 而失败，损失的不只是钱。所以我现在都是先用 1% 的数据把整个 pipeline 跑一遍，确认损失在下降、checkpoint 能存、日志能看，再切全量数据。

最后分享一个我觉得挺有用的小技巧：把常用的开机命令写成一个 shell 脚本放在数据盘里。脚本里包含切目录、激活环境、设置环境变量、启动训练这一整套动作，开机之后一行命令就进去了。这样既避免了每次手敲命令出错，也把“环境应该长什么样”这件事给文档化了。如果你要换机器、换平台，把这个脚本稍微改改就能用，迁移成本几乎为零——这大概是我用云端训练这么久，收获的最有复用价值的一个东西。