ストレージの制限

Hugging Faceでは、パブリックリポジトリ用の無料ストレージスペースをAIコミュニティに大量に提供することを目標としており、必要に応じて追加のストレージを購入するオプションも用意しています。また、プライベートリポジトリのストレージスペースについては、無料枠を超えた分を課金します（下表を参照）。

Hub上のすべてのリポジトリタイプ（モデル、データセット、バケットなど）に、ストレージの制限とポリシーが適用されます。

AIと機械学習の成長に伴う今後数年間の需要拡大を見据え、インフラストラクチャを継続的に最適化し、ストレージをスケールしています。

無料の公開ストレージの悪用を防ぐための対策は講じられていますが、一般的に、ユーザーおよび組織には、アップロードした大規模なモデルやデータセットがコミュニティにとってできるだけ有用なもの（例えば、いいね数やダウンロード数で表される）であることを確認していただくようお願いしています。より高い制限を解除するには、有料のOrganizationまたはUser（PRO）アカウントにアップグレードしてください。

ストレージプラン

💡 Team or Enterprise Organizationsのサブスクリプションには、1シートあたり1TBのプライベートストレージが含まれます。例えば、組織に40人のメンバーがいる場合、40TBのプライベートストレージが含まれます。

* 当社は、パブリックリポジトリに対して、AIコミュニティに寛大な無料ストレージスペースを提供し続けることを目指しています。最初の数ギガバイトを超えた場合、他のユーザーに真の価値を提供するコンテンツをアップロードすることで、このリソースを責任を持ってご利用ください。大量のストレージスペースが必要な場合は、PRO、Team、またはEnterpriseへのアップグレードが必要です。

† 一部のケースでは、有料プランでは本当にニーズをカバーできない高インパクトなオープンソース作業に対して、追加のストレージ割当が利用可能です。コミュニティへのインパクト（いいね数、ダウンロード数、引用数）の証拠を添えて、お問い合わせください。

Public Storage アドオン

有料プラン（PRO、Team、またはEnterprise）のユーザーは、Public Storage add-onに加入することで、プランのベース制限に加えて追加の公開ストレージを利用できます。

アカウントまたは組織のBilling設定ページから、サブスクリプションの登録やティアの変更を行うことができます。アップグレードは即時に反映されますが、ダウングレードは翌月の初めに反映されるようスケジュールされます。より多くのストレージ容量が必要な場合は、お問い合わせいただくことで、カスタム大規模価格設定をご利用いただけます。

プライベートストレージ 従量課金制

PROおよびTeamまたはEnterprise Organizationに含まれる1TB(または1シートあたり1TB)のプライベートストレージを超えた分については、Pay-as-you-goモードで、基本料金$18/TB/月にて、お支払い方法に請求されます。 大規模な容量については、アカウントエグゼクティブを通じて追加の割引が利用可能です:

詳細については、請求に関するドキュメントをご覧ください。最新の料金については、huggingface.co/pricingでご確認いただけます。

リポジトリの制限事項と推奨事項

このセクションはStorage Bucketsには適用されません。

アカウント（ユーザーまたは組織）レベルのストレージ制限に加えて、特定のGitベースのリポジトリで大量のデータを扱う際には、いくつかの制限に注意が必要です。データをストリーミングするのにかかる時間を考えると、アップロード/プッシュが処理の最後に失敗したり、hf.co上でもローカル作業中にも、体験が劣化したりすることは非常に煩わしいものです。次のセクションでは、大規模なリポジトリを最適な構造にするための推奨事項について説明します。

推奨事項

リポジトリの構成に関するヒントと推奨事項のリストをまとめました。より実践的なヒントをお探しの方は、Pythonライブラリを使用して大量のデータをアップロードする方法について解説したこのガイドをご覧ください。

* git CLIを直接使用する場合、関連ありません

これらの制限をより深く理解し、対処する方法を知るために、次のセクションをお読みください。

説明

「大規模なアップロード」とは具体的に何を指し、どのような制約がありますか。大規模なアップロードは多岐にわたり、数個の巨大ファイル（モデルの重みなど）を含むリポジトリから、数千個の小さなファイル（画像データセットなど）を含むリポジトリまで、その内容は非常に多様です。

