从文件到块: 提高 Hugging Face 存储效率

Hugging Face 在 Git LFS 仓库 中存储了超过 30 PB 的模型、数据集和 Spaces。由于 Git 在文件级别进行存储和版本控制，任何文件的修改都需要重新上传整个文件。这在 Hub 上会产生高昂的成本，因为平均每个 Parquet 和 CSV 文件大小在 200-300 MB 之间，Safetensor 文件约 1 GB，而 GGUF 文件甚至可能超过 8 GB。设想一下，仅仅修改 GGUF 文件中的一行元数据，就需要等待数 GB 大小的文件重新上传。除了耗费用户时间和传输成本外，Git LFS 还需要保存文件的两个完整版本，这进一步增加了存储开销。
下图展示了 Hub 上各类仓库 (模型、数据集和 Spaces) 中 LFS 存储容量在 2022 年 3 月至 2024 年 9 月期间的增长趋势:

Hugging Face 的 Xet 团队正在采用一种创新的存储方案: 将文件分块存储。通过只传输发生变化的数据块，我们可以显著提升存储效率和迭代速度，同时确保用户能可靠地访问不断演进的数据集和模型。下面让我们详细了解其工作原理。
基于内容的分块原理

我们采用的分块方法称为基于内容的分块 (Content-Defined Chunking，CDC)。与将文件视为不可分割的整体不同，CDC 根据文件内容本身来确定边界，将文件划分为大小可变的数据块。为了计算这些块的边界，我们使用 滚动哈希算法 来扫描文件的字节序列。
让我们通过一个简单的例子来说明:

1. transformerstransformerstransformers

复制代码

这里我们用文本来演示，但实际上这个过程适用于任何字节序列。
滚动哈希算法通过在数据上滑动固定大小的窗口来计算哈希值。比如，当窗口长度为 4 时，算法会依次计算 tran 、 rans 、 ansf 等字符序列的哈希值，直到处理完整个文件。
当某个位置的哈希值满足预设条件时，就会在该处设置块的边界。例如，可以设置如下条件:

1. hash(data) % 2^12 == 0

复制代码

如果序列 mers 的哈希值满足这个条件，那么文件就会被分成三个块:

1. transformers | transformers | transformers

复制代码

系统会计算这些块的哈希值，建立块哈希值到实际内容的映射，并最终将它们存储在基于内容寻址的存储系统 (Content-Addressed Storage，CAS) 中。由于这三个块完全相同，CAS 只需要存储一个块的实际内容，从而自动实现了数据去重。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！