桌面端瘦身六成：本地 AI 环境的磁盘账

一次砍掉六成，说明原来的占用里有多少是冗余

ChatGPT 和 Codex 的桌面端把磁盘占用削了大约六成。这类优化背后的逻辑很朴素：客户端为了「下次快一点」，把大量中间数据在本地留了一份，日子久了没人回头清。

有一件事值得你自己算一下。如果某个应用能在不大改功能的前提下瘦身六成，那你机器上其它同样积累了一两年的东西，大概也有同比例的冗余。

这篇不讲某个具体软件的设置项，讲的是一套通用顺序。任何在本地跑 AI 工具的机器都能用。

先看清楚空间花在哪：三类常见的大户

按经验，吃磁盘的一般集中在三处，而且顺序很固定。

第一类是缓存。 桌面端应用的各种缓存目录、浏览器的媒体缓存、包管理器的下载缓存。这一类删了最多变慢，不会坏。

第二类是模型权重。 跑本地出图、本地推理的人，这一块往往占几十到上百 GB。问题不在单个模型太大，在于你装了很多只用了一次的模型。

第三类是容器与环境。 Docker 的镜像层、悬空卷、旧的 Conda 环境、Python 虚拟环境里的依赖。这一类最容易被忽略，因为它藏在工具自己的数据目录里，不在你每天看一眼的那个下载文件夹里。

动手之前，先把「能删」和「不敢删」分开

清理的第一原则是：不要拿「不知道这是啥」当删除依据。误删一次配置文件的代价，远高于它占的那几百 MB。

一个判断办法是看这个目录能不能由工具自动重建。缓存能重建，镜像能重拉，模型权重能重下，只是慢。但你自己写的配置、下载下来的人工交付物、没有任何再生成路径的东西，这些都不能删。

真不建议做的一件事是装一个一键清理软件对着系统目录扫描删除。它在帮你清理的同时会删掉你没法重建的东西，而且你根本不知道删了什么。

第一步：从可重建的缓存开始

这一步风险最低，收益通常也不小。

• 包管理器的下载缓存。Homebrew 的下载缓存、npm 的缓存、pip 的缓存都是纯下载缓存。清掉只会让下一次安装变慢。
• 桌面端与浏览器的缓存。删了之后第一次启动慢一点，属于一次性代价。
• 日志。本地服务开久了，日志文件有时候能涨到几个 GB，尤其是调试级别没关的情况。

删这一层不太需要专业知识，因为它们有一个共同特点：工具下次会自己再建一份。

第二步：模型权重是大头，别急着删，先分级

如果你跑本地生成，这一步可能一次性释放几十 GB。但权重文件下载很慢，删之前要想清楚。

给本地模型做一次分级，比一次性删一半有用。

• 常用的两三个：保留。这几个是你真正每天调用的。
• 偶尔用一次的老模型：移到冷存储。外接固态或者网络盘都行，需要的时候再拷回来，几十 GB 挪一次并不慢。
• 从下载完就没再打开过的：直接删。这类通常你自己也想不起来当时为什么要下。

还有一个容易漏的点。很多工具会把下载过程中的临时文件、中断留下的半截文件丢在一个临时目录里。这种文件常常占着最刺眼的空间，而且一定可以删。

第三步：容器与环境，隐形的大户

容器主机上磁盘爆掉的原因往往不是你主动拉的那几个镜像，而是层层叠加之后、不再被任何容器引用的旧层。

• 先看有没有已经退出的容器还占着卷。 停止不等于清理，退出状态的容器照样占空间。
• 再看有没有无人引用的中间层。 这类在常规列表里名字会显示为空，很容易被跳过。
• 检查构建缓存。 反复构建留下的缓存很可观，清理后下次构建慢一些而已。

用 Python 的同学再补一句：每建一个新虚拟环境就装一套依赖，一年下来会出现十几个彼此重复的环境。删掉不再活跃的那几个，通常能回收几个 GB。养成「项目结束即销毁环境」的习惯，比事后清理省事得多。

Mac 用户额外补一刀

苹果的系统存储统计经常让人困惑，因为那一栏系统数据把所有不好归类的东西都塞进去了。

• 本地快照是最常被忽视的一块。系统在连接外部磁盘时会做快照备份，它们可能不会被算进任何一个应用的占用里。
• 旧设备的完整备份往往几十 GB，而且你可能已经换了两次手机。
• 集成开发环境的派生数据与模拟器。装过的人几乎都会在这里堆出十几 GB。

处理这些的安全做法是走系统自带的管理界面，不要手动去动资源库下面自己看不懂的目录。

把清理变成每周五分钟，而不是每两年一次战争

真正有效的不是一次性大清理，是不让它再长回来。

• 每周一次：只看可重建缓存，一两分钟删掉。
• 每月一次：做容器与环境的盘点，删掉这个月建出来的临时环境。
• 每季度一次：看一眼模型目录，把三个月没碰的文件挪到冷存储。

维持这件事的成本极低。代价高昂的是那个循环：磁盘告急、紧急查找、慌乱删除、最后删错东西。

固态盘寿命这件事要不要管

清理的时候常听到一个顾虑：频繁删写会不会伤盘。这个担心可以理解，但对正常使用来说基本不必放在心上。

消费级固态盘有自己的写入寿命标定，日常的软件安装卸载、缓存重建，离那个上限远得很。真正明显消耗寿命的是持续高吞吐写入，比如天天跑大型数据集训练、做视频素材批量转码。

如果你是后面这类用户，要做的事也简单：把高频读写的临时目录放在余量充足的分区上，长期保持百分之十五到二十的空间冗余。满盘运行对性能和寿命都不友好，这一点比总写入量更值得关注。

顺带一个细节。外接固态盘做冷存储很好用，但它不适合长期插着不动又从不检查。定期接上去看一眼健康状况，别等到它某天突然不认了。

给团队定一个磁盘预算

个人清理靠自觉，团队清理得靠规矩。

一个能落地的做法是给开发环境设磁盘预算，比如每个项目的数据目录不超过多少 GB，超过就得走清理或者外迁。数字不需要特别精确，重要的是有一条大家认的红线。

另一件事是把大件的存放位置约定清楚。模型权重统一放哪个目录，数据集放哪个目录，训练产物放哪个目录。约定清楚之后，清理就变成删这个目录下超过三个月的文件，而不是每次都重新判断某个东西能不能删。

还有一条很实用：临时产物一律写进带日期的目录。跑批也好，导出也好，日期命名意味着你能整体删掉某个时间点之前的全部内容，不需要逐个挑选。

这些规矩听起来琐碎，省掉的却是每次磁盘告急时那一整天的折腾。

还有一件更值得做的事

当你发现自己反复清理同一类东西的时候，就该改行为，而不是继续删文件。

比如本地环境总是爆，就把大文件集中到一个固定的冷目录统一管理，而不是散落在各个项目里。比如模型权重总是暴涨，就给自己定一条规矩，下载新模型之前必须先移走一个旧的。比如临时脚本总是忘了清理，那就规定临时产物一律写进一个带日期的目录，到期整体删掉。

桌面端瘦身六成这件事真正值得记住的不是那个数字。它提醒你一件事：任何会积累状态的工具，用久了都会自带冗余。定期看一眼，比等它满了再说要轻松得多。

磁盘这个东西有个特点，它从来不会在你方便的时候告急。所以它适合在你方便的时候先处理掉。