重新設計 Hugging Face 的上傳和下載架構

釋出於 2024 年 11 月 26 日
在 GitHub 上更新

作為 Hugging Face Xet 團隊改進 Hugging Face Hub 儲存後端工作的一部分,我們分析了 2024 年 10 月 11 日 24 小時內 Hugging Face 的上傳請求,以更好地瞭解訪問模式。我們觀察到:

  • 來自 88 個國家的上傳
  • 820 萬次上傳請求
  • 130.8 TB 資料傳輸

下圖透過各國每小時上傳位元組數來視覺化此活動。

Animated view of uploads

目前,上傳檔案儲存在 **`us-east-1`** 區域的 S3 儲存桶中,並使用 S3 Transfer Acceleration 進行最佳化。下載透過 AWS CloudFront 作為 CDN 進行快取和分發。CloudFront 的 400 多個便捷的邊緣站點提供全球覆蓋和低延遲資料傳輸。然而,像大多數 CDN 一樣,它針對網路內容進行了最佳化,檔案大小限制為 50GB。

雖然這個大小限制對於典型的網際網路檔案傳輸是合理的,但模型和資料集儲存庫中不斷增長的檔案大小帶來了挑戰。例如,meta-llama/Meta-Llama-3-70B 的權重總計 131GB,並被拆分為 30 個檔案,以符合 Hub 建議的將權重分塊成 20 GB 段。此外,為了實現上傳和下載的高階去重或壓縮技術,我們需要重新構思檔案傳輸的處理方式。

用於上傳和下載的自定義協議

為了將 Hugging Face 基礎設施推向當前極限之外,我們正在重新設計 Hub 的上傳和下載架構。我們計劃插入一個內容可定址儲存 (CAS) 作為內容分發的首站。這使我們能夠實現一個基於“**愚蠢讀取,智慧寫入**”指導理念的自定義協議。與將檔案視為不透明二進位制大物件(blob)的 Git LFS 不同,我們的方法在位元組級別分析檔案,從而發現提高模型和資料集儲存庫中大量檔案傳輸速度的機會。

讀取路徑優先考慮簡單性和速度,以確保高吞吐量和最小延遲。檔案請求被路由到 CAS 伺服器,該伺服器提供重構資訊。資料本身仍由 **`us-east-1`** 區域的 S3 儲存桶支援,AWS CloudFront 繼續作為下載的 CDN。

寫入路徑更為複雜,旨在最佳化上傳速度並提供額外的安全保障。與讀取類似,上傳請求被路由到 CAS 伺服器,但我們不是在檔案級別查詢,而是在塊級別操作。當找到匹配項時,CAS 伺服器會指示客戶端(例如 huggingface_hub)僅傳輸必要的(新)塊。這些塊在上傳到 S3 之前由 CAS 進行驗證。

還有許多實現細節需要解決,例如網路限制和儲存開銷,我們將在未來的文章中討論。目前,讓我們看看讀取目前是如何進行的。下面的第一張圖顯示了當前讀取和寫入路徑

Old read and write sequence diagram
左側表示讀取;右側表示寫入。請注意,寫入直接進入 S3,沒有任何中間環節。

同時,在新設計中,讀取將遵循以下路徑

New read path in proposed architecture
新的讀取路徑,內容可定址儲存 (CAS) 提供重構資訊。CloudFront 繼續充當 CDN。

最後是更新後的寫入路徑

New read path in proposed architecture
新的寫入路徑,CAS 加速並驗證上傳。S3 繼續提供後端儲存。

透過在位元組級別管理檔案,我們可以調整最佳化以適應不同的檔案格式。例如,我們已經探索了提高 Parquet 檔案去重能力的方法,現在正在研究壓縮張量檔案(例如 Safetensors),這有可能將上傳速度提高 10-25%。隨著新格式的出現,我們獨特的優勢在於可以開發進一步的增強功能,以改善 Hub 上的開發體驗。

此協議還為企業客戶和高階使用者帶來了顯著改進。插入檔案傳輸的控制平面提供了額外的保障,以確保惡意或無效資料無法上傳。在操作上,上傳不再是一個黑箱。增強的遙測功能提供了審計跟蹤和詳細日誌記錄,使 Hub 基礎設施團隊能夠快速有效地識別和解決問題。

