磁盘空间预警：清理缓存释放存储空间

磁盘空间预警：清理缓存释放存储空间

在一次例行的模型微调任务中，某团队使用 A10G 实例运行 Qwen2-7B 的 QLoRA 微调脚本，系统盘初始可用空间约 50GB。然而，训练进行到第三个 epoch 时，进程突然中断，日志报出一个熟悉的错误：

OSError: [Errno 28] No space left on device

这不是第一次发生这类问题——尽管他们已经多次扩容磁盘、优化代码，但“磁盘满”依然像幽灵一样反复出现。最终排查发现，真正吞噬空间的并非模型本身，而是那些被忽视的中间产物：检查点、分词器缓存、Arrow 数据快照……这些由现代大模型工具链自动生成的临时文件，在无人干预的情况下悄然堆积成山。

这正是当前大模型开发中的典型困境：随着 LLM 和多模态模型参数规模突破百亿甚至千亿，单个权重文件动辄数十 GB；而诸如 ms-swift 这类高度集成的开发框架虽然极大提升了研发效率，却也让存储管理变得更加隐蔽和复杂。开发者在享受“一键下载、自动训练”的便利时，往往忽略了背后持续增长的磁盘负担。

框架机制与缓存生成路径

ms-swift 是魔搭社区推出的大模型全链路开发框架，支持从模型拉取、微调、量化到推理部署的一站式操作。其核心设计理念是通过标准化配置驱动整个生命周期，用户只需编写 YAML 文件即可完成复杂任务。这种抽象带来了极高的开发效率，但也意味着许多底层行为（如缓存写入）对用户透明化。

当执行如下命令时：

swift download --model Qwen/Qwen2-7B-Instruct

ms-swift 会自动完成以下动作：

1. 查询 ModelScope API 获取模型元信息；
2. 若本地无缓存，则从远程仓库下载.bin或.safetensors权重文件；
3. 将 tokenizer、config、special_tokens_map 等配套资源一并保存至默认目录；
4. 后续调用直接读取~/.cache/modelscope/hub/下的缓存，避免重复传输。

类似地，在启动微调任务时，框架会根据配置创建输出目录（output_dir），并周期性保存 checkpoint。每个 checkpoint 包含完整的模型状态字典（state_dict），即使采用 LoRA 等轻量微调方法，若未设置保留限制，仍可能累积多个版本，占用数 GB 以上空间。

此外，数据集加载过程也会产生额外开销。例如使用load_dataset("mydata")时，Hugging Face Datasets 库会将原始格式转换为 Arrow 缓存以加速后续迭代，这部分内容通常存放在~/.cache/huggingface/datasets/，体积可达原始数据的 1.5 倍以上。

缓存类型与典型占用分析

注：以上数据基于实测案例及官方文档整理（https://swift.readthedocs.io）

可以看到，除了原始模型外，检查点和数据集缓存是最主要的空间贡献者。尤其在实验探索阶段，频繁试错会导致大量中间成果滞留磁盘，形成“存储黑洞”。

更值得注意的是，部分云实例（如竞价型 ECS）仅提供有限的本地 SSD 存储，且不具备持久性。在这种环境下，缓存既不能长期保留，又容易因任务密集导致瞬时爆满，进而引发 I/O 阻塞或容器崩溃。

如何识别关键缓存源？

要有效管理磁盘空间，第一步不是盲目删除，而是精准定位高占用项。以下是几种实用的诊断方式：

1. 使用du快速扫描大目录

# 查看前十大占用目录 du -h ~/.cache | sort -hr | head -10 # 统计 modelscope 总占用 du -sh ~/.cache/modelscope/hub/models/

2. 结合find定位特定模式文件

# 查找所有大于 1GB 的文件 find ~/.cache -type f -size +1G -exec ls -lh {} \; # 列出最近三天修改过的 checkpoint 目录 find ./output -name "checkpoint-*" -mtime -3

3. 利用 Hugging Face 官方工具管理缓存

# 显示当前缓存统计 huggingface-cli cache info # 删除指定数据集缓存 huggingface-cli cache remove --dataset my_dataset_name # 清空全部缓存（谨慎操作） huggingface-cli cache clear

这些命令能帮助你快速掌握缓存分布情况，避免误删正在使用的模型。

自动化清理策略设计

与其等到磁盘告警再手动介入，不如提前构建预防机制。以下是几个经过验证的工程实践方案。

事前：加入磁盘健康检查

在任何训练脚本启动之初，应先校验可用空间是否满足最低要求：

#!/bin/bash MIN_DISK_SPACE_GB=20 CURRENT_FREE=$(df /home --output=avail -B1G | tail -1) if [ "$CURRENT_FREE" -lt "$MIN_DISK_SPACE_GB" ]; then echo "ERROR: Only $CURRENT_FREE GB free, need at least $MIN_DISK_SPACE_GB GB" exit 1 fi

