Límites de almacenamiento

En Hugging Face nos proponemos ofrecer a la comunidad de IA grandes volúmenes de espacio de almacenamiento gratuito para repositorios públicos, con la opción de comprar más almacenamiento si es necesario. También cobramos por el espacio de almacenamiento de repositorios privados, por encima de un nivel gratuito (consulte la tabla siguiente).

Los límites y las políticas de almacenamiento se aplican a todos los tipos de repositorios (modelos, conjuntos de datos, cubos, …) en el Hub.

Optimizamos continuamente nuestra infraestructura para escalar nuestro almacenamiento de cara a los próximos años de crecimiento en IA y aprendizaje automático.

Contamos con medidas de mitigación para prevenir el abuso del almacenamiento público gratuito y, en general, pedimos a los usuarios y organizaciones que se aseguren de que cualquier modelo o conjunto de datos grande que suban sea lo más útil posible para la comunidad (representado, por ejemplo, por el número de me gusta o descargas). Actualice a una organización de pago o a una cuenta de usuario (PRO) de pago para desbloquear límites más altos.

Planes de almacenamiento

💡 Las organizaciones de equipo o empresariales incluyen 1 TB de almacenamiento privado por asiento en la suscripción: por ejemplo, si su organización tiene 40 miembros, dispone de 40 TB de almacenamiento privado incluido.

* Nuestro objetivo es seguir ofreciendo a la comunidad de IA un espacio de almacenamiento gratuito generoso para los repositorios públicos. Más allá de los primeros gigabytes, utilice este recurso de manera responsable subiendo contenido que ofrezca un valor genuino a otros usuarios. Si necesita un espacio de almacenamiento considerable, deberá actualizar a PRO, Team o Enterprise.

† En algunos casos, se pueden otorgar permisos de almacenamiento adicionales para trabajos de código abierto de alto impacto cuando un plan de pago no puede cubrir genuinamente la necesidad. Contáctenos con evidencia del impacto en la comunidad (me gusta, descargas, citas).

Add-on de almacenamiento público

Los usuarios con un plan de pago (PRO, Team o Enterprise) pueden suscribirse a un add-on de almacenamiento público para obtener almacenamiento público adicional por encima del límite base de su plan.

Puedes suscribirte o cambiar tu nivel desde la página de configuración de Facturación de tu cuenta u organización. Las mejoras surten efecto de inmediato; las reducciones se programan para entrar en vigor al inicio del mes siguiente. Si necesitas más almacenamiento, puedes contactarnos para aprovechar la tarifa personalizada a gran escala.

Almacenamiento privado Pago por uso

Por encima de los 1 TB (o 1 TB por asiento) de almacenamiento privado incluidos en PRO y Organizaciones de Team o Enterprise, el almacenamiento privado adicional se cobra a su método de pago en el modo Pay-as-you-go, con un precio base de 18 USD/TB/mes. Se pueden obtener descuentos adicionales para volúmenes a gran escala a través de nuestros ejecutivos de cuenta:

Consulte nuestro documento de facturación para obtener más detalles o consulte los precios más recientes en huggingface.co/pricing.

Limitaciones y recomendaciones del repositorio

Esta sección no se aplica a Storage Buckets

Además de los límites de almacenamiento a nivel de cuenta (usuario u organización), hay algunas limitaciones que conviene tener en cuenta al trabajar con grandes cantidades de datos en un repositorio específico basado en Git. Dado el tiempo que tarda en transmitirse los datos, que una carga o un push falle al final del proceso o que se experimente un rendimiento degradado, ya sea en hf.co o al trabajar localmente, puede resultar muy molesto. En la siguiente sección, describimos nuestras recomendaciones sobre cómo estructurar mejor los repositorios grandes.

Recomendaciones

Reunimos una lista de consejos y recomendaciones para estructurar tu repositorio. Si buscas consejos más prácticos, consulta esta guía sobre cómo cargar grandes cantidades de datos usando la biblioteca de Python.

* No es relevante al usar la CLI de git directamente

Lea la siguiente sección para comprender mejor esos límites y cómo abordarlos.

Explicaciones

¿A qué nos referimos cuando decimos “subidas grandes” y cuáles son sus limitaciones asociadas? Las subidas grandes pueden ser muy diversas, desde repositorios con unos pocos archivos enormes (p. ej., pesos de modelos) hasta repositorios con miles de archivos pequeños (p. ej., un conjunto de datos de imágenes).

