CarrieYung很多人第一次打开AutoDL的官网，第一反应是“这不就是个租显卡的云平台吗”，但真正用上一周就会发现，它其实是一台可以随时开关机的云端开发机。你可以在上面装环境、跑训练、挂服务，也可以把PyCharm连过去写代码，甚至通过Claude的API把大模型能力接进自己的脚本里。这篇文章就是一份基于我实际使用经验的autodl手册，重点覆盖大家搜索最多的几个问题：autodl使用教程、autodl链接pycharm、autodl清除垃圾箱、以及怎么运用云服务autodl做真实项目。不管你是第一次租GPU的学生党，还是已经在用但经常踩坑的算法工程师，应该都能在里面找到能直接抄作业的部分。
1. 先弄明白AutoDL是什么：它不是一台普通服务器
1.1 为什么你需要一块“按小时计费的GPU”
AutoDL本质上是把GPU算力按小时出租，但它的核心设计思路是“你只为自己真正用到的资源付费”。和传统云服务器不同，AutoDL的实例可以随时关机，关机后不再计费，但磁盘上的数据依然保留，下次开机还能继续工作。这个特性非常关键，意味着你可以把开发、训练、调试拆成多个时间段，不用像以前那样包月买一台昂贵的机器。
而且AutoDL的镜像系统也做得比较友好，PyTorch、TensorFlow、PaddlePaddle这些常用深度学习框架都有现成镜像，开机之后基本不需要折腾CUDA和cuDNN。对于时间紧迫的炼丹场景，这能帮你省下至少两小时的部署时间。我自己第一次用的时候，选择了一个带PyTorch 2.0的镜像，开机后直接跑通了之前本地环境一直报错的训练脚本，那种感觉确实顺畅。
另外，AutoDL的实例规格覆盖了从入门级RTX 4090到专业级A100等常见显卡，价格差异也比较明显。如果你是新手，建议先从便宜的小卡入手，把流程跑通后再切换到更高级的实例，避免一开始就花冤枉钱。对于大部分深度学习实验，单张RTX 4090其实已经非常能打了。
1.2 AutoDL的三种使用视角：Solo玩家、算法工程师、学生党
不同身份的人用AutoDL的方式差别很大。学生党通常是课程作业或者毕业设计需要跑模型，最关心的是性价比和复现便利性，所以适合用预置镜像加JupyterLab，快速上手。算法工程师则更多是把AutoDL当成远程开发机，用PyCharm连接实例，像写本地代码一样写训练脚本，并且需要频繁同步数据、清理缓存，这个场景下SSH和文件传输工具就变得很重要。
还有一类Solo玩家，可能是做个人项目和接私活，往往需要在AutoDL上同时跑多个实验，还要把结果数据保存下来。这类用户更关注磁盘管理和成本控制。比如AutoDL的系统盘和数据盘空间有限，跑几天实验后很容易堆满，尤其是pip和conda的缓存、Docker镜像、临时文件，占了大量空间。所以“autodl清除垃圾箱”会成为高频搜索词，这不难理解。
不管是哪类用户，核心其实都是三件事：把环境配好、把代码跑起来、把成本控制住。下面我就按实际操作顺序，从入门到进阶，把每一步都展开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从注册到开机：AutoDL手册的入门实操
2.1 账号、计费与实例选型
AutoDL的注册流程很简单，手机号或者账号注册后，一般都需要实名认证，这个环节卡住过不少人，记得提前准备身份证信息。认证通过后，进入控制台第一步就是充值。AutoDL是预付费模式，相当于先往账户里充钱，然后按实际使用时长扣费。需要注意的是，创建实例时会锁定一个小时的费用，如果余额不足，可能无法开机。
实例选型时，我一般会考虑三个维度：显存大小、算力水平、价格。显存主要看你跑什么模型，像ChatGLM这类7B级别的模型推理，至少需要16G显存，所以RTX 4090或者更大显存的卡更合适。训练任务则要看模型参数量和batch size，可以先在纸上估算一下。比如一个batch size为8的BERT微调，显存需求大概在12G左右，RTX 3090就够用了。
价格方面，AutoDL会显示每小时的费用，但要注意“按量计费”和“包天包月”的说法。实际上AutoDL更多是按小时计费，关机不计费，这点很划算。另外还要留意“无卡模式”开机，这个模式不占用GPU，只保留CPU环境，适合做环境配置和数据预处理，费用极低，算是个省钱小技巧。
2.2 镜像选择、数据盘与开机后的第一件事
创建实例时最关键的步骤是选择镜像。AutoDL的官方镜像里，通常有PyTorch、TensorFlow、MiniConda、PaddlePaddle等选项，还会标注版本号。我的建议是尽量选最新的稳定版本，不要选每日构建版，否则可能会有兼容性隐患。如果你有自己之前做的环境，也可以使用“自定义镜像”功能，把自己的环境打包保存，下次直接从自定义镜像创建实例，省去重复配置。
实例创建完成后，数据盘会自动挂载到/root/autodl-tmp目录，系统盘则是/root。这里要特别强调：系统盘空间通常不大，安装大型Python包时很容易把系统盘塞满，所以最好把虚拟环境、数据集放到/root/autodl-tmp下，甚至可以用软链接把/root/miniconda3里的某个环境目录指过去，避免系统盘爆满。
开机后的第一件事，不是急着跑模型，而是先更新源、检查磁盘空间、确认GPU驱动是否正常。可以用nvidia-smi看一眼显卡状态，用df -h查看磁盘情况。如果发现磁盘已经占用很多，就要先做清理，具体清理方法我在第4章会详细说。
2.3 SSH登录的三种姿势
AutoDL实例创建好之后，控制台会显示登录指令，形如ssh -p 12345 root@connect.xxx.seetacloud.com，密码和SSH公钥在实例页面里可以查看或设置。第一种登录姿势是直接用命令行，Windows用户可以用PowerShell，macOS/Linux用户直接用终端，把命令粘贴进去然后输入密码即可。这种方式适合临时登进去看看。
第二种方式是使用终端工具，比如MobaXterm、Xshell、FinalShell。如果你需要长期开发，这类工具会更顺手，因为可以保存会话、支持多标签、还能内置文件管理器。我自己常用FinalShell，因为它能图形化显示CPU、内存、带宽情况，排查问题很快。
第三种方式是SSH密钥登录，这在自动化脚本或者PyCharm连接时最有用。你可以在本地生成公钥私钥对，把公钥配置到AutoDL实例中，之后就可以免密登录。PyCharm连接远程解释器也强烈推荐配置密钥，比每次输密码稳定得多。密钥配置的核心思路很简单：本地私钥保管好，云端公钥写进~/.ssh/authorized_keys，非常简单。
3. 把PyCharm和AutoDL连起来：远程开发的标准配置
3.1 准备工作：确认IP、端口和SSH密钥
用PyCharm远程连接AutoDL，前提是PyCharm Professional版，社区版不支持远程解释器。准备工作的第一步是确认实例的SSH连接信息，包含主机、端口、用户名（一般是root）和密码。如果是按小时计费的实例，端口号和主机地址在每次开机后可能会变化，所以每次重新开机后都要去控制台重新复制一遍连接信息。
为了提高稳定性，我建议先配置SSH密钥。在本地生成密钥对的方式是ssh-keygen -t rsa -b 4096，生成后会得到id_rsa和id_rsa.pub。然后在AutoDL自定义实例页面或登录进实例后，把公钥内容追加到/root/.ssh/authorized_keys文件末尾。再在本地终端用ssh -i 私钥路径 -p 端口 root@主机测试一下，能免密登录就说明配置成功。
关于PyCharm连接远程开发，本质上就是把本地的IDE当成前端，所有代码运行都在远程执行。你不需要在本地安装任何深度学习环境，只要PyCharm能连上远程解释器，运行调试都会自动在AutoDL上完成，这样既省掉了本地配置环境的痛苦，也保证了训练任务的执行效率。这一点是我用AutoDL链接PyCharm后最明显的感觉：本地环境再乱也不影响跑代码了。
3.2 在PyCharm Professional中配置SSH解释器
打开PyCharm，进入Settings -> Project -> Python Interpreter，点击右上角的齿轮图标，选择Add Interpreter -> SSH Interpreter。在弹出的窗口中填写AutoDL的Host、Port和Username，然后选择密钥或密码认证。如果使用密钥，会要求选择私钥文件的路径；如果使用密码，直接输入root密码即可。
连接成功后，PyCharm会自动检测远程Python解释器，一般是/root/miniconda3/bin/python。如果你在AutoDL上用conda创建了专门的环境，可以手动把解释器路径修改为对应环境的python，比如/root/miniconda3/envs/myenv/bin/python。这一步很关键，否则即使连上了，用的也可能是默认的base环境。
之后PyCharm会把项目文件上传到远程环境，默认同步到/tmp/pycharm_project_XXX目录，这个目录在实例重启后可能会丢失，所以建议在Settings -> Build, Execution, Deployment -> Deployment中修改映射路径，把远程路径改成/root/autodl-tmp/your_project，这样数据更安全，也方便与数据集放一起。
3.3 代码同步与本地数据上传的两种方式
PyCharm连接远程后，文件同步有两种模式：自动同步和手动上传。自动同步适合代码量小的场景，每次修改保存后PyCharm会自动上传到远程，方便是方便，但如果本地文件太多，可能会让同步做很多无用功。手动上传则可以按需操作，选中文件或文件夹，右键选择Upload to Remote即可。
那大数据集怎么上传呢？PyCharm的文件传输功能不太适合传几十G的数据集。我一般用两种方式：第一种，如果数据集在本地电脑上，可以先压缩成tar包，然后用scp命令传到AutoDL的/root/autodl-tmp目录，或者在FinalShell这类工具中直接拖拽上传，速度会比较快。第二种，如果数据源在互联网上，可以直接在AutoDL实例里用wget或curl下载，这样数据不经过本地中转，效率更高。
上传完成后，记得在PyCharm的Deployment配置里添加映射，让本地项目路径和远程项目路径对应起来，否则代码里写相对路径时很容易找不到文件。我的习惯是本地项目结构尽量和远程保持一致，比如都叫src、data、output，这样迁移和调试都省心。
4. 磁盘空间告急：AutoDL清理垃圾箱与扩容方案
4.1 垃圾箱/临时文件的检查与清理
使用AutoDL一段时间后，最头疼的问题就是磁盘满了。很多人会问autodl清除垃圾箱怎么操作，这里的“垃圾箱”其实不是指Windows回收站里的东西，而是指系统盘和数据盘中积累的临时文件、缓存、旧版本依赖等。
首先要搞清楚空间被谁占了。用df -h可以看整体磁盘占用，用du -sh /root/*可以看系统盘根目录下每个文件夹的大小，用du -sh /root/autodl-tmp/*看数据盘的情况。通常最容易占空间的几个目录是：/root/.cache、/root/miniconda3、/root/.local、/tmp。如果某次训练中断或调试出错，/tmp下可能会残留大量临时文件，必须重点检查。
一个比较实用的清理思路是先查大文件：find /root -type f -size +100M，把超过100M的文件列出来，然后判断哪些可以删除。比如有些.npy、.pth是实验中间产物，确定不需要了就可以删。还有JupyterLab在运行时也会产生.ipynb_checkpoints目录，这些都可以删掉。
4.2 pip、conda、apt缓存清理实战
Python环境的缓存垃圾是磁盘杀手。pip会把下载的安装包缓存在~/.cache/pip，conda会把包缓存放在/root/miniconda3/pkgs，apt也有自己的缓存。清理这些缓存非常安全，删除后不会影响已安装的软件包，只会让下次安装需要重新下载。
建议依次执行这些清理命令：
- pip缓存清理：
pip cache purge - conda缓存清理：
conda clean --all -y - apt缓存清理：
sudo apt-get clean && sudo apt-get autoremove -y
如果说磁盘还是不够，可以查一下conda环境里有没有不再使用的旧环境。conda env list能看到所有环境，如果有些环境之前测试用，后来不用了，直接conda env remove -n 环境名删掉，往往能释放好几个GB。我自己的一个实例曾经因为conda里残留了三个不用的环境，占了将近20GB，清理后系统盘从99%降到了30%，非常明显。
4.3 数据盘扩容与迁移
如果清理完垃圾，数据盘还是不够，就需要考虑扩容。AutoDL控制台提供了数据盘扩容功能，你可以选择更大的数据盘容量，然后按新的容量支付费用。这个操作通常需要关机或者实例处于停止状态，而且扩容后数据还在，不需要重新迁移。
不过扩容会按新的价格计费，所以我的建议是在创建实例时就规划好数据盘大小，别一开始选太小后面频繁扩容。如果在同一账号下有多个实例，也可以把A实例的数据盘内容打包，在B实例下载，实现跨实例迁移。比如用tar打包整个/root/autodl-tmp，上传到自己的对象存储或者使用AutoDL的文件传输功能，再到新实例中解压。这个操作熟练后，换实例的成本会大大降低。
5. 在AutoDL上接入Claude API：实操记录
5.1 前置条件：密钥、Python环境和依赖
“autodl接入claude”这个需求，严格来说不是把AutoDL变成一个Claude客户端，而是利用AutoDL的运行环境，通过Claude官方提供的API，在你的代码中调用大模型能力。前提是你得有一个合法可用的API密钥，并且要明确API调用会产生费用，具体计费标准以官方文档为准。
在AutoDL实例中操作时，建议先创建一个独立的conda环境，避免把基础环境搞乱。命令如下：conda create -n claude-api python=3.10 -y && conda activate claude-api。然后安装依赖，最常用的是anthropic这个Python SDK，安装命令是pip install anthropic。如果你还想额外处理一些文本数据，可以顺便把openai、pandas、tqdm也装上。
关于密钥的配置，不要直接写在代码里硬编码，而是通过环境变量注入。在~/.bashrc里添加一行export ANTHROPIC_API_KEY="你的密钥"，然后执行source ~/.bashrc。这样做的好处是代码放到Git仓库时不会泄露密钥，多个项目之间切换密钥也更容易管理。
5.2 一个完整的调用示例
下面这段代码是我在AutoDL上实录过的调用流程，功能很简单：向Claude发送一条消息，然后把回复内容保存到本地文本文件中。
python复制from anthropic import Anthropic
import os
client = Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
messages = [
{
"role": "user",
"content": "请用三句话概括一下AutoDL云服务的核心优势。"
}
]
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
messages=messages
)
reply_text = response.content[0].text
with open("/root/autodl-tmp/claude_output.txt", "w", encoding="utf-8") as f:
f.write(reply_text)
print(reply_text)
运行脚本的方式很简单：python claude_test.py。如果一切正常，终端会打印出Claude的回复，同时生成claude_output.txt文件。注意，这里使用的模型名称是示例，实际可用模型列表需要查阅官方文档，并根据自己密钥的权限进行调整。如果提示模型不存在或权限不足，大概率是模型名写错了或者密钥没有对应模型的访问权。
5.3 请求异常与限流处理
实际调用时，最常遇到的是两类问题：一类是网络连接超时，一类是API返回429限流错误。连接超时常见于局域网环境或代理设置异常，但AutoDL本身是云服务器，通常网络状况是稳定的。如果出现超时，可以先检查一下httpx的日志，确认请求是否真的发出去。限流问题则是因为API有每分钟请求数限制（RPM），解决办法是在代码中加入time.sleep或者使用指数退避策略。
以指数退避为例，当收到429错误时，等待2秒、4秒、8秒……逐步增加重试间隔，直到请求成功。简单实现可以用tenacity库：
python复制from tenacity import retry, stop_after_attempt, wait_exponential
@retry(stop=stop_after_attempt(5), wait=wait_exponential(multiplier=1, max=30))
def call_claude(text):
return client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
messages=[{"role": "user", "content": text}]
)
这样做的好处是，在批量处理大量数据时能自动规避限流，不至于一个请求失败就导致整个任务中断。另外一个稳妥的做法是先把所有输入文本保存成JSON文件，然后用tqdm循环逐条调用，每条之间设置一个很小的间隔，既控制速度，又能看清进度。跑完之后记得检查输出文件中有没有空内容或异常返回，方便重新执行失败项。
6. 常见问题排查与使用心得
6.1 连接不上、卡死、磁盘满等典型问题
连接不上AutoDL实例是新手最常遇到的问题。这种情况先检查实例是否在运行状态，关机状态下SSH肯定连不上；然后确认端口、主机地址有没有复制完整，AutoDL的SSH命令里的端口是动态的，每次开机都会变，别用上一次的端口硬连。如果还在连接超时，可以试着从控制台页面直接用WebShell进入实例，看看系统是否正常，WebShell能进说明网络链路是通的。
实例卡死则需要区分是CPU跑满还是IO等待。可以用top命令看CPU占用，用iostat看磁盘读写，如果是磁盘满了，系统会变得非常卡。有时候进程还在跑，但SSH登录非常慢，多半是因为内存不足触发了OOM，dmesg -T | tail -n 20能看到系统日志。这时最直接的办法是强制重启实例，但要注意未保存的数据可能会丢失，所以建议在长时间任务中养成定期保存checkpoint的习惯。
磁盘满时还有一个比较隐蔽的原因：Docker镜像和容器文件残留。如果你在AutoDL上用过Docker，这些文件会占掉很大空间。可以通过docker system prune -a清理不再使用的镜像和构建缓存，这一步和之前提到的conda、pip缓存清理合在一起，就能处理绝大部分磁盘空间问题。
6.2 我的AutoDL使用习惯与建议
写到最后，分享几个我自己在AutoDL上摸索出来的习惯。第一，所有项目工程目录都放在/root/autodl-tmp，和系统盘隔离，这样系统盘即使出问题也不会影响代码和数据。第二，每次长时间运行任务之前，先做一次磁盘清理，用df -h确认空间充足，再启动训练，否则跑到一半磁盘满了，整个实验可能前功尽弃。
第三，善用无卡模式。比如安装依赖、处理数据、调试代码这些不涉及GPU的操作，切换到无卡模式下进行，可以大幅降低成本。从无卡模式切回GPU模式只需要关机再开机，数据完全保留，逻辑上无缝切换。
接入Claude API的脚本也一样，建议在无卡模式下开发和调试，跑通了再切换到GPU实例做完整批量任务。这样计算资源才真正花在了刀刃上。AutoDL不是一台简单的服务器，它更像是按天租用的远程工作台，关键是你要学会管理它的状态和数据，而不是一直被各种小问题打断节奏。