الذكاء الاصطناعي
#Xet
#GitLFS
الانتقال من Git LFS إلى Xet في Hugging Face
في يناير من هذا العام، أطلق فريق Xet في Hugging Face نظام تخزين جديد، وبعد فترة قصيرة، تم تحويل حوالي 6% من تحميلات Hub عبر هذه البنية التحتية. كانت هذه خطوة مهمة، لكنها كانت مجرد البداية. خلال 6 أشهر، انضمت 500,000 مستودع تحتوي على 20 بيتابايت إلى الانتقال إلى Xet، حيث يتجاوز Hub Git LFS وينتقل إلى نظام تخزين يتناسب مع أعباء عمل مطوري الذكاء الاصطناعي.
اليوم، يستخدم أكثر من مليون شخص في Hub Xet. في مايو، أصبح الخيار الافتراضي على Hub للمستخدمين الجدد والمنظمات. ومع وجود عدد قليل من قضايا GitHub، ومناقشات في المنتديات، ورسائل على Discord، قد تكون هذه واحدة من أكثر عمليات الانتقال هدوءًا من هذا الحجم.
كيف حدث ذلك؟ أولاً، جاء الفريق مستعدًا بخبرة سنوات في بناء ودعم متجر المحتوى المعنون (CAS) وعميل Rust الذي يوفر أساس النظام. بدون هذه العناصر، قد تظل Git LFS هي المستقبل في Hub. ومع ذلك، فإن الأبطال المجهولين في هذه العملية هم:
- جزء أساسي من البنية التحتية يعرف داخليًا باسم جسر Git LFS
- عمليات نقل المحتوى الخلفية التي تعمل على مدار الساعة
معًا، سمحت لنا هذه المكونات بالانتقال بشكل مكثف إلى PBs في غضون أيام دون القلق بشأن تأثير ذلك على Hub أو المجتمع. إنها تمنحنا راحة البال للتحرك بشكل أسرع في الأسابيع والأشهر القادمة.
الجسور والتوافق العكسي
في الأيام الأولى من التخطيط للانتقال إلى Xet، اتخذنا بعض القرارات التصميمية الرئيسية:
- لن يكون هناك "قطع حاد" من Git LFS إلى Xet
- يجب أن يكون المستودع المُمكَّن لـ Xet قادرًا على احتواء كل من ملفات Xet وLFS
- لا تتطلب عمليات نقل المستودعات من LFS إلى Xet "إغلاق"؛ أي يمكن أن تعمل في الخلفية دون تعطيل التحميلات أو التنزيلات
مدفوعين بالتزامنا تجاه المجتمع، كانت لهذه القرارات البسيطة ظواهر كبيرة. الأهم من ذلك، لم نعتقد أنه يجب على المستخدمين والفرق تغيير سير العمل الخاص بهم على الفور أو تنزيل عميل جديد للتفاعل مع المستودعات المُمكَّنة لـ Xet.
إذا كان لديك عميل يدعم Xet (مثل hf-xet، التكامل مع huggingface_hub)، فإن التحميلات والتنزيلات تمر عبر كامل مجموعة Xet. يقوم العميل إما بتقسيم الملفات إلى أجزاء باستخدام تقسيم المحتوى أثناء التحميل، أو يطلب معلومات إعادة بناء الملفات عند التنزيل. عند التحميل، يتم تمرير الأجزاء إلى CAS وتخزينها في S3. أثناء التنزيلات، يوفر CAS نطاقات الأجزاء التي يحتاجها العميل لطلبها من S3 لإعادة بناء الملف محليًا.
بالنسبة للإصدارات القديمة من huggingface_hub أو huggingface.js، التي لا تدعم نقل الملفات القائم على الأجزاء، لا يزال بإمكانك التنزيل والتحميل إلى مستودعات Xet، لكن هذه البايتات تأخذ مسارًا مختلفًا. عند طلب ملف مدعوم من Xet من Hub على طول نقطة النهاية resolve، يقوم جسر Git LFS بإنشاء وإرجاع عنوان URL مسبق التوقيع، مقلدًا بروتوكول LFS. ثم يقوم الجسر بعمل إعادة بناء الملف من المحتوى الموجود في 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 والتوافق العكسي في التحميل. إنها وراء نقل أكثر من عشرة PB من النماذج ومجموعات البيانات وتحافظ على 500,000 مستودع متزامن مع تخزين Xet دون أي تأخير.
في كل مرة يحتاج فيها ملف إلى الانتقال من LFS إلى Xet، يتم تفعيل webhook، مما يدفع الحدث إلى قائمة موزعة حيث تتم معالجته بواسطة منظم. يقوم المنظم:
- بتفعيل Xet على المستودع إذا كان الحدث يتطلب ذلك
- يستخرج قائمة من مراجعات LFS لكل ملف LFS في المستودع
- يجمع الملفات في مهام بناءً على الحجم أو عدد الملفات؛ إما 1000 ملف أو 500 ميغابايت، أيهما يأتي أولاً
- يضع المهام في قائمة أخرى لعمال نقل البيانات
ثم تلتقط هذه العمال المهام وكل حاوية:
- تنزيل ملفات LFS المدرجة في الدفعة
- تحميل ملفات LFS إلى متجر المحتوى المعنون Xet باستخدام xet-core
توسيع عمليات النقل
في أبريل، اختبرنا حدود هذا النظام من خلال التواصل مع bartowski وسؤالهم إذا كانوا يرغبون في اختبار Xet. مع ما يقرب من 500 تيرابايت عبر 2000 مستودع، كشفت عملية النقل الخاصة بـ bartowski عن بعض الروابط الضعيفة:
- تمت كتابة ملفات الشظايا المؤقتة للتخلص العالمي أولاً إلى
/tmpثم نقلها إلى ذاكرة الشظايا. على حاويات العمل الخاصة بنا، ومع ذلك، كان/tmpوذاكرة Xet يجلسان على نقاط تركيب مختلفة. فشلت الحركة ولم تتم إزالة ملفات الشظايا أبدًا. في النهاية، امتلأ القرص، مما أدى إلى ظهور موجة من أخطاءNo space left on device. - بعد دعم إطلاق Llama 4، قمنا بتوسيع CAS لتحميلات مفاجئة، لكن عمال النقل قلبوا السيناريو حيث دفعت مئات التحميلات متعددة الجيجابايت CAS إلى ما وراء موارده
- على الورق، كانت عمال النقل قادرة على إنتاجية أكبر بكثير مما تم الإبلاغ عنه؛ كشف تحليل الحاويات عن اختناقات في الشبكة وEBS I/O
كان إصلاح هذا الوحش ذو الرؤوس الثلاثة يعني لمس كل طبقة - تصحيح xet-core، إعادة ضبط حجم CAS، وزيادة مواصفات عقد العمل. لحسن الحظ، كان bartowski متحمسًا للعمل معنا بينما كانت كل مستودع في طريقها إلى Xet. كانت هذه الدروس نفسها تدعم انتقال أكبر مستخدمي التخزين في Hub مثل RichardErkhov (1.7PB و25,000 مستودع) وmradermacher (6.1PB و42,000 مستودع).
في هذه الأثناء، زادت إنتاجية CAS بمقدار كبير بين أول وآخر عمليات النقل الكبيرة:
- عملية نقل bartowski: حافظت CAS على ~35 Gb/s، مع ~5 Gb/s تأتي من حركة المرور العادية في Hub.
- عمليات نقل mradermacher وRichardErkhov: بلغت CAS ذروتها حوالي ~300 Gb/s، بينما لا تزال تخدم ~40 Gb/s من الحمل اليومي.
صفر احتكاك، نقل أسرع
عندما بدأنا في استبدال LFS، كان لدينا هدفان في الاعتبار:
- عدم إلحاق الضرر
- تحقيق أكبر تأثير بأسرع ما يمكن
سمح لنا التصميم مع قيودنا الأولية وهذه الأهداف بـ:
- تقديم وتقوية
hf-xetقبل تضمينه فيhuggingface_hubكاعتماد مطلوب - دعم المجتمع في التحميل والتنزيل من المستودعات المُمكَّنة لـ Xet من خلال أي وسيلة يستخدمونها اليوم بينما تتولى بنيتنا التحتية الباقي
- تعلم دروس لا تقدر بثمن - من النطاق إلى كيفية عمل عميلنا على أنظمة الملفات الموزعة - من الانتقال التدريجي لـ Hub إلى Xet
بدلاً من الانتظار حتى تصبح جميع مسارات التحميل مدركة لـ Xet، أو فرض قطع حاد، أو دفع المجتمع لتبني سير عمل معين، كان بإمكاننا البدء في نقل Hub إلى Xet على الفور مع الحد الأدنى من تأثير المستخدم. باختصار، دع الفرق تحتفظ بسير عملها وتنتقل بشكل عضوي إلى Xet مع دعم البنية التحتية لتحقيق الهدف الطويل الأمد لنظام تخزين موحد.
Xet للجميع
في يناير وفبراير، قمنا بتسجيل المستخدمين المميزين للحصول على تعليقات واختبار الضغط على البنية التحتية. للحصول على تعليقات المجتمع، أطلقنا قائمة انتظار لمعاينة المستودعات المُمكَّنة لـ Xet. بعد فترة وجيزة، أصبح Xet الخيار الافتراضي للمستخدمين الجدد في Hub.
نحن الآن ندعم بعض من أكبر المبدعين في Hub (Meta Llama، Google، OpenAI، وQwen) بينما يستمر المجتمع في العمل دون انقطاع.
ما هو التالي؟
بدءًا من هذا الشهر، نحن نقدم Xet للجميع. ترقب بريدًا إلكترونيًا يوفر لك الوصول إلى Xet وعندما تحصل عليه، قم بتحديث إلى أحدث إصدار من huggingface_hub (pip install -U huggingface_hub) لفتح نقل أسرع على الفور. سيعني هذا أيضًا:
- سيتم نقل جميع مستودعاتك الحالية من LFS إلى Xet
- ستكون جميع المستودعات التي تم إنشاؤها حديثًا مُمكَّنة لـ Xet بشكل افتراضي
إذا كنت تقوم بالتحميل أو التنزيل من Hub باستخدام متصفحك أو تستخدم Git، فلا بأس بذلك. دعم قائم على الأجزاء لكل منهما قادم قريبًا. في هذه الأثناء، استخدم أي سير عمل لديك بالفعل؛ لا قيود.
التالي: فتح مصدر بروتوكول Xet وكل مجموعة البنية التحتية. مستقبل تخزين ونقل البايتات التي تتناسب مع أعباء عمل الذكاء الاصطناعي هو على Hub، ونسعى لجعله متاحًا للجميع.
إذا كان لديك أي أسئلة، لا تتردد في ترك تعليق أدناه، أو فتح نقاش على صفحة فريق Xet.
التعليقات 0
سجل دخولك لإضافة تعليق
لا توجد تعليقات بعد. كن أول من يعلق!