Xet이 Hugging Face Hub에 상용화되었습니다

지난 몇 주 동안, Hugging Face 의 Xet 팀은 첫 번째 모델 및 데이터셋 저장소를 LFS 에서 Xet 스토리로 마이그레이션함으로써 중요한 한 걸음을 내딛었습니다.

이는 Hugging Face 의 Hub 에 대한 비전을 실현하기 위한 여러 단계 중 하나로, AI 빌더들이 거대 모델과 데이터셋을 더 효과적으로 구축하고 반복하며 협업할 수 있도록赋能합니다. 기술 자체에 대한 심층적인 내용을 원하시면 다음 게시물을 확인하세요:

• From Files to Chunks: Improving Hugging Face Storage Efficiency
• Rearchitecting Hugging Face Uploads and Downloads
• From Chunks to Blocks: Accelerating Uploads and Downloads on the Hub

하지만 이 글은 핵심 기술에 대한 것이 아닙니다. Xet 을 Hub 에 적용하는 과정의 behind-the-scenes 관점입니다. 우리의 proof-of-concept 에서 첫 번째 저장소 마이그레이션까지带您를 통해 보여드립니다.

마이그레이션은 Hub 의 다운로드 트래픽 약 6% 를 Xet 인프라로 전환시켰으며, 여러 핵심 구성 요소를 검증하고 다양한 방식으로 저장소가 접근되는 방식 (예: 로컬 개발 환경, 다른 라이브러리, CI 시스템, 클라우드 플랫폼 등) 과의 통합을 테스트했습니다. 거의 200 만 명의 개발자가 200 만 개의 공개 저장소에서 작업하고 있으므로, 실제 사용이 최종적인 검증장이 됩니다. Xet 스토리 같은 복잡한 시스템을 엔지니어링하는 것은 균형 잡힌 행위입니다. 규모, 성능, 신뢰성을 계획하지만, 바이트가 움직이기 시작하면 도전 과제가 발생합니다. 핵심은 디자인과 이론에서 실천으로 넘어갈 때를 아는 것입니다.

오늘날 저장소를 뒷받침하는 LFS 는 큰 파일을 저장소 외부의 별도의 객체 스토리지에 저장합니다. LFS 는 파일 수준에서 중복을 제거합니다. 심지어 작은 수정조차도 전체를 업로드해야 하는 새로운 리비전을 생성합니다; 많은 Hub 저장소에서 발견되는 멀티 기가바이트 파일들에게 고통스럽습니다.

반면, Xet 스토리지는 콘텐츠 정의된 chunking (CDC) 을 사용하여 바이트 수준에서 (~64KB 데이터 chunks) 중복을 제거합니다. Parquet 파일의 한 행을 수정하거나 GGUF 모델의 작은 메타데이터 조각을 조정하면, 변경된 chunks 만이 전송됩니다.

이는 큰 파일 전송에 상당한 이점을 제공합니다. 예를 들어, Xet 팀은 성능 대시보드를 구동하는 내부 약 5 GB SQLite 데이터베이스를 유지합니다. LFS 를 사용하면 1 MB (현재 평균 업데이트) 를 추가하려면 전체 5 GB 파일을 다시 업로드해야 합니다. Xet 스토리지에서는 새로운 데이터 만을 푸시합니다.

이는 대시보드 업로드가 LFS 로 백업된 경우보다 13 분 대신 10 분의 1 초 (50Mb/s) 를 소요함을 의미합니다.

이를 구현하기 위해서는 다음 구성 요소 간의 조정が必要です:

• Xet aware 클라이언트

• 데이터 ~64 KB chunks 로 분할합니다.

• 동일한 chunks 를 로컬에서 중복 제거하고 업로드 전에 ~64 MB blocks 으로 집계합니다.

• Hugging Face Hub

• 클라이언트 요청을 수신하고 올바른 저장소로 라우팅합니다.

• 인증 및 보안 보장을 제공합니다.

• Content Addressed Store (CAS)

• 업로드 및 다운로드를 위한 chunk 기반 중복 제거를 강제합니다.

• LFS Bridge 를 포함하여 오래된, Xet 이 아닌 클라이언트들을 위해 작동하며 전통적인 LFS 서버와 유사하게 단일 URL 을 제공합니다.

• Amazon S3

생산을 이전하기 전에, 시스템은 업로드 및 다운로드를 huggingface_hub 를 통해 가능하게 하는 기능의 steel thread 를 구축할 ephemeral 환경으로 출시되었습니다. 아래 비디오는 1 개월 후의 우리의 진척도를 보여줍니다:

