Hub documentation
Depolama sınırları
Depolama sınırları
Hugging Face'ta, gerekirse daha fazla depolama alanı satın alma seçenekleriyle, topluluk için halka açık depolar için ücretsiz depolama alanı sunmayı hedefliyoruz. Ayrıca, ücretsiz katmanın üzerindeki özel depolar için de depolama alanı ücretlendiriyoruz (aşağıdaki tabloya bakın).
Hub'daki tüm depo türlerine (modeller, veri kümeleri, variller, …) depolama sınırları ve politikaları uygulanır.
Altyapımızı sürekli olarak optimize ediyor ve yapay zeka ile makine öğrenmesindeki büyüme için önümüzdeki yıllarda depolamamızı ölçeklendirmek üzere hazırlanıyoruz.
Ücretsiz herkese açık depolamanın kötüye kullanılmasını önlemek için önlemlerimiz mevcuttur ve genel olarak kullanıcıların ve kuruluşların yükledikleri büyük modellerin veya veri kümelerinin mümkün olduğunca topluma faydalı olmasını (örneğin beğeni veya indirme sayıları ile temsil edildiği gibi) sağlamalarını rica ediyoruz. Daha yüksek sınırları açmak için ücretli bir Kuruluş veya Kullanıcı (PRO) hesabına yükseltme yapın.
Depolama planları
| Hesap türü | Herkese açık depolama | Özel depolama |
|---|---|---|
| Ücretsiz kullanıcı veya kuruluş | En iyi çaba* | 100GB |
| PRO | 10TB'ye kadar dahildir* + ek paket ✅ Etkili çalışmalar için hibeler mevcuttur† | 1 TB + kullanım bazlı |
| Ekip Organizasyonları | 12TB taban + koltuk başına 1TB + ek paket ✅ | Koltuk başına 1 TB + kullanımınıza göre ödeme |
| Kurumsal Kuruluşlar | 200TB taban + koltuk başına 1TB + ek paket 🏆 Büyük sözleşmeler için 1.000TB'a kadar | Koltuk başına 1 TB + kullanımınıza göre ödeme |
💡 Team or Enterprise Organizations aboneliğinde her koltuk başına 1 TB özel depolama alanı içerir: örneğin, organizasyonunuzda 40 üye varsa, 40 TB dahili özel depolama alanınız vardır.
* AI topluluğuna açık depolar için cömert ücretsiz depolama alanı sağlamaya devam etmeyi hedefliyoruz. İlk birkaç gigabaytın ötesinde, lütfen bu kaynağı diğer kullanıcılara gerçek bir değer sunan içerik yükleyerek sorumlu bir şekilde kullanın. Ciddi miktarda depolama alanına ihtiyacınız varsa, PRO, Team veya Enterprise planına yükseltme yapmanız gerekir.
† Bazı durumlarda, ücretli bir planın ihtiyacı gerçekten karşılayamadığı yüksek etki yaratan açık kaynak çalışmalar için ek depolama tahsisleri mevcuttur. Topluluk etkisine dair kanıtlarla (beğeniler, indirmeler, atıflar) bizimle iletişime geçin.
Herkese Açık Depolama Eklentisi
Ücretli bir plana (PRO, Team veya Enterprise) sahip kullanıcılar, planlarının temel sınırının üzerine ek halka açık depolama alanı için Public Storage eklentisine abone olabilir.
| Depolama eklentisi | Fiyat | TB başına |
|---|---|---|
| 1 TB | $12/ay | $12/TB/ay |
| 5 TB | Aylık $60 | $12/TB/ay |
| 10 TB | $120/ay | $12/TB/ay |
| 20 TB | $240/ay | $12/TB/ay |
| 50 TB | $500/ay | $10/TB/ay |
Aboneliğinizi veya planınızı hesabınızın veya organizasyonunuzun Faturalama ayarları sayfasından değiştirebilirsiniz. Yükseltmeler anında geçerli olur; düşürmeler ise bir sonraki ayın başında geçerli olacak şekilde planlanır. Daha fazla depolama alanına ihtiyacınız varsa, özel büyük ölçekli fiyatlandırma avantajından yararlanmak için bize ulaşabilirsiniz.
Özel depolama Kullan-dedikçe-öde
PRO ve Team veya Enterprise Organizasyonları kapsamında dahili olan 1 TB (veya koltuk başına 1 TB) özel depolama alanının üzerinde eklenen özel depolama alanı, Pay-as-you-go modunda ödeme yönteminize, TB başına aylık 18 $ temel fiyat üzerinden yansıtılır. Büyük ölçekli hacimler için hesap yöneticilerimiz aracılığıyla ek indirimler mevcuttur:
| Hacim | Fiyat (özel depolar) |
|---|---|
| Temel | $18/TB/ay |
| 50TB+ | $16/TB/ay |
| 200TB+ | $14/TB/ay |
| 500TB+ | $12/TB/ay |
Daha fazla ayrıntı için faturalama belgemize göz atabilir veya güncel fiyatlandırmayı huggingface.co/pricing adresinde görüntüleyebilirsiniz.
Depo kısıtlamaları ve önerileri
Bu bölüm Storage Buckets için geçerli değildir
Hesap (kullanıcı veya kuruluş) düzeyindeki depolama sınırlarının yanı sıra, Git tabanlı belirli bir depoda büyük miktarda veriyle çalışırken dikkat edilmesi gereken bazı kısıtlamalar vardır. Verilerin akışının (stream) alması gereken süre göz önüne alındığında, yükleme/itme (push) işleminin sürecin sonunda başarısız olması veya hf.co üzerinde ya da yerel çalışırken kötüleşmiş bir deneyimle karşılaşmak son derece sinir bozucu olabilir. Aşağıdaki bölümde, büyük depolarınızı en iyi şekilde nasıl yapılandırmanız gerektiğine dair önerilerimizi açıklıyoruz.
Öneriler
Deponuzu yapılandırmak için ipuçları ve önerilerden oluşan bir liste derledik. Daha pratik ipuçları arıyorsanız, Python kütüphanesiyle büyük miktarda veri yüklemenin nasıl yapılacağına dair bu kılavuza göz atın.
| Özellik | Önerilen | İpuçları |
|---|---|---|
| Depo boyutu | - | depolama planınızı yükseltin veya büyük depolar (TB'larca veri) için bizimle iletişime geçin |
| Depo başına dosyalar | <100b | verileri daha az dosyada birleştir |
| Klasör başına girdiler | <10k | depozitoda alt dizinler kullanın |
| Dosya boyutu | <200GB | verileri parçalı dosyalara böl |
| Commit boyutu | <100 dosya* | upload_folder/hf upload büyük klasörleri birden çok commit'e otomatik olarak böler |
| Depo başına commit | - | her commit'te birden fazla dosya yükleyin ve/veya geçmişi birleştirin |
* git CLI doğrudan kullanıldığında ilgili değildir
Bu sınırları ve bunlarla nasıl başa çıkılacağını daha iyi anlamak için lütfen bir sonraki bölümü okuyun.
Açıklamalar
“Büyük yüklemeler” derken neyi kastediyoruz ve bunlara ilişkin kısıtlamalar nelerdir? Büyük yüklemeler çok çeşitli olabilir; birkaç devasa dosyanın (ör. model ağırlıkları) bulunduğu depolardan binlerce küçük dosyanın (ör. bir görüntü veri seti) bulunduğu depolara kadar uzanabilir.
Arka planda Hub, verileri sürümlemek için Git kullanır; bu durum, repoda yapabilecekleriniz üzerinde yapısal sonuçlar doğurur.
Repodaki değerler, önceki bölümde belirtilen sayılardan bazılarını aşıyorsa, deneyiminizi etkileyecek farklı faktörler hakkında çok ayrıntılı belgelere sahip olan git-sizer aracına göz atmanızı şiddetle öneririz. Dikkate alınması gereken faktörlerin kısa bir özeti aşağıdadır:
- Depo boyutu: Yüklemeyi planladığınız verilerin toplam boyutu. Modeller ve veri kümeleri için depo başına boyut sınırı yoktur ancak yüklemeler, hesabınızın toplam depolama kotasına dahil edilir (bkz. yukarıdaki Depolama planları). Daha fazla depolama alanına ihtiyacınız varsa planınızı yükseltin veya bir depolama ek paketi satın alın.
- Number of files:
- En iyi deneyim için toplam dosya sayısının 100k altında, ideal olarak çok daha az olmasını öneririz. Daha fazla dosyanız varsa verileri daha az sayıda dosyada birleştirmeyi deneyin. Örneğin, json dosyaları tek bir jsonl dosyasında birleştirilebilir veya büyük veri kümeleri Parquet dosyaları olarak veya WebDataset biçiminde dışa aktarılabilir.
- Klasör başına maksimum dosya sayısı, klasör başına 10k dosyayı aşamaz. Basit bir çözüm, alt dizinler kullanan bir depo yapısı oluşturmaktır. Örneğin,
000/ile999/arasında 1k klasörden oluşan ve her birinde en fazla 1000 dosya barındıran bir depo bile yeterlidir.
- File size: Büyük dosyaları (ör. model ağırlıkları) yüklerken, bunları her biri 200GB'dan küçük parçalara bölmenizi şiddetle öneririz..
Bunun birkaç nedeni var:
- Daha küçük dosyaları yüklemek ve indirmek, hem sizin hem de diğer kullanıcılar için çok daha kolaydır. Veri akışı sırasında bağlantı sorunları her zaman yaşanabilir ve daha küçük dosyalar, hata durumunda baştan devam etme sorununu önler.
- Dosyalar kullanıcılara CloudFront kullanılarak sunulur. Deneyimlerimize göre, bu hizmet devasa dosyaları önbelleğe almaz ve bu da daha yavaş bir indirme hızına yol açar. Her durumda, tek bir dosya 500GB'ı aşmayacaktır. Yani, tek bir dosya boyutu için 500GB kesin üst sınırdır.
- Commit sayısı: Repo geçmişinizdeki toplam commit sayısı için kesin bir üst sınır yoktur. Ancak deneyimlerimize göre, Hub'daki kullanıcı deneyimi birkaç bin committen sonra yavaşlamaya başlar. Hizmeti sürekli olarak iyileştirmek için çalışıyoruz, ancak bir git deposunun çok sayıda yazma işlemi için bir veritabanı gibi çalışmak üzere tasarlanmadığını her zaman akılda tutmak gerekir. Repo geçmişiniz çok büyük hale gelirse,
huggingface_hub'insuper_squash_historyişlevini kullanarak tüm commitleri birleştirip (squash) taze bir başlangıç yapmanız her zaman mümkündür. Bu işlemin geri alınamaz olduğunu unutmayın. - Commit başına işlem sayısı: Bir kez daha belirtmek gerekir ki, burada kesin bir sınır yoktur. Bir commit Hub'a yüklendiğinde, her
git işlemi (ekleme veya silme) sunucu tarafından kontrol edilir. Yüz Büyük Dosya aynı anda commit edildiğinde,
her dosya, doğru şekilde yüklendiğinden emin olmak için ayrı ayrı kontrol edilir. Veriler HTTP üzerinden gönderildiğinde,
istek için 60 sn'lik bir zaman aşımı ayarlanır; bu da sürecin daha fazla zaman alması durumunda bir hatanın oluşturulduğu anlamına gelir. Ancak, zaman aşımı istemci tarafında oluşturulsa bile, sürecin sunucu tarafında
tamamlanmış olabileceği (nadir durumlarda) görülebilir. Bu, Hub'daki repoyu gezerek manuel olarak kontrol edilebilir.
upload_foldermetodu vehf uploadkomutu, büyük klasörleri birden fazla commit'e bölerek bunu otomatik olarak önler. Manuel olarak commit yapıyorsanız, commit başına yaklaşık 50-100 dosya tutun.
Hub'da büyük veri setlerini paylaşma
Hugging Face'in makine öğrenmesi ekosistemini desteklediği temel yollardan biri, Hub üzerinde veri setlerini, çok büyük olanlar dahil olmak üzere, barındırmasıdır. Büyük veri setleri hesabınızın toplam depolama kotasına dahil sayılır, bu nedenle yüklemeden önce depolama planınızın yeterli kapasiteye sahip olduğundan emin olun. Ek halka açık depolama, ek paket olarak satın alınabilir.
Hub üzerinde büyük veri setlerini barındırmak için aşağıdakiler gereklidir:
- Veri seti kartı: Veri setinizin topluluk tarafından etkili bir şekilde kullanılmasını sağlamak istiyoruz ve bunu mümkün kılan ana yollardan biri veri seti kartıdır. Bu kılavuz, bir veri seti kartının nasıl yazılacağına dair genel bir bakış sunmaktadır.
- Veri setini topluluk tarafından yeniden kullanılabilmesini sağlamak amacıyla paylaşıyorsunuz. Artık yeniden kullanılmayacağını öngördüğünüz bir veri seti yüklemeyi planlıyorsanız, diğer platformlar muhtemelen daha uygundur.
- Yukarıda belirtilen depo kısıtlamalarına uymalısınız.
- Hugging Face ekosistemiyle iyi entegre dosya biçimlerini kullanın. Parquet ve WebDataset biçimleri için iyi bir desteğimiz var; bu biçimler, büyük veri kümelerini verimli bir şekilde paylaşmak için genellikle iyi seçeneklerdir. Bu, veri kümesi görüntüleyicisinin veri kümeniz için çalışmasını da garanti altına alacaktır.
- Veri kümelerini kullanırken özel yükleme betiklerinden kaçının. Deneyimlerimize göre, kullanımı için özel kod gerektiren veri kümeleri genellikle sınırlı bir yeniden kullanım potansiyeline sahiptir.
Eğer bu gereksinimlerden herhangi birini, üzerinde çalıştığınız veri türü veya alan nedeniyle karşılamakta zorlanıyorsanız, lütfen bizimle iletişime geçin.
Hub üzerinde büyük hacimli modeller paylaşma
Veri kümeleriyle benzer şekilde, büyük modeller veya büyük hacimli modeller (örneğin, yüzlerce otomatik kuantizasyon) hesabınızın toplam depolama kotasına dahil edilir. depolama planınızın yeterli kapasiteye sahip olduğundan emin olun veya bir depolama ek paketi satın alın.
Araştırma ekipleri ve kâr amacı gütmeyen kuruluşlar için hibalar
Akademik ve araştırma kurumlarının, garanti edilen depolama sınırları için Team, Enterprise veya Academia Hub planlarına yükselmesini öneriyoruz. Bazı durumlarda, ücretli bir planın ihtiyacı gerçekten karşılayamadığı yüksek etki yaratan açık kaynak çalışmalar için depolama tahsisatları sağlanabilir. Bu tahsisatlar vaka bazlı olarak değerlendirilir ve kanıtlanmış bir topluluk etkisi (indirme, atıf, topluluk benimsemesi vb.) gerektirir. Detaylı bir öneriyle datasets@huggingface.co veya models@huggingface.co adreslerine ulaşabilirsiniz.
Hesabımda/organizasyonumda depolama alanı nasıl boşaltabilirim?
Hesabınızda veya organizasyonunuzda depolama alanı yönetmek ve serbest bırakmak için birkaç yol vardır. Öncelikle, daha fazla depolama alanına ihtiyacınız varsa, artan depolama sınırları için PRO, Team veya Enterprise planına yükseltme yapın.
⚠️ Önemli: Büyük Dosyaları Silme geri alınamayan yıkıcı bir işlemdir. Devam etmeden önce dosyalarınızın yedeğini almayı unutmayın.
Akılda tutulması gereken ana noktalar:
- Sadece LFS işaretçilerini silmek alan açmaz
- Git geçmişini yeniden yazmazsanız, silinen LFS dosyaları ve mevcut lfs işaretçileri içeren dalların/etiketlerin gelecekteki kontrol edilmeleri başarısız olacaktır (hataları önlemek için
.gitconfigdosyanıza şu satırı ekleyin:lfs.skipdownloaderrors=true)
Bireysel LFS dosyalarını silme
- Deponuzun Ayarlar sayfasına gidin
- “Depolama” bölümünde “LFS dosyalarını listele” seçeneğine tıklayın
- Belirli dosyaları silmek için actions menüsünü kullanın
Pull request referanslarını silme
Pull request'ler, commit'lerini saklayan git ref'leri oluşturur. Bir PR'ı kapatıp birleştirdikten sonra, depolama alanı açmak için ref'ini silebilirsiniz. Bu özellikle şu durumlarda faydalıdır:
- PR'ler birleştirilmemiş büyük dosyalar içerir
- Ana dalı sıkıştırdınız ve daha sonra dosyaları sildiniz — bu dosyalar, PR tarafından eklenmemiş olsalar bile, PR dalının geçmişinde kalır
Bir PR ref'ini silmek için kapatılmış veya birleştirilmiş PR'ı açın ve alt kısımda, serbest bırakılabilecek tahmini alanı gösteren depolama bildirimini bulun. Kalıcı olarak kaldırmak için “Delete ref” seçeneğine tıklayın.
Bir PR ref'inin silinmesi geri alınamaz ve bu commit'lerin yerel olarak alınmasını veya kontrol edilmesini engeller.
API kullanarak depoyu süper sıkıştırın
Super-squash işlemi, tüm Git geçmişinizi tek bir commit'e sıkıştırır. Kullanmadığınız eski LFS sürümlerinden depolama alanı geri kazanmanız gerektiğinde super-squash kullanmayı düşünün. Bu işlem yalnızca Hub Python Library veya API üzerinden kullanılabilir.
⚠️ Önemli: Bu, geri alınamayan yıkıcı bir işlemdir; commit geçmişi kalıcı olarak kaybolacak ve LFS dosya geçmişi kaldırılacaktır
Squash işleminin depolama kota üzerindeki etkileri anında gerçekleşmez ve kota üzerinde 36 saat içinde yansıtılır.
Gelişmiş: LFS dosya referanslarını izleyin
Deponuzdaki “List LFS files” bölümünde bir LFS dosyası bulduğunuzda ancak kaynağını bilmediğinizde, git log komutunu kullanarak SHA-256 OID’si üzerinden geçmişini izleyebilirsiniz:
git log --all -p -S <SHA-256-OID>Örneğin:
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