Por debajo, el Hub utiliza Git para versionar los datos, lo que tiene implicaciones estructurales sobre lo que puedes hacer en tu repositorio. Si tu repositorio supera alguno de los números mencionados en la sección anterior, te animamos encarecidamente a que eches un vistazo a git-sizer, que cuenta con una documentación muy detallada sobre los diferentes factores que afectarán a tu experiencia. Aquí tienes un resumen de los factores a considerar:

• Tamaño del repositorio: el tamaño total de los datos que planea subir. No hay un límite de tamaño por repositorio para modelos y conjuntos de datos, pero las cargas se descuentan de la cuota de almacenamiento total de su cuenta (consulte Planes de almacenamiento arriba). Si necesita más almacenamiento, mejore su plan o compre un complemento de almacenamiento.
• Number of files:
  • Para una experiencia óptima, recomendamos mantener el número total de archivos por debajo de 100k, e idealmente mucho menos. Si tienes más, intenta fusionar los datos en menos archivos. Por ejemplo, los archivos json se pueden fusionar en un único archivo jsonl, o los conjuntos de datos grandes se pueden exportar como archivos Parquet o en formato WebDataset.
  • El número máximo de archivos por carpeta no puede superar los 10k archivos por carpeta. Una solución sencilla es crear una estructura de repositorio que utilice subdirectorios. Por ejemplo, un repositorio con 1k carpetas desde 000/ hasta 999/, cada una con un máximo de 1000 archivos, ya es suficiente.
• File size: En el caso de subir archivos grandes (p. ej., pesos de modelos), recomendamos encarecidamente dividirlos en fragmentos de menos de 200 GB cada uno.. Hay varias razones para ello:
  • Subir y descargar archivos más pequeños es mucho más fácil tanto para ti como para los demás usuarios. Los problemas de conexión pueden ocurrir siempre al transmitir datos, y los archivos más pequeños evitan tener que reanudar desde el principio en caso de errores.
  • Los archivos se sirven a los usuarios mediante CloudFront. Según nuestra experiencia, los archivos de gran tamaño no se almacenan en caché por este servicio, lo que provoca una velocidad de descarga más lenta. En todos los casos, ningún archivo individual superará los 500 GB. Es decir, 500 GB es el límite máximo estricto para el tamaño de un archivo individual.
• Número de commits: No hay un límite estricto para el número total de commits en el historial de tu repositorio. Sin embargo, por experiencia, la experiencia de usuario en el Hub comienza a degradarse después de unos pocos miles de commits. Estamos trabajando constantemente para mejorar el servicio, pero siempre hay que recordar que un repositorio git no está diseñado para funcionar como una base de datos con muchas escrituras. Si el historial de tu repositorio se vuelve muy grande, siempre es posible comprimir todos los commits para comenzar de nuevo usando super_squash_history de huggingface_hub. Ten en cuenta que esta es una operación irreversible.
• Número de operaciones por commit: De nuevo, no hay un límite estricto aquí. Cuando un commit se sube al Hub, cada operación de git (adición o eliminación) es verificada por el servidor. Cuando se commitean cien Large Files a la vez, cada archivo se verifica individualmente para asegurarse de que se ha subido correctamente. Al enviar datos a través de HTTP, se establece un timeout de 60s en la solicitud, lo que significa que si el proceso tarda más tiempo, se genera un error. Sin embargo, puede ocurrir (en casos raros) que, aunque se genere el timeout en el lado del cliente, el proceso se complete en el lado del servidor. Esto se puede verificar manualmente navegando por el repositorio en el Hub. El método upload_folder y el comando hf upload evitan esto automáticamente dividiendo las carpetas grandes en múltiples commits. Si commiteas manualmente, mantén alrededor de 50-100 archivos por commit.

Compartir conjuntos de datos grandes en el Hub

Una forma clave en la que Hugging Face apoya el ecosistema de aprendizaje automático es alojando conjuntos de datos en el Hub, incluidos los de gran tamaño. Los conjuntos de datos grandes se descuentan de la cuota total de almacenamiento de tu cuenta, así que asegúrate de que tu plan de almacenamiento tenga capacidad suficiente antes de subirlos. El almacenamiento público adicional se puede comprar como un complemento.

Para alojar grandes conjuntos de datos en el Hub, se requiere lo siguiente:

