🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hugging Face Storage Buckets는 자주 변경되는 머신러닝 중간 산출물을 빠르게 저장·동기화·관리하고, Xet 기반 중복 제거와 사전 워밍을 통해 전송 효율과 데이터 접근성을 높이는 Hub 네이티브 객체 스토리지입니다.

📌 핵심 요약

• Storage Buckets는 체크포인트, 옵티마이저 상태, 가공 데이터 조각, 로그, 에이전트 추적 기록처럼 자주 생성·수정되지만 버전 관리가 필요하지 않은 중간 산출물을 위한 비버전형 저장소입니다.
• 사용자 또는 조직 네임스페이스와 Hugging Face 권한 체계를 그대로 사용하며, Hub 웹 화면, hf CLI, Python, JavaScript 및 hf:// 경로를 통해 접근할 수 있습니다.
• Xet의 청크 기반 중복 제거는 서로 비슷한 데이터셋과 연속 체크포인트에서 이미 존재하는 바이트의 재전송과 중복 저장을 줄여 속도와 저장 효율을 개선합니다.
• 사전 워밍 기능은 데이터가 필요한 클라우드와 리전에 미리 배치되도록 해 분산 학습 및 대규모 파이프라인의 리전 간 전송 부담을 줄이는 데 초점을 둡니다.
• Buckets는 작업 중인 가변 데이터를 맡고 모델·데이터셋 저장소는 안정된 결과물의 버전 관리와 공개를 맡도록 역할을 분리하며, 향후 두 저장 계층 사이의 직접 전송도 지원할 계획입니다.

🧩 주요 포인트

1. Storage Buckets는 체크포인트, 옵티마이저 상태, 가공 데이터 조각, 로그, 에이전트 추적 기록처럼 자주 생성·수정되지만 버전 관리가 필요하지 않은 중간 산출물을 위한 비버전형 저장소입니다.
2. 사용자 또는 조직 네임스페이스와 Hugging Face 권한 체계를 그대로 사용하며, Hub 웹 화면, hf CLI, Python, JavaScript 및 hf:// 경로를 통해 접근할 수 있습니다.
3. Xet의 청크 기반 중복 제거는 서로 비슷한 데이터셋과 연속 체크포인트에서 이미 존재하는 바이트의 재전송과 중복 저장을 줄여 속도와 저장 효율을 개선합니다.
4. 사전 워밍 기능은 데이터가 필요한 클라우드와 리전에 미리 배치되도록 해 분산 학습 및 대규모 파이프라인의 리전 간 전송 부담을 줄이는 데 초점을 둡니다.
5. Buckets는 작업 중인 가변 데이터를 맡고 모델·데이터셋 저장소는 안정된 결과물의 버전 관리와 공개를 맡도록 역할을 분리하며, 향후 두 저장 계층 사이의 직접 전송도 지원할 계획입니다.

🧠 상세 정리

1. Git 저장소로 다루기 어려운 머신러닝 중간 산출물

Hugging Face의 모델 및 데이터셋 저장소는 완성된 산출물을 버전과 함께 공개하는 용도에는 적합하지만, 운영 환경에서 계속 쏟아지는 중간 파일까지 모두 Git으로 관리하기에는 구조적인 부담이 있습니다. 학습 클러스터는 실행 도중 체크포인트와 옵티마이저 상태를 반복해서 기록하고, 데이터 파이프라인은 원본 데이터를 여러 차례 가공하면서 새로운 조각을 만들어 냅니다. 에이전트 기반 시스템도 추적 기록, 메모리, 공유 지식 그래프와 파생 요약을 지속적으로 저장하므로 여러 작업이 동시에 파일을 쓰거나 기존 파일을 덮어쓰는 상황이 빈번합니다. 이러한 파일들은 변경 빈도가 높고 오래된 항목을 제거해야 하며 최종 결과가 되기 전까지 세밀한 버전 이력을 보존할 필요가 거의 없기 때문에, 빠른 쓰기와 덮어쓰기, 디렉터리 동기화 및 삭제를 지원하는 별도의 저장 계층이 필요하다는 것이 Storage Buckets의 출발점입니다.