為全球訪問而設計

為了支援這個自定義協議,我們需要確定 CAS 服務的最佳地理分佈。AWS Lambda@Edge 最初被考慮用於其廣泛的全球覆蓋範圍,以幫助最大限度地減少往返時間。然而,它對 Cloudfront 觸發器的依賴使其與我們更新的上傳路徑不相容。因此,我們選擇在 AWS 的 34 個區域中的少數幾個部署 CAS 節點。

仔細研究我們 24 小時內的 S3 PUT 請求,我們識別出全球流量模式,揭示了資料上傳到 Hub 的分佈。正如預期的那樣,大部分活動來自北美和歐洲,全天都有持續的大量上傳。資料還突出顯示了亞洲強大且不斷增長的存在。透過專注於這些核心區域,我們可以放置我們的 CAS 存在點,以平衡儲存和網路資源,同時最大限度地減少延遲。

Pareto chart of uploads

雖然 AWS 提供 34 個區域,但我們的目標是保持基礎設施成本合理,同時保持高質量的使用者體驗。在這份快照中代表的 88 個國家中,上方的帕累託圖顯示,前 7 個國家貢獻了 80% 的上傳位元組,而前 20 個國家貢獻了總上傳量和請求的 95%。

美國是上傳流量的主要來源,因此有必要在該地區設立 PoP。在歐洲,大部分活動集中在中歐和西歐國家(例如盧森堡、英國和德國),儘管非洲也有一些額外的活動需要考慮(特別是阿爾及利亞、埃及和南非)。亞洲的上傳流量主要由新加坡、香港、日本和韓國驅動。

如果我們使用一個簡單的啟發式方法來分配流量,我們可以將 CAS 覆蓋範圍劃分為三個主要區域

  • **`us-east-1`**:服務北美和南美
  • **`eu-west-3`**:服務歐洲、中東和非洲
  • **`ap-southeast-1`**:服務亞洲和大洋洲

這最終效果相當好。美國和歐洲占上傳位元組的 78.4%,而亞洲佔 21.6%。

New AWS mapping

這種區域劃分使得我們的三個 CAS PoP 之間的負載均衡良好,**`ap-southeast-1`** 具有額外的增長容量,並且在需要時可以靈活地在 **`us-east-1`** 和 **`eu-west-3`** 中進行擴充套件。

根據預期流量,我們計劃按如下方式分配資源

  • **`us-east-1`**:4 個節點
  • **`eu-west-3`**:4 個節點
  • **`ap-southeast-1`**:2 個節點

驗證和審查

儘管我們正在增加某些使用者的首次跳躍距離,但對整個 Hub 的頻寬總體影響將是有限的。我們的估計預測,雖然所有上傳的總頻寬將從 48.5 Mbps 降低到 42.5 Mbps(減少 12%),但效能損失將被其他系統最佳化所抵消。

我們目前正在努力在 2024 年底前將我們的基礎設施投入生產,屆時我們將從 `us-east-1` 的單個 CAS 開始。從那裡,我們將開始將內部儲存庫複製到我們的新儲存系統以基準測試傳輸效能,然後將我們的 CAS 複製到上面提到的其他 PoP 以進行更多基準測試。根據這些結果,我們將繼續最佳化我們的方法,以確保明年我們的儲存後端完全到位時一切順利執行。

超越位元組

隨著我們繼續進行這項分析,新的更深入的洞察機會正在浮現。Hugging Face 擁有開源機器學習社群最大的資料集合之一,為探索全球人工智慧發展的模式和趨勢提供了獨特的視角。

例如,未來的分析可以根據用例(如自然語言處理、計算機視覺、機器人或大型語言模型)對上傳到 Hub 的模型進行分類,並檢查機器學習活動的地理趨勢。這些資料不僅為我們的基礎設施決策提供資訊,還提供了了解機器學習發展格局的視角。

我們誠摯邀請您更詳細地探索我們當前的發現!請訪問我們的互動式空間,檢視您所在地區的上傳分佈,並關注我們的團隊,瞭解我們正在構建的更多內容。

社群

文章作者

現在您可以加入候補名單,獲取我們在此處討論的所有改進!

https://huggingface.co/join/xet

註冊登入發表評論

© . This site is unofficial and not affiliated with Hugging Face, Inc.