• Ficha de un conjunto de datos: queremos asegurarnos de que tu conjunto de datos pueda ser utilizado de manera efectiva por la comunidad, y una de las formas clave de lograrlo es mediante una ficha de conjunto de datos. Esta guía ofrece una visión general sobre cómo escribir una ficha de conjunto de datos.
• Estás compartiendo el conjunto de datos para permitir su reutilización por parte de la comunidad. Si planeas subir un conjunto de datos que no prevé ninguna reutilización adicional, es probable que otras plataformas sean más adecuadas.
• Debes seguir las limitaciones del repositorio descritas anteriormente.
• Utilice formatos de archivo bien integrados con el ecosistema de Hugging Face. Tenemos buen soporte para los formatos Parquet y WebDataset, que suelen ser buenas opciones para compartir grandes conjuntos de datos de manera eficiente. Esto también asegurará que el visor de conjuntos de datos funcione con su conjunto de datos.
• Evite el uso de scripts de carga personalizados al utilizar datasets. Según nuestra experiencia, los datasets que requieren código personalizado para su uso suelen terminar con un uso limitado.

Póngase en contacto con nosotros si alguno de estos requisitos le resulta difícil de cumplir debido al tipo de datos o al dominio en el que está trabajando.

Compartir grandes volúmenes de modelos en el Hub

De manera similar a los conjuntos de datos, los modelos grandes o grandes volúmenes de modelos (por ejemplo, cientos de cuantizaciones automatizadas) se descuentan de la cuota total de almacenamiento de tu cuenta. Asegúrate de que tu plan de almacenamiento tenga capacidad suficiente, o compra un complemento de almacenamiento.

Subvenciones para equipos de investigación y organizaciones sin fines de lucro

Recomendamos que las instituciones académicas y de investigación migren a Team, Enterprise o Academia Hub para contar con límites de almacenamiento garantizados. En algunos casos, pueden estar disponibles concesiones de almacenamiento para trabajos de código abierto de alto impacto donde un plan de pago no pueda cubrir genuinamente la necesidad. Estas se evalúan caso por caso y requieren un impacto comunitario demostrado (descargas, citas, adopción por la comunidad, etc.). Póngase en contacto con datasets@huggingface.co o models@huggingface.co con una propuesta detallada.

¿Cómo puedo liberar espacio de almacenamiento en mi cuenta/organización?

Hay varias formas de gestionar y liberar espacio de almacenamiento en tu cuenta u organización. En primer lugar, si necesitas más espacio de almacenamiento, actualiza a un plan PRO, Team o Enterprise para aumentar los límites de almacenamiento.

⚠️ Importante: Eliminar archivos grandes es una operación destructiva que no se puede deshacer. Asegúrate de hacer una copia de seguridad de tus archivos antes de continuar.

Puntos clave a recordar:

• Eliminar solo los punteros de LFS no libera espacio
• Si no reescribes el historial de Git, los futuros checkouts de ramas/etiquetas que contengan archivos LFS eliminados con punteros lfs existentes fallarán (para evitar errores, añade la siguiente línea a tu archivo .gitconfig: lfs.skipdownloaderrors=true)

Eliminar archivos LFS individuales

1. Vaya a la página de Configuración de su repositorio
2. Haz clic en “List LFS files” en la sección “Storage”
3. Use el menú de acciones para eliminar archivos específicos

Eliminación de referencias de solicitudes de extracción

Los pull requests crean referencias de git que almacenan sus commits. Después de cerrar o fusionar un PR, puedes eliminar su referencia para liberar espacio de almacenamiento. Esto es especialmente útil cuando:

• Los PR contienen archivos grandes que nunca se fusionaron
• Has aplastado la rama principal y eliminado archivos más tarde: esos archivos permanecen en el historial de la rama de la PR, incluso si no fueron añadidos por la propia PR

Para eliminar una referencia de PR, abre la PR cerrada o fusionada y busca el aviso de almacenamiento en la parte inferior que muestra el espacio estimado que se podría liberar. Haz clic en “Delete ref” para eliminarla de forma permanente.

Eliminar una referencia de PR es irreversible y evitará que cualquier persona obtenga o descargue esos commits localmente.

Comprime tu repositorio al máximo usando la API

La operación super-squash comprime todo el historial de Git en un único commit. Considere usar super-squash cuando necesite recuperar almacenamiento de versiones antiguas de LFS que no esté utilizando. Esta operación solo está disponible a través de la Hub Python Library o la API.

⚠️ Importante: Esta es una operación destructiva que no se puede deshacer, el historial de commits se perderá de forma permanente y se eliminará el historial de archivos LFS

Los efectos de la operación de compactación en su cuota de almacenamiento no son inmediatos y se reflejarán en su cuota dentro de las 36 horas.

Avanzado: Rastrear referencias de archivos LFS

Cuando encuentras un archivo LFS en la sección “List LFS files” de tu repositorio pero no sabes de dónde proviene, puedes rastrear su historial mediante su OID SHA-256 usando el comando git log:

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

Por ejemplo:

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