2. Hub 권한과 주소 체계를 따르는 가변 객체 저장소

Storage Bucket은 Hugging Face Hub 안에서 제공되는 비버전형 저장 컨테이너로, S3와 유사한 가변 객체 저장 방식을 사용하면서도 Hub의 사용자 경험과 권한 체계를 유지합니다. 각 버킷은 사용자 또는 조직 네임스페이스 아래에 생성되며, 기존 Hugging Face 권한을 적용하고 공개 또는 비공개 상태를 선택할 수 있습니다. 사용자는 브라우저에서 전용 페이지를 열어 파일을 살펴보거나 hf CLI와 Python API로 관리할 수 있고, 프로그램에서는 hf://buckets/username/my-training-bucket 같은 핸들로 대상을 지정합니다. 따라서 작업 중인 데이터를 외부 저장 체계와 별도로 관리하기보다 Hub 안에서 접근 권한, 탐색 화면, 프로그래밍 인터페이스를 함께 사용할 수 있으며, 안정된 결과물을 게시하는 버전형 저장소와도 명확하게 역할을 나눌 수 있습니다.

3. Xet 청크 중복 제거가 제공하는 전송·저장 효율

Buckets의 핵심 기반은 파일 전체를 하나의 거대한 객체로 취급하지 않고 내용을 청크로 분할하는 Hugging Face의 Xet 저장 백엔드입니다. Xet은 청크 단위로 중복을 찾아 이미 저장된 내용은 다시 올리지 않으므로, 원본과 대부분이 동일한 가공 데이터셋이나 일부 가중치가 고정된 연속 체크포인트를 저장할 때 겹치는 바이트를 건너뛸 수 있습니다. 머신러닝 파이프라인은 원본과 가공 데이터, 여러 시점의 체크포인트, 에이전트 추적 기록과 파생 요약처럼 서로 상당 부분이 겹치는 산출물군을 반복적으로 만들기 때문에 이러한 방식과 특히 잘 맞습니다. 그 결과 업로드에 필요한 대역폭과 전송 시간이 줄고 저장 공간도 효율적으로 사용되며, Enterprise 고객은 중복 제거 후 실제 저장량을 기준으로 요금이 계산되므로 공유 청크가 많을수록 청구 대상 용량도 직접 감소합니다.

4. 연산 위치 가까이 데이터를 배치하는 사전 워밍

Buckets의 데이터는 기본적으로 Hub의 글로벌 저장소에 위치하지만, 분산 학습이나 대규모 데이터 처리에서는 저장 위치와 연산 위치 사이의 거리가 처리량에 직접적인 영향을 줄 수 있습니다. 사전 워밍은 작업이 실행될 클라우드 사업자와 리전을 미리 선언하면 필요한 데이터를 그 위치 가까이에 준비해 두는 기능으로, 각 읽기 요청마다 데이터를 리전 간 전송하는 상황을 줄이는 데 목적이 있습니다. 대규모 데이터셋이나 체크포인트를 빠르게 읽어야 하는 학습 클러스터뿐 아니라, 파이프라인의 서로 다른 단계가 여러 클라우드나 리전에서 실행되는 구성에서도 활용할 수 있습니다. Hugging Face는 우선 AWS 및 GCP와 협력해 이 기능을 시작하고 이후 더 많은 클라우드 사업자를 추가할 계획이라고 밝혔으며, 이는 저장소를 단순한 보관 장소가 아니라 연산 처리량을 지원하는 데이터 배치 계층으로 확장하려는 접근입니다.

5. hf CLI를 이용한 생성·동기화·검토 흐름