内部では、Hub は Git を使用してデータのバージョン管理を行っており、リポジトリで実行できる操作に構造的な制約が生じます。 前節で言及した数値のいずれかに該当するリポジトリの場合、git-sizer の確認を強くお勧めします。 このツールには、体験に影響を与えるさまざまな要因について非常に詳細なドキュメントが用意されています。考慮すべき要因の要点は以下の通りです。

• リポジトリのサイズ: アップロード予定のデータの合計サイズです。モデルとデータセットにはリポジトリごとのサイズ制限はありませんが、アップロードはアカウントの合計ストレージクォータにカウントされます（上記のストレージプランを参照）。より多くのストレージが必要な場合は、プランをアップグレードするか、ストレージアドオンを購入してください。
• Number of files:
  • 最適な体験を得るためには、ファイルの総数を10万未満、できればそれよりはるかに少ない数に抑えることをお勧めします。ファイル数が多い場合は、データをより少ないファイルにマージしてください。 例えば、jsonファイルは単一のjsonlファイルにマージしたり、大規模なデータセットはParquetファイルとして、またはWebDataset形式でエクスポートしたりできます。
  • フォルダごとのファイル数の上限は10,000個です。簡単な解決策として、サブディレクトリを利用するリポジトリ構造を作成することをお勧めします。例えば、000/から999/までの1,000個のフォルダを作成し、各フォルダに最大1,000個のファイルを格納する構成であれば、すでに十分です。
• File size: 大きなファイル（モデルの重みなど）をアップロードする場合は、 200GB 以下のチャンクに分割することを強くお勧めします。. その理由は以下の通りです：
  • 小さいファイルをアップロード・ダウンロードする方が、あなた自身や他のユーザーの両方にとってずっと簡単です。ストリーミングデータでは接続の問題が常に発生する可能性があり、小さいファイルであれば、エラーが発生した場合に最初から再開することを避けることができます。
  • ファイルはCloudFrontを使用してユーザーに配信されます。私たちの経験上、このサービスでは巨大なファイルがキャッシュされないため、ダウンロード速度が遅くなる場合があります。 いずれの場合も、単一のファイルのサイズは500GBを超えません。つまり、単一ファイルのサイズには500GBという上限が設定されています。
• コミット数: リポジトリの履歴におけるコミットの総数に厳密な上限はありません。ただし、私たちの経験上、Hub でのユーザー体験は数千回のコミットを超えると低下し始めます。私たちはサービスを継続的に改善に取り組んでいますが、git リポジトリは大量の書き込みを行うデータベースとして動作することを意図していないことを常に念頭に置く必要があります。リポジトリの履歴が非常に大きくなった場合、huggingface_hub の super_squash_history を使用してすべてのコミットを squash し、新しいスタートを切ることも常に可能です。この操作は元に戻せない点にご注意ください。
• コミットあたりの操作数: 再度、ここには厳密な上限はありません。Hub にコミットがアップロードされると、各 git 操作（追加または削除）がサーバーによってチェックされます。100 個の Large Files が一度にコミットされた場合、各ファイルが正しくアップロードされていることを確認するために個別にチェックされます。HTTP を介してデータをプッシュする際、リクエストには 60 秒のタイムアウトが設定されており、処理がこの時間を超えるとエラーが発生します。ただし、まれにクライアント側でタイムアウトが発生しても、サーバー側では処理が完了している場合があります。これは Hub 上でリポジトリを閲覧することで手動で確認できます。upload_folder メソッドと hf upload コマンドは、大きなフォルダを複数のコミットに分割することで、これを自動的に回避します。手動でコミットする場合は、1 コミットあたり 50〜100 ファイル程度にしてください。

Hubでの大規模データセットの共有

Hugging Faceが機械学習エコシステムを支える重要な方法の一つは、非常に大規模なものを含むデータセットをHub上でホスティングすることです。大規模なデータセットはアカウントの総ストレージクォータにカウントされるため、アップロード前にストレージプランに十分な容量があることを確認してください。追加の公開ストレージは、アドオンとして購入できます。

