Hugging Face, Hub에 Storage Buckets 도입… Xet 기반 S3형 ML artifact 저장소

Hugging Face는 2026년 3월 10일 Hub용 Storage Buckets를 공개했다. 이 기능은 model repo나 dataset repo처럼 versioned artifact를 배포하는 공간이 아니라, checkpoint, optimizer state, processed shard, log, trace처럼 계속 바뀌는 intermediate ML artifact를 저장하는 mutable·non-versioned object storage 계층이다.

왜 별도 storage 계층이 필요한가

Hugging Face는 Git 기반 repo가 최종 산출물 배포에는 적합하지만, 학습 중간 산출물처럼 자주 덮어쓰이고 여러 job이 동시에 쓰는 데이터에는 맞지 않는다고 설명한다. Storage Bucket은 이런 workload를 위해 설계된 S3-like 저장소이며, 사용자 또는 organization namespace 아래에서 public 또는 private으로 운영할 수 있고, hf://buckets/... 형식으로 programmatic access도 가능하다.

특히 이 기능은 Hugging Face의 Xet backend 위에 구축됐다. 회사 설명에 따르면 Xet은 파일을 chunk 단위로 나누고 중복 chunk를 deduplicate해, 비슷한 dataset이나 successive checkpoint를 올릴 때 이미 존재하는 byte를 다시 전송하지 않는다. 그 결과 bandwidth 절감, 전송 속도 개선, 저장 효율 향상이 동시에 가능하다는 주장이다.

운영 기능과 생태계 연결

Storage Buckets는 AWS와 GCP를 시작점으로 pre-warming을 지원한다. 즉, compute가 있는 cloud region 가까이 데이터를 미리 배치해 distributed training이나 대규모 pipeline의 throughput 저하를 줄이려는 접근이다. Hugging Face는 또한 이 기능을 hf CLI, Python의 huggingface_hub, JavaScript의 @huggingface/hub, 그리고 fsspec 기반 filesystem 접근과 연결했다.

이 조합은 training pipeline, data processing, agent trace 저장을 Hub 내부에서 더 일관되게 처리하도록 설계돼 있다. 회사는 장기적으로 Bucket과 versioned repo 사이의 직접 이동도 지원해, working layer와 publishing layer를 하나의 흐름으로 잇겠다고 밝혔다.

왜 중요한가

이번 공개는 Hugging Face가 단순한 model hosting 플랫폼을 넘어, ML 운영 전 과정의 storage substrate까지 제공하려는 움직임으로 읽힌다. 특히 agent trace, memory, shared knowledge graph 같은 artifact를 직접 예시로 든 점은 LLM application 운영 수요를 의식한 설계로 보인다. Enterprise 과금도 deduplicated storage 기준이라고 밝혀, 기능뿐 아니라 비용 구조까지 ML workload에 맞추려는 의도가 드러난다.

Storage Buckets는 기존 Hub storage plan 안에서 제공되지만, 실제 확산 속도는 대규모 transfer 성능, multi-cloud 운영성, 그리고 팀이 Git repo와 object storage를 얼마나 자연스럽게 섞어 쓸 수 있는지에 달려 있다.

Source: Hugging Face