存储用量高这个提示弹出来的时候多数人手上正压着一个训练任务。你可能刚把几十 G 的数据集解压完准备跑第一轮 epoch结果 AutoDL 实例开机失败、JupyterLab 打不开文件、或者训练跑到一半写 checkpoint 的时候直接抛No space left on device。今天这篇就专门讲 AutoDL 存储用量高这件事它到底卡在哪一层、怎么在五分钟内把真正的空间占用方找出来、哪几个目录是常年的重灾区、以及怎么从根上把存储变成一个可控的变量而不是随缘爆炸的定时器。内容偏实操命令可以直接复制跑适合刚上手租卡跑实验的同学也适合已经踩过一两次坑但没搞明白原理的老用户对照排查。1. 先把账算明白AutoDL 的存储到底分几块想把存储问题解决掉第一步不是敲删除命令而是搞清楚你在跟什么东西打交道。很多人一看到存储用量高就下意识去删文件删了半天提示还在原因是删错了地方——AutoDL 的存储不是一块硬盘而是分成几个独立计费、独立配额的区域你清空 A 区域对 B 区域的告警毫无帮助。1.1 系统盘、数据盘、文件存储三者不是一回事一台 AutoDL 实例开出来之后你至少会接触到三个存储位置各自的定位完全不同。系统盘是跟着镜像走的那部分装系统、装 conda 环境、装 CUDA 驱动都在这里。它的容量是固定的通常比较小属于够用但不宽裕的定位。系统盘的特点是你把数据放这儿它会很快满而且系统盘写满之后麻烦更大因为连日志、临时文件、进程锁都写不进去表现就是各种莫名其妙的服务起不来。数据盘是真正的干活区域一般挂载在/root/autodl-tmp这个路径下。数据集、模型权重、checkpoint、训练日志理论上都应该往这里放。数据盘的容量可以扩属于按量付费的部分也是存储用量高这个提示最常见的指向对象。文件存储很多人习惯叫网盘是跨实例共享的那一层通常挂在/root/autodl-fs之类的路径。它的价值在于你在 A 实例上传的数据B 实例能直接读到不用重复传一遍几十 G 的东西。但它同样有容量配额而且计费方式和数据盘不一样。这三者的关系用生活场景类比就是系统盘是你家里的玄关地方小但每天进出都要经过数据盘是你家的储物间能扩但租金按面积算文件存储是小区门口的共享仓多家都能取但你也得按占用付钱。你把储物间塞满了玄关不会报警但你要把玄关堵死了人连门都出不去。动手之前先跑一条命令确认挂载情况df -h输出里你会看到/、/root/autodl-tmp、/root/autodl-fs这几个条目分别对应系统盘、数据盘、文件存储。看清楚每个的Size、Used、Avail、Use%你就知道告警到底来自哪一层了。这一步千万不要跳过我见过太多人折腾半天最后发现是文件存储满了跑去数据盘删了一堆东西。注意不同镜像、不同实例形态下挂载点和容量都可能不一样上面提到的路径是常见情况。一切以你自己df -h的实际输出为准不要照着我写的路径硬删。1.2 为什么我明明删了文件空间却没释放这是存储排查里最经典的一个坑值得单独拎出来说。Linux 的文件删除机制是引用计数式的rm一个文件只是把它从目录项里摘掉真正占用的磁盘块要等所有打开这个文件的进程都关闭句柄之后才会被回收。所以如果你删的是一个正在被训练进程写入的日志文件、正在被 TensorBoard 读的事件文件、或者某个 Python 进程还 hold 着的临时文件du看到的目录大小会变小但df看到的已用空间纹丝不动。判断方法很简单lsof L1 2/dev/null | head -20这条命令列出所有已删除但仍有进程持有的文件。如果lsof没装退而求其次可以扫一遍/procfor pid in /proc/[0-9]*; do ls -l $pid/fd 2/dev/null | grep deleted done | head -20看到这类条目处理办法只有两个要么把对应进程杀掉kill -9 pid要么让它自己正常退出。杀掉之后空间立刻回来。这个现象在训练场景里出现频率极高因为大多数训练框架的日志是 append 模式写一个固定文件名的你以为删掉了重启就干净了其实老进程还在写那个已经不存在的 inode。1.3 空间被吃掉的六个高频黑洞在真正动手清理之前先建立一张嫌疑犯清单按经验命中率从高到低排排名占用源典型路径特点1模型权重缓存~/.cache/huggingface、~/.cache/modelscope单个模型动辄几个 G反复下载不同变体会叠加2checkpoint 堆积项目目录下的ckpt、checkpoints每个 epoch 存一份很快就上几十 G3数据集原始包与解压副本/root/autodl-tmp/data压缩包没删解压后又一份等于双倍占用4conda / pip 缓存~/anaconda3/pkgs、~/.cache/pip装环境时装过的包全留着几个 G 起步5训练日志与事件文件runs/、logs/、*.tfevents.*单文件不大但数量多长期训练能堆到十几个 G6临时文件与残留/tmp、~/.cache/torch、__pycache__不起眼但零碎小文件多了还会拖慢遍历这张表建议你直接存下来下次告警先按这个顺序查八成问题在前三项里就能定位到。2. 五分钟定位把占用查清楚再动手清理这件事最忌讳觉得应该是它。上来就rm -rf一通运气好清掉了运气不好把好不容易训出来的权重删了哭都来不及。正确姿势是先测量、再决策、最后动手。2.1 三条命令摸清家底我自己的排查流程固定是三步加起来不超过两分钟。第一步看总量df -h重点看Use%那一列以及Avail还剩多少。顺便看一眼df -iinode 用满的情况虽然少见但在小文件极多的场景比如几百万张图片的数据集确实会遇到表现出来的症状也是空间还有但写不进去。第二步从根往下扫一层找出最大的目录sudo du -h --max-depth1 / 2/dev/null | sort -rh | head -20这里--max-depth1是关键不加这个参数du会递归遍历整棵树在几十万文件的目录上能跑十几分钟。只扫一层先锁定是哪个一级目录大然后往下钻。第三步在锁定的目录里继续下钻du -h --max-depth1 /root/autodl-tmp 2/dev/null | sort -rh | head -20三步走完基本就能看到凶手了。如果还想更快装个ncdu交互式磁盘占用分析工具方向键就能浏览比du直观得多apt-get update apt-get install -y ncdu ncdu /root/autodl-tmpncdu的好处是能直接在里面按d删除文件省得来回敲路径。缺点是首次扫描大目录也要花点时间建议只在已经缩小到某个子目录之后再用。提示du统计的是文件实际占用ls -l看的是文件逻辑大小两个数字在大文件稀疏存储或压缩文件系统上可能对不上。排查存储一律以du和df为准。2.2 找大文件比找大目录更直接有时候空间是被几个巨型文件吃掉的比如一个 30G 的单体数据集压缩包、一个 20G 的合并权重文件。这种情况按目录下钻效率很低直接按大小筛文件更快find /root/autodl-tmp -type f -size 1G -exec ls -lh {} \; 2/dev/null | awk {print $5, $9} | sort -rh | head -30这条命令会列出数据盘下所有大于 1G 的文件按大小倒序。看到那个 20G 的xxx.tar你就知道该干什么了。还有一种情况是文件数量爆炸。比如某个目录下堆了 50 万张 10KB 的小图du统计出来才 5G但遍历一次要等半天训练时的 DataLoader 也会被拖垮。查一下各目录的文件数for d in /root/autodl-tmp/*/; do echo -n $d ; find $d -type f | wc -l; done | sort -k2 -rn | head文件数超过十万的目录就要考虑换存储格式了比如打包成tar、lmdb、webdataset的 shard读取效率会有质的提升索引开销也小得多。2.3 一个能直接跑的巡检脚本每次手动敲命令还是麻烦我一般会在数据盘根目录放一个巡检脚本随时跑一下看状态#!/bin/bash # save as /root/autodl-tmp/check_space.sh echo 磁盘总览 df -h | grep -E Filesystem|/$|autodl echo echo inode 使用 df -i | grep -E Filesystem|/$|autodl echo echo autodl-tmp 一级目录 TOP10 du -h --max-depth1 /root/autodl-tmp 2/dev/null | sort -rh | head -10 echo echo 大于 2G 的文件 find /root/autodl-tmp -type f -size 2G 2/dev/null | head -20 echo echo 删除未释放句柄 lsof L1 2/dev/null | head -10 echo echo 各类缓存体积 du -sh ~/.cache/pip ~/.cache/huggingface ~/.cache/torch \ ~/anaconda3/pkgs /tmp 2/dev/null赋权之后chmod x check_space.sh需要的时候./check_space.sh一把梭。养成习惯之后你对这台实例的空间变化会非常有数不会等到告警了才手忙脚乱。3. 逐项清理六个场景的实操手法定位到元凶之后接下来就是清理。不同来源的处理方式差别很大有些能一键清空有些必须谨慎下面按命中率从高到低逐个说。3.1 模型权重缓存最容易失控的一块Hugging Face 和 ModelScope 的缓存是存储黑洞排行榜的常客。你从 hub 上from_pretrained拉一个模型它会下载到~/.cache/huggingface/hub下面而且是按 commit 哈希存目录。同一个模型下载两个版本、或者不同代码路径拼错了模型名导致重复下载缓存就会翻倍。先看有多大du -sh ~/.cache/huggingface ~/.cache/modelscope 2/dev/null du -h --max-depth1 ~/.cache/huggingface/hub 2/dev/null | sort -rh | head -20清理策略分两档。第一档是清掉下载失败的临时文件和旧版本rm -rf ~/.cache/huggingface/hub/**/blobs/*.incomplete rm -rf ~/.cache/huggingface/hub/**/.no_exist第二档是只保留当前任务要用的模型其余全清。这一步要想清楚别把正在跑的模型删了——先把models--xxx--yyy的目录名列出来对一遍自己代码里的模型名确认之后再用rm -rf。更根本的做法是从一开始就把缓存指到数据盘别占用系统盘export HF_HOME/root/autodl-tmp/cache/huggingface export MODELSCOPE_CACHE/root/autodl-tmp/cache/modelscope export TORCH_HOME/root/autodl-tmp/cache/torch把这几行写进~/.bashrc以后所有下载都落在数据盘上。这个改动的意义不只是换个位置——系统盘空间小且不可扩一旦被缓存撑满问题会从存储告警升级成环境彻底不可用处理成本高得多。注意改HF_HOME之后之前已经下在旧路径的缓存不会自动搬过去需要手动mv或者直接删掉重下。用mv之前确认目标盘空间够别搬一半又满了。3.2 checkpoint 堆积训练脚本的锅checkpoint 是训练过程里最合理的存储消耗也是最容易失控的。很多开源训练脚本默认每个 epoch 存一次甚至每 N 个 step 存一次还带save_total_limit这种参数——但如果你用的脚本恰好没设置或者手动改过那就会无上限堆。先看一眼du -sh /root/autodl-tmp/**/checkpoint* 2/dev/null ls -lh /root/autodl-tmp/**/checkpoint*/ 2/dev/null | head -30清理原则是最新的 最优的留下中间过程全删。很多时候你只需要最终模型和最后一次 checkpoint用于断点续训中间那些checkpoint-500、checkpoint-1000的价值相当有限。如果是 Hugging Face Trainer 体系直接在训练参数里加TrainingArguments( output_dir/root/autodl-tmp/exp1, save_strategysteps, save_steps2000, save_total_limit2, # 只保留最新 2 个 load_best_model_at_endTrue, # 结束时只留最优 save_safetensorsTrue, # 用 safetensors 省一半空间 )save_total_limit这个参数是最省事的框架会自动删掉超出的旧 checkpoint。save_safetensorsTrue也值得开同样的权重用 safetensors 存比pytorch_model.bin小一些加载还快。如果是自己写的训练循环那就得手动管import os, glob, shutil def clean_old_ckpts(ckpt_dir, keep2): ckpts sorted(glob.glob(os.path.join(ckpt_dir, ckpt-*)), keylambda p: int(p.split(-)[-1])) for c in ckpts[:-keep]: shutil.rmtree(c, ignore_errorsTrue)在每个 epoch 结束、存完新 checkpoint 之后调一次逻辑简单但非常有效。这类自动化清理比想起来再删可靠得多因为训练跑起来之后你根本不会盯着磁盘看。3.3 数据集压缩包和解压副本的双份占用数据集相关的浪费有两个典型形态。第一种是上传了data.zip又解压出data/压缩包忘了删等于双份占用。第二种是同一份数据在多个项目目录下各拷了一份明明可以软链接解决。查压缩包find /root/autodl-tmp -type f \( -name *.zip -o -name *.tar -o -name *.tar.gz -o -name *.7z \) -size 500M -exec ls -lh {} \;确认解压完整、数据可用之后压缩包就该清掉了。如果担心以后还要用可以只保留压缩包、删掉解压目录——训练的时候现场解压用tar -xf直接流式读或者用zstd压缩格式压缩率高、解压速度比 gzip 快一个量级。查重复数据find /root/autodl-tmp -type d -name data* -exec du -sh {} \; 2/dev/null如果发现多个目录下都有同名同大小的数据集用软链接统一ln -s /root/autodl-tmp/shared/data /root/autodl-tmp/exp1/data软链接只占几个字节但要注意别搞成循环链接也别在打包备份的时候把链接当成实体文件展开。3.4 conda 和 pip装一次环境留三个 Gconda 的包缓存默认不清conda install装过的每一个版本的包都留在pkgs目录里。跑过几个项目的实例这个目录轻松上 5G。du -sh ~/anaconda3/pkgs ~/.cache/pip 2/dev/null conda clean -a -y pip cache purge rm -rf ~/.cache/pipconda clean -a会清掉包缓存、索引缓存、未使用的 tar 包一次能回收不少。这个操作是安全的已经装好的环境不受影响只是下次装同样的包要重新下载。还有一类是环境本身占空间。很多人喜欢给每个项目建一个独立 conda 环境每个环境装一份 PyTorch一个环境 5G十个环境就是 50G。更省的做法是用一份基础环境 额外的 requirements 覆盖或者用venv复用系统级包--system-site-packages。如果确实需要多环境装完就conda clean别让缓存跟着涨。实操心得清完缓存之后跑一次python -c import torch; print(torch.__version__)验证一下环境没坏。绝大多数情况没事但极少数情况下某个包是从缓存里软链接过去的清缓存会把它搞坏验证一下更稳妥。3.5 日志与事件文件单个不大但架不住多TensorBoard 的events.out.tfevents.*文件、训练输出的train.log、各种nohup.out这些属于润物细无声型占用。单个文件可能只有几十 M但一天跑十次实验、每次生成一个事件文件一个月下来就是几个 G。du -sh /root/autodl-tmp/**/runs 2/dev/null find /root/autodl-tmp -name events.out.tfevents.* -size 100M -exec ls -lh {} \; 2/dev/null日志的处理不是一删了之而是分级。当前正在跑的实验日志留着已经跑完、结论记下来的把关键指标摘出来存成 csv 或 md原始事件文件删掉调试阶段的nohup.out直接清空。清空日志用truncate而不是rm特别是当训练进程还在往那个文件写的时候truncate -s 0 /root/autodl-tmp/exp1/nohup.outtruncate会把文件大小归零但不改变 inode正在写的进程不会报错句柄也依然有效。这个技巧在处理日志把盘写满了但训练还不能停的场景特别好用我一直把它当成应急手段。对于历史日志可以加一条定时清理只保留最近七天的find /root/autodl-tmp -name *.log -mtime 7 -delete3.6 隐藏文件的排查看不见的地方最费劲前五类都是你看得见摸得着的还有一类是看不见的以点开头的目录、容器层的残留、被chmod 000保护的文件。du -sh /root/autodl-tmp/.[!.]* 2/dev/null du -sh /tmp/* 2/dev/null | sort -rh | head du -sh ~/.cache/* 2/dev/null | sort -rh | head -15/tmp目录经常被忽略但有些库比如某些数据处理框架、编译工具会往这里写大量临时文件进程异常退出后不清理慢慢积起来。还有一类是__pycache__和.pyc文件。单个很小但在有几千个 py 文件的项目里能占几百 Mfind /root/autodl-tmp -type d -name __pycache__ -exec rm -rf {} 2/dev/null find /root/autodl-tmp -name *.pyc -delete 2/dev/null清__pycache__是完全安全的Python 下次运行会重新生成只是首次启动稍慢一点点。4. 治本把存储变成可控的变量上面讲的都是救火。真正省心的做法是把存储管理前置让它在设计上就不会失控。这部分内容看起来不如命令行直接但长期收益大得多。4.1 目录约定从第一天就把位置放对我给自己定了一套固定约定每个新实例开出来先建好目录结构后面所有东西对号入座/root/autodl-tmp/ ├── shared/ # 跨项目复用的数据集、基座模型只读 ├── cache/ # HF_HOME、TORCH_HOME 统一指到这里 ├── exp/ # 每个实验一个子目录 │ └── 20240101_lr1e4/ │ ├── ckpt/ # 按 save_total_limit 轮转 │ ├── log/ │ └── code/ └── tmp/ # 中间产物随时可删这套结构的价值在于清空间的时候你知道该动哪里。shared和cache是共享的动之前要确认没有其他实验在用exp下面每个实验独立跑完整个目录打个包下载走本地留档之后整目录删掉tmp随便清没有任何心理负担。配套的第一条命令是设环境变量cat ~/.bashrc EOF export HF_HOME/root/autodl-tmp/cache/huggingface export TORCH_HOME/root/autodl-tmp/cache/torch export MODELSCOPE_CACHE/root/autodl-tmp/cache/modelscope export PIP_CACHE_DIR/root/autodl-tmp/cache/pip export TMPDIR/root/autodl-tmp/tmp EOF source ~/.bashrc最后那个TMPDIR很多人会忽略。Python 的tempfile模块、部分数据处理库、甚至某些编译过程都依赖TMPDIR默认指向系统盘的/tmp。把它指到数据盘既避免了系统盘被临时文件撑爆也让清理变得集中。4.2 训练流程内置清理让它自己管自己人工清理的可靠性取决于你记不记得清理。更稳的做法是把清理逻辑写进流程里跑完自动执行。如果用的是 shell 脚本起任务可以在末尾加一段#!/bin/bash set -e EXP_DIR/root/autodl-tmp/exp/$(date %Y%m%d_%H%M) mkdir -p $EXP_DIR/{ckpt,log} python train.py --output_dir $EXP_DIR/ckpt 21 | tee $EXP_DIR/log/train.log # 训练结束自动清理 find $EXP_DIR/ckpt -name checkpoint-* -type d | \ sort -t- -k2 -n | head -n -2 | xargs -r rm -rf rm -rf /root/autodl-tmp/tmp/* find /root/autodl-tmp/cache -type f -name *.incomplete -delete这里的head -n -2表示除了最后两个其他的都选出来删掉配合sort按编号排序就能实现只留最新两个 checkpoint。如果跑的是 JupyterLab 交互式实验那就用 Python 里面包一层try/finally把清理逻辑放在finally里保证异常退出也能执行try: train() finally: clean_old_ckpts(CKPT_DIR, keep2) cleanup_tmp()这个写法比训练成功才清理要稳妥因为训练崩掉的时候恰恰是最容易留下一堆垃圾的时候。4.3 存储额度与扩容的决策时机当清理做到位了还是不够用那就该考虑扩容或者换存储层了。这里有几点判断逻辑值得说清楚。第一先算清楚真实需求是多少。把当前数据盘占用拆成三块必须常驻数据集、基础模型、过程产物checkpoint、日志、可清理缓存、临时文件。只有第一块是硬需求第二块可以通过策略压缩第三块应该接近零。很多人的空间不够实际上是第二三块占了七成。第二如果要扩容注意扩容通常是单向的。绝大多数云平台的存储扩容之后不支持缩回去做决定之前把未来三个月的实验规模想清楚。宁可一次扩到位也别扩了又扩。第三善用分层。基础模型、公共数据集放文件存储跨实例共享一份不用每个实例各存一遍。过程产物放数据盘随实例走。这个分层的效果在小规模实验上不明显一旦你同时开两三个实例做对比实验节省立刻体现出来。还有一点很重要关机不等于不占存储。实例关机之后算力费用停了但数据盘上的东西还在存储该占还是占、该计费还是计费。所以做完实验、数据下载到本地之后该释放的实例就释放掉别让它挂在那儿吃灰。这个细节看着小但一个月下来差别不小。4.4 无卡模式的正确打开方式整理数据、清理文件这些事情其实不太需要 GPU。用无卡模式开机成本低很多而且整理起来没有任何心理压力——反正不占卡。我的常规操作流程是无卡模式开机 → 传数据、清理空间、验证环境 → 关机 → 有卡模式开机 → 直接跑训练。这样做的好处是把等待上传和等待算力这两件事解耦了上传 50G 数据集的两个小时里不占用昂贵的 GPU 时间。无卡模式下还能做的一件很有价值的事是验证脚本能不能跑通。把训练命令里的 epoch 改成 1、把 batch size 改成极小值在无卡模式下跑一遍确认路径没问题、依赖没缺失、数据能正常读取。这一步能过滤掉大部分开卡跑了十分钟才发现路径写错了的低级失误。提示无卡模式下有些依赖 GPU 的代码会直接报错验证时记得把相关逻辑跳过或者加上--dry_run之类的开关别把没有 GPU的报错误判成代码有问题。5. 常见问题速查与踩坑实录前面讲的是体系和流程这一节把高频问题整理成表方便你直接对照。5.1 问题速查表现象可能原因排查命令处理方式删了文件df没变化进程仍持有句柄lsof L1杀掉对应进程提示空间不足但df显示还有inode 用尽df -i清理小文件密集目录开机失败提示存储超限数据盘或文件存储配额满df -h清理或扩容训练中断No space left系统盘或数据盘写满df -hdu下钻清缓存、清 ckpt上传数据总是失败目标目录所在盘满了df -h换到有空间的路径du和df数字对不上有已删除未释放的文件lsof L1重启相关进程目录文件不多但遍历极慢小文件过多find ... | wc -l打包成 lmdb/tar 格式环境装完莫名坏了清了 conda pkgs 缓存python -c import xxx重装受影响包5.2 几个我实打实踩过的坑坑一在系统盘上解压数据集。刚上手的时候没注意路径直接在/root下unzip解压到 80% 的时候系统盘满了表现不是磁盘满的提示而是 JupyterLab 直接失联、SSH 上去也各种命令报错。后来才明白系统盘满了连日志都写不进去服务自然起不来。恢复方法只能是通过文件管理界面把大文件删掉。从那以后我所有解压操作第一件事是cd /root/autodl-tmp。坑二以为删了 checkpoint 就等于释放。训练进程还在跑我用另一个终端把旧的 checkpoint 目录rm -rf了du显示目录确实没了但df一点没变。查了半天才发现训练进程还持有那些文件的句柄。这种时候要么等它写完这一轮自动关闭要么就接受空间要过一会儿才回来。坑三缓存路径改晚了。一开始没设HF_HOME模型全下在系统盘的~/.cache里。意识到问题的时候系统盘已经用掉 80% 了搬移又是一轮折腾。正确的顺序是实例开出来第一件事就把环境变量配好再开始下载任何东西。坑四rm -rf通配符写错。这个最惊险。本来想删ckpt/checkpoint-*目录下的旧文件手抖删成了ckpt/*把最新那个也删了。教训是带通配符的删除命令先ls一遍看看匹配结果确认无误再把ls换成rm -rf。这个习惯值一条命。坑五压缩包和解压目录并存了三个月。一个 40G 的数据集压缩包留着以防万一解压目录也在用。等于白占 40G。后来想明白了数据集下载源还在真需要重下就行压缩包留着毫无意义。现在我的规则是解压完立刻删压缩包除非源链接已经失效。5.3 一个建议把存储当成实验的一部分来管理最后分享一个观念上的转变。刚开始跑实验的时候我只关心 loss 曲线和指标存储是出了问题再说的东西。后来实验规模上去、同时开几个实例之后我意识到存储其实和超参数一样是实验设计的一部分——你得为它预留预算、制定策略、设定清理时机。具体做法是把存储检查写进实验 checklist开实例先df -h记录基线训练启动前确认HF_HOME等环境变量生效每轮实验结束后跑一次巡检脚本实验数据下载完成后立刻释放实例。这套流程走下来我已经很久没被存储用量高打断过了。真正花时间的从来不是清理本身而是发现得晚——等到训练跑到一半才报错代价就是几小时的算力白花。