跳到正文
IFAI

產業動態

Hugging Face 收購 XetHub:告別 Git LFS,千億模型改引數不用重傳

首次發布 傳播指數 43

Hugging Face 宣佈收購 XetHub。XetHub 技術支援對海量資料集與模型進行分塊和去重,HF 將藉此替換老舊的 Git LFS 儲存後端。以後修改模型標頭檔案或資料集單行只需上傳幾千位元組的分塊,大幅提升協作效率。

Hugging Face 收購 XetHub:告別 Git LFS,千億模型改引數不用重傳
圖:huggingface.co

想像一下,你精心整理了一個 10GB 的 Parquet 資料集,後來發現漏了一條記錄。你補上這一行,然後不得不把整整 10GB 的大檔案重新上傳一遍。

改一個字母,傳十個 G,這就是目前在 Hugging Face 上折騰模型和資料的人每天都在忍受的荒誕現實。

Hugging Face 宣佈收購西雅圖初創團隊 XetHub,要把自家的底層儲存徹底換掉。這家只有 12 個人的團隊,此前一直在琢磨怎麼把 Git 擴充套件到可以支撐 TB 級倉庫的資料協作平臺。

治好 Git LFS 的大模型綜合徵

問題出在底層的 Git LFS 上。

據 Hugging Face 技術長 Julien Chaumond 回憶,2020 年搭建 Hugging Face Hub 時,團隊為了快速跑通業務,選擇了業界最通用的 Git LFS 作為大檔案儲存後端。但他坦言,Git LFS 雖然名字帶「大檔案」,但從來就不是為了今天動輒幾十 GB、幾百 GB 的 AI 權重設計的。

在現有的 Git LFS 機制下,檔案只要發生一點變動,系統就必須當成一個全新的檔案完整重傳。

XetHub 帶來的解法是基於資料塊的分塊切片和去重技術。接入這套系統後,那個 10GB 的檔案即便加了一行,你也只需要上傳包含這行增量的幾個資料塊。

模型微調和量化愛好者也會省下大量時間。比如社群開發者給 Llama 3.1 405B 的 GGUF 格式檔案修改模型頭部的後設資料,過去要折騰半天,未來只要重新上傳幾 KB 大小的單個分塊就行。

每天燒掉 6PB 頻寬背後的數字

Hugging Face 選在這個節點動手,很大程度上是因為 Hub 的體量已經膨脹到了物理極限。

官方公佈了一組相當驚人的資料。目前 Hub 上託管了 130 萬個模型、45 萬個資料集和 68 萬個 Spaces 演示應用。通過 Git LFS 儲存的總資料量達到了 12PB,包含了 2.8 億個大檔案,而純文本等非 LFS 儲存其實只有 7.3TB。

更誇張的是流量消耗。Hub 目前每天要響應 10 億次請求,每天消耗的 CloudFront 網路頻寬高達 6PB。

XetHub 的三位聯合創始人 Yucheng Low、Ajit Banerjee 和 Rajat Arya 此前都在蘋果負責內部機器學習基礎設施建設。Yucheng Low 過去把 GraphLab 賣給蘋果後,曾在蘋果內部管理超過 100PB 的 AI 資料,支撐過內部幾十個團隊每年上線數百個功能。

隨著社群開始出現萬億引數規模的開源模型,如果還抱著老舊的 Git LFS 不放,Hugging Face 的伺服器頻寬和開發者的上傳進度條遲早會一起崩掉。

為什麼重要

對於開源社群和開發者來說,這項收購的價值非常直觀。不論是個人開發者微調量化模型,還是企業團隊維護動態擴充的訓練集,都不用再為了一點小改動而反覆等待漫長的上傳和下載。AI 的版本迭代終於能像寫現代軟體那樣,只拉取和提交增量差分。

對行業而言,開源模型的引數競賽正在從幾百億衝向萬億。檔案越來越大,傳統的軟體分發機制完全跟不上節奏。Hugging Face 通過這次收購,實際上是在把自家的護城河從單純的「模型社群」延伸到「AI 原生版本控制底層」。如果這套增量儲存跑順了,其他想要挑戰 Hugging Face 平臺地位的對手,在開發者體驗和基礎設施成本上的差距會被進一步拉開。

我們認為 Hugging Face 這步棋走得非常聰明。收購一個成熟且在蘋果打過硬仗的小團隊,比自己從零重寫一套分散式去重儲存要穩妥得多。不過這也有一層隱患:把 12PB、近三億個歷史檔案的後端平滑遷移到新架構上,工程複雜度極高。新舊協議的相容、客戶端工具鏈的適配,以及企業版私有化部署的平穩過渡,看起來都需要很長時間去消化。

來源 (1)

  1. [1]
    huggingface.co(在新分頁開啟)原文huggingface.co

每日 AI 內容精選