Hub documentation
저장 한도
저장 한도
Hugging Face에서는 공개 저장소에 대한 무료 저장 공간을 대량으로 제공하여 AI 커뮤니티를 지원하며, 필요 시 추가 저장 공간을 구매할 수 있는 옵션도 제공합니다. 또한 비공개 저장소의 경우 무료 티어(아래 표 참조)를 초과하는 저장 공간에 대해 과금합니다.
Hub의 모든 유형의 저장소(모델, 데이터셋, 버킷, …)에는 저장량 한도와 정책이 적용됩니다.
AI와 Machine learning 분야의 향후 수년간의 성장을 위해 저장소를 확장할 수 있도록 인프라를 지속적으로 최적화하고 있습니다.
무료 공개 저장소의 남용을 방지하기 위한 완화 조치를 마련해 두었으며, 일반적으로 사용자 및 조직이 업로드한 대형 모델 또는 데이터셋이 커뮤니티에 최대한 유용하도록 (예를 들어, 좋아요 수나 다운로드 수로 나타나는) 보장해 달라고 요청합니다. 더 높은 한도를 해제하려면 유료 Organization 또는 User (PRO) 계정으로 업그레이드하세요.
스토리지 플랜
| 계정 유형 | 공개 저장소 | Private storage |
|---|---|---|
| 무료 사용자 또는 조직 | 최선 노력* | 100GB |
| PRO | 최대 10TB 포함* + 추가 요금 ✅ 영향력 있는 작업을 위한 사용 가능† | 1TB + 사용량 과금 |
| 팀 조직 | 12TB 기본 + 좌석당 1TB + 추가 항목 ✅ | 좌석당 1TB + 사용량 과금 |
| 기업 조직 | 200TB 기본 + 좌석당 1TB + 추가 옵션 🏆 대규모 계약의 경우 최대 1,000TB | 좌석당 1TB + 사용량 과금 |
💡 Team 또는 Enterprise Organizations는 구독당 시트당 1TB의 비공개 저장소를 포함합니다. 예를 들어, 조직에 40명의 멤버가 있으면 40TB의 비공개 저장소가 포함됩니다.
* 공개 저장소에 대해 AI 커뮤니티에 관대한 무료 저장 공간을 계속 제공하고자 합니다. 처음 몇 기가바이트를 초과하는 경우, 다른 사용자에게 진정한 가치를 제공하는 콘텐츠를 업로드하여 이 자원을 책임감 있게 사용해 주세요. 상당한 저장 공간이 필요하신 경우 PRO, Team 또는 Enterprise로 업그레이드해야 합니다.
† 일부 경우, 유료 플랜으로 실제 수요를 충족할 수 없는 고영향 오픈소스 작업에 대해 추가 저장량 할당이 가능합니다. 커뮤니티 영향력(좋아요, 다운로드 수, 인용 횟수)에 대한 근거를 첨부하여 문의해 주세요.
Public Storage 추가 기능
유료 플랜(PRO, Team, Enterprise) 사용자는 플랜의 기본 한도를 초과하여 추가 공개 저장소를 사용할 수 있도록 Public Storage add-on에 구독할 수 있습니다.
| 스토리지 추가 기능 | 가격 | TB당 |
|---|---|---|
| 1 TB | $12/월 | $12/TB/월 |
| 5 TB | $60/month | $12/TB/월 |
| 10 TB | $120/month | $12/TB/월 |
| 20 TB | $240/month | $12/TB/월 |
| 50 TB | $500/month | TB당 $10/월 |
계정 또는 조직의 Billing 설정 페이지에서 구독을 신청하거나 티어를 변경할 수 있습니다. 업그레이드는 즉시 적용되며, 다운그레이드는 다음 달 초에 적용되도록 예약됩니다. 더 많은 저장 공간이 필요하면 문의하여 custom large-scale pricing을 활용할 수 있습니다.
Private storage Pay-as-you-go
PRO 및 Team 또는 Enterprise Organization에 포함된 1TB(또는 시트당 1TB)의 개인 저장소를 초과하는 추가 개인 저장소는 Pay-as-you-go 모드로 결제 수단에 청구되며, 기본 가격은 $18/TB/월입니다. 대규모 용량에 대한 추가 할인은 담당 계정 매니저를 통해 제공됩니다:
| 볼륨 | 가격 (비공개 저장소) |
|---|---|
| Base | $18/TB/월 |
| 50TB 이상 | $16/TB/월 |
| 200TB 이상 | $14/TB/월 |
| 500TB 이상 | $12/TB/월 |
자세한 내용은 billing doc을 참고하거나, huggingface.co/pricing에서 최신 요금제를 확인하세요.
리포지토리 제한 사항 및 권장 사항
이 섹션은 Storage Buckets에는 적용되지 않습니다.
계정(사용자 또는 조직) 수준의 저장 용량 제한 외에도, 특정 Git 기반 저장소에서 대량의 데이터를 다룰 때 알아야 할 몇 가지 제한 사항이 있습니다. 데이터를 스트리밍하는 데 걸리는 시간을 고려할 때, 업로드/푸시 작업이 프로세스 후반부에 실패하거나 hf.co에서든 로컬에서든 성능 저하를 경험하는 것은 매우 번거로운 일이 될 수 있습니다. 다음 섹션에서는 대용량 저장소를 가장 효과적으로 구성하는 방법에 대한 권장 사항을 설명합니다.
권장 사항
리포지토리를 구성하는 데 도움이 되는 팁과 권장 사항을 정리했습니다. 더 실용적인 팁이 필요하시다면, Python 라이브러리를 사용하여 대량의 데이터를 업로드하는 방법에 대한 이 가이드를 확인해 보세요.
| 특징 | 권장 | 팁 |
|---|---|---|
| 리포지토리 크기 | - | 스토리지 플랜을 업그레이드하거나 대용량 저장소(TB급 데이터)의 경우 저희에게 문의해 주세요 |
| 리포지토리당 파일 | <100k | 데이터를 더 적은 수의 파일로 병합 |
| 폴더당 항목 | <10k | 레포지토리에 하위 디렉터리 사용 |
| 파일 크기 | <200GB | split data into chunked files |
| 커밋 크기 | <100개 파일* | upload_folder/hf upload는 큰 폴더를 여러 커밋으로 자동 분할합니다 |
| 리포지토리별 커밋 | - | 커밋당 여러 파일을 업로드하고/또는 히스토리를 압축 |
* git CLI를 직접 사용하는 경우 해당 사항 없음
다음 섹션을 읽으시면 이러한 한계와 이를 다루는 방법에 대해 더 잘 이해하실 수 있습니다.
설명
“대형 업로드”라고 할 때 무엇을 의미하며, 이에 따른 제한 사항은 무엇인가요? 대형 업로드는 매우 다양할 수 있습니다. 몇 개의 거대한 파일(예: 모델 가중치)이 포함된 저장소부터 수천 개의 작은 파일(예: 이미지 데이터셋)이 포함된 저장소까지 그 범위가 넓습니다.
Hub은 내부적으로 Git을 사용하여 데이터를 버전 관리하므로, 저장소에서 수행할 수 있는 작업에 구조적 제약이 따릅니다.
저장소가 이전 섹션에서 언급된 수치를 초과하는 경우, git-sizer를 확인해 보시는 것을 강력히 권장합니다.
해당 도구는 사용자 경험에 영향을 미치는 다양한 요인에 대해 매우 상세한 문서를 제공합니다. 고려해야 할 요인의 요약은 다음과 같습니다:
- 저장소 크기: 업로드할 데이터의 총 크기입니다. 모델과 데이터셋에는 저장소별 크기 제한이 없지만, 업로드는 계정의 총 저장 용량 할당량에 포함됩니다(위 저장 요금제 참조). 더 많은 저장 공간이 필요하면 요금제를 업그레이드하거나 저장 용량 추가 패키지를 구매하세요.
- Number of files:
- 최적의 경험을 위해 파일 총 개수를 100k 미만으로 유지하는 것을 권장하며, 가능하면 그보다 훨씬 적게 유지하세요. 파일이 더 많다면 데이터를 더 적은 수의 파일로 병합해 보세요. 예를 들어, json 파일을 단일 jsonl 파일로 병합하거나, 대규모 데이터셋을 Parquet 파일 또는 WebDataset 형식으로 내보낼 수 있습니다.
- 폴더당 최대 파일 수는 10k를 초과할 수 없습니다. 간단한 해결 방법은 하위 디렉터리를 사용하는 저장소 구조를 만드는 것입니다. 예를 들어,
000/부터999/까지 1k개의 폴더가 있고 각 폴더에 최대 1000개의 파일이 포함된 저장소만으로도 충분합니다.
- File size: 대용량 파일(예: 모델 가중치)을 업로드하는 경우, 이를 각 200GB 이하의 청크로 나누는 것을 강력히 권장합니다..
그 이유는 다음과 같습니다:
- 작은 파일을 업로드하고 다운로드하는 것은 사용자와 다른 사용자 모두에게 훨씬 쉽습니다. 스트리밍 데이터 전송 중 연결 문제가 항상 발생할 수 있으며, 작은 파일은 오류 발생 시 처음부터 다시 시작하는 것을 방지합니다.
- 파일은 CloudFront를 통해 사용자에게 제공됩니다. 저희 경험에 따르면, 이 서비스는 매우 큰 파일을 캐시하지 않아 다운로드 속도가 느려질 수 있습니다. 모든 경우에서 단일 파일은 500GB를 초과하지 않습니다. 즉, 500GB는 단일 파일 크기의 하드 리미트입니다.
- 커밋 수: 저장소 히스토리의 총 커밋 수에 대한硬性한 제한은 없습니다. 그러나 저희 경험에 따르면, Hub의 사용자 경험은 수천 개의 커밋 이후부터 저하되기 시작합니다. 서비스 개선을 위해 지속적으로 노력하고 있지만, git 저장소는 많은 쓰기 작업이 발생하는 데이터베이스로 동작하도록 설계된 것이 아니라는 점을 항상 기억해야 합니다. 저장소 히스토리가 매우 커진 경우,
huggingface_hub의super_squash_history를 사용하여 모든 커밋을 squash하여 새로운 시작을 할 수 있습니다. 이 작업은 되돌릴 수 없음을 유의하세요. - 커밋당 작업 수: 마찬가지로, 여기에는 엄격한 한계가 없습니다. Hub에 커밋이 업로드되면 서버는 각 git 작업(추가 또는 삭제)을 검사합니다. 대용량 파일 100개가 한 번에 커밋되면, 각 파일이 올바르게 업로드되었는지 확인하기 위해 개별적으로 검사됩니다. HTTP를 통해 데이터를 푸시할 때 요청에 60초의 타임아웃이 설정되므로, 프로세스가 이보다 더 오래 걸리면 오류가 발생합니다. 그러나 (드문 경우이지만) 클라이언트 측에서 타임아웃이 발생해도 서버 측에서는 프로세스가 완료될 수 있습니다. 이는 Hub에서 저장소를 직접 탐색하여 수동으로 확인할 수 있습니다.
upload_folder메서드와hf upload명령은 큰 폴더를 여러 커밋으로 나누어 이를 자동으로 방지합니다. 수동으로 커밋하는 경우, 커밋당 약 50~100개 파일을 유지하는 것이 좋습니다.
Hub에서 대규모 데이터셋 공유
Hugging Face가 머신러닝 생태계를 지원하는 주요 방법 중 하나는 Hub에 데이터셋, 특히 매우 큰 데이터셋을 호스팅하는 것입니다. 큰 데이터셋은 계정의 총 저장 용량 할당량에 포함되므로 업로드 전에 저장 플랜에 충분한 용량이 있는지 확인하세요. 추가적인 공개 저장 공간은 추가 옵션으로 구매할 수 있습니다.
Hub에 대규모 데이터셋을 호스팅하려면 다음이 필요합니다:
- 데이터셋 카드: 커뮤니티가 데이터셋을 효과적으로 사용할 수 있도록 보장하는 것이 목표이며, 이를 가능하게 하는 핵심 방법 중 하나는 데이터셋 카드입니다. 이 가이드는 데이터셋 카드를 작성하는 방법에 대한 개요를 제공합니다.
- 데이터셋을 공유하여 커뮤니티의 재사용을 가능하게 하려는 것입니다. 추가 재사용이 예상되지 않는 데이터셋을 업로드할 계획이라면, 다른 플랫폼이 더 적합할 가능성이 높습니다.
- 위에서 설명한 저장소 제한 사항을 준수해야 합니다.
- Hugging Face 생태계와 잘 통합된 파일 형식을 사용합니다. Parquet 및 WebDataset 형식에 대한 지원이 잘 되어 있으며, 대용량 데이터셋을 효율적으로 공유하는 데 좋은 선택지인 경우가 많습니다. 이를 통해 데이터셋 뷰어가 해당 데이터셋에서 정상적으로 작동하도록 보장할 수 있습니다.
- datasets를 사용할 때 커스텀 로딩 스크립트의 사용을 피하세요. 저희 경험상, 사용에 커스텀 코드가 필요한 datasets는 재사용성이 제한되는 경우가 많습니다.
처리 중인 데이터나 도메인의 특성으로 인해 이러한 요구 사항 중 충족하기 어려운 항목이 있다면, 저희에게 연락해 주세요.
Hub에서 대량의 모델을 공유하기
데이터셋과 마찬가지로, 대규모 모델 또는 대량의 모델(예: 수백 개의 자동화된 quants)은 계정의 총 저장 용량 할당량에 포함됩니다. 저장 용량 플랜에 충분한 용량이 있는지 확인하거나, 저장 용량 추가 패키지를 구매하세요.
연구 팀 및 비영리 단체 대상 보조금
학술 및 연구 기관에는 저장 공간 한도가 보장되는 Team, Enterprise, 또는 Academia Hub로 업그레이드하는 것을 권장합니다. 일부 경우, 유료 플랜으로 실제 수요를 충족할 수 없는 고영향 오픈소스 작업에 대해 저장 공간 지원이 제공될 수 있습니다. 이러한 지원은 개별 사례별로 평가되며, 입증된 커뮤니티 영향력(다운로드 수, 인용 횟수, 커뮤니티 채택 등)이 필요합니다. 상세한 제안서를 작성하여 datasets@huggingface.co 또는 models@huggingface.co로 문의해 주세요.
계정/조직에서 저장 공간을 어떻게 확보할 수 있나요?
계정 또는 조직의 저장 공간을 관리하고 일부 공간을 확보하는 방법은 여러 가지가 있습니다. 먼저, 더 많은 저장 공간이 필요하시다면 PRO, Team 또는 Enterprise 플랜으로 업그레이드하여 저장 공간 한도를 늘릴 수 있습니다.
⚠️ 중요: 대용량 파일 삭제는 되돌릴 수 없는 파괴적 작업입니다. 진행하기 전에 파일을 백업하십시오.
기억해야 할 주요 사항:
- LFS 포인터만 삭제해도 공간을 확보할 수 없습니다
- Git 히스토리를 다시 작성하지 않으면, 삭제된 LFS 파일에 기존 lfs 포인터가 포함된 브랜치/태그의 향후 체크아웃이 실패합니다(에러를 방지하려면
.gitconfig파일에 다음 줄을 추가하세요:lfs.skipdownloaderrors=true)
개별 LFS 파일 삭제
- 리포지토리의 Settings 페이지로 이동합니다
- Storage 섹션의 List LFS files를 클릭합니다
- actions 메뉴를 사용하여 특정 파일을 삭제합니다
Pull request refs 삭제
Pull requests는 커밋을 저장하는 git refs를 생성합니다. PR을 닫거나 병합한 후에는 해당 ref를 삭제하여 저장 공간을 확보할 수 있습니다. 이는 다음 경우에 특히 유용합니다:
- PR에는 병합되지 않은 대형 파일이 포함되어 있습니다
- 메인 브랜치를 squash하고 나중에 파일을 삭제한 경우, 해당 파일이 PR 자체에 의해 추가되지 않았더라도 PR 브랜치의 히스토리에 남아 있습니다
PR ref를 삭제하려면 닫거나 병합된 PR을 열고, 하단에 표시되는 저장소 알림에서 해제될 수 있는 예상 공간을 확인합니다. Delete ref를 클릭하여 영구적으로 삭제합니다.
PR ref를 삭제하는 작업은 되돌릴 수 없으며, 이로 인해 다른 사용자가 해당 커밋을 로컬에서 가져오거나 체크아웃하는 것이 차단됩니다.
API를 사용하여 저장소를 Super-squash
super-squash 작업은 Git 히스토리를 단일 커밋으로 압축합니다. 사용하지 않는 오래된 LFS 버전에서 저장 공간을 확보해야 할 때 super-squash를 사용하는 것을 고려해 보세요. 이 작업은 Hub Python Library 또는 API를 통해서만 사용할 수 있습니다.
⚠️ 중요: 되돌릴 수 없는 파괴적 작업입니다. 커밋 기록이 영구적으로 삭제되고 LFS 파일 기록이 제거됩니다
squash 작업이 저장 공간 할당량에 미치는 영향은 즉시 반영되지 않으며, 36시간 이내에 할당량에 반영됩니다.
고급: LFS 파일 참조 추적
리포지토리의 “List LFS files”에서 LFS 파일을 찾았지만 그 출처를 모를 경우, git log 명령을 사용하여 해당 파일의 SHA-256 OID로 히스토리를 추적할 수 있습니다:
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 <Narsil@users.noreply.huggingface.co>
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