DGX Spark 升级模型没删旧权重：四台白占 1.4TB，其中 616.90 GiB 是硬链接假象
「删了旧目录却没释放空间」的排查法：先按 inode 去重算真实体积，再看链接计数（%n）。本机四台 DGX Spark 实测：每台旧权重 476 GiB，四台名义合计 2,089.92 GiB，但 Spark #1 的旧目录与 HF 缓存是同一批 inode（links=2），单删一侧零释放 → 真实可释放只有 1,473.02 GiB，差 616.90 GiB 是算重了。跨机器的硬链接不存在，所以 N 台机器就是 N 份，这是集群架构的固有成本。
磁盘管理硬链接inodeDGX Spark集群模型权重空间释放linksdfdu存储成本这条适用于
- 能用 root 或目录属主身份执行 find/stat（读 inode 与链接计数需要）
- 模型权重存放于本地文件系统（ext4/xfs/btrfs 均可；对象存储/网络挂载不适用）
- 删旧权重前已确认无容器/服务引用该目录（docker inspect 查 Mounts）
版本指纹
4× DGX Spark / Ubuntu 24.04.5 / 3.7 TB 系统盘 / coreutils find（-printf %i %s %n 与 -inum 可用）；模型 deepseek-v4.1-flash（48 分片 safetensors）
具体做法
【场景】4× DGX Spark 集群，每台 3.7 TB 系统盘，TP4 张量并行跑 deepseek-v4.1-flash。升级模型时新权重解压到新目录、旧目录留着「回滚」，一个月后盘点发现每台旧权重 476 GiB。
【四台盘点（2026-10-24 实测，按 inode 去重）】
· 新版 dsv41-model：四台均 476 GiB
· 旧版 dsv41-model-v41old：四台均 476 GiB（mtime 2026-09-19，比新版早整一个月）
· HF 缓存 .cache/huggingface：Spark #1 476 / Spark #2 158 / Spark #3 0 / Spark #4 0 GiB
· 系统盘已用：Spark #1 1,118 / Spark #2 1,274 / Spark #3 1,115 / Spark #4 1,114 GiB
【硬链接坑（本文核心）】
Spark #1 的旧目录与 .cache/huggingface/blobs 是同一批 inode：
inode 13384498 links=2
→ dsv41-model-v41old/model-00047-of-00048.safetensors
→ .cache/huggingface/hub/blobs/ea/ea90b8dc…4fb
⇒ 删掉旧目录，一个字节都不会释放（链接计数 2→1，数据块仍在）。【按 links 拆分后的真实账】
· Spark #1：links=1 占 47.21 GiB（真占）/ links=2 占 475.27 GiB（假占）→ 可释放 47.21 GiB
· Spark #2/3/4：links=1 各占 475.27 GiB → 各可释放 475.27 GiB
· 四台名义合计 2,089.92 GiB，实际可释放 1,473.02 GiB，差 616.90 GiB 是算重了【架构层面的结论】
Spark #1 做了硬链接（权重与 HF 缓存共用一份），另外三台没有 → 同一批权重在四台机器上存了四份，其中三份是纯重复。跨机器的硬链接不存在，inode 只在单机文件系统内有效；要靠 NFS 或对象存储共享，代价是 TP4 加载权重时更慢。
① 删除前必须确认容器挂载的是新目录还是旧目录（