LFS와의 하위 호환성
LFS와의 하위 호환성 (Backward Compatibility with LFS)
레거시/비-Xet 인식 클라이언트의 업로드는 저장소가 이미 Xet 기반이더라도 여전히 표준 Git LFS 경로를 따릅니다. 파일이 LFS에 업로드되면 백그라운드 프로세스가 해당 파일을 자동으로 Xet 스토리지 사용으로 마이그레이션해요. Xet 아키텍처는 Git LFS 브리지를 제공해 레거시 클라이언트가 Xet 기반 저장소에서 파일을 다운로드할 수 있도록 하위 호환성을 보장합니다. Xet 인식 클라이언트는 CAS로부터 파일 재구성 정보를 받아 Xet 기반 파일을 다운로드하지만, 레거시 클라이언트는 브리지에서 단일 URL을 받아 요청한 파일을 재구성하고 리소스 URL을 반환하는 작업을 수행해요. 이를 통해 URL로 파일을 다운로드할 수 있어 허브 웹 인터페이스나 curl을 계속 사용할 수 있어요. LFS 파일 업로드를 자동으로 마이그레이션하고 이전 클라이언트가 Xet 기반 저장소에서 계속 다운로드하게 함으로써, 유지 관리자와 허브의 다른 사용자들은 자기 속도에 맞춰 파이프라인을 업데이트할 수 있어요.
출처: 문서
본문
Xet 스토리지는 기존 허브 저장소에 매끄러운 전환을 제공해요. Xet 백엔드가 관여하는지 알 필요가 전혀 없어요. Xet 기반 저장소는 계속 Git LFS 포인터 파일 형식을 사용하며, Xet backed hash의 추가는 웹 인터페이스의 편의를 위한 것일 뿐이에요. 실질적으로 이는 기존 저장소와 새로 만든 저장소를 bare clone(GIT_OBJECT_DIRECTORY 밖 클론)으로 복제해도 달라 보이지 않음을 의미해요. 각 대형 파일(또는 바이너리 파일)은 계속 Git LFS 포인터 파일 스펙에 맞는 포인터 파일을 갖게 됩니다.
이 대칭성 덕분에 비-Xet 인식 클라이언트(예: 이전 버전의 huggingface_hub)도 걱정 없이 Xet 기반 저장소와 상호작용할 수 있어요. 실제로 저장소 내에서 Git LFS와 Xet 기반 파일이 혼재될 수 있어요. Xet 백엔드는 파일이 Git LFS인지 Xet 스토리지인지 표시해, 다운스트림 서비스가 어떤 스토리지 시스템에 콘텐츠가 있든 S3에서 적절한 URL을 요청할 수 있게 해 줘요.
레거시 스토리지: Git LFS
허브의 레거시 스토리지 시스템인 Git LFS는 Xet 기반 저장소와 비슷한 많은 규칙을 사용해요. 허브의 Git LFS 백엔드는 Amazon Simple Storage Service (S3)예요. Git LFS가 호출되면 SHA256 해시로 파일을 S3에 저장해 파일명을 정해서 이후 접근에 사용해요. 이 스토리지 아키텍처는 비교적 단순하며 허브가 수백만 개의 모델, 데이터셋, Spaces 저장소 파일을 저장할 수 있게 해 줬어요.
Git LFS의 주요 한계는 파일 중심의 중복 제거(deduplication) 방식이에요. 파일을 얼마나 작게든 크게든 변경하면 전체 파일이 새 버전으로 기록돼요. 즉 변경이 크든 작든 전체 파일을 업로드(저장소 커밋 시)하거나 다운로드(최신 버전을 내 머신으로 가져올 때)해야 하므로 파일 전송에 상당한 오버헤드가 발생해요.
이는 나쁜 개발자 경험과 추가 스토리지의 확산을 초래해요.