Serving 2 Million Models Without Melting: Scaling the Hugging Face Hub — Arek Borucki, Hugging Face
Hugging Face’s Hub shows how to scale model search: precompute tokens, separate metadata from artifacts, isolate heavy reads, and autoscale from workload signals.
Hugging Face reports **3 million public models**, **1 million datasets**, and more than **14 million users**. Model metadata lives in MongoDB Atlas, artifacts live in object storage, and search uses precomputed tokens plus Lucene-backed Atlas Search.
For large agent-facing catalogs, optimize the read path separately from writes and binary storage. Route stale-tolerant reads and heavy aggregation away from the primary, isolate reporting, and scale both application pods and cluster nodes.
Hugging Face reports **3 million public models**, **1 million datasets**, and more than **14 million users**. Model metadata lives in MongoDB Atlas, artifacts live in object storage, and search uses precomputed tokens plus Lucene-backed Atlas Search. For large agent-facing catalogs, optimize the read path separately from writes and binary storage. Route stale-tolerant reads and heavy aggregation away from the primary, isolate reporting, and scale both application pods and cluster nodes. These choices reflect Hugging Face’s workload, not a universal blueprint. Sharding is still planned, and moving from CPU- and memory-based HPA to **KEDA workload metrics** is described as upcoming work.
This contributes a concrete read-heavy catalog architecture rather than another model-serving or retrieval technique: metadata, binaries, search, reporting, and stale-tolerant reads are scaled as distinct paths. It is useful as workload-specific evidence, not a finished blueprint, because sharding and workload-based autoscaling remain planned rather than demonstrated.