Hub 의 복잡한 생태계 (프라이버시, 후방 호환성, 분산 등) 와 맞서 싸우는 통합 지점의 난해한 문제들을 해결하는 과정에서, 팀은 빠른 프로브-오브-컨셉의 뜨겁고 높은 에너지를 경험한 후, Hugging Face 팀원들의 인프라가 프로덕션으로 이동했습니다. 실제 사용이 이제 들어오면서, 우리는 첫 대규모 마이그레이션을 진행했습니다.

2 월 20 일 오전 10 시에 모든 사람이 준비되었습니다. 몇 주 전에는 팀이 LFS 에서 Xet 으로 파일을 마이그레이션하는 내부 도구를 구축했고, 또한 필요시 저장소를 LFS 로 롤백할 수 있는 도구도 구축했습니다. 이제 그것이 시험의 시간이었습니다. Grafana 와 Kibana 는 새로운 로그와 지표로 점등되어 실시간으로 부하 이동을 보여줍니다.

Kibana 의 그림은 동일하지만, 여기서는 우리는 점심 휴식을 취했을 때를 알 수 있습니다:

그날 저녁에, 우리는 총 4.5 TB 의 모든 목표 저장소를 Xet 스토리지로 성공적으로 마이그레이션했습니다. 각 저장소의 다운로드가 이제 우리의 인프라로 제공됩니다.

어떤 출시도 그 교훈을 갖지 않습니다. 시스템은 부하를 부드럽게 처리했고 마이그레이션은 큰 중단 없이 진행되었지만, 바이트들이 다양한 구성 요소를 통해 흐르면서 우리는 몇 가지 경향을 보이기 시작했습니다.

마이그레이션 후 네트워크 트루스피트를 검토했을 때, CAS 는 클라이언트에게 반환하는 데이터보다 4 배 더 많은 데이터를 다운로드하고 있었습니다:

추가 조사에서 우리는 CAS 의 요청의 대부분이 파일 내의 10MB 범위의 데이터에 대한 것이었습니다. 이러한 요청은 hf_transfer 를 사용하여 대형 파일의 다운로드를 가속화하는 사용자들로부터 옵니다. 요청된 범위들은 블록 경계와 정렬되지 않으며, 블록 형식은 블록 내에서 직접적으로 데이터를 건너뛰기 위해 압축되지 않은 청크 길이를 제공합니다.

CAS 는 블록의 시작에서부터 스트리밍하고, 요청된 데이터를 찾기까지 읽습니다.

평균 크기가 60MB 인 블록과 해당 블록 내의 범위에 대한 여러 부분 요청이 주어지면 오버헤드가 누적됩니다. CAS 는 210 MB 를 다운로드하여 60 MB 를 전달하며, 이는 다운로드된 바이트 : 전송된 바이트 비율이 3.5 : 1 입니다. 규모가 크고 불규칙한 크기의 블록과 몇 개의 블록을 가로지르는 범위가 있을 때, 4 바이트 다운로드 : 1 바이트 전송 비율은 일치합니다.

이미지는 보통 천 단어에 그치지 않습니다:

이를 해결하기 위해, 우리는 청크 길이 메타데이터를 저장하는 블록 형식을 업데이트하여 CAS 가 각 요청이 실제로 필요로 하는 것만 다운로드하도록 했습니다. 이 형식 변경은 다음을 위한 조정된 업데이트가 필요했습니다:

• CAS API
• 블록 메타데이터 형식
  2^16 + 1
  S3 의 블록 (이것은 내가 맹세하는 우연입니다)

모두가 다운타임 없이 수행되었습니다.这不仅 resulted in CAS 다운로드와 반환 데이터의 균형 비율을 달성했지만, 또한 전체적으로 GET 지연 시간을 약 35% 감소시켰습니다.

동시에, 우리는 또한 우리의 CAS 클러스터에 예상치 못한 부하 불균형을 보았습니다. 하나의 포드는 수백 개의 활성 업로드로 스파이크했고 다른 포드는 단 자리수에서 진행되었습니다. 로드 밸런서의 라우팅 알고리즘을 (라운드 로빈에서 최소 미완료 요청으로 변경) 하고 더 많은 노드를 추가하는 것이 순간에는 큰 차이를 만들지 못했습니다.

더 깊이 파고들어서 우리는 업로드 중 CAS 가 fsync 를 호출하지 않고 유효성 검사 전에 임시 파일에 작성하여 OS 에 페이지 캐시에서 작성을 버퍼링할 수 있게 합니다. 업로드의 스파이크가 들어오면, 비flush 된 페이지 캐시는 증가된 메모리 압력으로 이어집니다.

OS 가 페이지 캐시를 디스크로 플러시 (flush) 하려 할 때, pod 은 블록 스토리지에서 Throughput throttling 을 경험하며 업로드에 지연이 발생합니다. 업로드가 천천히 처리되는 동안 새로운 요청들이 계속 들어와 디스크를 더 밀어넣습니다. 이는 악순환을 만들어 업로드 대기열과 우리가 마이그레이션 중 관찰한 불균형을 초래합니다.

