스토리지 한도
스토리지 한도 (Storage limits)
허깅페이스는 AI 커뮤니티에 공개 저장소용 상당한 무료 저장 공간을 제공하는 것을 목표로 하고, 필요하면 추가 스토리지를 살 수 있게 해요. 또한 프라이빗 저장소의 스토리지 공간에 대해 무료 티어를 넘어선 부분을 청구해요. 이 문서는 요금제별 스토리지 플랜과 저장소 구조 권장 사항을 다룬답니다.
출처: 문서
본문
Hugging Face에서 우리는 AI 커뮤니티에 공개 저장소를 위한 상당한 분량의 무료 저장 공간을 제공하고, 필요하면 더 많은 스토리지를 구매할 수 있는 옵션을 제공하는 것을 목표로 해요. 또한 프라이빗 저장소의 스토리지 공간에 대해 무료 티어를 넘어선 부분을 청구해요 (아래 표 참고).
[!TIP] 스토리지 한도와 정책은 Hub의 모든 유형의 저장소(모델, 데이터셋, 버킷 등)에 적용돼요.
우리는 AI·머신러닝의 향후 수년간 성장을 위해 스토리지를 확장하도록 인프라를 지속 최적화하고 있어요.
무료 공개 스토리지의 남용을 방지하기 위한 완화 조치가 있으며, 일반적으로 사용자·조직에게 업로드하는 대규모 모델·데이터셋이 커뮤니티에 최대한 유용하도록(예: 좋아요·다운로드 수로 표현) 할 것을 요청해요. 유료 Organization 또는 User(PRO) 계정으로 업그레이드하면 더 높은 한도를 해제할 수 있어요.
스토리지 플랜
| 계정 유형 | 공개 스토리지 | 프라이빗 스토리지 |
|---|---|---|
| Free user or org | Best-effort* | 100GB |
| PRO | 포함된 최대 10TB* + 애드온 ✅ 영향력 있는 작업에 대한 할당 가능† |
1TB + pay-as-you-go |
| Team Organizations | 기본 12TB + 좌석당 1TB + 애드온 ✅ | 좌석당 1TB + pay-as-you-go |
| Enterprise Organizations | 기본 200TB + 좌석당 1TB + 애드온 🏆 대규모 계약은 최대 1,000TB |
좌석당 1TB + pay-as-you-go |
💡 Team 또는 Enterprise Organizations는 구독에 좌석당 1TB의 프라이빗 스토리지를 포함해요: 예를 들어 조직에 40명의 멤버가 있으면 40TB의 포함 프라이빗 스토리지가 있어요.
* 우리는 AI 커뮤니티에 공개 저장소를 위한 넉넉한 무료 저장 공간을 계속 제공하는 것을 목표로 해요. 처음 몇 GB를 넘어서는 것은, 다른 사용자에게 진정한 가치를 제공하는 콘텐츠를 업로드해 이 리소스를 책임 있게 사용해 주세요. 상당한 저장 공간이 필요하면 PRO, Team 또는 Enterprise로 업그레이드해야 해요.
† 일부 경우 유료 플랜으로는 진정으로 감당할 수 없는 고영향 오픈소스 작업에 추가 스토리지 할당이 가능해요. 커뮤니티 영향(좋아요, 다운로드, 인용)의 증거와 함께 연락해 주세요.
공개 스토리지 애드온
유료 플랜(PRO, Team, Enterprise) 사용자는 플랜의 기본 한도 위에 추가 공개 스토리지를 위한 Public Storage 애드온을 구독할 수 있어요.
| 스토리지 애드온 | 가격 | TB당 |
|---|---|---|
| 1 TB | $12/월 | $12/TB/월 |
| 5 TB | $60/월 | $12/TB/월 |
| 10 TB | $120/월 | $12/TB/월 |
| 20 TB | $240/월 | $12/TB/월 |
| 50 TB | $500/월 | $10/TB/월 |
계정이나 조직의 Billing 설정 페이지에서 구독하거나 티어를 변경할 수 있어요. 업그레이드는 즉시 적용되고, 다운그레이드는 다음 달 시작 시 적용되도록 예약돼요. 더 많은 스토리지가 필요하면 문의하여 커스텀 대규모 가격을 받을 수 있어요.
프라이빗 스토리지 Pay-as-you-go
PRO와 Team 또는 Enterprise Organizations에 포함된 1TB(또는 좌석당 1TB) 프라이빗 스토리지를 넘어서면, 추가 프라이빗 스토리지는 기본 가격 $18/TB/월로 Pay-as-you-go 모드로 지불 방법에 청구돼요. 대규모 볼륨에는 계정 담당자를 통해 추가 할인이 가능해요:
| 볼륨 | 가격 (프라이빗 저장소) |
|---|---|
| Base | $18/TB/월 |
| 50TB+ | $16/TB/월 |
| 200TB+ | $14/TB/월 |
| 500TB+ | $12/TB/월 |
자세한 내용은 billing 문서, 최신 가격은 huggingface.co/pricing을 참고해요.
저장소 제한 사항 및 권장 사항
[!NOTE] 이 섹션은 Storage Buckets에는 적용되지 않아요.
계정(사용자·조직) 수준의 스토리지 한도 외에도, 특정 Git 기반 저장소에서 대량의 데이터를 다룰 때 알아야 할 제한 사항이 있어요. 데이터를 스트리밍하는 데 걸리는 시간을 고려하면, 업로드/push가 프로세스 끝에서 실패하거나 hf.co나 로컬 작업에서 경험 저하를 겪는 것은 매우 짜증날 수 있어요. 다음 섹션에서는 대용량 저장소를 가장 잘 구성하는 방법에 대한 권장 사항을 설명해요.
권장 사항
저장소 구조화에 대한 팁·권장 목록을 모았어요. 더 실용적인 팁은 Python 라이브러리로 대량 데이터를 업로드하는 방법에 대한 이 가이드를 확인해요.
| 특성 | 권장 | 팁 |
|---|---|---|
| Repo 크기 | - | 스토리지 플랜을 업그레이드하거나 대용량 저장소(TB 단위 데이터)는 문의 |
| 저장소당 파일 | <100k | 데이터를 더 적은 파일로 병합 |
| 폴더당 항목 | <10k | 저장소에 하위 디렉토리 사용 |
| 파일 크기 | <200GB | 데이터를 청크 파일로 분할 |
| 커밋 크기 | <100 파일* | upload_folder/hf upload는 대용량 폴더를 여러 커밋으로 자동 분할 |
| 저장소당 커밋 | - | 커밋당 여러 파일 업로드 및/또는 history squash |
* 직접 git CLI를 사용할 때는 무관
다음 섹션을 읽어 이러한 한도를 더 잘 이해하고 어떻게 대처할지 알아봐요.
설명
"큰 업로드"라고 할 때 무엇을 말하는 걸까요, 그리고 관련 제한 사항은 무엇인가요? 큰 업로드는 매우 다양할 수 있어요 — 몇 개의 거대한 파일(예: 모델 가중치)이 있는 저장소부터 수천 개의 작은 파일(예: 이미지 데이터셋)이 있는 저장소까지요.
내부적으로 Hub는 Git으로 데이터를 버전 관리하므로, 저장소에서 무엇을 할 수 있는지에 구조적 영향을 줘요. 저장소가 이전 섹션에서 언급한 숫자 중 일부를 넘어서면 반드시 git-sizer를 확인해 보시길 강력히 권장해요. 경험에 영향을 줄 다양한 요인에 대한 매우 상세한 문서가 있어요. 고려할 요인의 요약:
- 저장소 크기: 업로드할 데이터의 총 크기. 모델·데이터셋에 저장소당 크기 제한은 없지만, 업로드는 계정의 총 스토리지 할당량에 합산돼요(위 스토리지 플랜 참고). 더 많은 스토리지가 필요하면 플랜 업그레이드하거나 스토리지 애드온을 구매해요.
- 파일 수:
- 최적의 경험을 위해 총 파일 수를 100k 미만, 이상적으로는 훨씬 적게 유지하는 걸 권장해요. 더 많다면 데이터를 더 적은 파일로 병합해 보세요. 예를 들어 json 파일을 단일 jsonl 파일로 병합하거나, 대용량 데이터셋을 Parquet 파일이나 WebDataset 형식으로 내보낼 수 있어요.
- 폴더당 최대 파일 수는 폴더당 10k 파일을 초과할 수 없어요. 간단한 해결책은 하위 디렉토리를 사용하는 저장소 구조를 만드는 거예요. 예를 들어
000/부터999/까지 1k 폴더를 두고 각 폴더에 최대 1000개 파일을 두는 저장소면 충분해요.
- 파일 크기: 대용량 파일(예: 모델 가중치)을 업로드하는 경우, 각각 200GB 아래의 청크로 분할하는 걸 강력히 권장해요.
이유는 몇 가지:
- 더 작은 파일을 업로드·다운로드하는 것이 여러분과 다른 사용자 모두에게 훨씬 쉽기 때문이에요. 데이터 스트리밍 중 연결 문제는 항상 발생할 수 있고, 작은 파일은 오류 시 처음부터 재개하는 것을 피해요.
- 파일은 CloudFront를 통해 사용자에게 제공돼요. 경험상 이 서비스는 거대한 파일을 캐시하지 않아 다운로드 속도가 느려져요. 어떤 경우든 단일 파일이 500GB를 초과하지 않아요. 즉 500GB가 단일 파일 크기의 하드 한도예요.
- 커밋 수: 저장소 history의 총 커밋 수에는 하드 한도가 없어요. 하지만 경험상 Hub에서의 사용자 경험은 수천 개의 커밋 이후로 저하되기 시작해요. 우리는 서비스를 지속적으로 개선하고 있지만, git 저장소는 쓰기가 많은 데이터베이스로 동작하도록 만들어진 게 아니라는 점을 항상 기억해야 해요. 저장소 history가 매우 커지면,
huggingface_hub의super_squash_history로 모든 커밋을 squash해 새로 시작하는 것이 항상 가능해요. 이는 되돌릴 수 없는 작업임을 유의하세요. - 커밋당 작업 수: 여기서도 하드 한도는 없어요. 커밋이 Hub에 업로드되면 각 git 작업(추가 또는 삭제)이 서버에서 검사돼요. 한 번에 수백 개의 대용량 파일을 커밋하면 각 파일이 올바르게 업로드됐는지 개별적으로 확인돼요. HTTP로 데이터를 push할 때 요청에 60초 타임아웃이 설정돼 있어서, 프로세스가 더 오래 걸리면 오류가 발생해요. 하지만 (드물게) 클라이언트 측에서 타임아웃이 발생해도 프로세스가 서버 측에서 완료되는 경우가 있을 수 있어요. 이는 Hub에서 저장소를 탐색해 수동으로 확인할 수 있어요.
upload_folder메서드와hf upload명령은 대용량 폴더를 여러 커밋으로 분할해 이를 자동으로 피해요. 수동으로 커밋한다면 커밋당 약 50-100개 파일을 유지해요.
Hub에서 대용량 데이터셋 공유하기
Hugging Face가 머신러닝 생태계를 지원하는 핵심 방법 중 하나는 매우 큰 것들을 포함한 데이터셋을 Hub에서 호스팅하는 거예요. 대용량 데이터셋은 계정의 총 스토리지 할당량에 합산되므로, 업로드 전에 스토리지 플랜에 충분한 용량이 있는지 확인해요. 추가 공개 스토리지는 애드온으로 구매할 수 있어요.
Hub에서 대용량 데이터셋을 호스팅하려면 다음이 필요해요:
- 데이터셋 카드: 데이터셋이 커뮤니티에서 효과적으로 사용되도록 보장하고 싶고, 이를 가능하게 하는 핵심 방법 중 하나가 데이터셋 카드예요. 이 가이드는 데이터셋 카드를 작성하는 방법의 개요를 제공해요.
- 커뮤니티 재사용을 가능하게 하기 위해 데이터셋을 공유하고 있어야 해요. 재사용이 없을 것으로 예상되는 데이터셋을 업로드할 계획이라면, 다른 플랫폼이 더 적합할 가능성이 커요.
- 위에 설명한 저장소 제한 사항을 따라야 해요.
- Hugging Face 생태계와 잘 통합된 파일 형식을 사용해요. 우리는 Parquet과 WebDataset 형식을 잘 지원하는데, 이는 종종 대용량 데이터셋을 효율적으로 공유하기 좋은 옵션이에요. 이렇게 하면 데이터셋 viewer가 여러분의 데이터셋에서 동작하는 것도 보장돼요.
- 데이터셋을 사용할 때 커스텀 로딩 스크립트는 피해요. 경험상 커스텀 코드가 필요한 데이터셋은 재사용이 제한되는 경우가 많아요.
이러한 요구사항 중 어떤 것이 데이터 유형이나 도메인 때문에 충족하기 어렵다면 연락해 주세요.
Hub에서 대용량 모델 볼륨 공유하기
데이터셋과 마찬가지로, 대용량 모델이나 대량의 모델(예: 수백 개의 자동 양자화)은 계정의 총 스토리지 할당량에 합산돼요. 스토리지 플랜에 충분한 용량이 있는지 확인하거나 스토리지 애드온을 구매해요.
연구 팀과 비영리 단체를 위한 할당
학술·연구 기관은 보장된 스토리지 한도를 위해 Team, Enterprise 또는 Academia Hub로 업그레이드하는 걸 권장해요. 일부 경우 유료 플랜으로는 진정으로 감당할 수 없는 고영향 오픈소스 작업에 스토리지 할당이 가능할 수 있어요. 이는 사례별로 평가되며 입증된 커뮤니티 영향(다운로드, 인용, 커뮤니티 채택 등)이 필요해요. 상세 제안과 함께 [email protected] 또는 [email protected]로 연락해 주세요.
내 계정/조직에서 스토리지 공간을 어떻게 확보할 수 있나요?
계정이나 조직에서 스토리지 공간을 관리·확보하는 방법은 여러 가지가 있어요. 먼저, 더 많은 스토리지 공간이 필요하면 스토리지 한도를 높이려면 PRO, Team 또는 Enterprise 플랜으로 업그레이드해요.
⚠️ 중요: 대용량 파일(Large Files) 삭제는 되돌릴 수 없는 파괴적 작업이에요. 진행 전에 파일을 백업하세요.
기억할 핵심 사항:
- LFS 포인터만 삭제해서는 공간이 확보되지 않아요
- Git history를 다시 쓰지 않으면, 삭제된 LFS 파일을 포함한 브랜치/태그의 향후 checkout은(기존 lfs 포인터가 있으므로) 실패해요 (오류를 피하려면
.gitconfig파일에lfs.skipdownloaderrors=true줄을 추가하세요)
개별 LFS 파일 삭제
- 저장소의 Settings 페이지로 이동해요
- "Storage" 섹션에서 "List LFS files"를 클릭해요
- 작업 메뉴로 특정 파일을 삭제해요
Pull request ref 삭제
Pull requests는 커밋을 저장하는 git ref를 만들어요. PR을 닫거나 병합한 후 그 ref를 삭제해 스토리지 공간을 확보할 수 있어요. 특히 다음 경우에 유용해요:
- PR에 병합되지 않은 대용량 파일이 있는 경우
- 메인 브랜치를 squash하고 나중에 파일을 제거한 경우 — 그 파일들이 PR 자체에 추가되지 않았더라도 PR 브랜치 history에 남아요.
PR ref를 삭제하려면 닫거나 병합된 PR을 열고 하단의 스토리지 공지에서 확보할 수 있는 예상 공간을 확인해요. "Delete ref"를 클릭해 영구적으로 제거해요.
[!NOTE] PR ref 삭제는 되돌릴 수 없으며, 누구도 로컬에서 그 커밋을 fetch하거나 checkout할 수 없게 돼요.
API로 저장소 super-squash하기
super-squash 작업은 전체 Git history를 단일 커밋으로 압축해요. 사용하지 않는 오래된 LFS 버전에서 스토리지를 회수해야 할 때 super-squash를 고려해요. 이 작업은 Hub Python 라이브러리나 API로만 사용할 수 있어요.
⚠️ 중요: 이는 되돌릴 수 없는 파괴적 작업이에요. 커밋 history는 영구히 사라지고 LFS 파일 history가 제거됩니다.
squash 작업이 스토리지 할당량에 미치는 영향은 즉각적이지 않으며 36시간 내에 할당량에 반영돼요.
고급: LFS 파일 참조 추적
저장소의 "List LFS files"에서 LFS 파일을 찾았지만 어디서 왔는지 모를 때, SHA-256 OID로 git log 명령을 사용해 history를 추적할 수 있어요:
git log --all -p -S <SHA-256-OID>
예를 들어:
git log --all -p -S 68d45e234eb4a928074dfd868cead0219ab85354cc53d20e772753c6bb9169d3
commit 5af368743e3f1d81c2a846f7c8d4a028ad9fb021
Date: Sun Apr 28 02:01:18 2024 +0200
Update LayerNorm tensor names to weight and bias
diff --git a/model.safetensors b/model.safetensors
index a090ee7..e79c80e 100644
--- a/model.safetensors
+++ b/model.safetensors
@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
-oid sha256:68d45e234eb4a928074dfd868cead0219ab85354cc53d20e772753c6bb9169d3
+oid sha256:0bb7a1683251b832d6f4644e523b325adcf485b7193379f5515e6083b5ed174b
size 440449768
commit 0a6aa9128b6194f4f3c4db429b6cb4891cdb421b (origin/pr/28)
Date: Wed Nov 16 15:15:39 2022 +0000
Adding `safetensors` variant of this model (#15)
- Adding `safetensors` variant of this model (18c87780b5e54825a2454d5855a354ad46c5b87e)
Co-authored-by: Nicolas Patry <[email protected]>
diff --git a/model.safetensors b/model.safetensors
new file mode 100644
index 0000000..a090ee7
--- /dev/null
+++ b/model.safetensors
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:68d45e234eb4a928074dfd868cead0219ab85354cc53d20e772753c6bb9169d3
+size 440449768
commit 18c87780b5e54825a2454d5855a354ad46c5b87e (origin/pr/15)
Date: Thu Nov 10 09:35:55 2022 +0000
Adding `safetensors` variant of this model
diff --git a/model.safetensors b/model.safetensors
new file mode 100644
index 0000000..a090ee7
--- /dev/null
+++ b/model.safetensors
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:68d45e234eb4a928074dfd868cead0219ab85354cc53d20e772753c6bb9169d3
+size 440449768
더 알아보기 (Learn more)
- 공개 스토리지는 무료 티어가 있고, 프라이빗은 좌석당 1TB 포함 + pay-as-you-go로 이어져요.
- 대용량 저장소는 파일·폴더·파일 크기·커밋 권장 사항을 지키고, LFS 파일은 안전하게 정리할 수 있어요.