Hub documentation
Giới hạn lưu trữ
Giới hạn lưu trữ
Tại Hugging Face, chúng tôi hướng đến việc cung cấp cho cộng đồng AI một lượng lớn không gian lưu trữ miễn phí cho các kho lưu trữ công khai, với tùy chọn mua thêm dung lượng lưu trữ khi cần. Chúng tôi cũng tính phí cho không gian lưu trữ của các kho lưu trữ riêng tư, vượt quá mức miễn phí (xem bảng bên dưới).
Các giới hạn và chính sách về lưu trữ áp dụng cho tất cả các loại kho (mô hình, bộ dữ liệu, bucket, …) trên Hub.
Chúng tôi điều chỉnh cơ sở hạ tầng liên tục nhằm mở rộng lưu trữ cho những năm tăng trưởng sắp tới của AI và Machine learning.
Chúng tôi đã có các biện pháp để ngăn chặn việc lạm dụng lưu trữ công khai miễn phí, và nói chung, chúng tôi yêu cầu người dùng và tổ chức đảm bảo rằng bất kỳ mô hình hoặc bộ dữ liệu lớn nào được tải lên đều có ích nhất có thể cho cộng đồng (ví dụ, được thể hiện qua số lượt thích hoặc lượt tải xuống). Nâng cấp lên tài khoản Organization hoặc User (PRO) trả phí để mở khóa các giới hạn cao hơn.
Kế hoạch lưu trữ
| Loại tài khoản | Lưu trữ công khai | Lưu trữ riêng |
|---|---|---|
| Người dùng hoặc tổ chức miễn phí | Nỗ lực tối đa* | 100GB |
| PRO | Tối đa 10TB được bao gồm* + gói bổ sung ✅ các khoản trợ cấp có sẵn cho các công việc có tác động† | 1TB + thanh toán theo mức sử dụng |
| Tổ chức nhóm | 12TB cơ bản + 1TB cho mỗi chỗ ngồi + thêm ✅ | 1TB mỗi chỗ ngồi + thanh toán theo mức sử dụng |
| Tổ chức doanh nghiệp | 200TB cơ bản + 1TB cho mỗi chỗ ngồi + gói bổ sung 🏆 Tối đa 1.000TB cho các hợp đồng lớn | 1TB mỗi chỗ ngồi + thanh toán theo mức sử dụng |
💡 Tổ chức Team hoặc Enterprise bao gồm 1TB lưu trữ riêng tư cho mỗi ghế trong gói đăng ký: ví dụ, nếu tổ chức của bạn có 40 thành viên, bạn sẽ có 40TB lưu trữ riêng tư được bao gồm.
* Chúng tôi cam kết tiếp tục cung cấp cho cộng đồng AI dung lượng lưu trữ miễn phí hào phóng cho các kho lưu trữ công khai. Vượt quá vài gigabyte đầu tiên, vui lòng sử dụng tài nguyên này một cách có trách nhiệm bằng cách tải lên nội dung mang lại giá trị thực sự cho người dùng khác. Nếu bạn cần dung lượng lưu trữ lớn, bạn sẽ cần nâng cấp lên PRO, Team hoặc Enterprise.
† Trong một số trường hợp, các quyền cấp thêm dung lượng lưu trữ có sẵn cho các dự án mã nguồn mở có tác động lớn mà gói trả phí thực sự không thể đáp ứng được. Hãy liên hệ với chúng tôi kèm theo bằng chứng về tác động đối với cộng đồng (số lượt thích, lượt tải xuống, trích dẫn).
Gói bổ sung lưu trữ công khai
Người dùng thuộc gói trả phí (PRO, Team hoặc Enterprise) có thể đăng ký gói bổ sung Public Storage để có thêm dung lượng lưu trữ công khai ngoài hạn mức cơ bản của gói hiện tại.
| Gói bổ sung lưu trữ | Giá | Theo TB |
|---|---|---|
| 1 TB | 12 USD/tháng | $12/TB/tháng |
| 5 TB | 60 USD/tháng | $12/TB/tháng |
| 10 TB | 120 USD/tháng | $12/TB/tháng |
| 20 TB | 240 USD/tháng | $12/TB/tháng |
| 50 TB | 500 USD/tháng | $10/TB/tháng |
Bạn có thể đăng ký hoặc thay đổi gói của mình từ trang cài đặt Thanh toán của tài khoản hoặc tổ chức của bạn. Nâng cấp có hiệu lực ngay lập tức; hạ cấp được lên lịch có hiệu lực vào đầu tháng tiếp theo. Nếu bạn cần thêm dung lượng lưu trữ, bạn có thể liên hệ với chúng tôi để tận dụng định giá quy mô lớn tùy chỉnh.
Lưu trữ riêng Trả theo mức sử dụng
Ngoài 1TB (hoặc 1TB mỗi chỗ ngồi) lưu trữ riêng tư được bao gồm trong PRO và Tổ chức Team hoặc Enterprise, dung lượng lưu trữ riêng tư bổ sung sẽ được tính phí vào phương thức thanh toán của bạn theo chế độ Pay-as-you-go, với giá cơ bản là 18 USD/TB/tháng. Các khoản giảm giá bổ sung cho khối lượng lớn có sẵn thông qua các nhân viên kinh doanh của chúng tôi:
| Dung lượng | Giá (kho lưu trữ riêng tư) |
|---|---|
| Cơ bản | $18/TB/tháng |
| 50TB+ | $16/TB/tháng |
| 200TB+ | $14/TB/tháng |
| 500TB+ | $12/TB/tháng |
Xem tài liệu thanh toán của chúng tôi để biết thêm chi tiết, hoặc xem bảng giá mới nhất tại huggingface.co/pricing.
Hạn chế và khuyến nghị về kho lưu trữ
Phần này không áp dụng cho Storage Buckets
Ngoài các giới hạn về dung lượng lưu trữ ở cấp độ tài khoản (người dùng hoặc tổ chức), có một số hạn chế cần lưu ý khi làm việc với lượng dữ liệu lớn trong một kho lưu trữ Git cụ thể. Do thời gian cần thiết để truyền dữ liệu, việc tải lên/đẩy (push) thất bại ở cuối quy trình hoặc trải nghiệm bị giảm chất lượng, dù là trên hf.co hay khi làm việc cục bộ, đều có thể gây khó chịu. Trong phần tiếp theo, chúng tôi mô tả các khuyến nghị về cách cấu trúc tối ưu các kho lưu trữ lớn của bạn.
Khuyến nghị
Chúng tôi đã tổng hợp một danh sách các mẹo và khuyến nghị để tổ chức kho lưu trữ của bạn. Nếu bạn đang tìm kiếm các mẹo thực tế hơn, hãy xem hướng dẫn này về cách tải lên một lượng lớn dữ liệu bằng thư viện Python.
| Đặc điểm | Được khuyến nghị | Mẹo |
|---|---|---|
| Kích thước kho | - | nâng cấp kế hoạch lưu trữ của bạn hoặc liên hệ với chúng tôi cho các kho lớn (dữ liệu hàng TB) |
| Số tệp mỗi kho | <100k | gộp dữ liệu vào ít tệp hơn |
| Số mục trong mỗi thư mục | <10k | sử dụng thư mục con trong kho |
| Kích thước tệp | <200GB | chia dữ liệu thành các tệp dạng chunk |
| Kích thước commit | <100 tệp* | upload_folder/hf upload tự động chia các thư mục lớn thành nhiều commit |
| Số lượt commit trên mỗi kho | - | tải lên nhiều tệp mỗi commit và/hoặc nén lịch sử |
* Không liên quan khi sử dụng trực tiếp git CLI
Hãy đọc phần tiếp theo để hiểu rõ hơn về những giới hạn đó và cách xử lý chúng.
Giải thích
Khi nói đến “tải lên lớn”, chúng ta đang đề cập đến điều gì và những hạn chế liên quan là gì? Các thao tác tải lên lớn có thể rất đa dạng, từ các kho chứa một vài tệp cực lớn (ví dụ: trọng số mô hình) đến các kho chứa hàng nghìn tệp nhỏ (ví dụ: bộ dữ liệu ảnh).
Bên trong, Hub sử dụng Git để quản lý phiên bản dữ liệu, điều này có những hệ quả về cấu trúc đối với những gì bạn có thể thực hiện trong kho của mình.
Nếu kho của bạn đang vượt qua một số con số được đề cập ở phần trước, chúng tôi khuyến khích mạnh mẽ bạn xem xét git-sizer,
công cụ có tài liệu rất chi tiết về các yếu tố khác nhau sẽ ảnh hưởng đến trải nghiệm của bạn. Dưới đây là tóm tắt ngắn gọn về các yếu tố cần cân nhắc:
- Kích thước kho lưu trữ: Tổng kích thước dữ liệu bạn dự định tải lên. Không có giới hạn kích thước cho từng kho lưu trữ đối với mô hình và bộ dữ liệu, nhưng các tệp tải lên sẽ được tính vào hạn mức lưu trữ tổng của tài khoản bạn (xem Gói lưu trữ ở trên). Nếu bạn cần thêm dung lượng lưu trữ, hãy nâng cấp gói hoặc mua gói lưu trữ bổ sung.
- Number of files:
- Để có trải nghiệm tối ưu, chúng tôi khuyến nghị giữ tổng số tệp dưới 100k, và lý tưởng là ít hơn nhiều. Hãy thử gộp dữ liệu vào ít tệp hơn nếu bạn có nhiều tệp. Ví dụ, các tệp json có thể được gộp thành một tệp jsonl duy nhất, hoặc các bộ dữ liệu lớn có thể được xuất dưới dạng tệp Parquet hoặc ở định dạng WebDataset.
- Số lượng tệp tối đa trong mỗi thư mục không được vượt quá 10k tệp/thư mục. Một giải pháp đơn giản là tạo cấu trúc kho sử dụng các thư mục con. Ví dụ, một kho có 1k thư mục từ
000/đến999/, mỗi thư mục chứa tối đa 1000 tệp, đã là đủ.
- File size: Trong trường hợp tải lên các tệp lớn (ví dụ: trọng số mô hình), chúng tôi rất khuyến nghị chia chúng thành các phần nhỏ, mỗi phần dưới 200GB..
Có một số lý do cho điều này:
- Việc tải lên và tải xuống các tệp nhỏ hơn dễ dàng hơn nhiều cho cả bạn và các người dùng khác. Các vấn đề về kết nối luôn có thể xảy ra khi truyền dữ liệu, và các tệp nhỏ hơn giúp tránh việc phải bắt đầu lại từ đầu trong trường hợp xảy ra lỗi.
- Các tệp được phân phối cho người dùng bằng CloudFront. Theo kinh nghiệm của chúng tôi, các tệp rất lớn không được dịch vụ này lưu vào bộ nhớ đệm, dẫn đến tốc độ tải xuống chậm hơn. Trong mọi trường hợp, không có tệp đơn lẻ nào vượt quá 500GB. Nghĩa là 500GB là giới hạn cứng cho kích thước tệp đơn lẻ.
- Số lượng commit: Không có giới hạn cứng cho tổng số commit trong lịch sử repo của bạn. Tuy nhiên, theo kinh nghiệm của chúng tôi, trải nghiệm người dùng trên Hub bắt đầu giảm sau vài nghìn commit. Chúng tôi đang không ngừng làm việc để cải thiện dịch vụ, nhưng cần luôn nhớ rằng một kho git không được thiết kế để hoạt động như một cơ sở dữ liệu với nhiều thao tác ghi. Nếu lịch sử repo của bạn trở nên rất lớn, luôn có thể squash tất cả các commit để bắt đầu lại bằng cách sử dụng
super_squash_historycủahuggingface_hub. Lưu ý rằng đây là một thao tác không thể hoàn tác. - Số lượng thao tác mỗi lần commit: Một lần nữa, không có giới hạn cứng ở đây. Khi một commit được tải lên Hub, mỗi thao tác git (thêm hoặc xóa) sẽ được máy chủ kiểm tra. Khi một trăm Large File được commit cùng lúc, mỗi tệp sẽ được kiểm tra riêng lẻ để đảm bảo đã được tải lên đúng cách. Khi đẩy dữ liệu qua HTTP, một timeout 60s được đặt cho yêu cầu, có nghĩa là nếu quá trình mất nhiều thời gian hơn, một lỗi sẽ được ném ra. Tuy nhiên, có thể xảy ra (trong các trường hợp hiếm) rằng ngay cả khi timeout được ném ra phía client, quá trình vẫn được hoàn thành phía server. Điều này có thể được kiểm tra thủ công bằng cách duyệt repo trên Hub. Phương thức
upload_foldervà lệnhhf uploadtự động tránh điều này bằng cách chia các thư mục lớn thành nhiều commit. Nếu bạn commit thủ công, hãy giữ khoảng 50-100 tệp mỗi commit.
Chia sẻ các bộ dữ liệu lớn trên Hub
Một cách quan trọng mà Hugging Face hỗ trợ hệ sinh thái machine learning là lưu trữ các dataset trên Hub, bao gồm cả những dataset rất lớn. Các dataset lớn được tính vào hạn mức lưu trữ tổng của tài khoản bạn, vì vậy hãy đảm bảo kế hoạch lưu trữ của bạn có đủ dung lượng trước khi tải lên. Bạn có thể mua thêm dung lượng lưu trữ công khai dưới dạng add-on.
Để lưu trữ các bộ dữ liệu lớn trên Hub, chúng tôi yêu cầu các điều kiện sau:
- Thẻ mô tả dataset: chúng tôi muốn đảm bảo rằng dataset của bạn có thể được cộng đồng sử dụng một cách hiệu quả và một trong những cách chính để làm được điều này là thông qua thẻ mô tả dataset. Hướng dẫn này cung cấp cái nhìn tổng quan về cách viết thẻ mô tả dataset.
- Bạn đang chia sẻ bộ dữ liệu để cộng đồng có thể tái sử dụng. Nếu bạn dự định tải lên một bộ dữ liệu mà bạn dự đoán sẽ không được tái sử dụng thêm, các nền tảng khác có thể phù hợp hơn.
- Bạn phải tuân thủ các hạn chế của kho lưu trữ được nêu ở trên.
- Sử dụng các định dạng tệp được tích hợp tốt với hệ sinh thái Hugging Face. Chúng tôi hỗ trợ tốt các định dạng Parquet và WebDataset, đây thường là những lựa chọn tốt để chia sẻ các bộ dữ liệu lớn một cách hiệu quả. Điều này cũng sẽ đảm bảo rằng trình xem bộ dữ liệu hoạt động cho bộ dữ liệu của bạn.
- Tránh sử dụng các script tải tùy chỉnh khi làm việc với datasets. Theo kinh nghiệm của chúng tôi, các dataset yêu cầu mã tùy chỉnh để sử dụng thường có mức độ tái sử dụng hạn chế.
Hãy liên hệ với chúng tôi nếu bất kỳ yêu cầu nào trong số này gây khó khăn cho bạn do loại dữ liệu hoặc lĩnh vực bạn đang làm việc.
Chia sẻ khối lượng lớn mô hình trên Hub
Tương tự như datasets, các mô hình lớn hoặc số lượng lớn mô hình (ví dụ, hàng trăm quants tự động) sẽ được tính vào hạn mức lưu trữ tổng của tài khoản bạn. Hãy đảm bảo kế hoạch lưu trữ của bạn có đủ dung lượng, hoặc mua thêm gói lưu trữ bổ sung.
Học bổng dành cho các nhóm nghiên cứu và tổ chức phi lợi nhuận
Chúng tôi khuyến nghị các cơ sở học thuật và nghiên cứu nâng cấp lên Team, Enterprise, hoặc Academia Hub để có giới hạn lưu trữ được đảm bảo. Trong một số trường hợp, các khoản cấp lưu trữ có thể được xem xét cho các dự án mã nguồn mở có tác động lớn mà gói trả phí thực sự không thể đáp ứng nhu cầu. Các trường hợp này được đánh giá theo từng trường hợp cụ thể và yêu cầu bằng chứng về tác động đối với cộng đồng (số lượt tải xuống, trích dẫn, mức độ áp dụng trong cộng đồng, v.v.). Vui lòng liên hệ datasets@huggingface.co hoặc models@huggingface.co kèm theo đề xuất chi tiết.
Làm thế nào để tôi giải phóng dung lượng lưu trữ trong tài khoản/tổ chức của mình?
Có một số cách để quản lý và giải phóng dung lượng lưu trữ trong tài khoản hoặc tổ chức của bạn. Trước tiên, nếu bạn cần thêm dung lượng lưu trữ, hãy nâng cấp lên gói PRO, Team hoặc Enterprise để có giới hạn lưu trữ cao hơn.
⚠️ Quan trọng: Việc xóa các tệp lớn là một thao tác hủy hoại không thể hoàn tác. Hãy đảm bảo sao lưu tệp của bạn trước khi tiếp tục.
Những điểm chính cần ghi nhớ:
- Việc chỉ xóa các con trỏ LFS không giải phóng được dung lượng
- Nếu bạn không viết lại lịch sử Git, các lần checkout sau này của các nhánh/tag chứa các tệp LFS đã bị xóa với các con trỏ lfs hiện có sẽ thất bại (để tránh lỗi, hãy thêm dòng sau vào tệp
.gitconfigcủa bạn:lfs.skipdownloaderrors=true)
Xóa các tệp LFS riêng lẻ
- Điều hướng đến trang Cài đặt của kho lưu trữ của bạn
- Nhấp vào “List LFS files” trong phần “Storage”
- Sử dụng menu hành động để xóa các tệp cụ thể
Xóa các tham chiếu Pull request
Pull requests tạo các git refs để lưu trữ các commit của chúng. Sau khi đóng hoặc hợp nhất một PR, bạn có thể xóa ref của nó để giải phóng dung lượng lưu trữ. Điều này đặc biệt hữu ích khi:
- Các PR chứa các tệp lớn chưa bao giờ được hợp nhất
- Bạn đã nén nhánh chính và sau đó xóa các tệp — những tệp đó vẫn còn trong lịch sử của nhánh PR ngay cả khi chúng không được thêm vào bởi chính PR
Để xóa một PR ref, hãy mở PR đã đóng hoặc đã hợp nhất và tìm thông báo lưu trữ ở cuối trang, hiển thị dung lượng ước tính có thể được giải phóng. Nhấp vào “Delete ref” để xóa vĩnh viễn.
Việc xóa một PR ref là không thể hoàn tác và sẽ ngăn bất kỳ ai lấy hoặc kiểm tra các commit đó cục bộ.
Siêu nén kho của bạn bằng API
Thao tác super-squash nén toàn bộ lịch sử Git của bạn thành một commit duy nhất. Hãy cân nhắc sử dụng super-squash khi bạn cần thu hồi dung lượng lưu trữ từ các phiên bản LFS cũ mà bạn không còn sử dụng. Thao tác này chỉ có sẵn thông qua Hub Python Library hoặc API.
⚠️ Quan trọng: Đây là một thao tác hủy bỏ không thể hoàn tác, lịch sử commit sẽ bị mất vĩnh viễn và lịch sử tệp LFS sẽ bị xóa
Tác động của thao tác squash đối với hạn mức lưu trữ của bạn không có hiệu lực ngay lập tức và sẽ được phản ánh trong hạn mức của bạn trong vòng 36 giờ.
Nâng cao: Theo dõi các tham chiếu tệp LFS
Khi bạn tìm thấy một tệp LFS trong “List LFS files” của kho lưu trữ nhưng không biết nó đến từ đâu, bạn có thể truy vết lịch sử của nó bằng OID SHA-256 của tệp đó bằng cách sử dụng lệnh git log:
git log --all -p -S <SHA-256-OID>Ví dụ:
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