Limites de stockage

Chez Hugging Face, nous visons à offrir à la communauté de l’IA des volumes importants d’espace de stockage gratuit pour les dépôts publics, avec la possibilité d’acheter plus de stockage si nécessaire. Nous facturons également l’espace de stockage pour les dépôts privés, au-delà d’un forfait gratuit (voir le tableau ci-dessous).

Des limites et des politiques de stockage s'appliquent à tous les types de dépôts (modèles, jeux de données, buckets, …) sur le Hub.

Nous optimisons notre infrastructure en continu afin de faire évoluer notre stockage pour les années de croissance à venir dans les domaines de l'IA et de l'apprentissage automatique.

Des mesures de mitigation sont en place pour prévenir l’abus du stockage public gratuit. De manière générale, nous demandons aux utilisateurs et aux organisations de s’assurer que tout modèle ou jeu de données volumineux téléversé est le plus utile possible pour la communauté (comme en témoignent, par exemple, le nombre de « j’aime » ou de téléchargements). Passez à un compte Organisation ou Utilisateur (PRO) payant pour débloquer des limites plus élevées.

Plans de stockage

💡 Les organisations Team ou Enterprise incluent 1 To de stockage privé par siège dans l’abonnement : par exemple, si votre organisation compte 40 membres, vous disposez de 40 To de stockage privé inclus.

* Nous nous engageons à continuer d’offrir à la communauté de l’IA un espace de stockage gratuit généreux pour les dépôts publics. Au-delà des premiers gigaoctets, veuillez utiliser cette ressource de manière responsable en téléchargeant du contenu qui apporte une valeur réelle aux autres utilisateurs. Si vous avez besoin d’un espace de stockage important, vous devrez passer à PRO, Team ou Enterprise.

† Dans certains cas, des autorisations de stockage supplémentaires sont disponibles pour les travaux open source à fort impact, lorsque l’abonnement payant ne couvre réellement pas le besoin. Contactez-nous en fournissant des preuves de l’impact communautaire (likes, téléchargements, citations).

Extension de stockage public

Les utilisateurs disposant d’un abonnement payant (PRO, Team ou Enterprise) peuvent souscrire à un add-on Public Storage pour bénéficier d’un stockage public supplémentaire au-delà de la limite de base de leur plan.

Vous pouvez vous abonner ou modifier votre forfait depuis la page de paramètres Facturation de votre compte ou de votre organisation. Les mises à niveau prennent effet immédiatement ; les rétrogradations sont programmées pour prendre effet au début du mois suivant. Si vous avez besoin de plus de stockage, vous pouvez nous contacter pour bénéficier d'un tarif personnalisé à grande échelle.

Stockage privé Paiement à l'usage

En plus des 1 To (ou 1 To par siège) de stockage privé inclus dans PRO et les Organisations Team ou Enterprise, le stockage privé supplémentaire est facturé à votre moyen de paiement en mode Pay-as-you-go, à un tarif de base de 18 $/To/mois. Des remises supplémentaires sont disponibles pour les volumes importants via nos responsables commerciaux :

Consultez notre document de facturation pour plus de détails, ou consultez les tarifs les plus récents sur huggingface.co/pricing.

Limites et recommandations du dépôt

Cette section ne s'applique pas aux Storage Buckets

En plus des limites de stockage au niveau du compte (utilisateur ou organisation), il existe certaines restrictions à prendre en compte lors de la manipulation de grandes quantités de données dans un dépôt Git spécifique. Compte tenu du temps nécessaire pour diffuser les données, le fait qu’un téléversement/push échoue à la fin du processus ou qu’une expérience dégradée survienne, que ce soit sur hf.co ou lors d’un travail local, peut être très gênant. Dans la section suivante, nous décrivons nos recommandations sur la meilleure façon de structurer vos dépôts volumineux.

Recommandations

Nous avons rassemblé une liste de conseils et de recommandations pour structurer votre dépôt. Si vous recherchez des conseils plus pratiques, consultez ce guide sur la manière de téléverser de grandes quantités de données à l'aide de la bibliothèque Python.

* Non pertinent lors de l'utilisation directe de l'interface en ligne de commande git

Veuillez lire la section suivante pour mieux comprendre ces limites et savoir comment y faire face.

Explications

De quoi parle-t-on lorsque l’on évoque les « grands dépôts », et quelles sont les limitations associées ? Les grands dépôts peuvent être très variés, allant de dépôts contenant quelques fichiers très volumineux (par exemple des poids de modèle) à des dépôts contenant des milliers de petits fichiers (par exemple un jeu de données d’images).

Sous le capot, le Hub utilise Git pour versionner les données, ce qui a des implications structurelles sur ce que vous pouvez faire dans votre dépôt. Si votre dépôt dépasse certains des seuils mentionnés dans la section précédente, nous vous encourageons vivement à consulter git-sizer, qui propose une documentation très détaillée sur les différents facteurs qui influenceront votre expérience. Voici un résumé des facteurs à prendre en compte :

