დღეისათვის, Hub-ის 1 მილიონზე მეტი მომხმარებელი Xet-ს იყენებს. მაისში, ის Hub-ის ნაგულისხმევ არჩევანად იქცა ახალი მომხმარებლებისა და ორგანიზაციებისთვის. რამდენიმე ათეული GitHub-ის პრობლემის, ფორუმის თემისა და Discord-ის შეტყობინების გათვალისწინებით, ეს ალბათ ამ მასშტაბის ყველაზე უხმაურო მიგრაციაა. როგორ? ერთი მხრივ, გუნდი წლების გამოცდილებით მოვიდა, რამაც მათ საშუალება მისცა შეექმნათ და მხარი დაეჭირათ კონტენტ-მისამართადი საცავისთვის (CAS) და Rust კლიენტისთვის, რომლებიც სისტემის საფუძველს წარმოადგენენ. ამ კომპონენტების გარეშე, Git LFS შესაძლოა კვლავ Hub-ის მომავალი ყოფილიყო. ეს კომპონენტები ერთად გვაძლევს საშუალებას, აგრესიულად მოვახდინოთ პეტაბაიტების (PBs) მიგრაცია დღეების განმავლობაში, Hub-ზე ან საზოგადოებაზე ზემოქმედების შესახებ ფიქრის გარეშე. ისინი გვაძლევენ სიმშვიდეს, რათა მომდევნო კვირებსა და თვეებში კიდევ უფრო სწრაფად ვიმოქმედოთ (იხილეთ ბოლომდე, რომ გაიგოთ, რა გველის წინ 👇). Xet-ზე მიგრაციის დაგეგმვის ადრეულ ეტაპზე, ჩვენ მივიღეთ რამდენიმე ძირითადი დიზაინერული გადაწყვეტილება. საზოგადოებისადმი ჩვენი ვალდებულებით განპირობებული, ამ ერთი შეხედვით მარტივ გადაწყვეტილებებს მნიშვნელოვანი შედეგები მოჰყვა. რაც ყველაზე მთავარია, ჩვენ არ გვჯეროდა, რომ მომხმარებლებსა და გუნდებს დაუყოვნებლივ უნდა შეეცვალათ თავიანთი სამუშაო პროცესი ან ჩამოეტვირთათ ახალი კლიენტი Xet-ის მხარდაჭერილ რეპოზიტორიებთან ურთიერთობისთვის. თუ თქვენ გაქვთ Xet-ის მხარდამჭერი კლიენტი (მაგ., hf-xet, Xet-ის ინტეგრაცია huggingface_hub-თან), ატვირთვები და ჩამოტვირთვები გადის Xet-ის სრულ სისტემაში. კლიენტი ან ყოფს ფაილებს ნაწილებად კონტენტზე დაფუძნებული დანაწილების გამოყენებით ატვირთვისას, ან ითხოვს ფაილის აღდგენის ინფორმაციას ჩამოტვირთვისას. ატვირთვისას, ნაწილები გადაეცემა CAS-ს და ინახება S3-ში. ჩამოტვირთვის დროს, CAS უზრუნველყოფს ნაწილების დიაპაზონებს, რომლებიც კლიენტს სჭირდება S3-დან მოთხოვნისთვის, რათა ფაილი ლოკალურად აღადგინოს. huggingface_hub-ის ან huggingface.js-ის ძველი ვერსიებისთვის, რომლებიც არ უჭერენ მხარს ნაწილებად დაფუძნებულ ფაილთა გადაცემას, თქვენ კვლავ შეგიძლიათ ჩამოტვირთოთ და ატვირთოთ Xet-ის რეპოზიტორიებში, მაგრამ ეს მონაცემები სხვა გზით მიედინება. როდესაც Xet-ის მიერ მხარდაჭერილი ფაილი მოთხოვნილია Hub-დან resolve endpoint-ის მეშვეობით, Git LFS Bridge აგებს და აბრუნებს ერთ წინასწარ ხელმოწერილ URL-ს, LFS პროტოკოლის იმიტირებით. Bridge შემდეგ ასრულებს ფაილის აღდგენის სამუშაოს S3-ში შენახული კონტენტისგან და უბრუნებს მას მომთხოვნს. ამის სანახავად, დააწკაპუნეთ ზემოთ მოცემულ სურათზე მარჯვენა ღილაკით და გახსენით ახალ ჩანართში. URL გადამისამართდება https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/migrating-the-hub-to-xet/bridge.png-დან ისეთზე, რომელიც იწყება https://cas-bridge.xethub.hf.co/xet-bridge-us/.... თქვენ ასევე შეგიძლიათ გამოიყენოთ curl -vL იგივე URL-ზე, რათა იხილოთ გადამისამართებები თქვენს ტერმინალში. ამასობაში, როდესაც Xet-ის მხარდაჭერის არმქონე კლიენტი ფაილს ატვირთავს, ის ჯერ LFS საცავში იგზავნება, შემდეგ კი Xet-ზე გადადის. ეს „ფონური მიგრაციის პროცესი“, რომელიც მხოლოდ მოკლედ არის ნახსენები ჩვენს დოკუმენტაციაში, უზრუნველყოფს როგორც Xet-ზე მიგრაციას, ასევე ატვირთვის უკან თავსებადობას. ის დგას ათობით პეტაბაიტის (PBs) მოდელებისა და მონაცემთა ნაკრებების მიგრაციის უკან და 500,000 რეპოზიტორიას Xet საცავთან სინქრონში ინახავს, ყოველგვარი შეფერხების გარეშე. ყოველ ჯერზე, როდესაც ფაილი LFS-დან Xet-ზე უნდა გადავიდეს, ირთვება webhook, რომელიც მოვლენას უბიძგებს განაწილებულ რიგში, სადაც მას ამუშავებს ორკესტრატორი. ორკესტრატორი ამ პროცესს მართავს, რის შემდეგაც მიგრაციის მუშაკები სამუშაოებს იღებენ და თითოეული მათგანი უზრუნველყოფს ფაილების ეფექტურ გადაცემას. აპრილში, ჩვენ შევამოწმეთ ამ სისტემის შესაძლებლობები, როდესაც bartowski-ს მივმართეთ და ვკითხეთ, სურდათ თუ არა Xet-ის გამოცდა. თითქმის 500 ტერაბაიტის (TB) მონაცემებით 2,000 რეპოზიტორიაზე, bartowski-ის მიგრაციამ რამდენიმე სუსტი წერტილი გამოავლინა: ამ „სამთავიანი ურჩხულის“ გამოსწორება ნიშნავდა ყველა ფენაზე მუშაობას - xet-core-ის პაჩირებას, CAS-ის ზომის შეცვლას და მუშაკი კვანძების (worker node) სპეციფიკაციების გაუმჯობესებას. საბედნიეროდ, bartowski მზად იყო ჩვენთან ემუშავა, სანამ ყოველი რეპოზიტორია Xet-ზე გადავიდოდა. ამავე გაკვეთილებმა განაპირობა Hub-ის უმსხვილესი საცავის მომხმარებლების, როგორიცაა RichardErkhov (1.7PB და 25,000 რეპოზიტორია) და mradermacher (6.1PB და 42,000 რეპოზიტორია 🤯), მონაცემთა გადატანა. ამასობაში, CAS-ის გამტარუნარიანობა რიგითობით გაიზარდა პირველ და ბოლო ფართომასშტაბიან მიგრაციებს შორის. როდესაც LFS-ის ჩანაცვლება დავიწყეთ, ჩვენი საწყისი შეზღუდვებითა და მიზნებით დიზაინმა საშუალება მოგვცა: იმის ნაცვლად, რომ დავლოდებოდით ყველა ატვირთვის გზის Xet-ის მხარდამჭერად ქცევას, იძულებითი ცვლილებების შემოღებას ან საზოგადოებისთვის კონკრეტული სამუშაო პროცესის დანერგვას, ჩვენ შეგვეძლო Hub-ის Xet-ზე მიგრაციის დაუყოვნებლივ დაწყება მომხმარებელზე მინიმალური ზემოქმედებით. მოკლედ, გუნდებს მიეცათ საშუალება შეენარჩუნებინათ თავიანთი სამუშაო პროცესები და ორგანულად გადასულიყვნენ Xet-ზე, ინფრასტრუქტურის მხარდაჭერით, რომლის გრძელვადიანი მიზანიც ერთიანი შენახვის სისტემაა. იანვარსა და თებერვალში ჩვენ ჩავრთეთ „დიდი“ მომხმარებლები (power users), რათა მიგვეღო უკუკავშირი და გამოგვეცადა ინფრასტრუქტურა ზეწოლის ქვეშ. საზოგადოებისგან უკუკავშირის მისაღებად, ჩვენ გავუშვით ლოდინის სია Xet-ის მხარდაჭერილი რეპოზიტორიების წინასწარი დათვალიერებისთვის. მალევე, Xet Hub-ის ახალი მომხმარებლებისთვის ნაგულისხმევად იქცა. ჩვენ ახლა მხარს ვუჭერთ Hub-ის ზოგიერთ უმსხვილეს შემქმნელს (Meta Llama, Google, OpenAI და Qwen) მაშინ, როდესაც საზოგადოება განუწყვეტლივ მუშაობს. რა გველის შემდეგ? ამ თვიდან დაწყებული, Xet-ს ყველასთვის ხელმისაწვდომს ვხდით. დაელოდეთ ელ.წერილს, რომელიც Xet-ზე წვდომას მოგცემთ და როგორც კი მიიღებთ, განაახლეთ huggingface_hub-ის უახლეს ვერსიამდე (pip install -U huggingface_hub).