Hugging Face Xet 儲存整合

Hugging Face 已將 Xet 儲存整合到 Hub 中，將第一批 Model 和 Dataset 儲存庫從 Git LFS 遷移出去。此過程引入了內容定義分塊（CDC）以實現位元級去重複，大幅降低更新大型檔案所需的時間與頻寬。

Xet 儲存架構

Xet 儲存使用內容定義分塊（CDC）將檔案層級去重複替換為位元級去重複。雖然 Git LFS 將大型檔案的任何變更視為必須重新上傳整個檔案的需求，但 Xet 會將資料分割為約 64KB 的區塊。只有變更的區塊會透過網路傳輸。

例如，在 LFS 下將 1MB 的資料追加到 5GB 的 SQLite 資料庫需要完整重新上傳 5GB，但使用 Xet 時僅推送新增的資料。在內部測試中，這使得上傳時間從 13 分鐘縮短至 50Mb/s 下的十分之一秒。

Xet-aware Client：負責將資料分割為約 64KB 的區塊，在本地進行相同區塊的去重複，並在上傳前將它們彙總為約 64MB 的區塊。
Hugging Face Hub：負責路由、驗證與安全保證。
Content Addressed Store (CAS)：對傳輸實施基於區塊的去重複。它包含一個 LFS Bridge，以透過模擬傳統 LFS 伺服器來確保非 Xet 客戶端的向後相容性。
Amazon S3：作為最終的持久層，儲存區塊（檔案內容）和碎片（重建中繼資料）。

2025 年 2 月 20 日，Hugging Face 將 4.5 TB 的資料遷移至目標儲存庫的 Xet 儲存。此遷移將 Hub 總下載流量約 6% 轉移至 Xet 基礎設施，為系統的可靠性與效能提供了真實世界的驗證場域。

遷移後的分析顯示，兩個主要的技術瓶頸透過架構更新得以解決：

初步指標顯示 Content Addressed Store (CAS) 從 S3 下載的資料量是返回給客戶端的四倍。這是由於 hf_transfer 對 10MB 範圍的請求未與 Xet 的區塊邊界對齊所致。因為區塊格式缺少未壓縮的區塊長度，CAS 必須從頭開始串流整個區塊以尋找請求的資料。

解決方案：Hugging Face 更新了區塊格式以儲存區塊長度元資料。這使得 CAS 能僅下載每個請求所需的特定資料，使 GET 延遲降低約 35%，並實現下載與發送資料的平衡。

團隊觀察到 CAS 叢集中單個 Pod 會處理數百個活躍上傳而其他 Pod 閒置的異常負載尖峰。這被追溯為在驗證期間，OS 頁面快取在未呼叫 fsync 的情況下緩衝寫入暫存檔案。高上傳量導致記憶體壓力以及來自 AWS EBS 區塊儲存的吞吐量節流，形成延遲與積壓的循環。

解決方案：團隊為每台機器設定了可接受的同時上傳數量上限。當 Pod 達到上限時，請求會被推送至叢集中的其他 Pod；如果所有 Pod 都飽和，則會觸發自動擴縮政策。

使用者可以透過加入等候名單來存取支援 Xet 的儲存。一旦被接受，新儲存庫將自動使用 Xet，而現有儲存庫將會被遷移。

Tooling：hf_xet Python 套件正在被整合到 huggingface_hub 中。transformers 或 datasets 的使用者可以在其環境中安裝 hf_xet 以獲得其優勢。
Compatibility：舊版客戶端透過 LFS Bridge 仍保持相容，但若要獲得完整效能提升，則必須升級至 hf_xet。