腾 /home 空间 86% 到 55%：llm、VTuber、uv、pip 全迁 /data 的完整操作

/home 分区 187G，用掉 172G 只剩 5.8G，这是 10 月 15 日 OpenClaw 升级验收时最红的一项。三天后它降到了 55%（81G 可用）。这篇文章把整个腾空间过程写下来，包括每一步的判断依据、哪些能删哪些不能删、迁移后怎么验证，以及我踩的一个"删缓存"的口误。

先搞清楚：/home 到底被什么占满了

腾空间的第一步不是动手，是体检。用 du 分层扫，结果如下（10 月 17 日实测）：

两个分区的基本盘：

/dev/nvme1n1p3  187G  152G   26G   86% /home
/dev/nvme0n1p4  1.5T  409G 1016G   29% /data

判断标准很简单：大文件、可再生的、有稳定路径约定的，迁 /data；一次性残留，直接删。

阶段一：删残留（86% → 82%，释放 ~7G）

可以直接删的类别只有一种：失败残留和一次性安装包。

# 发布备份残骸（6.6G，publish 流程的历史残留，数据已无用）
rm -rf ~/.openclaw-backup-publish

# CUDA 安装 deb 包残留（3.9G，装完驱动后就没有用了）
rm -f /var/cuda-repo-ubuntu*.deb

执行完查效果：

/dev/nvme1n1p3  187G  146G   32G   82% /home

这里我犯了这篇文章最该写出来的错。 当时我把 .cache/uv + .cache/pip（18.6G）列为"纯缓存，可安全清理，零风险"，用户直接怼了回来：

缓存删除了，下次用到相关的不是又要重新下载？这个能清楚？你在放狗屁？

这句怼得对。所谓"零风险"说反了：缓存删了不丢数据，但会把下次构建/安装的时间成本转嫁给未来。uv/pip 缓存删了，下一个 Python 项目要重新下载整个依赖树。所以正确处置不是"删"，是"迁移"——数据留着，只是换个分区住。

正确的分类应该是三档：

阶段二：llm 29G 迁移（→ 69%）

/home/oklife/llm 里有三块东西，得拆开看：

1. litellm 依赖的模型文件（~27G）——litellm 走 docker，挂载的就是这个目录，核心资产
2. 旧版 llama.cpp 源码（2.5G）——和 litellm 无关，弃用的旧 build
3. vllm 残留（4K）——可忽略

执行前只读检查（这一步不能省）：

• config.yaml 里模型路径写的是相对还是绝对路径？（绝对路径，迁移后要么改配置，要么用软链接兜住旧路径）
• 有没有进程正在占用这些文件（lsof / fuser 查）
• /data 下有没有同名目录会撞车

确认无占用、无撞车后执行：

# 1. 模型搬到 /data
mv /home/oklife/llm/models /data/llm-models   # 按实际目录名

# 2. 旧路径接回（docker 挂载路径不变，litellm 无感）
ln -s /data/llm-models /home/oklife/llm/models

# 3. 旧 llama.cpp 源码直接删（2.5G，弃）
rm -rf /home/oklife/llm/llama.cpp

软链接是整篇文章的核心手法：程序里写死的路径（docker 挂载、shell 脚本、服务配置）一行不用改，数据物理上搬到 /data，旧路径通过软链接接回来。验证方法就一条——从旧路径读一个文件试试：

ls /home/oklife/llm/models/    # 能列出内容 = 软链接通了

/home 从 82% 降到 69%。

阶段二补充：llama.cpp 重新编译（顺手做的）

llm 迁移时发现旧的 llama.cpp 是 8 月 13 号编的，顺带升级 + 重编。踩到一个具体的坑：CMakeCache 污染。

旧 build 目录里的 CMakeCache.txt 写死了旧路径，直接 cmake --build 会挂。正确做法是干净重建 + 显式指定 CUDA：

cd /data/llm/llama.cpp
rm -rf build            # 删污染的 build 目录（1.2G）
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
# 关键：显式 CUDACXX，别依赖 CMake 自动探测
CUDACXX=/usr/local/cuda/bin/nvcc cmake --build build -j

验证两件事：

./build/bin/llama-cli --version
# 0.7.0-dev (build 11706, commit f74e2fa6a)

