幸运小姐我最早意识到"默认目录"这个事有多坑，是在帮朋友排查一台 CentOS 7.9 服务器的时候。那台机器配置不算差，内存 64G，GPU 是 A100，根分区给了 120G，怎么看都够跑个 7B 模型。结果 snapshot_download 下载到一半直接报磁盘不足，df -h 一看，/ 已经 100% 占满，再一查，好家伙，ModelScope 默认把模型全下载到了 ~/.cache/modelscope/hub 下，而他是 root 登录，~ 就是 /root，一个 70 多 G 的模型文件直接把我拍死在沙滩上。
这个坑其实特别隐蔽。ModelScope 不像有些工具会在日志里打印"模型已下载到 /xx/xx 目录"，它静默写到默认缓存路径，服务器跑到一半磁盘爆了才发现。所以这篇文章我打算把 CentOS 系统下 ModelScope 模型下载的默认目录规则、迁移方法、磁盘排查思路、以及一堆和下载目录相关的周边问题一次讲透。不管你是刚入门的小白，还是已经被磁盘搞到头秃的老运维，这份内容应该都能帮到你。
1. ModelScope 下载模型的默认目录到底在哪
先说结论，ModelScope Python SDK 安装后，默认模型缓存目录遵循一个固定的规则：
code复制~/.cache/modelscope/hub
其中 ~ 是当前执行 Python 脚本的操作系统用户的 HOME 目录。如果你是 root 执行，那就是 /root/.cache/modelscope/hub；如果是普通用户 work，那就是 /home/work/.cache/modelscope/hub。这一点和 Hugging Face 的 ~/.cache/huggingface/hub 非常像，ModelScope 在设计上明显参考了类似的缓存机制。
往下拆一层，hub 目录内部的布局也有规律。ModelScope 会按照模型 ID 的组织结构来分层存放。比如你下载模型 ID 为 qwen/Qwen2.5-7B-Instruct 的模型，那么实际文件会放在：
code复制~/.cache/modelscope/hub/models/qwen/Qwen2.5-7B-Instruct/
也就是说，模型 ID 中的"组织名/模型名"会被解析成目录层级，但在最前面加了一层 models。如果你下载的是某个数据集，则是 datasets，比如：
code复制~/.cache/modelscope/hub/datasets/zhangpeng/data_demo/
模型目录下还有快照版本的概念。ModelScope 借鉴了 Git LFS 和 Hugging Face 的快照机制，下载的模型会带一个版本目录或者快照标识，同一模型多次下载不同版本时，不同版本之间会分目录存放，避免相互覆盖。不过日常使用中，大多数用户只下载 master 分支或默认版本，所以看到的结构通常比较简洁。
如果你是第一次接触这个目录，建议先做一个自查操作，确认当前机器上的实际路径：
bash复制# 查看 modelscope 缓存根目录占用
du -sh ~/.cache/modelscope
# 查看已经下载了哪些模型
find ~/.cache/modelscope/hub -maxdepth 3 -type d | head -50
# 如果想看具体的模型文件大小
du -sh ~/.cache/modelscope/hub/models/*/*/
执行之后你会发现，模型文件的真实体积往往比你在模型主页看到的要大。因为很多模型页标注的是权重文件的大小，实际下载后还要算上分片文件、配置文件、tokenizer 文件、甚至是一些临时下载残留。多模型累积下来，缓存目录变成磁盘杀手一点都不奇怪。
还有一个容易误判的地方：ModelScope 的下载和支持库版本没关系。不管你是用 pip install modelscope 装的最新版，还是某个旧版本，默认缓存路径在逻辑上是一致的，都走 ~/.cache/modelscope 这个根。区别只是不同版本对目录内部的快照管理和临时文件清理策略不同，但大方向不变。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么这个目录在 CentOS 上特别容易引发事故
默认目录在哪个系统上都存在，但 CentOS 环境下它尤其危险，我总结下来有三个现实原因。
第一，CentOS 服务器大多是传统分区习惯。很多运维老哥（包括我早年）安装系统时喜欢把 /boot 给 200M，/ 给 50G 或者 80G，/home 独立分区，然后单独挂一个 /data 大分区放业务数据。这种分区方案的出发点是好管理、好备份，但它有一个致命点：**