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

한 줄 핵심

Hugging Face Hub가 300만 개 모델과 1400만 사용자 규모에서도 빠른 검색과 안정적인 서비스를 유지하려면, 메타데이터·검색·오토스케일링·샤딩을 분리해 수평 확장하는 인프라 설계가 핵심이다.

시간별 요약

1. 0:01
   Hugging Face는 300만 모델, 100만 데이터셋, 1400만 사용자 규모로 성장했고, 이 폭증한 트래픽과 데이터가 인프라 설계를 다시 생각하게 만들었다. 특히 대규모 공개 모델 출시가 계속 새로운 모델과 데이터셋을 쏟아내면서 저장·인덱싱·검색이 가장 큰 병목이 되었다.
2. 4:02
   검색 품질의 핵심은 평균 응답속도보다 P99를 지키는 것이며, 이를 위해 검색용 메타데이터를 별도 읽기 컬렉션으로 분리하고 삽입 시점에 토큰화를 수행한다. 과거의 MongoDB find와 regex 기반 검색은 규모가 커지며 지연이 커졌고, 지금은 Atlas search와 Apache lucine 기반 autocomplete로 빠르게 응답한다.
3. 13:00
   MongoDB는 단일 저장소가 아니라 역할별로 분리해 사용하며, 쓰기와 강한 일관성이 필요한 요청은 primary, 대량 집계와 읽기 트래픽은 secondaries, 리포팅과 실험성 쿼리는 hidden node로 보낸다. 이렇게 분산하면 primary의 부담을 줄이면서도 수백 개 서비스가 동시에 수백만 건의 쿼리를 처리할 수 있다.
4. 17:00
   현재는 Kubernetes의 horizontal pod autoscaler와 Cast AI로 pod와 노드 두 층에서 함께 확장하지만, 앞으로는 실제 요청량을 반영하는 KEDA로 더 정교하게 바꾸려 한다. 최종 목표는 내부 구조가 복잡해져도 사용자는 모델 업로드·검색·다운로드를 항상 단순하고 빠르게 경험하게 만드는 것이다.

실무 인사이트

• 대규모 검색 서비스는 평균 성능보다 P99와 읽기 경로 최적화가 체감 품질을 좌우하므로, 검색 전용 읽기 모델과 사전 토큰화를 먼저 설계하는 것이 효과적이다.
• 메타데이터, 바이너리 아티팩트, 분석 쿼리를 분리하면 각 워크로드를 서로 다른 저장소와 노드에 최적화할 수 있어 병목과 비용을 동시에 줄일 수 있다.
• 오토스케일링은 pod만 늘리는 것으로 끝나지 않으며, 노드 부족까지 포함한 이중 확장과 실제 트래픽 지표 기반의 스케일링 전략이 필요하다.