Di chuyển Hub từ Git LFS sang Xet

July 17, 2025
10 min read

Chuyển Đổi Hub từ Git LFS sang Xet

Vào tháng 1 năm nay, Nhóm Xet của Hugging Face đã triển khai một backend lưu trữ mới và ngay sau đó đã chuyển ~6% lượt tải xuống Hub thông qua cơ sở hạ tầng. Đây là một cột mốc quan trọng, nhưng đó chỉ là sự khởi đầu. Trong 6 tháng, 500.000 kho lưu trữ chứa 20 PB đã tham gia vào việc chuyển sang Xet khi Hub phát triển lớn hơn Git LFS và chuyển sang một hệ thống lưu trữ có thể mở rộng theo khối lượng công việc của những người xây dựng AI.

Ngày nay, hơn 1 triệu người trên Hub đang sử dụng Xet. Vào tháng 5, nó đã trở thành mặc định trên Hub cho người dùng và tổ chức mới. Với chỉ một vài chục vấn đề trên GitHub, các chủ đề diễn đàn và tin nhắn Discord, đây có lẽ là cuộc di chuyển lớn nhất trong âm thầm.

Như thế nào? Thứ nhất, nhóm đã chuẩn bị sẵn nhiều năm kinh nghiệm xây dựng và hỗ trợ kho lưu trữ nội dung được định địa chỉ (CAS) và ứng dụng khách Rust, cung cấp nền tảng cho hệ thống. Nếu không có những phần này, Git LFS có thể vẫn là tương lai trên Hub. Tuy nhiên, những anh hùng thầm lặng của cuộc di chuyển này là:

Một phần không thể thiếu của cơ sở hạ tầng được gọi nội bộ là Cầu Git LFS
Di chuyển nội dung nền chạy suốt ngày đêm

Cùng với nhau, các thành phần này đã cho phép chúng tôi tích cực di chuyển PBs trong khoảng thời gian vài ngày mà không phải lo lắng về tác động đến Hub hoặc cộng đồng. Chúng mang lại cho chúng ta sự an tâm để di chuyển nhanh hơn nữa trong những tuần và tháng tới (bỏ qua phần cuối 👇 để xem những gì sắp tới).

Cầu nối và khả năng tương thích ngược

Trong những ngày đầu lên kế hoạch di chuyển sang Xet, chúng tôi đã đưa ra một vài quyết định thiết kế quan trọng:

Sẽ không có “cắt cứng” từ Git LFS sang Xet
Một kho lưu trữ hỗ trợ Xet sẽ có thể chứa cả tệp Xet và LFS
Việc di chuyển kho lưu trữ từ LFS sang Xet không yêu cầu “khóa”; tức là, chúng có thể chạy trong nền mà không làm gián đoạn quá trình tải xuống hoặc tải lên

Được thúc đẩy bởi cam kết của chúng tôi với cộng đồng, những quyết định có vẻ đơn giản này đã có những tác động đáng kể. Quan trọng nhất, chúng tôi không tin rằng người dùng và nhóm nên phải thay đổi ngay lập tức quy trình làm việc của họ hoặc tải xuống một ứng dụng khách mới để tương tác với kho lưu trữ hỗ trợ Xet.

Nếu bạn có một ứng dụng khách nhận biết Xet (ví dụ: hf-xet, tích hợp Xet với huggingface_hub), quá trình tải lên và tải xuống sẽ đi qua toàn bộ ngăn xếp Xet. Ứng dụng khách hoặc chia nhỏ các tệp thành các đoạn bằng cách sử dụng phân đoạn được xác định theo nội dung trong khi tải lên hoặc yêu cầu thông tin tái cấu trúc tệp khi tải xuống. Khi tải lên, các đoạn được chuyển đến CAS và được lưu trữ trong S3. Trong quá trình tải xuống, CAS cung cấp các phạm vi đoạn mà ứng dụng khách cần yêu cầu từ S3 để tái cấu trúc tệp cục bộ.

Đối với các phiên bản cũ hơn của huggingface_hub hoặc huggingface.js, không hỗ trợ chuyển tệp dựa trên đoạn, bạn vẫn có thể tải xuống và tải lên kho lưu trữ Xet, nhưng các byte này đi theo một tuyến đường khác. Khi một tệp được hỗ trợ bởi Xet được yêu cầu từ Hub dọc theo điểm cuối resolve, Cầu Git LFS xây dựng và trả về một URL được ký trước duy nhất, bắt chước giao thức LFS. Sau đó, Cầu thực hiện công việc tái cấu trúc tệp từ nội dung được giữ trong S3 và trả lại cho người yêu cầu.

