ბოლო რამდენიმე კვირის განმავლობაში, Hugging Face-ის Xet გუნდმა მნიშვნელოვანი ნაბიჯი გადადგა წინ, როდესაც LFS-დან Xet საცავში გადაიტანა მოდელებისა და მონაცემთა ნაკრებების პირველი საცავები. ეს არის მრავალი ნაბიჯიდან ერთ-ერთი, რომელიც ემსახურება Hugging Face-ის ხედვის განხორციელებას Hub-ის მიმართ, რაც ხელოვნური ინტელექტის დეველოპერებს საშუალებას აძლევს, უფრო ეფექტურად შექმნან, განაახლონ და ითანამშრომლონ მასიურ მოდელებსა და მონაცემთა ნაკრებებზე. ტექნოლოგიის უფრო ღრმა გაგების მსურველებს შეუძლიათ გაეცნონ შესაბამის პოსტებს. თუმცა, ეს პოსტი არ არის ძირითად ტექნოლოგიაზე. ეს არის კულისებს მიღმა ხედვა Xet-ის Hub-ზე ინტეგრაციის პროცესზე; ის გიჩვენებთ ჩვენს კონცეფციის დამტკიცებიდან საცავების პირველ მიგრაციამდე გზას. მიგრაციამ Hub-ის ჩამოტვირთვის ტრაფიკის დაახლოებით 6% Xet ინფრასტრუქტურაზე გადაიტანა, რითაც დადასტურდა რამდენიმე ინტეგრალური კომპონენტის ეფექტურობა და შემოწმდა ინტეგრაცია საცავებზე წვდომის მრავალფეროვან ხერხებთან (მაგ., ლოკალური განვითარების გარემოები, სხვადასხვა ბიბლიოთეკები, CI სისტემები, ღრუბლოვანი პლატფორმები და ა.შ.). თითქმის ორი მილიონი დეველოპერი მუშაობს ორ მილიონზე მეტ საჯარო საცავზე, და სწორედ რეალური გამოყენებაა საბოლოო საპროტესტო მოედანი. Xet საცავის მსგავსი რთული სისტემის ინჟინერია წონასწორობის აქტია. თქვენ გეგმავთ მასშტაბურობას, შესრულებას და საიმედოობას, მაგრამ როგორც კი ბაიტები იწყებენ მოძრაობას, გამოწვევები ჩნდება. ხრიკი იმაშია, რომ იცოდეთ, როდის უნდა გადახვიდეთ დიზაინიდან და თეორიიდან პრაქტიკაზე. LFS, დღევანდელი საცავების უკან არსებული სისტემა, დიდ ფაილებს ინახავს ცალკე ობიექტის საცავში, საცავის გარეთ. LFS ახდენს დედუპლიკაციას ფაილის დონეზე. თუნდაც მცირე რედაქტირება ქმნის ახალ რევიზიას, რომელიც სრულად უნდა აიტვირთოს; ეს მტკივნეულია მრავალგიგაბაიტიანი ფაილებისთვის, რომლებიც მრავალ Hub საცავში გვხვდება. კონტრასტულად, Xet საცავი იყენებს კონტენტით განსაზღვრულ დანაწევრებას (CDC), რათა მოახდინოს დედუპლიკაცია ბაიტების დონეზე (დაახლოებით 64KB მონაცემთა ჩანკები). თუ თქვენ შეცვლით ერთ სტრიქონს Parquet ფაილში ან შეცვლით მეტამონაცემების მცირე ნაწილს GGUF მოდელში, მხოლოდ ეს შეცვლილი ჩანკები იგზავნება ქსელში. ეს მნიშვნელოვან სარგებელს იძლევა დიდი ფაილების გადაცემისას. მაგალითად, Xet გუნდი ინახავს შიდა ~5 GB SQLite მონაცემთა ბაზას, რომელიც ამუშავებს მეტრიკების დაფას. LFS-ის შემთხვევაში, 1 მბ-ის დამატება (რაც ამჟამად საშუალო განახლებაა) მოითხოვს მთელი 5 გბ ფაილის ხელახლა ატვირთვას. Xet საცავის შემთხვევაში, ჩვენ მხოლოდ ახალ მონაცემებს ვტვირთავთ. ეს ნიშნავს, რომ დაფისთვის ატვირთვა წამის მეათედ ნაწილს იღებს (50 მბ/წმ სიჩქარით) იმ 13 წუთის ნაცვლად, რაც დასჭირდებოდა, თუ მონაცემთა ბაზა LFS-ით იქნებოდა გამყარებული. ამ ყველაფრის განსახორციელებლად საჭიროა კოორდინაცია შემდეგ კომპონენტებს შორის: საწარმოო გარემოზე გადასვლამდე, სისტემა გაეშვა ეფემერულ გარემოში, სადაც ჩვენ ავაშენეთ ფუნქციონალურობის „ფოლადის ძაფი“ huggingface_hub-ის მეშვეობით ატვირთვისა და ჩამოტვირთვის გასააქტიურებლად. ქვემოთ მოცემული ვიდეო აჩვენებს ჩვენს პროგრესს ერთი თვის შემდეგ: სწრაფი კონცეფციის დამტკიცების ამაღელვებელი მაჩვენებლების შემდეგ, გუნდი შეუდგა რთულ ინტეგრაციის წერტილებთან ბრძოლას (კონფიდენციალურობა, უკუთავსებადობა, ფრაგმენტაცია და ა.შ.) Hub-ის კომპლექსურ ეკოსისტემასთან. საბოლოოდ, ინფრასტრუქტურა პროდაქშენში გადავიდა Hugging Face გუნდის წევრებისთვის. რეალური გამოყენების დაწყების შემდეგ, ჩვენ გადავედით პირველ ფართომასშტაბიან მიგრაციაზე. 20 თებერვალს, დილის 10 საათზე, ყველა მზადყოფნაში იყო. წინა კვირების განმავლობაში გუნდმა შექმნა შიდა ინსტრუმენტები LFS-დან Xet-ში ფაილების მიგრაციისთვის და, რაც არანაკლებ მნიშვნელოვანია, საჭიროების შემთხვევაში საცავის LFS-ზე უკან დასაბრუნებლად. ახლა დრო იყო, ეს ყველაფერი გამოგვეცადა. გრაფანა და კიბანა ახალი ლოგებითა და მეტრიკებით განათდა, რაც რეალურ დროში აჩვენებდა დატვირთვის ცვლას. სურათი იგივეა კიბანაში, მხოლოდ აქ შეგიძლიათ გაიგოთ, როდის ვისვენებდით ლანჩზე: დღის ბოლოს, ჩვენ წარმატებით გადავიტანეთ ყველა მიზნობრივი საცავი, ჯამში 4.5 ტბ მონაცემი, Xet საცავში. თითოეული საცავიდან ჩამოტვირთვებს ახლა ჩვენი ინფრასტრუქტურა ემსახურებოდა. არცერთი გაშვება არ ხდება გაკვეთილების გარეშე. სისტემამ შეუფერხებლად გაართვა თავი დატვირთვას და მიგრაციები მნიშვნელოვანი შეფერხებების გარეშე დასრულდა, მაგრამ როდესაც ბაიტები სხვადასხვა კომპონენტებში გაედინებოდა, ჩვენ დავიწყეთ გარკვეული ტენდენციების შემჩნევა. მიგრაციის შემდგომი ქსელის გამტარუნარიანობის განხილვისას, დავინახეთ, რომ CAS ოთხჯერ მეტ მონაცემს იტვირთავდა, ვიდრე კლიენტებს უბრუნებდა: დამატებითი გამოკვლევის შემდეგ აღმოვაჩინეთ, რომ CAS-ის მიმართ მოთხოვნების უმეტესობა იყო ფაილებში მონაცემთა 10 მბ დიაპაზონებისთვის. ეს მოთხოვნები მოდის მომხმარებლებისგან, რომლებიც იყენებენ hf_transfer-ს დიდი ფაილების ჩამოტვირთვის დასაჩქარებლად. მოთხოვნილი დიაპაზონები არ ემთხვევა ბლოკის საზღვრებს და ბლოკის ფორმატი არ იძლევა შეუკუმშული ჩანკების სიგრძეს, რათა ხელი შეუწყოს უშუალოდ მონაცემებზე გადასვლას ბლოკის შიგნით. ამის ნაცვლად, CAS ახდენს ბლოკის სტრიმინგს დასაწყისიდან და კითხულობს მანამ, სანამ არ იპოვის მოთხოვნილ მონაცემებს. მოცემული ბლოკის საშუალო ზომით 60 მბ და ამ ბლოკის შიგნით დიაპაზონების მრავალი ნაწილობრივი მოთხოვნით, დანახარჯი გროვდება. CAS კითხულობს 210 მბ-ს მხოლოდ 60 მბ მიწოდებული მონაცემისთვის, რაც არის 3.5 გადმოწერილი ბაიტი : 1 კლიენტისთვის გაგზავნილი ბაიტი. მასშტაბით, არარეგულარული ზომის ბლოკებსა და დიაპაზონებში, რომლებმაც შეიძლება რამდენიმე ბლოკი მოიცვას, 4 გადმოწერილი ბაიტი : 1 გაგზავნილი ბაიტი თანაფარდობა მიიღწევა. როგორც ყოველთვის, ერთი სურათი ათასი სიტყვის ტოლია: ამის გამოსასწორებლად, ჩვენ განვაახლეთ ბლოკის ფორმატი, რათა შეენახა ჩანკების სიგრძის მეტამონაცემები, რაც CAS-ს საშუალებას აძლევს, ჩამოტვირთოს მხოლოდ ის, რაც თითოეულ მოთხოვნას რეალურად სჭირდება.