Pod 이 이 상태에 빠지지 않도록, 각 머신이 수용하는 동시 업로드 수에 한도를 두고, 그 한도가 도달하면 요청을 거절하고 클러스터 내 다른 Pod 으로 요청을 전달합니다. 만약 클러스터의 모든 Pod 이 이 상태에 빠지면, 자동 확장 정책이 작동합니다. 장기적인 해결책으로는 디스크 동기화를 강제하거나, 온디스크 버퍼링을 제거하거나, 더 나은 Throughput 을 가진 임시 스토지로 전환하는 것 등이 있을 수 있습니다.

이 두 가지 문제는 중요한 아키텍처 개선으로 이어졌지만, 마이그레이션 이후 몇 주 동안 팀이 해결한 유일한 문제가 아니었습니다. 우리는 또한 다른 성능 문제를 해결했고, 메모리 누수 (우리는 이를 고쳤지만 여전히 근본 원인을 확정할 수 없는 상태) 와 AWS 의 조언에 따라 LFS Bridge 를 Application Load Balancer (ALB) 에서 Network Load Balancer (NLB) 로 마이그레이션하여 트래픽 폭주 시 확장성을 개선했습니다.

PROD 환경과 달리 테스트 환경은 대규모 사용자 행동을 모사할 수 없습니다. 신중한 통합 작업과 Hugging Face 팀원들이 인프라를 몇 개월 동안 테스트해 보았음에도 불구하고, 우리는 실제 사용량을 시스템에 흘려보낼 때만 코너 케이스가 드러났습니다.

마이그레이션은 실제 트래픽을 모사합니다. 인프라에 더 많은 트래픽이 들어가기 전에 이러한 문제를 발견하기 위해 마이그레이션을 단계적으로 스테이지함으로써, 다운타임을 방지하고 중단 없이 해결했습니다. 전체 Hub 가 Xet 에서 첫날부터 시작하는 것보다 분수의 트래픽과 스토리를 관리하는 것은 상대적으로 쉬웠습니다.

학습을 합성 (Compound) 합니다. 인프라 및 시스템 설계는 수주에 걸쳐 점진적으로 강화되었습니다. Xet 의 모든 향후 바이트와 네트워크 요청은 이러한 교훈의 혜택을 받게 됩니다.

요약하자면, 실제 세계의 부하가 이러한 문제를 드러내는 데 필수적이었고, 단계적 마이그레이션이 이를 안전하게 해결할 수 있게 했습니다. 이것이 우리가 더 빠른 업로드, 적은 병목 현상, 최소한의 중단으로 Hugging Face 커뮤니티 전체에 Xet 기반 저장소를 신뢰성 있게 확장하는 방법입니다.

초기 마이그레이션이 완료되면서, Xet 은 이제 Hugging Face Hub 에 있습니다.

우리는 huggingface_hub 와의 공식 통합을 최종화하고 있으며, 이는 현재 워크플로우에 큰 변화 없이 Xet 의 혜택을 받을 수 있음을 의미합니다. 시작하려면:

Waitlist 에 가입하세요- 사용자 또는 조직 계정 (관리자/쓰기 권한이 있는 경우) 로 여기에 등록하세요.

• 승인되면, 새로운 저장소는 자동으로 Xet 기반 스토리를 활용합니다.
• 우리는 기존 저장소를도 마이그레이션할 것이므로 더 빠른 전송을 놓치지 않습니다.

보통의 도구 사용하세요- hf_xet Python 패키지가 곧 huggingface_hub 에 출시됩니다. transformers 또는 datasets 라이브러리를 사용하는 경우, 이미 huggingface_hub 를 사용하고 있으므로 동일한 환경에서 hf_xet 를 설치할 수 있습니다. 설치 단계와 문서는 곧 제공됩니다.

• 기존에 사용하던 명령어로 큰 파일의 다운로드 및 업로드를 계속 진행하세요.

혜택을 즐기세요- 업로드 및 다운로드 대기 시간이 줄어들고, 큰 파일의 반복이 빨라집니다.

• 팀 내 모든 사람이 hf_xet 로 업그레이드하여 전체 혜택을 누릴 수 있지만, 레거시 클라이언트는 LFS Bridge 를 통해 호환성을 유지합니다.

질문이 있으시다면 댓글에 남겨주세요 👇 또는 Xet 팀 페이지에서 토론을 시작해 주세요. 더 빠른 웹 업로드와 더 빠른 Git 워크플로우를 포함한 추가 기능들을 출시하며, 모든 Hugging Face AI 빌더에게 더 빠른 대용량 파일 협업을 제공하겠습니다!