Rearchitecting Hugging Face Uploads and Downloads
Quick Summary
허깅페이스는 대용량 모델·데이터셋 전송의 한계를 극복하기 위해 바이트 단위 중복 제거와 검증을 수행하는 콘텐츠 주소 기반 저장소(CAS)를 도입하고, 전 세계 업로드 분포에 맞춰 세 지역에 노드를 배치하는 새로운 업로드·다운로드 구조를 설계했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
허깅페이스는 대용량 모델·데이터셋 전송의 한계를 극복하기 위해 바이트 단위 중복 제거와 검증을 수행하는 콘텐츠 주소 기반 저장소(CAS)를 도입하고, 전 세계 업로드 분포에 맞춰 세 지역에 노드를 배치하는 새로운 업로드·다운로드 구조를 설계했다.
📌 핵심 요약
- 2024년 10월 11일 하루 동안 허깅페이스 허브에는 88개국에서 820만 건의 업로드 요청과 130.8TB의 데이터 전송이 발생했으며, 대용량 파일 증가로 기존 전송 구조의 한계가 커졌다.
- 새 구조는 콘텐츠 주소 기반 저장소(CAS)를 전송의 첫 관문으로 두고, 읽기는 단순하고 빠르게 유지하면서 쓰기에서는 파일을 청크 단위로 분석해 새로운 데이터만 전송하는 방식을 채택한다.
- CAS는 업로드 청크를 검증한 뒤 S3에 저장하고, 감사 추적과 상세 로그를 제공해 악성·유효하지 않은 데이터 차단과 운영 문제 진단을 강화한다.
- 업로드의 80%가 상위 7개국, 95%가 상위 20개국에서 발생한다는 분석을 바탕으로 미국 동부, 프랑스 서부, 싱가포르에 세 개의 CAS 거점을 배치하고 각각 4개, 4개, 2개 노드를 할당할 계획이다.
- 초기 추정에서는 첫 홉 거리가 늘어 전체 업로드 대역폭이 48.5Mbps에서 42.5Mbps로 약 12% 감소하지만, 중복 제거·압축·필요 청크만 전송하는 최적화가 이를 상쇄할 것으로 보고 단계적인 벤치마크와 확장을 추진한다.
🧩 주요 포인트
- 2024년 10월 11일 하루 동안 허깅페이스 허브에는 88개국에서 820만 건의 업로드 요청과 130.8TB의 데이터 전송이 발생했으며, 대용량 파일 증가로 기존 전송 구조의 한계가 커졌다.
- 새 구조는 콘텐츠 주소 기반 저장소(CAS)를 전송의 첫 관문으로 두고, 읽기는 단순하고 빠르게 유지하면서 쓰기에서는 파일을 청크 단위로 분석해 새로운 데이터만 전송하는 방식을 채택한다.
- CAS는 업로드 청크를 검증한 뒤 S3에 저장하고, 감사 추적과 상세 로그를 제공해 악성·유효하지 않은 데이터 차단과 운영 문제 진단을 강화한다.
- 업로드의 80%가 상위 7개국, 95%가 상위 20개국에서 발생한다는 분석을 바탕으로 미국 동부, 프랑스 서부, 싱가포르에 세 개의 CAS 거점을 배치하고 각각 4개, 4개, 2개 노드를 할당할 계획이다.
- 초기 추정에서는 첫 홉 거리가 늘어 전체 업로드 대역폭이 48.5Mbps에서 42.5Mbps로 약 12% 감소하지만, 중복 제거·압축·필요 청크만 전송하는 최적화가 이를 상쇄할 것으로 보고 단계적인 벤치마크와 확장을 추진한다.
🧠 상세 정리
1. 글로벌 업로드 규모와 기존 구조의 한계
허깅페이스의 Xet 팀은 저장소 백엔드 개선을 위해 2024년 10월 11일의 업로드 요청을 24시간 단위로 분석했다. 이 기간에 88개국에서 820만 건의 업로드 요청이 발생했고, 전송된 데이터는 130.8TB에 달했다. 현재 업로드 데이터는 미국 동부 리전의 S3 버킷에 저장되며 S3 Transfer Acceleration으로 전송을 최적화하고, 다운로드는 400개가 넘는 엣지 위치를 가진 CloudFront를 통해 캐시·배포한다. 그러나 일반 웹 콘텐츠에 맞춰진 CDN에는 50GB 파일 크기 제한이 있어 계속 커지는 모델과 데이터셋 파일을 처리하기 어렵다. 실제로 Meta-Llama-3-70B의 가중치는 총 131GB이며, 허브의 권장 방식에 따라 약 20GB 크기의 파일 30개로 분할돼 있다. 기존처럼 파일을 불투명한 단일 객체로 취급하는 구조로는 대규모 전송뿐 아니라 고급 중복 제거와 압축까지 적용하기 어렵다는 것이 재설계의 출발점이다.
2. CAS와 ‘단순한 읽기, 지능적인 쓰기’ 원칙
새 아키텍처는 콘텐츠 주소 기반 저장소인 CAS를 콘텐츠 배포의 첫 관문으로 삽입하고, 그 위에 맞춤형 업로드·다운로드 프로토콜을 구축한다. 설계 원칙은 ‘읽기는 단순하게, 쓰기는 지능적으로’이며, Git LFS처럼 파일 전체를 하나의 불투명한 블롭으로 다루지 않고 바이트 수준에서 내용을 분석한다. 읽기 요청이 들어오면 CAS 서버가 해당 파일을 재구성하는 데 필요한 정보를 제공하고, 실제 데이터는 계속 미국 동부 리전의 S3 버킷에 보관된다. 다운로드용 CDN 역할 역시 CloudFront가 유지하므로, 기존의 글로벌 배포 기반을 버리지 않으면서 CAS를 제어 계층으로 추가하는 형태다. 읽기 경로는 처리 단계를 불필요하게 복잡하게 만들지 않고 높은 처리량과 낮은 지연 시간을 확보하는 데 초점을 맞춘다. 즉, 저장소와 CDN의 핵심 역할은 유지하되 파일을 이해하고 재구성하는 기능을 CAS가 담당하도록 책임을 분리한 구조다.
3. 청크 기반 업로드와 검증·최적화
쓰기 경로에서는 업로드 요청도 CAS 서버로 전달되지만, 파일 전체가 아니라 청크 단위로 일치 여부를 확인한다. CAS가 이미 존재하는 청크를 찾아내면 huggingface_hub 같은 클라이언트에 실제로 필요한 새 청크만 보내도록 지시하고, 수신한 청크를 검증한 뒤 S3에 업로드한다. 이 방식은 동일하거나 유사한 데이터의 반복 전송을 줄이는 동시에 유효하지 않거나 악의적인 데이터가 저장소에 들어가는 것을 제어할 수 있게 한다. 바이트 수준 관리 덕분에 파일 형식별 최적화도 가능해져, 팀은 Parquet 파일의 중복 제거 가능성을 높이는 방법을 연구했고 Safetensors 같은 텐서 파일의 압축도 조사하고 있다. 원문은 텐서 파일 압축이 업로드 관련 부담을 10~25% 줄일 잠재력이 있다고 설명한다. 또한 전송 제어 계층에서 감사 추적과 상세 로그를 수집함으로써 과거에는 블랙박스에 가까웠던 업로드 과정을 관찰하고, 인프라 팀이 문제를 더 빠르게 식별·해결할 수 있게 된다.
4. 업로드 분포에 따른 세 지역 CAS 배치
맞춤형 프로토콜을 전 세계에서 운영하려면 CAS 서비스의 지리적 배치를 결정해야 한다. 팀은 처음에 광범위한 글로벌 범위를 제공하는 Lambda@Edge를 검토했지만, CloudFront 트리거에 의존하는 구조가 새 업로드 경로와 맞지 않아 AWS의 34개 리전 중 일부에 직접 CAS 노드를 배치하기로 했다. 24시간 동안의 S3 PUT 요청을 분석한 결과 업로드 활동은 북미와 유럽에서 하루 종일 높은 수준으로 이어졌고, 아시아의 비중도 강하고 성장하는 흐름을 보였다. 전체 88개국 가운데 상위 7개국이 업로드 바이트의 80%를 차지했고, 상위 20개국은 총 업로드 용량과 요청의 95%를 담당했다. 미국은 가장 큰 업로드 발생지였으며, 유럽은 룩셈부르크·영국·독일을 포함한 중서부 지역에 집중되고 아시아는 싱가포르·홍콩·일본·한국이 중심이었다. 이 분포를 바탕으로 미주를 담당하는 us-east-1, 유럽·중동·아프리카를 담당하는 eu-west-3, 아시아·오세아니아를 담당하는 ap-southeast-1의 세 거점이 선정됐다.
5. 노드 할당과 단계적 성능 검증
세 지역으로 나눈 결과 미국과 유럽이 업로드 바이트의 78.4%, 아시아가 21.6%를 차지해 CAS 거점 사이에 비교적 균형 잡힌 부하를 구성할 수 있었다. 예상 트래픽을 기준으로 us-east-1과 eu-west-3에는 각각 4개 노드, ap-southeast-1에는 2개 노드를 배치할 계획이며, 아시아에는 성장 여력을 남기고 미국과 유럽은 필요에 따라 확장할 수 있도록 했다. 일부 사용자는 첫 번째 접속 지점까지의 거리가 늘어나지만, 전체 업로드의 추정 대역폭은 48.5Mbps에서 42.5Mbps로 약 12% 감소하는 수준으로 계산됐다. 팀은 이 감소가 필요한 청크만 전송하는 방식과 기타 시스템 최적화로 충분히 상쇄될 것으로 판단했다. 2024년 말까지 먼저 us-east-1에 단일 CAS를 운영 환경에 도입하고, 내부 저장소를 새 시스템에 복제해 전송 성능을 측정할 예정이다. 이후 나머지 두 거점으로 CAS를 복제해 추가 벤치마크를 수행하고, 결과에 따라 전체 저장소 백엔드가 자리 잡기 전까지 구조를 계속 조정한다.
6. 인프라 분석을 넘어선 데이터 활용 가능성
이번 분석은 CAS 배치와 전송 구조를 결정하는 데 그치지 않고, 허깅페이스가 보유한 오픈소스 머신러닝 생태계 데이터를 더 깊이 이해할 수 있는 출발점도 제공한다. 허깅페이스 허브에는 세계 각지에서 생성된 대규모 모델과 데이터셋이 모이므로, 업로드 패턴은 지역별 머신러닝 활동과 기술 흐름을 관찰할 수 있는 자료가 된다. 후속 분석에서는 업로드된 모델을 자연어 처리, 컴퓨터 비전, 로보틱스, 대규모 언어 모델 등의 용도별로 분류하고, 각 분야의 지리적 추세를 살펴볼 수 있다고 제안한다. 이러한 정보는 어느 지역에 인프라를 배치하고 확장할지 판단하는 근거가 되는 동시에, 세계적으로 어떤 머신러닝 활용 분야가 성장하는지 보여주는 관점도 제공한다. 글은 현재 분석 결과를 지역별로 확인할 수 있는 인터랙티브 스페이스를 안내하고, Xet 팀의 후속 개발 내용을 계속 공개하겠다고 밝힌다. 따라서 이번 작업은 대용량 파일 전송 문제를 해결하는 기술적 재설계와 글로벌 오픈소스 머신러닝 활동을 분석하는 데이터 기반을 함께 마련하는 과정으로 정리된다.
🧾 핵심 주장 / 시사점
- 새 구조의 핵심은 S3와 CloudFront를 교체하는 것이 아니라, CAS를 제어 계층으로 추가해 파일 재구성·청크 판별·검증·관찰 기능을 분리하는 데 있다.
- 전체 88개국을 동일하게 지원하려 하기보다 업로드의 95%가 집중된 상위 20개국의 분포를 기준으로 세 거점을 선택해 비용과 사용자 경험의 균형을 맞췄다.
- 바이트 단위 처리는 중복 청크 전송을 줄이는 성능 최적화뿐 아니라 형식별 압축, 업로드 데이터 검증, 감사 추적과 장애 진단을 하나의 프로토콜 안에서 가능하게 한다.
✅ 액션 아이템
- 하루 업로드 820만 건·130.8TB와 대용량 증가 추세를 기준으로 CAS 전환 전후 처리량·지연·성공률을 동등 지표로 비교한다.
- 쓰기 경로는 파일을 청크 단위로 분석해 신규 데이터만 전송하고 읽기는 단순하고 빠르게 유지하는 CAS 파이프라인 설계를 검증한다.
- 업로드 청크 검증 뒤 S3 저장·감사 로그·상세 로그를 결합해 악성·유효하지 않은 데이터 차단 및 운영 진단 기준을 정한다.
❓ 열린 질문
- 청크 단위 검증과 감사 로그 체계가 실제로 악성·유효하지 않은 데이터의 탐지 정확도를 얼마나 개선할 것인가?
- 상위 7개국(80%), 상위 20개국(95%) 유입 구조 변화 시 미국 동부·프랑스 서부·싱가포르 4·4·2 노드 배치 비중은 어떤 지표로 조정할 것인가?
- 48.5Mbps에서 42.5Mbps로 계산된 초기 대역폭 저하가 중복 제거·압축·필요 청크 전송 최적화로 상쇄되는지 어떤 단계별 벤치마크 지표를 우선 볼 것인가?