• Taille du dépôt : la taille totale des données que vous prévoyez de téléverser. Il n’y a pas de limite de taille par dépôt pour les modèles et les jeux de données, mais les téléversements sont comptés dans le quota de stockage total de votre compte (voir Plans de stockage ci-dessus). Si vous avez besoin de plus de stockage, mettez à niveau votre plan ou achetez un ajout de stockage.
• Number of files:
  • Pour une expérience optimale, nous recommandons de maintenir le nombre total de fichiers sous la barre de 100 k, et idéalement bien en dessous. Si vous en avez davantage, essayez de fusionner les données dans un nombre réduit de fichiers. Par exemple, les fichiers json peuvent être fusionnés en un seul fichier jsonl, ou les grands jeux de données peuvent être exportés au format Parquet ou au format WebDataset.
  • Le nombre maximal de fichiers par dossier ne peut pas dépasser 10 k fichiers par dossier. Une solution simple consiste à créer une structure de dépôt qui utilise des sous-dossiers. Par exemple, un dépôt avec 1 k dossiers allant de 000/ à 999/, chacun contenant au maximum 1000 fichiers, est déjà suffisant.
• File size: Lors de la téléversement de fichiers volumineux (par exemple, des poids de modèle), nous recommandons vivement de les diviser en segments de moins de 200 Go chacun.. Il y a plusieurs raisons à cela :
  • Téléverser et télécharger des fichiers plus petits est beaucoup plus simple, tant pour vous que pour les autres utilisateurs. Des problèmes de connexion peuvent toujours survenir lors du streaming de données, et des fichiers plus petits évitent de reprendre depuis le début en cas d’erreurs.
  • Les fichiers sont servis aux utilisateurs via CloudFront. D'après notre expérience, les très gros fichiers ne sont pas mis en cache par ce service, ce qui entraîne une vitesse de téléchargement plus lente. Dans tous les cas, aucun fichier unique ne dépassera 500 Go. Autrement dit, 500 Go est la limite stricte pour la taille d'un fichier unique.
• Nombre de commits : Il n’y a pas de limite stricte au nombre total de commits dans l’historique de votre dépôt. Cependant, d’après notre expérience, l’expérience utilisateur sur le Hub commence à se dégrader après quelques milliers de commits. Nous travaillons constamment à améliorer le service, mais il faut toujours garder à l’esprit qu’un dépôt git n’est pas conçu pour fonctionner comme une base de données avec de nombreuses écritures. Si l’historique de votre dépôt devient très volumineux, il est toujours possible d’écraser tous les commits pour repartir de zéro à l’aide de super_squash_history de huggingface_hub. Sachez qu’il s’agit d’une opération irréversible.
• Nombre d’opérations par commit : Là encore, il n’existe pas de limite stricte. Lorsqu’un commit est téléversé sur le Hub, chaque opération git (ajout ou suppression) est vérifiée par le serveur. Lorsque cent fichiers de grande taille sont commités d’un coup, chaque fichier est vérifié individuellement pour s’assurer qu’il a été correctement téléversé. Lors de l’envoi de données via HTTP, un délai d’attente de 60 s est défini sur la requête, ce qui signifie qu’une erreur est levée si le processus prend plus de temps. Il peut toutefois arriver (dans de rares cas) que, même si le délai d’attente est dépassé côté client, le processus soit tout de même terminé côté serveur. Cela peut être vérifié manuellement en parcourant le dépôt sur le Hub. La méthode upload_folder et la commande hf upload évitent ce problème automatiquement en découpant les grands dossiers en plusieurs commits. Si vous effectuez les commits manuellement, visez environ 50 à 100 fichiers par commit.

Partager de grands jeux de données sur le Hub

L’une des principales façons dont Hugging Face soutient l’écosystème de l’apprentissage automatique est d’héberger des jeux de données sur le Hub, y compris des jeux de données très volumineux. Les grands jeux de données comptent dans le quota de stockage total de votre compte, assurez-vous donc que votre plan de stockage dispose d’une capacité suffisante avant de téléverser. Un stockage public supplémentaire peut être acheté en tant qu’option.

Pour l'hébergement de grands jeux de données sur le Hub, les conditions suivantes sont requises :

