Hub 文档
存储限制
并获得增强的文档体验
开始使用
存储限制
在 Hugging Face，我们的目的是为 AI 社区提供公共仓库的免费存储空间。我们确实会对私有仓库的存储空间收费，超出免费层级（见下表）。
我们持续优化我们的基础设施，以便在机器学习未来几年的增长中扩展我们的存储。
我们确实有缓解措施来防止滥用免费公共存储，总的来说，我们要求用户和组织确保任何上传的大型模型或数据集尽可能对社区有用（例如，以点赞数或下载量表示）。
存储计划
| 账户类型 | 公共存储 | 私有存储 |
|---|---|---|
| 免费用户或组织 | 尽力而为* 🙏 | 100GB |
| PRO | 无限 ✅ | 1TB + 按需付费 |
| 企业 Hub | 无限 ✅ | 每席位 1TB + 按需付费 |
💡 企业 Hub 订阅包含每席位 1TB 的私有存储：例如，如果您的组织有 40 名成员，那么您将获得 40TB 的包含私有存储。
*我们的目标是继续为 AI 社区提供公共仓库的免费存储空间，请不要滥用并上传数十 TB 的生成动漫 😁。如果可能，我们仍然建议您尽可能考虑升级到 PRO 和/或企业 Hub。
按需付费价格
超出 PRO 和企业 Hub 中包含的 1TB（或每席位 1TB）私有存储空间后，私有存储的费用为每月 25 美元/TB，以 1TB 为增量。有关更多详细信息，请参阅我们的账单文档。
仓库限制和建议
除了账户（用户或组织）级别的存储限制外，在特定仓库中处理大量数据时，还需要注意一些限制。考虑到流式传输数据所需的时间，在流程结束时上传/推送失败或遇到降级的体验（无论是在 hf.co 上还是在本地工作时），都可能非常令人恼火。在以下部分中，我们描述了关于如何最佳地构建大型仓库的建议。
建议
我们收集了一系列关于构建仓库的技巧和建议。如果您正在寻找更实用的技巧，请查看本指南，了解如何使用 Python 库上传大量数据。
| 特征 | 建议 | 提示 |
|---|---|---|
| 仓库大小 | - | 对于大型仓库（TB 级数据），请联系我们 |
| 每个仓库的文件数 | <10 万 | 将数据合并到更少的文件中 |
| 每个文件夹的条目数 | <1 万 | 在仓库中使用子目录 |
| 文件大小 | <20GB | 将数据拆分为分块文件 |
| 提交大小 | <100 个文件* | 在多次提交中上传文件 |
| 每个仓库的提交数 | - | 每次提交上传多个文件和/或压缩历史记录 |
* 使用 git CLI 直接操作时，不相关
请阅读下一节，以更好地理解这些限制以及如何处理它们。
解释
当我们说“大型上传”时，我们指的是什么，以及它们相关的限制是什么？大型上传可能非常多样化，从只有几个巨大文件（例如模型权重）的仓库，到有数千个小文件（例如图像数据集）的仓库。
在底层，Hub 使用 Git 来版本化数据，这对您在仓库中所能做的事情有结构性影响。如果您的仓库超过了上一节中提到的一些数字，我们强烈建议您查看 git-sizer，其中有关于影响您体验的不同因素的非常详细的文档。以下是要考虑的因素的 TL;DR：
- 仓库大小：您计划上传的数据的总大小。我们通常支持最大 300GB 的仓库。如果您想上传超过 300GB（甚至 TB）的数据，您需要要求我们授予更多存储空间。为此，请将包含您的项目详细信息的电子邮件发送至 datasets@huggingface.co（对于数据集）或 models@huggingface.co（对于模型）。
- 文件数量:
- 为了获得最佳体验，我们建议将文件总数保持在 10 万以下，理想情况下要少得多。如果文件数量更多，请尝试将数据合并到更少的文件中。例如，json 文件可以合并到一个 jsonl 文件中，或者大型数据集可以导出为 Parquet 文件或 WebDataset 格式。
- 每个文件夹的最大文件数不能超过每个文件夹 1 万个文件。一个简单的解决方案是创建一个使用子目录的仓库结构。例如，一个包含从
000/到999/的 1 千个文件夹的仓库，每个文件夹最多包含 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 或 Enterprise Hub 计划以获得更高的存储限制。
⚠️ 重要提示：删除 LFS 文件是不可撤销的破坏性操作。在继续操作之前，请务必备份您的文件。
需要记住的要点
- 仅删除 LFS 指针不会释放空间
- 如果您不重写 Git 历史记录，则将来检出包含已删除 LFS 文件且具有现有 lfs 指针的分支/标签将会失败（为避免错误，请将以下行添加到您的
.gitconfig文件中：lfs.skipdownloaderrors=true）
删除单个 LFS 文件
- 导航到您仓库的“设置”页面
- 在“存储”部分点击“列出 LFS 文件”
- 使用操作菜单删除特定文件
使用 API 对您的仓库进行超级压缩
超级压缩操作将您的整个 Git 历史记录压缩为单个提交。当您需要从您不使用的旧 LFS 版本中回收存储空间时，请考虑使用超级压缩。此操作仅通过 Hub Python 库或 API 提供。
⚠️ 重要提示：这是一个不可撤销的破坏性操作，提交历史记录将永久丢失，并且 **LFS 文件历史记录将被删除**
压缩操作对您的存储配额的影响不是立竿见影的，将在 36 小时内反映在您的配额中。
高级：跟踪 LFS 文件引用
当您在仓库的“列出 LFS 文件”中找到一个 LFS 文件，但不知道它来自哪里时，您可以使用其 SHA-256 OID 通过使用 git log 命令来追溯其历史记录
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