Chunks 에서 Blocks 으로: Hub 의 업로드 및 다운로드 가속화

실제로는 더 복잡합니다. 만약 중복 제거를 극대화하는 데만 집중했다면, 가능한 최소한의 chunk size 를 사용하는 설계가 필요할 것입니다. 그렇게 하면 Hub 의 인프라와 빌더에게 상당한 오버헤드가 발생합니다.

Hugging Face 의 Xet 팀에서는 CDC 를 이론에서 실제로 가져와 AI 빌더에게 더 빠른 업로드 및 다운로드를 제공합니다 (일부 경우 2-3 배). 우리의 핵심 원리는 간단합니다: 모델과 데이터셋을 구축하고 반복하는 팀의 빠른 실험과 협업을 가능하게 합니다. 이는 단순히 중복 제거뿐만 아니라 데이터를 네트워크를 통해 이동시키는 방법, 저장 방법, 그리고 전체 개발 경험을 최적화하는 것을 의미합니다.

예를 들어, 200GB 의 레포지토리를 Hub 에 업로드한다고 상상해보세요. 오늘날에는 여러 가지 방법이 있지만 모두 파일 중심 접근법을 사용합니다. 더 빠른 파일 전송을 위해 우리는 xet-core 와 hf_xet 를 오픈 소스로 공개했습니다. 이는 Rust 로 작성된 chunk 기반 접근 방식을 사용하는 huggingface_hub 의 통합입니다.

유니크한 chunk 가 있는 200GB 레포지토리를 고려하면, 모든 레포지토리를 뒷받침하는 content-addressed store (CAS) 에는 약 64KB 당 chunk 로 300 만 개의 항목이 있습니다. 모델의 새로운 버전이 업로드되거나 레포지토리의 브랜치가 다른 데이터로 생성되면 더 많은 유니크한 chunk 가 추가되어 CAS 의 항목 수가 증가합니다.

Hub 에서 거의 45PB 가 200 만 개의 모델, 데이터셋 및 공간 레포지토리에 걸쳐 있다면, 순수 chunk 기반 접근법은 690 억 개의 chunk를 유발할 수 있습니다. chunk 만을 사용하여 이 양의 콘텐츠를 관리하는 것은 다음 이유로 단순하게 실현 불가능합니다:

Network Overheads: 각 chunk 가 개별적으로 다운로드 또는 업로드되면, 각 업로드 및 다운로드에서 수백만 개의 요청이 생성되어 클라이언트와 서버를 압도합니다. 쿼리를 단순히 배치해도 문제가 저장 계층으로 이동합니다.
Infrastructure Overheads: chunk 를 개별적으로 추적하는 단순한 CAS 는 수십억 개의 항목을 필요로 하여 DynamoDB 나 S3 와 같은 서비스에서 급격한 월별 요금을 초래합니다. Hugging Face 의 규모에서는 이는 빠르게 합산됩니다.

요약하면, 네트워크 요청은 불어오며, 데이터베이스는 메타데이터를 관리하기 어렵고, 각 chunk 를 조정하는 비용은 파일 전송이 기다리는 동안 모두 급증합니다.

이러한 도전은 중요한 통찰로 이어집니다:

중복 제거는 성능 최적화일 뿐, 최종 목표는 아닙니다.

최종 목표는 모델과 데이터셋을 반복하고 협업하는 빌더의 경험을 개선하는 것입니다. 클라이언트부터 저장 계층까지의 시스템 구성 요소는 중복 제거를 보장할 필요가 없습니다. 대신, 그들은 이 작업을 돕기 위한 여러 도구 중 하나인 중복 제거를 활용합니다.

중복 제거 제약을 완화함으로써 자연스럽게 두 번째 설계 원칙에 도달하게 됩니다:

chunk 의 수와 1:1 으로 스케일하는 통신 또는 저장 전략을 피하세요.

이것은 무엇을 의미합니까? 우리는 aggregation으로 스케일합니다.

Aggregation 은 chunk 를 그룹화하고, 이를 지능적으로 참조하여 실용적인 이점을 제공하는 방식으로 참조합니다:

Blocks: 덤플링 (deduplication) 후 최대 64MB 크기의 블록으로 데이터를 묶습니다. 블록은 여전히 내용 주소화 (content-addressed) 되지만, CAS 엔트리를 1,000 배 줄입니다.Shards: Shards 는 파일과 덤블 (chunks) 간의 매핑을 제공합니다 (이를 위해 블록을 참조합니다). 이는 과거 업로드에서 생성된 shards 를 참조하여 파일의 어떤 부분이 변경되었는지 식별할 수 있게 합니다. 덤블이 CAS 에 이미 존재하는 것으로 알려져 있으면, 불필요한 전송과 쿼리가 줄어듭니다.

Together, blocks and shards unlock significant benefits. However, when someone uploads a new file, how do we know if a chunk has been uploaded before so we can eliminate an unnecessary request? Performing a network query for every chunk is not scalable and goes against the "no 1:1" principle we mentioned above.