• Fiche de jeu de données : nous souhaitons nous assurer que votre jeu de données peut être utilisé efficacement par la communauté, et l'un des moyens clés de le permettre est de fournir une fiche de jeu de données. Ce guide présente un aperçu de la manière de rédiger une fiche de jeu de données.
• Vous partagez le jeu de données pour permettre sa réutilisation par la communauté. Si vous prévoyez de téléverser un jeu de données dont vous ne prévoyez aucune réutilisation ultérieure, d'autres plateformes sont probablement plus adaptées.
• Vous devez respecter les limitations du dépôt décrites ci-dessus.
• Utiliser des formats de fichiers bien intégrés à l'écosystème Hugging Face. Nous prenons bien en charge les formats Parquet et WebDataset, qui sont souvent de bonnes options pour partager efficacement de grands jeux de données. Cela garantira également que le visualiseur de jeux de données fonctionne pour votre jeu de données.
• Évitez l'utilisation de scripts de chargement personnalisés lors de l'utilisation de datasets. D'après notre expérience, les datasets qui nécessitent du code personnalisé pour être utilisés finissent souvent par avoir une réutilisation limitée.

N'hésitez pas à nous contacter si l'une de ces exigences est difficile à respecter en raison du type de données ou du domaine dans lequel vous travaillez.

Partager de grands volumes de modèles sur le Hub

De la même manière que pour les jeux de données, les grands modèles ou les grands volumes de modèles (par exemple, des centaines de quantifications automatisées) comptent dans le quota de stockage total de votre compte. Assurez-vous que votre plan de stockage dispose d’une capacité suffisante, ou achetez un ajout de stockage.

Subventions pour les équipes de recherche et les organisations à but non lucratif

Nous recommandons aux institutions académiques et de recherche de passer à Team, Enterprise ou Academia Hub pour bénéficier de limites de stockage garanties. Dans certains cas, des subventions de stockage peuvent être accordées pour des travaux open source à fort impact, lorsque l’offre payante ne couvre réellement pas le besoin. Ces demandes sont évaluées au cas par cas et exigent une démonstration de l’impact communautaire (téléchargements, citations, adoption par la communauté, etc.). Contactez datasets@huggingface.co ou models@huggingface.co avec une proposition détaillée.

Comment libérer de l'espace de stockage dans mon compte/organisation ?

Plusieurs méthodes permettent de gérer et de libérer de l’espace de stockage dans votre compte ou votre organisation. Tout d’abord, si vous avez besoin de plus d’espace de stockage, passez à un plan PRO, Team ou Enterprise pour bénéficier de limites de stockage accrues.

⚠️ Important : La suppression de fichiers volumineux est une opération destructive qui ne peut pas être annulée. Assurez-vous de sauvegarder vos fichiers avant de procéder.

Points clés à retenir :

• Supprimer uniquement les pointeurs LFS ne libère pas d’espace
• Si vous ne réécrivez pas l’historique Git, les futures vérifications de branches/étiquettes contenant des fichiers LFS supprimés avec des pointeurs lfs existants échoueront (pour éviter les erreurs, ajoutez la ligne suivante à votre fichier .gitconfig : lfs.skipdownloaderrors=true)

Suppression de fichiers LFS individuels

1. Accédez à la page Paramètres de votre dépôt
2. Cliquez sur « List LFS files » dans la section « Storage »
3. Utilisez le menu des actions pour supprimer des fichiers spécifiques

Suppression des références de demande de tirage

Les demandes de fusion (pull requests) créent des références git qui stockent leurs commits. Après avoir fermé ou fusionné une PR, vous pouvez supprimer sa référence pour libérer de l’espace de stockage. Cela est particulièrement utile lorsque :

• Les PR contiennent de grands fichiers qui n'ont jamais été fusionnés
• Vous avez écrasé la branche principale et supprimé des fichiers par la suite — ces fichiers restent dans l’historique de la branche de la PR, même s’ils n’ont pas été ajoutés par la PR elle-même

Pour supprimer une référence de PR, ouvrez la PR fermée ou fusionnée et repérez l’avis de stockage en bas de page indiquant l’espace estimé qui pourrait être libéré. Cliquez sur « Delete ref » pour la supprimer définitivement.

La suppression d'une référence de PR est irréversible et empêchera toute personne de récupérer ou de vérifier localement ces commits.

Super-squash votre dépôt à l'aide de l'API

L’opération super-squash compresse l’ensemble de votre historique Git en un seul commit. Envisagez d’utiliser super-squash lorsque vous devez libérer de l’espace de stockage occupé par d’anciennes versions LFS que vous n’utilisez plus. Cette opération n’est disponible que via la Hub Python Library ou l’API.

⚠️ Important : il s'agit d'une opération destructive irréversible, l'historique des commits sera définitivement perdu et l'historique des fichiers LFS sera supprimé

Les effets de l'opération de compression sur votre quota de stockage ne sont pas immédiats et seront reflétés sur votre quota dans un délai de 36 heures.

Avancé : Suivre les références de fichiers LFS

Lorsque vous trouvez un fichier LFS dans « List LFS files » de votre dépôt mais que vous ignorez d’où il provient, vous pouvez retracer son historique à l’aide de son OID SHA-256 en utilisant la commande git log :

git log --all -p -S <SHA-256-OID>

Par exemple :

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