პრაქტიკაში, ეს უფრო კომპლექსურია. თუ მხოლოდ დედუპლიკაციის მაქსიმიზაციაზე გავამახვილებდით ყურადღებას, დიზაინი მოითხოვდა რაც შეიძლება მცირე ზომის ჩანკებს. ამით ჩვენ შევქმნიდით მნიშვნელოვან დამატებით ხარჯებს ინფრასტრუქტურისთვის და Hub-ზე მომუშავე დეველოპერებისთვის. Hugging Face-ის Xet გუნდში, ჩვენ CDC-ს თეორიიდან პრაქტიკაში ვნერგავთ, რათა AI დეველოპერებს უფრო სწრაფი ატვირთვა და ჩამოტვირთვა შევთავაზოთ (ზოგიერთ შემთხვევაში 2-3-ჯერ სწრაფად). ჩვენი მთავარი პრინციპი მარტივია: ხელი შევუწყოთ სწრაფ ექსპერიმენტებსა და თანამშრომლობას გუნდებისთვის, რომლებიც მუშაობენ მოდელებსა და მონაცემთა ნაკრებებზე. ეს ნიშნავს, რომ ყურადღებას ვამახვილებთ არა მხოლოდ დედუპლიკაციაზე; ჩვენ ვახდენთ მონაცემთა ქსელში გადაადგილების, მათი შენახვისა და განვითარების მთლიანი გამოცდილების ოპტიმიზაციას. წარმოიდგინეთ 200GB რეპოზიტორიის ატვირთვა Hub-ზე. დღეს ამის გაკეთების რამდენიმე გზა არსებობს, მაგრამ ყველა მათგანი იყენებს ფაილებზე ორიენტირებულ მიდგომას. Hub-ზე ფაილების უფრო სწრაფი გადაცემის უზრუნველსაყოფად, ჩვენ გავხსენით xet-core-ისა და hf_xet-ის კოდები. ეს არის ინტეგრაცია huggingface_hub-თან, რომელიც იყენებს Rust-ში დაწერილ ჩანკებზე დაფუძნებულ მიდგომას. თუ განვიხილავთ 200GB რეპოზიტორიას უნიკალური ჩანკებით, ეს ნიშნავს 3 მილიონ ჩანაწერს (დაახლოებით 64KB თითო ჩანკზე) კონტენტით მისამართირებად საცავში (CAS), რომელიც ყველა რეპოზიტორიას უჭერს მხარს. თუ მოდელის ახალი ვერსია იტვირთება ან რეპოზიტორიაში სხვა მონაცემების მქონე განშტოება იქმნება, ემატება მეტი უნიკალური ჩანკი, რაც ზრდის CAS-ში არსებულ ჩანაწერებს. Hub-ზე არსებული თითქმის 45PB მონაცემით, რომელიც მოიცავს 2 მილიონ მოდელს, მონაცემთა ნაკრებს და სივრცის რეპოზიტორიას, მხოლოდ ჩანკებზე დაფუძნებულმა მიდგომამ შესაძლოა 690 მილიარდი ჩანკი წარმოშვას. კონტენტის ამ მოცულობის მხოლოდ ჩანკების გამოყენებით მართვა უბრალოდ არ არის სიცოცხლისუნარიანი, რადგან: მოკლედ, ქსელური მოთხოვნები უზარმაზარი ხდება, მონაცემთა ბაზებს უჭირთ მეტამონაცემების მართვა, და თითოეული ჩანკის ორკესტრირების ღირებულება მკვეთრად იზრდება, სანამ თქვენ ელოდებით თქვენი ფაილების გადაცემას. ეს გამოწვევები მიგვიყვანს საკვანძო დასკვნამდე: დედუპლიკაცია არის შესრულების ოპტიმიზაცია და არა საბოლოო მიზანი. საბოლოო მიზანია დეველოპერების გამოცდილების გაუმჯობესება, რომლებიც მოდელებსა და მონაცემთა ნაკრებებზე მუშაობენ და მათზე თანამშრომლობენ. სისტემის კომპონენტებს, კლიენტიდან საცავის ფენამდე, არ სჭირდებათ დედუპლიკაციის გარანტირება. ამის ნაცვლად, ისინი დედუპლიკაციას იყენებენ, როგორც მრავალი ინსტრუმენტიდან ერთ-ერთს. დედუპლიკაციის შეზღუდვის მოხსნით, ჩვენ ბუნებრივად მივდივართ მეორე დიზაინის პრინციპთან: მოერიდეთ კომუნიკაციისა და შენახვის სტრატეგიებს, რომლებიც ჩანკების რაოდენობასთან 1:1 მასშტაბით იზრდება. რას ნიშნავს ეს? ჩვენ მასშტაბირებას ვახდენთ აგრეგაციით. აგრეგაცია იღებს ჩანკებს და აჯგუფებს მათ, ინტელექტუალურად მიმართავს მათ ისე, რომ უზრუნველყოფს ჭკვიანურ (და პრაქტიკულ) სარგებელს: ბლოკები და შარდები ერთად მნიშვნელოვან უპირატესობებს გვთავაზობენ. თუმცა, როდესაც ვინმე ახალ ფაილს ტვირთავს, როგორ გავიგოთ, ატვირთული იყო თუ არა ეს ჩანკი ადრე, რათა თავიდან ავიცილოთ ზედმეტი მოთხოვნა? ყოველი ჩანკისთვის ქსელური მოთხოვნის შესრულება არ არის მასშტაბირებადი და ეწინააღმდეგება ზემოთ ხსენებულ „არა 1:1“ პრინციპს. გამოსავალი არის საკვანძო ჩანკები, რომლებიც წარმოადგენს ყველა ჩანკის 0.1%-იან ქვეჯგუფს, შერჩეულს მარტივი მოდულოს პირობით, რომელიც დაფუძნებულია ჩანკის ჰეშზე. ჩვენ ვუზრუნველყოფთ გლობალურ ინდექსს ამ საკვანძო ჩანკებსა და იმ შარდებზე, რომლებშიც ისინი გვხვდება, ისე რომ ჩანკის მოთხოვნისას, დაკავშირებული შარდი დაბრუნდება ადგილობრივი დედუპლიკაციის უზრუნველსაყოფად. ეს საშუალებას გვაძლევს გამოვიყენოთ სივრცითი ლოკალურობის პრინციპები. თუ საკვანძო ჩანკი მოხსენიებულია შარდში, სავარაუდოა, რომ სხვა მსგავსი ჩანკის მითითებები ხელმისაწვდომია იმავე შარდში. ეს კიდევ უფრო აუმჯობესებს დედუპლიკაციას და ამცირებს ქსელურ და მონაცემთა ბაზის მოთხოვნებს. Hub ამჟამად ინახავს 3.5PB-ზე მეტ .gguf ფაილს, რომელთა უმეტესობა Hub-ზე არსებული სხვა მოდელების კვანტიზებული ვერსიებია. კვანტიზებული მოდელები საინტერესო შესაძლებლობას იძლევა დედუპლიკაციისთვის კვანტიზაციის ბუნებიდან გამომდინარე, სადაც მნიშვნელობები შეზღუდულია მცირე მთელი რიცხვითი დიაპაზონით და მასშტაბირებულია. ეს ზღუდავს მნიშვნელობების დიაპაზონს წონის მატრიცებში, რაც ბუნებრივად იწვევს მეტ გამეორებას. გარდა ამისა, კვანტიზებული მოდელების მრავალი რეპოზიტორია ინახავს მრავალ განსხვავებულ ვარიანტს (მაგ., Q4_K, Q3_K, Q5_K) დიდი გადაფარვით. ამის კარგი პრაქტიკული მაგალითია bartowski/gemma-2-9b-it-GGUF, რომელიც შეიცავს google/gemma-2-9b-it-ის 29 კვანტიზაციას, ჯამში 191GB. ატვირთვისთვის, ჩვენ ვიყენებთ hf_xet-ს, რომელიც ინტეგრირებულია huggingface_hub-თან, რათა შევასრულოთ ჩანკების დონის დედუპლიკაცია ლოკალურად, შემდეგ კი მოვახდინოთ მონაცემების აგრეგაცია და შენახვა ბლოკის დონეზე. ატვირთვის შემდეგ, ჩვენ შეგვიძლია დავინახოთ საინტერესო შაბლონები! ჩვენ ჩავრთეთ ვიზუალიზაცია, რომელიც აჩვენებს დედუპლიკაციის კოეფიციენტს თითოეული ბლოკისთვის. რაც უფრო მუქია ბლოკი, მით უფრო ხშირად ხდება მისი ნაწილების მითითება მოდელების სხვადასხვა ვერსიებში. თუ გადახვალთ სივრცეში, რომელიც ამ ვიზუალიზაციას მასპინძლობს, ნებისმიერ heatmap უჯრედზე გადატარება ნარინჯისფრად გაანათებს ბლოკის ყველა მითითებას ყველა მოდელში, ხოლო უჯრედზე დაწკაპუნება აირჩევს ყველა სხვა ფაილს, რომლებიც იზიარებენ ბლოკებს: დედუპლიკაციის ერთი ბლოკი შესაძლოა მხოლოდ რამდენიმე MB-ის დანაზოგს წარმოადგენდეს, მაგრამ როგორც ხედავთ, მრავალი გადამფარავი ბლოკია! ამდენი ბლოკის გათვალისწინებით, დანაზოგი სწრაფად გროვდება. 191GB-ის ატვირთვის ნაცვლად, gemma-2-9b-it-GGUF რეპოზიტორიის Xet-ის მხარდაჭერილი ვერსია ინახავს 1515 უნიკალურ ბლოკს, ჯამში დაახლოებით 97GB-ს ჩვენს სატესტო CAS გარემოში.