ქვემოთ მოცემული რუკა ვიზუალურად აჩვენებს ამ აქტივობას, სადაც ქვეყნები შეფერილია საათში ატვირთული ბაიტების მიხედვით. ამჟამად, ატვირთული მონაცემები ინახება S3 „ბაკეტში“ (bucket) us-east-1 რეგიონში და ოპტიმიზებულია S3 Transfer Acceleration-ის გამოყენებით. ჩამოტვირთვები ქეშირდება და ვრცელდება AWS CloudFront-ის მეშვეობით, როგორც CDN-ის (კონტენტის მიწოდების ქსელი). CloudFront-ის 400-ზე მეტი მოსახერხებელი კიდე-ლოკაცია უზრუნველყოფს გლობალურ დაფარვას და დაბალ ლატენციის მონაცემთა გადაცემას. თუმცა, CDN-ების უმეტესობის მსგავსად, ის ოპტიმიზებულია ვებ კონტენტისთვის და აქვს ფაილის ზომის ლიმიტი 50 GB. მიუხედავად იმისა, რომ ეს ზომის შეზღუდვა გონივრულია ინტერნეტში ფაილების ტიპური გადაცემისთვის, მოდელებისა და მონაცემთა ნაკრებების (dataset) რეპოზიტორებში ფაილების მუდმივად მზარდი ზომა გამოწვევას ქმნის. მაგალითად, meta-llama/Meta-Llama-3-70B-ის წონების ჯამური მოცულობა 131 GB-ია და ის დაყოფილია 30 ფაილად, რათა დააკმაყოფილოს Hub-ის რეკომენდაცია – წონების 20 GB სეგმენტებად დაყოფა. გარდა ამისა, როგორც ატვირთვისთვის, ასევე ჩამოტვირთვისთვის მოწინავე დედუპლიკაციის ან კომპრესიის ტექნიკების დანერგვა მოითხოვს ფაილების გადაცემის მეთოდების ხელახლა გააზრებას. Hugging Face-ის ინფრასტრუქტურის ამჟამინდელი საზღვრების გასაფართოებლად, ჩვენ ვახდენთ Hub-ის ატვირთვისა და ჩამოტვირთვის არქიტექტურის გადამუშავებას. ჩვენ ვგეგმავთ კონტენტზე მისამართირებული საცავის (Content-Addressed Store - CAS) ინტეგრირებას, როგორც კონტენტის დისტრიბუციის პირველ წერტილს. ეს საშუალებას გვაძლევს დავნერგოთ მორგებული პროტოკოლი, რომელიც აგებულია „მუნჯი წაკითხვის“ (dumb reads) და „ჭკვიანი ჩაწერის“ (smart writes) ფილოსოფიაზე. Git LFS-ისგან განსხვავებით, რომელიც ფაილებს როგორც გაუმჭვირვალე „ბლობებს“ (blobs) ისე აღიქვამს, ჩვენი მიდგომა ფაილებს ბაიტის დონეზე აანალიზებს, რაც იძლევა შესაძლებლობებს გავაუმჯობესოთ გადაცემის სიჩქარე მოდელებისა და მონაცემთა ნაკრებების რეპოზიტორებში არსებული მასიური ფაილებისთვის. წაკითხვის გზა (read path) პრიორიტეტს ანიჭებს სიმარტივესა და სიჩქარეს, რათა უზრუნველყოს მაღალი გამტარუნარიანობა მინიმალური შეყოვნებით. ფაილის მოთხოვნები იგზავნება CAS სერვერზე, რომელიც უზრუნველყოფს აღდგენის ინფორმაციას. თავად მონაცემები კვლავ ინახება S3 „ბაკეტში“ us-east-1-ში, ხოლო AWS CloudFront განაგრძობს CDN-ის ფუნქციის შესრულებას ჩამოტვირთვებისთვის. ჩაწერის გზა (write path) უფრო რთულია ატვირთვის სიჩქარის ოპტიმიზაციისა და უსაფრთხოების დამატებითი გარანტიების უზრუნველსაყოფად. წაკითხვის მსგავსად, ატვირთვის მოთხოვნები იგზავნება CAS სერვერზე, მაგრამ ფაილის დონის მოთხოვნის ნაცვლად, ჩვენ ვმუშაობთ „ნაწილებზე“ (chunks). შესაბამისობების აღმოჩენისას, CAS სერვერი კლიენტს (მაგალითად, huggingface_hub) ავალებს მხოლოდ საჭირო (ახალი) ნაწილების გადაცემას. ნაწილები ვალიდირებულია CAS-ის მიერ S3-ში ატვირთვამდე. არსებობს მრავალი საიმპლემენტაციო დეტალი, რომელთა განხილვაც მომავალ პოსტებში მოხდება, მაგალითად, ქსელური შეზღუდვები და შენახვის დამატებითი ხარჯები. ამ ეტაპზე კი, მოდით გადავხედოთ, თუ როგორ გამოიყურება წაკითხვის პროცესი დღეს. პირველი დიაგრამა ქვემოთ ასახავს წაკითხვისა და ჩაწერის გზებს, როგორც ისინი ამჟამად არის: ახალი დიზაინის მიხედვით კი, წაკითხვა შემდეგ გზას გაივლის: და ბოლოს, განახლებული ჩაწერის გზა: ფაილების ბაიტის დონეზე მართვით, ჩვენ შეგვიძლია ოპტიმიზაციები სხვადასხვა ფაილის ფორმატს მოვარგოთ. მაგალითად, ჩვენ შევისწავლეთ Parquet ფაილების დედუპლიკაციის გაუმჯობესება და ახლა ვიკვლევთ ტენსორული ფაილების (მაგალითად, Safetensors) კომპრესიას, რასაც შეუძლია ატვირთვის სიჩქარე 10-25%-ით შეამციროს. ახალი ფორმატების გაჩენისას, ჩვენ განსაკუთრებულ პოზიციაში ვართ, რათა შევიმუშაოთ შემდგომი გაუმჯობესებები, რომლებიც Hub-ზე დეველოპმენტის გამოცდილებას გააუმჯობესებს. ეს პროტოკოლი ასევე მნიშვნელოვან გაუმჯობესებებს გვთავაზობს კორპორატიული მომხმარებლებისა და მოწინავე მომხმარებლებისთვის. ფაილების გადაცემისთვის საკონტროლო დონის დანერგვა დამატებით გარანტიებს იძლევა იმის უზრუნველსაყოფად, რომ მავნე ან არასწორი მონაცემები არ აიტვირთოს. ოპერაციულად, ატვირთვები აღარ არის „შავი ყუთი“. გაუმჯობესებული ტელემეტრია უზრუნველყოფს აუდიტის კვალს და დეტალურ ლოგირებას, რაც Hub-ის ინფრასტრუქტურის გუნდს საშუალებას აძლევს სწრაფად და ეფექტურად გამოავლინოს და გადაჭრას პრობლემები. ამ მორგებული პროტოკოლის მხარდასაჭერად, ჩვენ უნდა განვსაზღვროთ CAS სერვისის ოპტიმალური გეოგრაფიული განაწილება. თავდაპირველად განვიხილავდით AWS Lambda@Edge-ს მისი ფართო გლობალური დაფარვის გამო, რაც მინიმუმამდე შეამცირებდა ქსელური მიმოსვლის დროს (round-trip time). თუმცა, მისი დამოკიდებულება CloudFront-ის ტრიგერებზე შეუთავსებელი აღმოჩნდა ჩვენს განახლებულ ატვირთვის გზასთან. ამის ნაცვლად, ჩვენ ავირჩიეთ CAS ნოდების განლაგება AWS-ის 34 რეგიონიდან რამდენიმე შერჩეულში. S3 PUT მოთხოვნების ჩვენი 24-საათიანი მონაცემების დეტალური განხილვისას, ჩვენ გამოვავლინეთ გლობალური ტრაფიკის ნიმუშები, რომლებიც Hub-ში მონაცემთა ატვირთვების განაწილებას ავლენს. მოსალოდნელისამებრ, აქტივობის უმეტესი ნაწილი მოდის ჩრდილოეთ ამერიკიდან და ევროპიდან, დღის განმავლობაში უწყვეტი, მაღალი მოცულობის ატვირთვებით. მონაცემები ასევე ხაზს უსვამს ძლიერ და მზარდ ყოფნას აზიაში. ამ ძირითად რეგიონებზე ფოკუსირებით, ჩვენ შეგვიძლია განვათავსოთ ჩვენი CAS წარმომადგენლობის წერტილები (points of presence), რათა დავაბალანსოთ შენახვისა და ქსელური რესურსები ლატენციის მინიმუმამდე დაყვანისას. მიუხედავად იმისა, რომ AWS გვთავაზობს 34 რეგიონს, ჩვენი მიზანია ინფრასტრუქტურის ხარჯები გონივრულ ფარგლებში შევინარჩუნოთ მაღალი მომხმარებლის გამოცდილების უზრუნველყოფით. ამ მონაცემების 88 წარმოდგენილი ქვეყნიდან, ზემოთ მოცემული პარეტოს დიაგრამა აჩვენებს, რომ ტოპ 7 ქვეყანაზე მოდის ატვირთული ბაიტების 80%, ხოლო ტოპ 20 ქვეყანა მთლიანი ატვირთვის მოცულობისა და მოთხოვნების 95%-ს შეადგენს. აშშ ატვირთვის ტრაფიკის ძირითად წყაროდ გვევლინება, რაც ამ რეგიონში PoP-ის (Point of Presence) განთავსებას აუცილებელს ხდის. ევროპაში აქტივობის უმეტესი ნაწილი კონცენტრირებულია ცენტრალურ და დასავლეთ ქვეყნებში (მაგალითად, ლუქსემბურგი, გაერთიანებული სამეფო და გერმანია), თუმცა გარკვეული დამატებითი აქტივობა არის გასათვალისწინებელი A