從檔案到分塊：提高 HF 儲存效率
Hugging Face 在 Git LFS 倉庫中儲存了超過 30 PB 的模型、資料集和空間。由於 Git 在檔案級別進行儲存和版本控制，對檔案的任何更改都需要重新上傳整個資產——當 Hub 上的 Parquet 和 CSV 檔案平均大小為 200-300 MB，Safetensor 檔案平均大小為 1 GB 左右，GGUF 檔案甚至可以超過 8 GB 時，這些操作會非常昂貴。想象一下只修改 GGUF 檔案中的一行元資料，然後等待多吉位元組的檔案上傳；除了使用者時間和傳輸成本外，Git LFS 還需要儲存兩個檔案的完整版本，從而增加儲存成本。
下圖展示了 2022 年 3 月至 2024 年 9 月間 Hub 上模型、資料集和空間倉庫中 LFS 儲存的增長情況
Hugging Face 的 Xet 團隊正在採用一種不同的儲存方法：將檔案儲存為分塊。透過只傳輸修改過的分塊，我們可以顯著提高儲存效率和迭代速度，同時確保對不斷演變的資料集和模型進行可靠訪問。其工作原理如下。
內容定義分塊基礎
我們用於檔案分塊的方法稱為內容定義分塊（CDC）。CDC 不將檔案視為一個不可分割的單元，而是使用資料定義邊界，將檔案分解成可變大小的分塊。為了計算分塊，我們應用一種 滾動雜湊演算法 來掃描檔案的位元組序列。
考慮一個包含以下內容的檔案
transformerstransformerstransformers
我們使用文字進行說明，但它可以是任何位元組序列。
滾動雜湊演算法在資料滑動視窗上計算雜湊。在這種情況下，視窗長度為 4 時，雜湊將首先在 `tran` 上計算，然後是 `rans`，然後是 `ansf`，依此類推，直到檔案結束。
當雜湊滿足預定義條件時（例如）確定分塊邊界
hash(data) % 2^12 == 0
如果序列 `mers` 生成的雜湊滿足此條件，檔案將被分成三個分塊
transformers | transformers | transformers
這些分塊的內容會被雜湊，以建立分塊雜湊與位元組之間的對映，並最終儲存在內容定址儲存（CAS）中。由於所有三個分塊都是相同的，我們只在 CAS 中儲存一個分塊以實現內建去重。🪄
插入和刪除
當檔案內容更改時，CDC 允許進行細粒度更新，使其能夠穩健地處理插入和刪除操作。讓我們透過插入 `super` 來修改檔案，使新檔案內容變為
transformerstransformerssupertransformers
再次應用帶有相同邊界條件的滾動雜湊後，新的分塊如下所示
transformers | transformers | supertransformers
我們不需要儲存以前見過的分塊；它們已經儲存。然而，`supertransformers` 是一個新分塊。因此，儲存此檔案更新版本的唯一成本是上傳和儲存一個新分塊。
為了在實際世界中驗證這種最佳化，我們對 XetHub 上 CDC 支援儲存的先前實現與 Git LFS 進行了基準測試，發現在三個迭代開發用例中，儲存和傳輸效能始終提高了 50%。一個例子是 CORD-19 資料集，這是一個在 2020 年至 2022 年間整理的 COVID-19 研究論文集合，包含 50 次增量更新。Xet 支援和 Git LFS 支援的倉庫之間的比較總結如下
| 指標 | Git LFS 支援的倉庫 | Xet 支援的倉庫 |
|---|---|---|
| 平均下載時間 | 51 分鐘 | 19 分鐘 |
| 平均上傳時間 | 47 分鐘 | 24 分鐘 |
| 已用儲存 | 8.9 GB | 3.52 GB |
透過僅傳輸和儲存修改過的分塊，使用 CDC 的 Xet 支援的倉庫（以及各種提高壓縮和簡化網路請求的技術）顯示出顯著更快的上傳/下載時間，並大幅削減了捕獲資料集所有版本所需的儲存量。想了解更多資訊？請閱讀 完整的基準測試報告。
CDC 對 Hub 意味著什麼
CDC 如何應用於 Hugging Face Hub 上儲存的檔案型別？我們製作了一個簡單的 去重估算器，以視覺化將 CDC 應用於檔案集合時可能節省的儲存空間。在 openai-community/gpt2 倉庫提交歷史中上傳的 `model.safetensors` 檔案的兩個版本上執行此工具，返回以下結果
綠色表示兩個版本之間存在顯著重疊，因此有機會在檔案內部和不同版本之間進行去重。
| 所需 Git LFS 儲存 | 所需 Xet 支援儲存 | |
|---|---|---|
| 版本 1 | 664 MB | 509 MB |
| 版本 2 | 548 MB | 136 MB |
| 總計 | 1.2 GB | 645 MB |
在這種情況下，使用我們基於 Xet 的儲存後端將為第二個版本節省大量的上傳/下載時間，並將總儲存佔用減少 53%。加上壓縮，我們估計可以額外節省 10%。
我們對 Hub 上倉庫的初步研究表明，對於某些微調模型和許多模型檢查點，結果是積極的。微調模型只修改部分引數，因此模型的大部分在不同版本之間保持不變，這使得它們成為去重的好選擇。模型檢查點捕獲增量訓練狀態，也是很好的目標，因為檢查點之間的變化通常很小。兩者都顯示出 30-85% 的去重率。PyTorch 模型檢查點約佔 Hub 上總儲存的 200 TB。如果實現 50% 的去重，我們將立即節省多達 100 TB 的儲存，並且每月大約節省 7-8 TB。
除了降低儲存成本，塊級去重還提高了上傳/下載速度，因為只傳輸修改過的塊。這對於處理多個版本模型或資料集的團隊來說是一個巨大的好處，因為它最大限度地減少了使用者和機器的等待時間。
我們的團隊目前正在為 Hub 上的 Xet 後端儲存進行概念驗證，並希望在 2025 年初推出一些 Xet 後端倉庫。 關注我們，瞭解更多資訊，我們將分享未來主題的學習成果，例如在全球分散式倉庫中擴充套件 CDC，平衡網路效能、隱私邊界和並行化我們的分塊演算法。
