Serving 2 Million Models Without Melting: Scaling the Hugging Face Hub — Arek Borucki, Hugging Face
三句話摘要
Hugging Face 如何透過架構決策與基礎設施優化，應對從 20,000 個模型快速成長至 300 萬個模型的規模挑戰。 Hugging Face 透過元資料 / 二進制分離、全文搜尋引擎升級、讀寫工作負載隔離與多層自動擴縮，在保持用戶體驗簡潔的前提下，成功應對 300 倍的規模成長。 元資料與二進制分離架構：MongoDB 只儲存模型元資料（名稱、配置、權限、計費資訊），實際模型檔案與分詞器存放於 AWS S3，允許獨立擴展每層且針對不同工作負載單獨優化，降低單點瓶頸。
重點整理
重點- 1
元資料與二進制分離架構：MongoDB 只儲存模型元資料（名稱、配置、權限、計費資訊），實際模型檔案與分詞器存放於 AWS S3，允許獨立擴展每層且針對不同工作負載單獨優化，降低單點瓶頸。
- 2
搜尋優化的關鍵轉變：從查詢時的正規表達式改為插入時分詞化模型名稱，配合 MongoDB Atlas Search（Apache Lucene 引擎）與自動完成功能，搜尋延遲大幅改善且 P99 響應時間達要求。
- 3
讀寫工作負載隔離：7 節點副本集將寫入集中於主節點、讀取分散於從節點，額外隱藏節點專門處理複雜聚合與報告查詢，防止重操作阻塞生產流量並確保一致性。
- 4
多層自動擴縮策略：Pod 層用 HPA 基於 CPU / 內存自動調整，集群層用 Cast AI 或 KEDA 基於實際應用指標（請求隊列、事件迴圈利用率）動態增減節點，允許從 10 到 500 個 Pod 的彈性擴展。
實用技巧與重點
乾貨- 規模指標：
- 用戶數：1,400 萬
- 公共模型：300 萬（兩年成長 150 倍，從 20,000 → 300 萬）
- 資料集：100 萬（2022 年 10,000 → 2024 年 100 萬）
- 組織數：5 萬
- 財富 500 強企業採用比例：>30%
- 技術棧：
- 元資料存儲：MongoDB Atlas（7 節點副本集）
- 二進制存儲：AWS S3
- 全文搜尋引擎：Apache Lucene（MongoDB Atlas Search）
- 容器編排：Kubernetes
- 集群自動擴縮：Cast AI、KEDA（規劃中）
- 搜尋實作細節：
- 分詞時機：插入時而非查詢時
- 索引名稱：「model_search_autocomplete_v3」
- 排序依據：趨勢分數（過去 7 天下載量 + 讚數）
- 實例：meta-llama 模型熱度指數 33 和 14
- Pod 擴縮範圍：
- 規模區間：10 ～ 500 個 Pod
- HPA 遷移方案：
- 現況：基於 CPU / 內存指標
- 目標：KEDA 事件驅動自動擴縮，使用 RPS、事件迴圈利用率等應用層指標
結論
結論“Hugging Face 透過元資料 / 二進制分離、全文搜尋引擎升級、讀寫工作負載隔離與多層自動擴縮，在保持用戶體驗簡潔的前提下，成功應對 300 倍的規模成長。”
完整解析
詳細Hugging Face 作為全球最快成長的開源 AI 社群平台，面臨指數級規模挑戰。短短兩年內模型數從 20,000 暴增至 300 萬、資料集從 10,000 躍升至 100 萬、用戶突破 1,400 萬大關，其中逾 30% 為財富 500 強企業。此爆發式成長直接衝擊基礎設施，尤其是搜尋功能。當模型數少於 20,000 時，即使無索引也能快速回應；但用戶規模達 1,400 萬時，同樣方案完全失效。1% 的慢搜尋用戶意味著 14 萬人的負面體驗，故優化 P99 響應時間成為重中之重。
針對搜尋瓶頸，團隊詳細介紹優化歷程。過去採用 MongoDB 的 find 方法搭配正規表達式，於查詢時進行文本匹配。隨著資料量爆炸，regex 效率問題浮現導致延遲。轉折點是導入 MongoDB Atlas Search，其底層集成 Apache Lucene 全文搜尋引擎。關鍵創新在改變分詞策略：不再於查詢時分析搜尋詞，而在模型插入時就對名稱進行分詞——例如「meta-llama/llama-3.1」被拆分成「meta」「llama」「3.1」等標籤存入陣列。查詢時直接利用 Lucene 的自動完成功能迅速定位，結合趨勢分數（過去七天下載量與讚數）排序。此優化使搜尋體驗從延遲問題徹底翻身。
平台架構另一核心決策是關注點分離。MongoDB 並不儲存實際模型檔案，只維護元資料（模型名稱、配置、權限、計費等），真實的模型工件、分詞器、配置檔案存放於 AWS S3。此分離讓 Hugging Face 獨立擴展各組件：元資料層優化查詢能力、二進制層優化存儲成本、計算層自由編排。MongoDB 副本集由 7 個節點組成，寫入操作集中於主節點（保證一致性），讀取分散於從節點（提升吞吐量），隱藏節點則隔離報告查詢、複雜聚合等重操作，防止搶佔生產流量。設計確保主節點專注高一致性操作，其他工作負載由專用機器承擔。
容器編排層，Hugging Face 採用 Kubernetes 與多層自動擴縮策略。第一層是水平 Pod 自動擴縮器（HPA），根據 CPU 與記憶體閾值自動增減 Pod 數量，使樞紐規模在 10 到 500 個 Pod 間靈活變動。第二層透過 Cast AI 進行集群自動擴縮，當 HPA 需要新 Pod 但無可用節點時，Cast AI 自動新增基礎設施節點。未來計畫遷移至 KEDA，改為基於實際應用指標（每秒請求數、事件迴圈利用率）而非單純資源使用率進行擴縮，更能對應業務波動。整體設計哲學是隱藏複雜性，讓使用者按下模型按鈕、執行搜尋或下載時一切無縫運作，背後基礎設施複雜度對終端使用者完全透明。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
