ამჟამად, ატვირთული ფაილები ინახება S3 ბაკეტში us-east-1 რეგიონში და ოპტიმიზებულია S3 Transfer Acceleration-ის გამოყენებით. ჩამოტვირთვები ქეშირებულია და მოწოდებულია AWS CloudFront-ის, როგორც CDN-ის მეშვეობით. CloudFront-ის 400-ზე მეტი მოსახერხებელი კიდეის ლოკაცია უზრუნველყოფს გლობალურ დაფარვას და დაბალშემცირებულ მონაცემთა გადაცემას. თუმცა, უმეტეს CDN-ის მსგავსად, ის ოპტიმიზებულია ვებ კონტენტისთვის და აქვს ფაილის ზომის ლიმიტი 50 GB. მიუხედავად იმისა, რომ ეს ზომის შეზღუდვა გონივრულია ინტერნეტში ფაილების ტიპიური გადაცემისთვის, მოდელისა და მონაცემთა ნაკრებების რეპოზიტორიუმებში ფაილების მუდმივად მზარდი ზომა გამოწვევას წარმოადგენს. მაგალითად, 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-ისგან განსხვავებით, რომელიც ფაილებს გაუმჭვირვალე ბლობებად განიხილავს, ჩვენი მიდგომა აანალიზებს ფაილებს ბაიტის დონეზე, რაც შესაძლებლობებს ქმნის გადაცემის სიჩქარის გასაუმჯობესებლად მოდელისა და მონაცემთა ნაკრებების რეპოზიტორიუმებში არსებული მასიური ფაილებისთვის. წაკითხვის გზა პრიორიტეტს ანიჭებს სიმარტივესა და სიჩქარეს, რათა უზრუნველყოს მაღალი გამტარუნარიანობა მინიმალური შეყოვნებით. ფაილის მოთხოვნები მიემართება CAS სერვერზე, რომელიც უზრუნველყოფს რეკონსტრუქციის ინფორმაციას. თავად მონაცემები კვლავ ინახება S3 ბაკეტში us-east-1 რეგიონში, ხოლო AWS CloudFront განაგრძობს CDN-ის როლის შესრულებას ჩამოტვირთვებისთვის. ჩაწერის გზა უფრო კომპლექსურია ატვირთვის სიჩქარის ოპტიმიზაციისა და დამატებითი უსაფრთხოების გარანტიების უზრუნველსაყოფად. წაკითხვის მსგავსად, ატვირთვის მოთხოვნები მიემართება CAS სერვერზე, მაგრამ ფაილის დონეზე მოთხოვნის ნაცვლად, ჩვენ ვმოქმედებთ ჩანკებზე (chunks). როდესაც შესაბამისობები მოიძებნება, CAS სერვერი ავალებს კლიენტს (მაგ., huggingface_hub) გადაიტანოს მხოლოდ საჭირო (ახალი) ჩანკები. ჩანკები მოწმდება CAS-ის მიერ S3-ზე ატვირთვამდე. არსებობს მრავალი იმპლემენტაციის დეტალი, როგორიცაა ქსელური შეზღუდვები და შენახვის დანახარჯები, რომლებსაც ჩვენ მომავალ პოსტებში განვიხილავთ. ახლა კი, მოდით გადავხედოთ, როგორ გამოიყურება წაკითხვები ამჟამად. ქვემოთ მოცემული პირველი დიაგრამა აჩვენებს წაკითხვისა და ჩაწერის გზებს, როგორც ისინი დღეს გამოიყურება: [დიაგრამები მოცემული არ არის ტექსტში] ამასობაში, ახალ დიზაინში, წაკითხვები შემდეგ გზას გაივლის: [დიაგრამა მოცემული არ არის ტექსტში] და ბოლოს, განახლებული ჩაწერის გზა ასე გამოიყურება: [დიაგრამა მოცემული არ არის ტექსტში] ფაილების ბაიტის დონეზე მართვით, ჩვენ შეგვიძლია ადაპტირება გავუკეთოთ ოპტიმიზაციებს სხვადასხვა ფაილის ფორმატებს. მაგალითად, ჩვენ შევისწავლეთ Parquet ფაილების დედუპლიკაციის გაუმჯობესება და ახლა ვიკვლევთ ტენზორული ფაილების (მაგ., Safetensors) კომპრესიას, რამაც შეიძლება ატვირთვის სიჩქარე 10-25%-ით შეამციროს. ახალი ფორმატების გაჩენასთან ერთად, ჩვენ უნიკალურ პოზიციაში ვართ, რომ შევიმუშაოთ შემდგომი გაუმჯობესებები, რომლებიც გააუმჯობესებს Hub-ზე განვითარების გამოცდილებას. ეს პროტოკოლი ასევე მნიშვნელოვან გაუმჯობესებებს გვთავაზობს კორპორატიული მომხმარებლებისა და გამოცდილი მომხმარებლებისთვის. ფაილების გადაცემისთვის მართვის პანელის (control plane) ინტეგრირება უზრუნველყოფს დამატებით გარანტიებს იმისათვის, რომ მავნე ან არასწორი მონაცემები არ აიტვირთოს. ოპერაციული თვალსაზრისით, ატვირთვები აღარ არის „შავი ყუთი“. გაუმჯობესებული ტელემეტრია უზრუნველყოფს აუდიტის ჩანაწერებსა და დეტალურ ჟურნალირებას, რაც Hub-ის ინფრასტრუქტურის გუნდს საშუალებას აძლევს სწრაფად და ეფექტურად გამოავლინოს და გადაჭრას პრობლემები. ამ პერსონალიზებული პროტოკოლის მხარდასაჭერად, ჩვენ უნდა განვსაზღვროთ CAS სერვისის ოპტიმალური გეოგრაფიული განაწილება. AWS Lambda@Edge თავდაპირველად განიხილებოდა მისი ფართო გლობალური დაფარვის გამო, რათა შეემცირებინა დაყოვნება. თუმცა, CloudFront ტრიგერებზე მისი დამოკიდებულება შეუთავსებელი გახდა ჩვენს განახლებულ ატვირთვის გზასთან. ამის ნაცვლად, ჩვენ ავირჩიეთ CAS კვანძების განთავსება AWS-ის 34 რეგიონიდან რამდენიმე შერჩეულში. S3 PUT მოთხოვნების 24-საათიანი ფანჯრის უფრო დეტალურად განხილვისას, ჩვენ გამოვავლინეთ გლობალური ტრაფიკის ნიმუშები, რომლებიც ავლენს მონაცემთა ატვირთვების განაწილებას Hub-ში. მოსალოდნელისამებრ, აქტივობის უმეტესი ნაწილი მოდის ჩრდილოეთ ამერიკიდან და ევროპიდან, დღის განმავლობაში უწყვეტი, მაღალი მოცულობის ატვირთვებით. მონაცემები ასევე ხაზს უსვამს აზიაში ძლიერ და მზარდ არსებობას. ამ ძირითად რეგიონებზე ფოკუსირებით, ჩვენ შეგვიძლია განვათავსოთ ჩვენი CAS ყოფნის წერტილები, რათა დავაბალანსოთ საცავი და ქსელური რესურსები, მინიმალური შეყოვნების შენარჩუნებით. მიუხედავად იმისა, რომ AWS გვთავაზობს 34 რეგიონს, ჩვენი მიზანია ინფრასტრუქტურის ხარჯები გონივრულ დონეზე შევინარჩუნოთ, მაღალი მომხმარებლის გამოცდილების შენარჩუნებისას. ამ მონაცემთა ნაკრებში წარმოდგენილი 88 ქვეყნიდან, პარეტო დიაგრამა აჩვენებს, რომ ტოპ 7 ქვეყანაზე მოდის ატვირთული ბაიტების 80%, ხოლო ტოპ 20 ქვეყანა მთლიანი ატვირთვის მოცულობისა და მოთხოვნების 95%-ს შეადგენს. შეერთებული შტატები გამოირჩევა, როგორც ატვირთვის ტრაფიკის ძირითადი წყარო, რაც ამ რეგიონში PoP-ის აუცილებლობას ქმნის. ევროპაში აქტივობის უმეტესი ნაწილი კონცენტრირებულია ცენტრალურ და დასავლურ ქვეყნებში (მაგ., ლუქსემბურგი, გაერთიანებული სამეფო და გერმანია), თუმცა არის გარკვეული დამატებითი აქტივობა, რომელიც გასათვალისწინებელია.