Hugging Face 的 LOGO

Hub 文档

存储限制

Hugging Face's logo
加入 Hugging Face 社区

并获得增强的文档体验

开始使用

存储限制

在 Hugging Face，我们的目标是为 AI 社区提供公共存储库的免费存储空间。对于超出免费额度的私有存储库，我们会收取存储费用（见下表）。

存储限制和政策适用于 Hub 上的模型和数据集存储库。

我们持续优化我们的基础设施，以在机器学习未来多年的增长中扩展我们的存储。

我们已经采取了缓解措施，以防止滥用免费公共存储，通常我们要求用户和组织确保任何上传的大型模型或数据集都尽可能对社区有用（例如，通过点赞数或下载数来体现）。

存储方案

账户类型 公共存储 私有存储
免费用户或组织 尽力而为* 🙏 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 文件

  1. 导航到您的仓库设置页面
  2. 在“存储”部分点击“列出 LFS 文件”
  3. 使用操作菜单删除特定文件

使用 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
< > 在 GitHub 上更新

←存储后端 后续步骤→