Để xem điều này đang hoạt động, hãy nhấp chuột phải vào hình ảnh trên và mở nó trong một tab mới. URL chuyển hướng từ https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/migrating-the-hub-to-xet/bridge.png sang một URL bắt đầu bằng https://cas-bridge.xethub.hf.co/xet-bridge-us/.... Bạn cũng có thể sử dụng curl -vL trên cùng một URL để xem các chuyển hướng trong thiết bị đầu cuối của bạn.

Trong khi đó, khi một ứng dụng khách không nhận biết Xet tải lên một tệp, tệp đó sẽ được gửi trước tiên đến bộ nhớ LFS, sau đó được di chuyển sang Xet. “Quy trình di chuyển nền” này, chỉ được đề cập ngắn gọn trong tài liệu của chúng tôi, cung cấp năng lượng cho cả việc di chuyển sang Xet và khả năng tương thích ngược khi tải lên. Nó đứng sau việc di chuyển hơn chục PBs mô hình và bộ dữ liệu và giữ cho 500.000 kho lưu trữ đồng bộ với bộ nhớ Xet mà không bỏ lỡ một nhịp nào.

Mỗi khi một tệp cần được di chuyển từ LFS sang Xet, một webhook sẽ được kích hoạt, đẩy sự kiện vào một hàng đợi phân tán nơi nó được xử lý bởi một orchestrator. Orchestrator:

Bật Xet trên kho lưu trữ nếu sự kiện yêu cầu
Tìm nạp danh sách các bản sửa đổi LFS cho mọi tệp LFS trong kho lưu trữ
Gộp các tệp thành các công việc dựa trên kích thước hoặc số lượng tệp; hoặc 1000 tệp hoặc 500MB, tùy theo điều kiện nào đến trước
Đặt các công việc trên một hàng đợi khác cho các nhóm trình xử lý di chuyển

Sau đó, các trình xử lý di chuyển này sẽ chọn các công việc và mỗi nhóm:

Tải xuống các tệp LFS được liệt kê trong lô
Tải các tệp LFS lên kho lưu trữ nội dung được định địa chỉ Xet bằng cách sử dụng xet-core

Mở rộng quy mô di chuyển

Vào tháng 4, chúng tôi đã kiểm tra giới hạn của hệ thống này bằng cách liên hệ với bartowski và hỏi xem họ có muốn dùng thử Xet không. Với gần 500 TB trên 2.000 kho lưu trữ, việc di chuyển của bartowski đã phát hiện ra một vài liên kết yếu:

Các tệp phân đoạn tạm thời để khử trùng lặp toàn cầu trước tiên được ghi vào /tmp và sau đó được chuyển vào bộ đệm phân đoạn. Tuy nhiên, trên các nhóm trình xử lý của chúng tôi, /tmp và bộ đệm Xet nằm trên các điểm gắn kết khác nhau. Việc di chuyển không thành công và các tệp phân đoạn không bao giờ bị xóa. Cuối cùng, đĩa đầy, kích hoạt một làn sóng lỗi Không còn dung lượng trên thiết bị.
Sau khi hỗ trợ ra mắt Llama 4, chúng tôi đã mở rộng quy mô CAS cho các lượt tải xuống bùng nổ, nhưng các trình xử lý di chuyển đã lật ngược kịch bản khi hàng trăm lượt tải lên nhiều gigabyte đã đẩy CAS vượt quá tài nguyên của nó
Trên giấy tờ, các trình xử lý di chuyển có khả năng thông lượng lớn hơn đáng kể so với những gì đã báo cáo; việc lập hồ sơ các nhóm đã tiết lộ các nút thắt cổ chai I/O mạng và EBS

Việc sửa chữa con quái vật ba đầu này có nghĩa là chạm vào mọi lớp - vá xet-core, thay đổi kích thước CAS và tăng cường thông số kỹ thuật của nút trình xử lý. May mắn thay, bartowski đã chơi game để làm việc với chúng tôi trong khi mọi kho lưu trữ đều được chuyển sang Xet. Những bài học tương tự này đã thúc đẩy việc di chuyển của những người dùng lưu trữ lớn nhất trên Hub như RichardErkhov (1,7PB và 25.000 kho lưu trữ) và mradermacher (6,1PB và 42.000 kho lưu trữ 🤯).

