Hub 文件
儲存限制
並獲得增強的文件體驗
開始使用
儲存限制
在 Hugging Face，我們的目標是為 AI 社群提供公共儲存庫的免費儲存空間。對於超出免費額度的私有儲存庫，我們會收取儲存費用（見下表）。
我們持續最佳化我們的基礎設施，以在機器學習未來多年的增長中擴充套件我們的儲存。
我們已經採取了緩解措施，以防止濫用免費公共儲存，通常我們要求使用者和組織確保任何上傳的大型模型或資料集都儘可能對社群有用（例如，透過點贊數或下載數來體現）。
儲存方案
| 賬戶型別 | 公共儲存 | 私有儲存 |
|---|---|---|
| 免費使用者或組織 | 盡力而為* 🙏 | 100GB |
| PRO | 無限制* ✅ | 1TB + 按量付費 |
| 團隊或企業組織 | 無限制* ✅ | 每個席位 1TB + 按量付費 |
💡 團隊或企業組織的訂閱中包含每個席位 1TB 的私有儲存：例如，如果您的組織有 40 名成員，那麼您將擁有 40TB 的私有儲存。
*我們旨在繼續為 AI 社群提供公共儲存庫的免費儲存空間。請透過上傳對其他使用者具有真正價值的內容來負責任地使用此資源——而不是上傳幾十TB但社群興趣有限的內容。如果您需要大量儲存空間，應升級到PRO、團隊或企業計劃。
按量付費價格
在PRO和團隊或企業組織中，除了包含的 1TB（或每個席位 1TB）私有儲存外，超出部分的私有儲存按25 美元/TB/月收費，以 1TB 為增量。更多詳情請參閱我們的計費文件。
儲存庫限制和建議
除了賬戶（使用者或組織）級別的儲存限制之外，在處理特定儲存庫中的大量資料時，還需要注意一些限制。考慮到資料流式傳輸所需的時間，上傳/推送失敗或遇到降級體驗（無論是在 hf.co 上還是在本地工作時）都可能非常惱人。在以下部分中，我們將介紹關於如何最好地組織大型儲存庫的建議。
建議
我們收集了一系列關於構建儲存庫的提示和建議。如果您正在尋找更實用的提示，請檢視此指南，瞭解如何使用 Python 庫上傳大量資料。
| 特徵 | 建議 | 技巧 |
|---|---|---|
| 倉庫大小 | - | 大型倉庫（TB 級資料）請聯絡我們 |
| 每個倉庫的檔案數 | <100k | 將資料合併到更少的檔案中 |
| 每個資料夾的條目數 | <10k | 在倉庫中使用子目錄 |
| 檔案大小 | <20GB | 將資料拆分為分塊檔案 |
| 提交大小 | <100 個檔案* | 分多次提交上傳檔案 |
| 每個倉庫的提交數 | - | 每次提交上傳多個檔案和/或合併歷史記錄 |
* 直接使用 git CLI 時不相關
請閱讀下一節，以便更好地理解這些限制以及如何處理它們。
解釋
我們所說的“大型上傳”指的是什麼，以及它們相關的限制是什麼？大型上傳可能非常多樣化，從包含少量巨大檔案（例如模型權重）的儲存庫到包含數千個小檔案（例如影像資料集）的儲存庫。
Hub 在底層使用 Git 進行資料版本控制，這對於您在倉庫中可以執行的操作具有結構性影響。如果您的倉庫超出了前一部分中提到的某些數字，我們強烈建議您檢視 git-sizer，它提供了關於影響您體驗的不同因素的非常詳細的文件。以下是需要考慮的因素的簡要概述：
- 倉庫大小：您計劃上傳資料的總大小。我們通常支援最大 300GB 的倉庫。如果您想上傳超過 300 GB（甚至 TB 級）的資料，您需要申請更多儲存空間。請將專案詳細資訊傳送電子郵件至 datasets@huggingface.co（用於資料集）或 models@huggingface.co（用於模型）。
- 檔案數量:
- 為了獲得最佳體驗，我們建議將檔案總數保持在 100k 以下，最好是遠低於此。如果檔案數量更多，請嘗試將資料合併到更少的檔案中。例如，json 檔案可以合併到單個 jsonl 檔案中，或者大型資料集可以匯出為 Parquet 檔案或 WebDataset 格式。
- 每個資料夾的最大檔案數不能超過 10k 個檔案。一個簡單的解決方案是建立使用子目錄的倉庫結構。例如，一個包含 1k 個資料夾（從
000/到999/），每個資料夾最多包含 1000 個檔案的倉庫就足夠了。
- 檔案大小：在上傳大檔案（例如模型權重）的情況下，我們強烈建議將其分割成大約 20GB 的塊。有幾個原因如下：
- 上傳和下載較小的檔案對於您和其他使用者來說都更容易。在資料流式傳輸時，連線問題總是可能發生，較小的檔案可以避免在發生錯誤時從頭開始。
- 檔案透過 CloudFront 提供給使用者。根據我們的經驗，大型檔案不會被此服務快取，導致下載速度較慢。在任何情況下，單個 LFS 檔案都不能大於 50GB。即，50GB 是單個檔案大小的硬性限制。
- 提交次數：您的倉庫歷史記錄中的提交總數沒有硬性限制。然而，根據我們的經驗，在數千次提交後，Hub 上的使用者體驗開始下降。我們正在不斷努力改進服務，但必須始終記住，git 倉庫並非旨在作為具有大量寫入的資料庫執行。如果您的倉庫歷史記錄變得非常大，始終可以使用
huggingface_hub的super_squash_history來合併所有提交以重新開始。請注意，這是一個不可逆的操作。 - 每次提交的運算元量：同樣，這裡沒有硬性限制。當提交上傳到 Hub 時，每個 Git 操作（新增或刪除）都會由伺服器檢查。當一百個 LFS 檔案同時提交時，每個檔案都會單獨檢查，以確保其已正確上傳。透過 HTTP 推送資料時，請求設定了 60 秒的超時時間，這意味著如果該過程花費的時間更長，則會引發錯誤。但是，在極少數情況下，即使客戶端引發了超時，伺服器端的過程也可能仍然完成。這可以透過在 Hub 上瀏覽儲存庫手動檢查。為了防止此超時，我們建議每次提交新增約 50-100 個檔案。
在 Hub 上共享大型資料集
Hugging Face 支援機器學習生態系統的一個關鍵方式是在 Hub 上託管資料集，包括非常大的資料集。但是，如果您的資料集大於 300GB，您需要請求我們授予更多儲存空間。
在這種情況下，為了確保我們能夠有效地支援開源生態系統，您需要透過 datasets@huggingface.co 告知我們。
當您與我們聯絡時，請告知我們：
- 資料集是什麼，它可能對誰/什麼有用？
- 資料集的大小。
- 您計劃用於共享資料集的格式。
為了在 Hub 上託管大型資料集，我們要求您的資料集滿足以下條件：
- 資料集卡片：我們希望確保您的資料集能夠被社群有效利用，而實現這一點的關鍵方式之一就是透過資料集卡片。本指南提供瞭如何編寫資料集卡片的概述。
- 您共享資料集是為了社群重用。如果您計劃上傳一個預計不會有任何進一步重用的資料集，那麼其他平臺可能更適合。
- 您必須遵守上述儲存庫限制。
- 使用與 Hugging Face 生態系統良好整合的檔案格式。我們對 Parquet 和 WebDataset 格式有良好的支援，這些格式通常是高效共享大型資料集的良好選擇。這也將確保資料集檢視器適用於您的資料集。
- 在使用資料集時避免使用自定義載入指令碼。根據我們的經驗，需要自定義程式碼才能使用的資料集通常重用率有限。
如果您因為資料型別或領域而難以滿足這些要求中的任何一項，請與我們聯絡。
在 Hub 上共享大量模型
與資料集類似，如果您託管的模型大於 300GB，或者您計劃上傳大量較小模型（例如，數百個自動化量化模型）總計超過 1TB，您需要請求我們授予更多儲存空間。
為此，為確保我們能有效支援開源生態系統，請傳送包含專案詳情的電子郵件至 models@huggingface.co。
私有儲存庫授權
如果您因學術/研究目的需要比您分配的私有儲存更多的模型/資料集儲存空間，請透過 datasets@huggingface.co 或 models@huggingface.co 聯絡我們，並附上您將如何使用儲存授權的提案。
如何在我的賬戶/組織中釋放儲存空間？
有幾種方法可以管理和釋放您賬戶或組織中的儲存空間。首先，如果您需要更多儲存空間，可以考慮升級到 PRO 或企業 Hub 計劃以獲得更高的儲存限制。
⚠️ 重要：刪除 LFS 檔案是破壞性操作，無法撤消。請務必在操作前備份您的檔案。
記住以下關鍵點：
- 僅刪除 LFS 指標並不能釋放空間
- 如果您不重寫 Git 歷史記錄，則將來檢出包含已刪除 LFS 檔案（但仍有現有 LFS 指標）的分支/標籤將失敗（為避免錯誤，請將以下行新增到您的
.gitconfig檔案中：lfs.skipdownloaderrors=true）
刪除單個 LFS 檔案
- 導航到您的倉庫設定頁面
- 在“儲存”部分點選“列出 LFS 檔案”
- 使用操作選單刪除特定檔案
使用 API 對您的倉庫進行超級合併 (Super-squash)
超級合併操作將您的整個 Git 歷史壓縮成一個單獨的提交。當您需要從不再使用的舊 LFS 版本中回收儲存空間時，請考慮使用超級合併。此操作僅透過 Hub Python 庫或 API 提供。
⚠️ 重要：這是一個破壞性操作，無法撤消，提交歷史將被永久丟失，並且LFS 檔案歷史將被刪除
合併操作對您的儲存配額的影響不是即時的，將在 36 小時內反映在您的配額中。
高階：追蹤 LFS 檔案引用
當您在倉庫的“LFS 檔案列表”中找到一個 LFS 檔案但不知道它來自何處時，可以使用 Git 日誌命令透過其 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