Hugging Face Hub 怎麼撐住三百萬個模型

053Arek Borucki（Hugging Face）21:392026-07-28 上架

Serving 2 Million Models Without Melting: Scaling the Hugging Face Hub — Arek Borucki, Hugging Face

Arek Borucki 拆解 Hub 在模型數暴增下的做法：搜尋從 regex 改走 Lucene、MongoDB 讀寫分流與分片、Kubernetes 兩層自動擴展。

這場講了什麼

• 規模暴增逼出重構：Arek 說 Hub 有超過 1400 萬使用者，模型數從幾年前的 20,000 個長到 300 萬個，約 150 倍。每次 Llama、DeepSeek 這類大發布，都會在上面長出數千個衍生模型。
• 搜尋看 P99，不看 P50：模型少的時候沒有索引也沒人發現，到了 300 萬就撐不住。Arek 的看法是規模大了以後 P99 比 P50 重要，所以他們預先算好 token、做反正規化、針對讀取最佳化。
• 中繼資料與模型檔分開存：MongoDB Atlas 是中繼資料的唯一真相來源，存的是倉庫、設定、帳務、權限這些；模型檔、tokenizer 檔等放在 AWS S3 這類雲端物件儲存，兩邊可以各自擴展。
• 搜尋從 regex 換成 Lucene：原本是在預先算好的 token 陣列上跑 regex，資料一多延遲就出問題。後來改用 Atlas Search（底層是 Apache Lucene）的 autocomplete，排序仍用 trending score。
• 讀寫分流到不同機器：七個節點的叢集裡，寫入只走 primary，不需要最新資料的讀取、重型聚合、change streams 交給 secondaries，報表與臨時查詢丟給隱藏的分析節點。下一步是分片。
• Hub 本身有兩層自動擴展：HPA 讓 Hub 在 10 到 500 個 pod 之間伸縮，pod 排不進去時由 Cast.ai 補節點。之後打算把 HPA 換成 KEDA，改依實際應用指標擴展。

影片從哪一段開始看12 段

1. 00:13開場與主題Arek 自我介紹是 Hugging Face 的 machine learning platform 與資料庫工程師，說明這場要講架構決策、遇到的挑戰與學到的教訓。
2. 01:43規模數字超過 1400 萬使用者，超過 30% 的 Fortune 500 在 AI 工作流程裡用 Hugging Face，模型從 20,000 個長到 300 萬個。
3. 04:02為什麼要重做搜尋模型少時沒有索引也沒人會發現，到 300 萬就不行了；使用者嫌慢就會離開，所以盯 P99。
4. 05:34高層架構請求從前端進 Hub API，Hub 跑在 Kubernetes，後面是 MongoDB Atlas；MongoDB 只存模型的相關資訊，檔案放在 S3。
5. 08:01搜尋 llama 的流程搜尋走一份專為讀取與列表準備的反正規化集合，模型名稱在寫入時就切成 token 存進陣列。
6. 10:35regex 撐不住，改用 Lucene舊做法用 regex 比對 token、依 trending score 排序，資料變大後延遲出問題；改用 mongot 這個包著 Lucene 的程序，查詢經 $search 走索引。
7. 12:43七節點的 MongoDB 叢集公司內有數百個服務在用 MongoDB；寫入全走單一 primary，讀取分散到多台機器，避免單一節點變成讀取瓶頸。
8. 13:51隱藏節點與 secondaries 的分工隱藏的分析節點從 primary 複製資料但不接正式流量，專跑報表與重型查詢；secondaries 處理不需要最新資料的讀取、大型聚合與 change streams。
9. 16:42下一步：分片單一 replica set 很快會不夠用；分片把資料切到各個 shard，加機器就能橫向擴展，shard key 怎麼選這場不談。
10. 18:15Hub 的 pod 自動擴展Hub 跑 HPA，CPU 或記憶體超過門檻就加 pod，流量退了就縮回，部署規模在 10 到 500 個 pod 之間。
11. 19:08Cast.ai 與 KEDA沒有空節點時由 Cast.ai 補節點，形成兩層擴展；之後要把 HPA 換成 KEDA，改看每秒請求數這類實際應用指標。
12. 20:40結語下載模型時一切照常運作，擴展的重點就是不管底下多複雜，使用者的體驗都要維持簡單。

值得記的話5 句

• P99 is much more important than P50.規模大了，P99 比 P50 重要得多04:47

• MongoDB does not store the models themselves. It stores everything about the models.MongoDB 不存模型本身，存的是關於模型的一切06:34

• Primary should focus on what only primary can do.primary 只該做只有 primary 能做的事16:16

• POD can have low CPU but high request queue, KEDA can see it, HPA not.pod 的 CPU 可能很低、請求卻大排長龍，KEDA 看得到，HPA 看不到20:22

• keeping the user experience simple no matter how complex it gets under the hood不管底下變得多複雜，使用者的體驗都要維持簡單21:01

名詞與人物9 個

Arek Borucki

Hugging Face 的 machine learning platform 與資料庫工程師，這場的講者

MongoDB Atlas

Hub 中繼資料的唯一真相來源，存倉庫、模型、資料集、設定、帳務與權限，不存模型檔本身

Apache Lucene

Atlas Search 底層的全文檢索引擎，取代原本在 token 陣列上跑的 regex

mongot

包著 Lucene 的 MongoDB 程序，MongoDB 核心本身不提供全文檢索

trending score

搜尋結果的排序依據，每五分鐘算一次，用的是下載數與按讚數，Arek 憑印象說是近七天

hidden node

叢集裡對應用程式不可見的分析節點，只負責報表與重型查詢

HPA

Kubernetes 的 horizontal pod autoscaler，只依 CPU 與記憶體伸縮 pod

Cast.ai

負責 Kubernetes 節點層級的自動擴展，pod 排不進去時補節點

KEDA

Kubernetes event-driven autoscaling，打算用來取代 HPA，可依每秒請求數、event loop 使用率擴展

提到但沒有展開

• Arek 提到每個 shard 各有自己的 primary 與 secondary，由 MongoDB balancer 在 shard 間平衡資料。
• change streams 除了做快取驗證，也用來把資料同步到其他資料儲存（例如 AWS Redshift）或驅動事件型工作負載。

開源開發工具產業觀察

在 YouTube 看原片 ↗