# MTP 支持校验（Qwen 系列 MTP 模型需要的参数还在）
./build/bin/llama-server --help | grep spec-draft

sm_89 对应 RTX 4070，架构参数写错了 CUDA 加速就白编了。

阶段三：VTuber 10.4G 迁移（69% → 67%）

Open-LLM-VTuber（8.6G）和 Open-LLM-VTuber-Web（1.8G）是标准的项目目录，迁移前确认三件事：

1. 无进程占用（两个目录都没有跑着的进程）
2. /data 下无同名目录
3. 没有 service 或脚本硬编码引用旧路径

mv /home/oklife/Open-LLM-VTuber /data/Open-LLM-VTuber
ln -s /data/Open-LLM-VTuber /home/oklife/Open-LLM-VTuber

mv /home/oklife/Open-LLM-VTuber-Web /data/Open-LLM-VTuber-Web
ln -s /data/Open-LLM-VTuber-Web /home/oklife/Open-LLM-VTuber-Web

# 验证
ls /home/oklife/Open-LLM-VTuber/    # CLAUDE.md 等能列出 = 通了
df -h /home
# 187G  118G  60G  67%

阶段四：uv + pip 18.6G 迁移（65% → 55%）

~/.cache/uv 和 ~/.cache/pip 是标准缓存目录，所有工具（uv、pip）都认 $HOME/.cache 这个约定路径，迁移手法和前两批完全一样：

mkdir -p /data/.cache
mv /home/oklife/.cache/uv /data/.cache/uv
mv /home/oklife/.cache/pip /data/.cache/pip

ln -s /data/.cache/uv /home/oklife/.cache/uv
ln -s /data/.cache/pip /home/oklife/.cache/pip

# 验证软链接可读
ls /home/oklife/.cache/uv/ | head -3    # archive-v0 / builds-v0 能列出
df -h /home
# 187G  97G  81G  55%

两个"不迁"的决策

.cache/qmd（4.4G）不迁

qmd 是 OpenClaw 记忆检索的索引目录。它能迁（手法一样），但迁了收益小、且索引程序对路径敏感，要停 OpenClaw 服务再动。当时 /home 已经到 55%，没必要为 4.4G 冒这个险。结论：暂不迁移，等下次容量告警再评估。

comfy 大模型：剪切，不用软链接

ComfyUI 的两个大模型（十几个 G）是手动剪切到 /data 的（mv 后原路径就没有了，没有建软链接）。这个和上面"迁移 + 软链接"的区别要说清楚：

• 迁移 + 软链接：旧路径还能用，程序无感，适合有路径约定的东西（缓存、docker 挂载）
• 纯剪切：旧路径失效，所有引用它的程序都得改配置，适合"反正要改配置指向 /data"的东西（ComfyUI 启动脚本本来就是手动指定的）

两种手法对应两种场景，别混用：如果剪切后还有程序写死了旧路径，它就挂了。

全程账本

（65% 和 67% 之间有一小段是中途 df 读数波动 + qmd 4.4G 的评估窗口，不影响总量。）

从 86% 的红区边缘到 55% 的健康水位，全程没有删任何"以后还要用"的数据，所有动作都有回滚点：软链接一删，数据在 /data 里原样躺在那。

可以抄走的操作清单

# 1. 体检：谁在占 /home
du -sh /home/* /home/.[!.]* 2>/dev/null | sort -rh | head -15

# 2. 迁移三件套（以目录 D 为例）
mv /home/oklife/D /data/D
ln -s /data/D /home/oklife/D
ls /home/oklife/D/        # 验证旧路径可读

# 3. 检查占用（迁移前必做）
sudo lsof +D /home/oklife/D 2>/dev/null | head

# 4. 查效果
df -h /home

三条铁律：

1. 迁移前先查占用，跑着的进程迁走就挂了
2. 缓存不是"零风险可删"，是"迁了不亏"，删缓存 = 把成本转嫁给未来
3. 软链接兜旧路径，程序配置一行不改，回滚 = 删软链接

参考来源

• 本文素材：OC工程师 agent 会话记录（2026-10-17 腾 /home 空间全程）
• 前篇：[[OpenClaw 连续三次升级踩坑全记录：从 2026.9.1 到 2026.10.3 的排障方法论]]（磁盘 97% 红区的发现过程）