Hub上で大規模なデータセットをホスティングするには、以下の要件が必要です。

• データセットカード: コミュニティがあなたのデータセットを効果的に活用できるようにすることが重要であり、そのための重要な手段の一つがデータセットカードです。このガイダンスでは、データセットカードの作成方法について概要を説明します。
• コミュニティでの再利用を可能にするために、データセットを共有しています。さらなる再利用が見込めないデータセットをアップロードする予定がある場合は、他のプラットフォームの方が適している可能性が高いです。
• 上記で説明したリポジトリの制限を遵守する必要があります。
• Hugging Faceエコシステムと密に統合されたファイル形式を使用します。ParquetおよびWebDataset形式には十分なサポートがあり、大規模なデータセットを効率的に共有するための優れた選択肢となる場合が多いです。これにより、データセットビューアがあなたのデータセットで正常に動作することも保証されます。
• datasets を使用する際は、カスタムローディングスクリプトの使用を避けてください。経験上、使用するためにカスタムコードを必要とするデータセットは、再利用性が限られることが多いです。

データの種類や対象ドメインの特性により、これらの要件を満たすことが困難な場合は、お気軽にお問い合わせください。

Hubでの大量のモデルの共有

データセットと同様に、大規模なモデルや大量のモデル（例えば、数百の自動クオンタイズ）は、アカウントの合計ストレージクォータにカウントされます。ストレージプランに十分な容量があることを確認するか、ストレージアドオンを購入してください。

研究チームおよび非営利団体向けの助成金

学術機関および研究機関には、Team、Enterprise、または Academia Hubへのアップグレードを推奨します。これにより、ストレージの上限が保証されます。一部のケースでは、有料プランでは本当にニーズをカバーできない高インパクトなオープンソース作業に対して、ストレージの提供が利用可能な場合があります。これらの提供はケースバイケースで評価され、コミュニティへの実証されたインパクト（ダウンロード数、引用、コミュニティでの採用など）が必要です。詳細な提案書とともに、datasets@huggingface.coまたはmodels@huggingface.coまでご連絡ください。

アカウント/組織のストレージ容量を解放するにはどうすればよいですか?

アカウントまたは組織のストレージ容量を管理し、空き領域を確保するには、いくつかの方法があります。まず、より多くのストレージ容量が必要な場合は、ストレージ上限を引き上げるためにPRO、Team、またはEnterpriseプランにアップグレードしてください。

⚠️ 重要: 大きなファイルの削除は元に戻せない破壊的操作です。続行する前に、必ずファイルをバックアップしてください。

覚えておくべき重要なポイント:

• LFSポインタのみを削除しても、スペースは解放されません
• Git の履歴を書き換えない場合、削除された LFS ファイルの既存の lfs ポインターを含むブランチ/タグの将来のチェックアウトが失敗します（エラーを回避するには、.gitconfig ファイルに次の行を追加してください: lfs.skipdownloaderrors=true）

個々のLFSファイルの削除

1. リポジトリの設定ページに移動します
2. Storage セクションの List LFS files をクリックします
3. アクションメニューを使用して、特定のファイルを削除します

Pull request refs の削除

Pull requestsは、そのコミットを保存するgit refを作成します。PRをクローズまたはマージした後、そのrefを削除してストレージの空き領域を確保できます。これは特に次の場合に役立ちます：

• PRには、マージされなかった大きなファイルが含まれています
• メインブランチをsquashして、その後でファイルを削除した場合、そのファイルはPR自体によって追加されなかったとしても、PRブランチの履歴に残り続けます

PR ref を削除するには、クローズまたはマージされた PR を開き、下部に表示されるストレージ通知を確認してください。この通知には、解放できる推定容量が表示されます。“Delete ref” をクリックして、恒久的に削除します。

PR refの削除は元に戻すことができず、それらのコミットをローカルでフェッチしたりチェックアウトしたりすることができなくなります。

APIを使用してリポジトリをスーパースクワッシュします

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