해결책은 key chunks 입니다. 이는 덤블 해시 (chunk hash) 를 기반으로 간단한 모듈로 조건에 따라 선택된 모든 덤블의 0.1% 소집합입니다. 우리는 이 key chunks 과 그들을 찾은 shards 에 대한 글로벌 인덱스를 제공하므로, 덤블이 쿼리될 때 관련 shard 가 반환되어 로컬 덤플링을 제공합니다. 이는 공간적 국소성 (spatial locality) 원리를 활용하게 합니다. 만약 key chunk 가 shard 에 참조되면, 동일한 shard 에 다른 유사한 덤블 참조가 이용 가능한 가능성이 높습니다. 이는 더 많은 덤플링을 가능하게 하고 네트워크 및 데이터베이스 요청을 줄입니다.

Hub 는 현재 3.5PB 이상의 .gguf 파일을 저장하고 있으며, 대부분 Hub 의 다른 모델들의 양자화 버전 (quantized versions) 입니다. 양자화 모델은 값이 더 작은 정수 범위와 스케일링으로 제한되는 양자화의 특성 때문에 덤플링에 흥미로운 기회를 제공합니다. 이는 중량 행렬의 값 범위를 자연스럽게 제한하여 더 많은 반복을 유도합니다. 또한, 많은 양자화 모델 저장소는 Q4_K, Q3_K, Q5_K 와 같이 많은 중복이 있는 여러 다른 변형을 저장합니다.

실제로 좋은 예는 bartowski/gemma-2-9b-it-GGUF 입니다. 이는 google/gemma-2-9b-it 의 29 개 양자화를 포함하여 총 191GB 를 차지합니다. 업로드를 위해 hf_xet을 huggingface_hub과 통합하여 덤블 수준의 덤플링을 로컬로 수행한 후 블록 수준에서 데이터를 집계하고 저장합니다.

업로드 한 후 우리는 몇 가지 멋진 패턴을 볼 수 있습니다! 우리는 각 블록의 덤플링 비율을 보여주는 시각화를 포함했습니다. 블록이 어두울수록 해당 블록의 일부가 모델 버전 간에 더 자주 참조됩니다. 이 시각화를 호스팅하는 Space 로 이동하면, 열매체 (heatmap) 셀 위에 마우스를 올리면 모든 모델에서 해당 블록의 참조를 오렌지색으로 강조하고, 셀을 클릭하면 해당 블록을 공유하는 다른 모든 파일을 선택합니다:

단일 덤블링 블록은 몇 MB 의 절감만 나타낼 수 있지만, 많은 중복된 블록이 있다는 것을 알 수 있습니다! 이렇게 많은 블록이 빠르게 합쳐집니다. 191GB 를 업로드하는 대신, gemma-2-9b-it-GGUF 저장소의 Xet 백업 버전은 약 97GB 의 총합으로 테스트 CAS 환경에 1515 개의 고유 블록을 저장합니다 (약 94GB 의 절감).

저장소 개선은 상당하지만, 실제 혜택은 Hub 기여자에게 무엇을 의미하는지입니다. 50MB/s 에서 덤플링 최적화는 업로드 시간의 4 시간 차이; 거의 2 배의 속도 향상:

Repo	Stored Size	Upload Time @ 50MB/s
Original	191 GB	509 minutes
Xet-backed	97 GB	258 minutes

동일하게도 로컬 chunk caching 은 다운로드 속도를 크게 향상시킵니다. 파일이 변경되거나 로컬 chunk cache 와 상당한 중복을 가지는 새로운 양자화 (quantization) 가 추가되면, 변경되지 않은 chunk 들은 다시 다운로드할 필요가 없습니다. 이는 전체적으로 새로 생성되거나 업데이트된 파일을 다운로드해야 하는 파일 기반 접근 방식과 대조됩니다.

이를 종합하면, 로컬 chunk 레벨의 중복 제거와 블록 레벨의 집계는 저장뿐만 아니라 Hub 에서 개발하는 것을 극적으로 단순화함을 보여줍니다. 이 수준의 효율성을 파일 전송에 제공함으로써 AI 빌더들은 더 빠르게 진행할 수 있고, 반복을 신속하게 수행하며 인프라 병목 현상을 걱정하지 않을 수 있습니다. 대형 파일을 Hub 에 푸시는 모든 분 (새로운 모델 양자화 또는 훈련 데이터셋의 업데이트 버전이든 간에) 에게는 집중을 건설과 공유로 전환하고 기다림과 문제 해결에서 벗어나도록 도와줍니다.

우리는 Xet 기반 저장소를 몇 주와 몇 달 안에 첫 번째로 출시하며, 우리는 이러한 속도를 Hub 의 모든 빌더에게 제공하여 파일 전송을 보이지 않는 것처럼 느끼게 할 것입니다.