Hugging Face Hub 從 Git LFS 遷移至 Xet

Hugging Face 已將 50 萬個倉庫與 20 PB 的資料從 Git LFS 遷移至 Xet，這是一個為 AI 開發者龐大資料需求而設計的新儲存後端。此轉換可實現更快的傳輸速度與更佳的可擴展性，且不需要使用者更改現有工作流程。

透過 Git LFS Bridge 的無縫向後相容性

為避免「硬性切換」並將使用者中斷降至最低，Hugging Face 實作了一套系統，使啟用 Xet 的倉庫同時可包含 Xet 與 LFS 檔案。此相容性的核心是 Git LFS Bridge，它確保使用較舊客戶端的使用者仍能與 Xet 支援的檔案互動。

Git LFS Bridge 的運作方式

當非 Xet 感知的客戶端（例如較舊版本的 huggingface_hub 或 huggingface.js）透過 resolve 端點請求檔案時，Git LFS Bridge 會：

  1. 建立並回傳一個模擬 LFS 協定的單一預簽名 URL。
  2. 從 S3 中保存的內容重建檔案。
  3. 將重建的檔案回傳給請求者。

Xet 感知客戶端工作流程

感知 Xet 的客戶端（例如 hf-xet 或 huggingface_hub 中的 Xet 整合）會繞過橋接層，直接使用完整的 Xet 堆疊：

  • 上傳： 檔案會使用內容定義的分塊方式切割，傳送至內容可尋址儲存 (CAS)，並儲存於 S3。
  • 下載： 客戶端請求檔案重建資訊，並透過 CAS 從 S3 取得特定的分塊範圍。

背景遷移流程

Hugging Face 採用背景遷移流程，將資料從 LFS 移至 Xet，無需鎖定倉庫或中斷正在進行的上傳與下載。

當檔案被遷移時，Webhook 會觸發由 orchestrator 處理的分散式佇列。該 orchestrator 為倉庫啟用 Xet，取得 LFS 版本，並將檔案批次化為工作（每批 1,000 個檔案或 500 MB）。遷移工作者 pod 隨後下載 LFS 檔案，並使用 xet-core 上傳至 Xet CAS。

擴展挑戰與效能提升

在針對大型使用者的廣域遷移過程中——包括跨 42,000 個倉庫、資料量高達 6.1 PB 的情況——Hugging Face 辨識並解決了多項技術瓶頸：

  • 磁碟空間： 修正了全域去重的暫存分片檔案寫入位於與 Xet 快取不同掛載點的 /tmp，導致 No space left on device 錯誤的問題。
  • 資源配置： 調整 CAS 大小，以應對遷移工作者的突發上傳，這與在大型模型發布（如 Llama 4）期間常見的突發下載模式不同。
  • I/O 瓶頸： 升級工作節點規格，以解決網路與 EBS I/O 的瓶頸。

CAS 吞吐量改進

透過這些最佳化，內容可尋址儲存 (CAS) 的吞吐量顯著提升：

  • 初始遷移： 持續約 35 Gb/s（加上約 5 Gb/s 的一般 Hub 流量）。
  • 最新遷移： 峰值約 300 Gb/s，同時支援約 40 Gb/s 的基礎負載。

未來路線圖與可用性

截至 2025 年 7 月，Xet 已成為新使用者與組織的預設儲存。Hugging Face 正在將 Xet 的使用權擴展至所有使用者，並自動將所有既有倉庫從 LFS 遷移至 Xet。

即將推出的開發包括：

  • 基於分塊的支援，用於瀏覽器上傳/下載以及 Git。
  • 開源 Xet 協定與整個基礎設施堆疊。

Sources