기본 사용 절차는 hf CLI를 설치하고 로그인한 뒤 hf buckets create 명령으로 공개 여부를 지정해 버킷을 생성하는 것에서 시작합니다. 로컬 학습 작업이 ./checkpoints에 결과를 기록한다면 hf buckets sync를 사용해 해당 디렉터리를 버킷 내부의 checkpoints 경로와 동기화할 수 있으며, 작업이 끝난 뒤에는 CLI 목록 명령이나 Hub의 버킷 페이지에서 내용을 확인할 수 있습니다. 대규모 전송 전에는 --dry-run으로 실제 파일을 이동하지 않고 수행 계획을 출력할 수 있고, --plan으로 계획을 JSONL 파일에 저장한 다음 검토를 거쳐 --apply로 나중에 실행하는 방식도 지원합니다. 전체 디렉터리 동기화 외에도 hf buckets cp로 개별 파일을 복사하고 hf buckets remove로 오래된 객체를 정리할 수 있으므로, 생성하고 동기화한 뒤 필요할 때 검사·정리하는 반복 작업을 CLI만으로 구성할 수 있습니다.

6. Python과 JavaScript에서의 프로그래밍 방식 관리

huggingface_hub v1.5.0부터는 CLI에서 제공하는 생성, 동기화, 탐색 흐름을 Python 코드에서도 사용할 수 있습니다. create_bucket으로 비공개 버킷을 만들고 sync_bucket으로 로컬 체크포인트 디렉터리를 지정 경로에 동기화한 뒤, list_bucket_tree에 접두어와 재귀 옵션을 전달해 저장된 항목의 경로와 크기를 조회하는 형태입니다. 이 인터페이스를 학습 스크립트, 데이터 파이프라인 또는 산출물 관리 서비스에 직접 넣을 수 있으며, 더 세밀한 제어가 필요할 때는 일괄 업로드, 선택적 다운로드, 삭제 및 버킷 이동 기능도 사용할 수 있습니다. JavaScript에서는 @huggingface/hub v2.10.5부터 Bucket 지원이 제공되므로 Node.js 서비스와 웹 애플리케이션에서도 같은 저장 계층을 연동할 수 있고, 사용 환경에 따라 CLI와 언어별 클라이언트를 선택할 수 있습니다.

7. fsspec 호환 파일시스템과 데이터 도구 연동

Buckets는 huggingface_hub의 fsspec 호환 파일시스템인 HfFileSystem을 통해 일반적인 파일시스템처럼 다룰 수도 있습니다. hffs.ls로 디렉터리 항목을 나열하고 hffs.glob으로 여러 하위 경로에 있는 특정 형식의 파일을 검색하며, hffs.open으로 설정 파일 같은 객체를 직접 읽거나 쓰는 방식이 지원됩니다. fsspec은 Python 원격 파일시스템의 표준 인터페이스로 널리 사용되기 때문에, 이를 지원하는 pandas, Polars, Dask 같은 라이브러리도 별도의 저장소 전용 입출력 구조를 만들지 않고 hf:// 경로를 사용할 수 있습니다. 예를 들어 pandas에서 버킷의 CSV를 바로 데이터프레임으로 읽고 처리 결과를 다른 버킷 경로에 다시 저장할 수 있으므로, 기존 데이터 처리 코드의 읽기·쓰기 방식을 크게 바꾸지 않으면서 Hub 저장소를 작업 흐름에 연결할 수 있습니다.

8. 작업 저장소와 버전형 공개 저장소의 연속적 분리

Hugging Face는 Buckets를 산출물이 계속 변하는 동안 사용하는 빠르고 가변적인 작업 계층으로, 모델 및 데이터셋 저장소를 안정된 결과물을 버전과 함께 게시하는 계층으로 정의합니다. 파이프라인이 진행되는 동안에는 체크포인트, 가공 데이터, 로그와 추적 기록을 버킷에 저장하고, 결과가 확정된 뒤에는 최종 가중치나 데이터 조각을 버전형 저장소에 공개하는 구조입니다. 향후 로드맵에는 버킷의 최종 체크포인트를 모델 저장소로 승격하거나 완성된 가공 조각을 데이터셋 저장소에 커밋하는 등 두 계층 사이의 직접 전송을 양방향으로 지원하는 기능이 포함되어 있지만, 현재 제공되는 기능으로 설명되지는 않았습니다. 출시 전 비공개 베타에는 Jasper, Arcee, IBM, PixAI가 참여했으며, Buckets는 기존 Hub 저장 요금제에 포함되고 무료 계정에는 시작용 용량이, PRO 및 Enterprise 요금제에는 더 높은 한도가 제공됩니다.