Trong khi đó, thông lượng CAS đã tăng lên một bậc độ lớn giữa các cuộc di chuyển quy mô lớn đầu tiên và gần đây nhất:

Di chuyển Bartowski: CAS duy trì ~35 Gb/s, với ~5 Gb/s đến từ lưu lượng Hub thông thường.
Di chuyển mradermacher và RichardErkhov: CAS đạt đỉnh khoảng ~300 Gb/s, trong khi vẫn phục vụ ~40 Gb/s tải hàng ngày.

Không ma sát, truyền nhanh hơn

Khi chúng tôi bắt đầu thay thế LFS, chúng tôi có hai mục tiêu trong đầu:

Không gây hại
Tạo ra tác động lớn nhất nhanh nhất có thể

Thiết kế với các ràng buộc ban đầu và các mục tiêu này cho phép chúng tôi:

Giới thiệu và làm cứng hf-xet trước khi bao gồm nó trong huggingface_hub như một phụ thuộc bắt buộc
Hỗ trợ cộng đồng tải lên và tải xuống từ kho lưu trữ hỗ trợ Xet thông qua bất kỳ phương tiện nào họ sử dụng ngày nay trong khi cơ sở hạ tầng của chúng tôi xử lý phần còn lại
Học được những bài học vô giá - từ quy mô đến cách ứng dụng khách của chúng tôi hoạt động trên các hệ thống tệp phân tán - từ việc di chuyển Hub sang Xet một cách gia tăng

Thay vì chờ tất cả các đường dẫn tải lên trở nên nhận biết Xet, buộc phải cắt cứng hoặc thúc đẩy cộng đồng áp dụng một quy trình làm việc cụ thể, chúng tôi có thể bắt đầu di chuyển Hub sang Xet ngay lập tức với tác động tối thiểu đến người dùng. Tóm lại, hãy để các nhóm giữ quy trình làm việc của họ và chuyển đổi hữu cơ sang Xet với cơ sở hạ tầng hỗ trợ mục tiêu dài hạn của một hệ thống lưu trữ thống nhất.

Xet cho mọi người

Vào tháng 1 và tháng 2, chúng tôi đã giới thiệu người dùng năng lượng để cung cấp phản hồi và kiểm tra áp lực cơ sở hạ tầng. Để nhận phản hồi từ cộng đồng, chúng tôi đã ra mắt danh sách chờ để xem trước kho lưu trữ hỗ trợ Xet. Ngay sau đó, Xet đã trở thành mặc định cho người dùng mới trên Hub.

Chúng tôi hiện hỗ trợ một số người sáng tạo lớn nhất trên Hub (Meta Llama, Google, OpenAI và Qwen) trong khi cộng đồng vẫn tiếp tục làm việc không bị gián đoạn.

Tiếp theo là gì?

Bắt đầu từ tháng này, chúng tôi sẽ mang Xet đến cho mọi người. Hãy theo dõi email cung cấp quyền truy cập vào Xet và khi bạn đã có, hãy cập nhật lên huggingface_hub mới nhất (pip install -U huggingface_hub) để mở khóa việc truyền nhanh hơn ngay lập tức. Điều này cũng có nghĩa là:

Tất cả các kho lưu trữ hiện có của bạn sẽ di chuyển từ LFS sang Xet
Tất cả các kho lưu trữ mới được tạo sẽ được bật Xet theo mặc định

Nếu bạn tải lên hoặc tải xuống từ Hub bằng trình duyệt của mình hoặc sử dụng Git, điều đó là tốt. Hỗ trợ dựa trên đoạn cho cả hai sẽ sớm ra mắt. Trong thời gian chờ đợi, hãy sử dụng bất kỳ quy trình làm việc nào bạn đã có; không có hạn chế.

Tiếp theo: mở nguồn giao thức Xet và toàn bộ ngăn xếp cơ sở hạ tầng. Tương lai của việc lưu trữ và di chuyển các byte mở rộng quy mô cho khối lượng công việc AI nằm trên Hub và chúng tôi đang hướng đến việc mang nó đến cho mọi người.

Nếu bạn có bất kỳ câu hỏi nào, hãy gửi cho chúng tôi một dòng trong phần bình luận 👇, mở một cuộc thảo luận trên trang nhóm Xet.

AI Today - SkyAI