注意：此处建议针对具体挂载点（如/home或/mnt/data）而非根目录/，防止系统盘干扰判断。

事中：控制中间产物数量

在训练过程中主动限制缓存生成量，是最高效的节流方式。

设置最大保存 checkpoint 数量

training_args = TrainingArguments( output_dir="./output", save_total_limit=3, # 只保留最新3个，旧的自动删除 save_steps=500, ... )

该参数由 Hugging Face Transformers 提供支持，启用后每次保存新 checkpoint 时会自动清理最老的一个。

使用流式加载避免 Arrow 缓存

dataset = load_dataset("my_large_dataset", streaming=True)

启用streaming=True后，数据不会被缓存为 Arrow 格式，而是按需读取，显著降低磁盘压力，适合一次性训练场景。

关闭冗余日志写入

training_args = TrainingArguments( logging_dir=None, # 不生成 TensorBoard 日志 run_name=None, # 不创建 runs 子目录 ... )

对于短期实验，可关闭非必要日志输出，减少零碎文件积累。

事后：建立统一清理流程

任务结束后，及时回收资源是保障环境可持续性的关键。

编写专用清理脚本

#!/bin/bash echo "开始清理缓存..." # 清理 modelscope 模型缓存（保留配置） rm -rf ~/.cache/modelscope/hub/models/* # 清理 huggingface 数据集缓存 huggingface-cli cache remove --confirm # 删除除 final_model 外的所有 checkpoint find ./output -name "checkpoint-*" -type d -exec rm -rf {} \; # 清理临时目录 rm -rf ./tmp/* ./runs/* echo "清理完成"

可将其封装为cleanup.sh并纳入 CI/CD 流程，确保每次运行后自动执行。

利用软链接分离存储路径

将默认缓存目录映射到独立数据盘，既能缓解系统盘压力，也便于集中管理：

# 创建外部存储挂载点 mkdir -p /mnt/data/cache/modelscope # 建立软链接 ln -sf /mnt/data/cache/modelscope ~/.cache/modelscope/hub

此后所有 modelscope 下载内容都将落盘至大容量 SSD，不影响主系统稳定性。

配置定时清理任务

对于长期运行的服务节点，可通过 cron 实现自动化维护：

# 每日凌晨两点清理超过7天的 checkpoint 0 2 * * * find /home/user/output -name "checkpoint-*" -mtime +7 -exec rm -rf {} \; # 每周日清理旧日志 0 3 * * 0 find /home/user/logs -name "*.log" -mtime +30 -delete

这类策略特别适用于共享服务器或多用户环境，防止个别用户无意识占用公共资源。

工程最佳实践建议

结合实际项目经验，我们总结出以下几条高价值的设计原则：

1. 分离系统盘与数据盘

始终将模型缓存、输出目录挂载至独立的数据盘（如 NVMe SSD 或网络存储）。推荐最小配比：
- 系统盘：80~100GB（仅存放 OS 和基础依赖）
- 数据盘：≥500GB（用于缓存、checkpoints、日志等）

2. 实施分级保留策略

根据不同阶段设定不同的缓存保留规则：
-开发调试期：保留最近 3 天内的所有中间结果，便于复现实验；
-测试验证期：仅保留最佳模型和对应日志；
-生产部署期：只保留最终量化后的推理模型，其余全部清除。

3. 引入缓存成本意识

在云端按量计费场景下，存储不仅是技术问题，更是成本问题。一块 1TB 的 ESSD 云盘每月费用可达数百元。定期清理无效缓存，不仅能避免任务失败，还能直接实现“降本增效”。

4. 多人协作环境下的权限管理

在共用服务器上，.cache目录可能被多个用户交叉写入。建议：
- 为每位用户分配独立 home 目录；
- 使用 group 权限控制共享缓存访问；
- 定期审计大文件归属，防止“缓存侵占”。

最终思考：高效开发 ≠ 放任自流

ms-swift 这类现代化大模型框架确实让“几分钟启动一个训练任务”成为现实。它集成了 600+ 纯文本模型和 300+ 多模态模型的支持，兼容 LoRA、QLoRA、DoRA 等轻量微调方法，并打通了从训练到 vLLM 推理的完整链路。这种高度封装极大降低了入门门槛。

但正因其自动化程度高，反而更容易让人忽略底层资源消耗。真正的工程能力，不在于能否跑通模型，而在于能否稳定、可持续地运行系统。

一次成功的微调任务，不应止步于 loss 曲线下降，还应包括合理的资源回收。将磁盘监控、缓存清理纳入标准工作流，就像写单元测试一样，是一种必要的职业习惯。

未来，随着 MoE 架构、长上下文建模等技术普及，中间缓存的复杂度只会更高。提前建立科学的存储管理机制，不仅是为了应对今天的磁盘告警，更是为明天更大规模的挑战做好准备。

那种高度集成的设计思路，正引领着智能音频设备向更可靠、更高效的方向演进。