9. 출시 목적과 커뮤니티에서 제기된 후속 요구

이 기능이 지향하는 핵심은 Git을 억지로 중간 파일 저장소처럼 사용하는 대신, 높은 쓰기 빈도와 변경 가능성을 전제로 한 Hub 네이티브 저장 공간을 제공하는 것입니다. Xet 중복 제거를 통해 관련성이 높은 머신러닝 산출물의 전송과 저장을 효율화하고, 기존 Hub 사용자는 더 많은 작업 단계를 한곳에 유지하며 S3형 저장 방식에 익숙한 사용자는 유사한 객체 저장 모델과 최종 공개 경로를 함께 얻습니다. 공개 후 커뮤니티에서는 접근 빈도가 낮은 대형 정적 자산을 위한 저비용·저속 콜드 스토리지 계층이 제안됐으며, 작성자는 내부 논의는 있었지만 단기 로드맵에는 없고 현재 우선순위는 데이터 집약적 AI 워크플로 지원이라고 답했습니다. Hugging Face Spaces에서 빠른 검색과 영속 저장을 위해 버킷을 연결하는 방법에 대한 질문에는 관련 기능이 곧 제공될 예정이라는 짧은 답변이 있었지만, 구체적인 방식이나 출시 일정은 제시되지 않았습니다.

🧾 핵심 주장 / 시사점

• Buckets의 핵심 설계는 저장 기술 하나를 추가하는 데 그치지 않고, 변경 중인 산출물과 공개할 최종 산출물을 서로 다른 저장 계층에 배치해 Git 버전 관리의 역할을 명확히 제한하는 데 있습니다.
• 청크 단위 중복 제거는 연속 체크포인트와 반복 가공 데이터처럼 파일 전체는 달라도 상당한 내용이 겹치는 머신러닝 산출물의 특성을 직접 활용하므로, 일반적인 객체 저장보다 AI 작업 흐름에 맞춘 효율을 제공합니다.
• CLI의 사전 계획·재실행 기능, 언어별 API, fsspec 연동 및 사전 워밍을 함께 제공함으로써 Buckets는 수동 파일 보관보다 자동화된 학습·데이터 파이프라인의 작업 저장 계층을 목표로 하고 있습니다.

✅ 액션 아이템

• 중간 산출물은 체크포인트·옵티마이저 상태·로그처럼 버전 관리가 불필요한 데이터로 분류해 Storage Buckets에 반영하고, 모델·데이터셋 저장소와 역할을 분리한다.
• 사용자·조직 네임스페이스 기반 권한 체계를 그대로 유지해 접근 경로별(웹, hf CLI, Python, JavaScript, hf://) 사용 방식을 정리하고 일관성을 점검한다.
• 연속 체크포인트 특성의 작업군에서 Xet 중복 제거와 사전 워밍을 적용해 전송량·저장 효율·리전 간 전송 부담 변화를 비교 측정한다.

❓ 열린 질문

• 연속 체크포인트가 많은 파이프라인에서 Xet 중복 제거가 실제로 절감하는 전송량의 비율은 어느 수준인가?
• 사전 워밍이 필요한 데이터가 어떤 조건에서 미리 배치되며, 리전 간 전송 부담 감소 효과는 어느 지표로 확인할 것인가?
• 작업 데이터와 버전형 저장소 간 직접 전송이 공개되면 기존 동기화 절차는 무엇을 기준으로 변경해야 하는가?