يلعب التقطيع المحدد بالمحتوى (CDC) دورًا مركزيًا في تمكين إلغاء البيانات المكررة داخل مستودع Xet المدعوم. الفكرة واضحة ومباشرة: قم بتقسيم بيانات كل ملف إلى أجزاء، وقم بتخزين البيانات الفريدة فقط، ثم جني الفوائد.
في الممارسة العملية، الأمر أكثر تعقيدًا. إذا ركزنا فقط على تعظيم إلغاء البيانات المكررة، فإن التصميم سيتطلب أصغر حجم ممكن للقطعة. ومن خلال القيام بذلك، سننشئ نفقات عامة كبيرة للبنية التحتية والبنائين في المركز.
في فريق Hugging Face’s Xet، نقوم بنقل مركز السيطرة على الأمراض (CDC) من النظرية إلى الإنتاج لتقديم تحميلات وتنزيلات أسرع لمنشئي الذكاء الاصطناعي (بعامل 2-3x في بعض الحالات). المبدأ التوجيهي لدينا بسيط: تمكين التجريب والتعاون السريع للفرق التي تقوم ببناء النماذج ومجموعات البيانات وتكرارها. وهذا يعني التركيز على أكثر من مجرد إلغاء البيانات المكررة؛ نحن نعمل على تحسين كيفية انتقال البيانات عبر الشبكة، وكيفية تخزينها، وتجربة التطوير بأكملها.
حقائق توسيع نطاق إلغاء البيانات المكررة
تخيل أنك قمت بتحميل مستودع بسعة 200 جيجابايت إلى Hub. اليوم، هناك عدد من الطرق للقيام بذلك، ولكن جميعها تستخدم أسلوبًا يركز على الملفات. لإجراء عمليات نقل أسرع للملفات إلى المركز، قمنا باستخدام برنامج xet-core مفتوح المصدر و hf_xet، التكامل مع huggingface_hub والذي يستخدم منهجًا قائمًا على القطعة مكتوبًا بلغة Rust.
إذا كنت تفكر في مستودع سعة 200 جيجابايت يحتوي على مجموعات فريدة، فهذا يعني 3 ملايين إدخال (بحجم 64 كيلو بايت تقريبًا لكل مجموعة) في المتجر المعنون بالمحتوى (CAS) الذي يدعم جميع المستودعات. إذا تم تحميل إصدار جديد من النموذج أو تم إنشاء فرع في المستودع ببيانات مختلفة، فسيتم إضافة المزيد من القطع الفريدة، مما يؤدي إلى زيادة الإدخالات في CAS.
مع ما يقرب من 45 بيتا بايت عبر 2 مليون نموذج ومجموعة بيانات ومستودعات مساحة على المركز، يمكن أن يؤدي النهج القائم على الأجزاء البحتة إلى 690 مليار قطعة. إن إدارة هذا الحجم من المحتوى باستخدام أجزاء فقط غير قابلة للتطبيق للأسباب التالية:
- النفقات العامة للشبكة: إذا تم تنزيل كل جزء أو تحميله بشكل فردي، فسيتم إنشاء ملايين الطلبات عند كل عملية تحميل وتنزيل، مما يؤدي إلى إرباك كل من العميل والخادم. حتى الاستعلامات المجمعة تنقل المشكلة ببساطة إلى طبقة التخزين.
- النفقات العامة للبنية التحتية: إن نظام CAS الساذج الذي يتتبع القطع بشكل فردي سيتطلب مليارات الإدخالات، مما يؤدي إلى فواتير شهرية باهظة على خدمات مثل DynamoDB أو S3. على مقياس Hugging Face، يتزايد هذا بسرعة.
باختصار، تتضخم طلبات الشبكة، وتكافح قواعد البيانات لإدارة البيانات الوصفية، وترتفع تكلفة تنسيق كل جزء بشكل كبير أثناء انتظار نقل ملفاتك.
مبادئ التصميم لإلغاء البيانات المكررة على نطاق واسع
تؤدي هذه التحديات إلى إدراك رئيسي:
يعد إلغاء البيانات المكررة بمثابة تحسين للأداء، وليس الهدف النهائي.
الهدف النهائي هو تحسين تجربة المنشئين في التكرار والتعاون في النماذج ومجموعات البيانات. لا تحتاج مكونات النظام من العميل إلى طبقة التخزين إلى ضمان إلغاء البيانات المكررة. وبدلاً من ذلك، فإنهم يستفيدون من إلغاء البيانات المكررة كأداة واحدة من بين العديد من الأدوات للمساعدة في ذلك.
من خلال تخفيف قيود إلغاء البيانات المكررة، نصل بطبيعة الحال إلى مبدأ التصميم الثاني:
تجنب استراتيجيات الاتصال أو التخزين التي تعتمد على مقياس 1:1 مع عدد القطع.
ماذا يعني هذا؟ نحن نتوسع مع تجميع.
توسيع نطاق إلغاء البيانات المكررة مع التجميع
يأخذ التجميع أجزاءً ويجمعها، ويشير إليها بذكاء بطرق توفر فوائد ذكية (وعملية):
- كتل: بدلاً من نقل الأجزاء وتخزينها، نقوم بتجميع البيانات معًا في كتل يصل حجمها إلى 64 ميجابايت بعد إلغاء البيانات المكررة. لا تزال الكتل تتناول المحتوى، ولكن هذا يقلل من إدخالات CAS بعامل قدره 1000.
- شظايا: توفر Shards التعيين بين الملفات والأجزاء (الكتل المرجعية أثناء قيامها بذلك). يتيح لنا ذلك تحديد أجزاء الملف التي تم تغييرها، مع الإشارة إلى الأجزاء التي تم إنشاؤها من التحميلات السابقة. عندما تكون القطع معروفة بالفعل بوجودها في CAS، يتم تخطيها، مما يؤدي إلى خفض عمليات النقل والاستعلامات غير الضرورية.
معًا، تفتح الكتل والشظايا فوائد كبيرة. ومع ذلك، عندما يقوم شخص ما بتحميل ملف جديد، كيف يمكننا معرفة ما إذا كان قد تم تحميل جزء من الملف من قبل حتى نتمكن من حذف الطلب غير الضروري؟ إن إجراء استعلام شبكة لكل قطعة غير قابل للتوسع ويتعارض مع مبدأ “no 1:1” الذي ذكرناه أعلاه.
الحل هو قطع المفاتيح وهي عبارة عن مجموعة فرعية بنسبة 0.1% من جميع القطع المحددة بشرط معياري بسيط يعتمد على تجزئة القطعة. نحن نقدم فهرسًا عالميًا لهذه القطع الرئيسية والأجزاء التي تم العثور عليها فيها، بحيث يتم إرجاع القطعة ذات الصلة عند الاستعلام عن القطعة لتوفير إلغاء البيانات المكررة محليًا. وهذا يسمح لنا بالاستفادة من مبادئ المنطقة المكانية. إذا تمت الإشارة إلى مقطع رئيسي في جزء، فمن المحتمل أن تكون مراجع القطع المشابهة الأخرى متوفرة في نفس الجزء. يؤدي هذا إلى تحسين إلغاء البيانات المكررة وتقليل طلبات الشبكة وقاعدة البيانات.
إلغاء البيانات المكررة المجمعة في الممارسة العملية
يقوم Hub حاليًا بتخزين أكثر من 3.5 بيتابايت من .gguf الملفات، ومعظمها عبارة عن إصدارات كمية من النماذج الأخرى الموجودة على المحور. تمثل النماذج الكمية فرصة مثيرة للاهتمام لإلغاء البيانات المكررة نظرًا لطبيعة القياس الكمي حيث تقتصر القيم على نطاق عدد صحيح أصغر ويتم قياسه. وهذا يحد من نطاق القيم في مصفوفات الوزن، مما يؤدي بطبيعة الحال إلى المزيد من التكرار. بالإضافة إلى ذلك، العديد من مستودعات النماذج الكمية تخزن متغيرات مختلفة متعددة (على سبيل المثال، Q4_K، Q3_K، Q5_K) مع قدر كبير من التداخل.
ومن الأمثلة الجيدة على ذلك عمليًا bartowski/gemma-2-9b-it-GGUF الذي يحتوي على 29 تكميمًا لـ google/gemma-2-9b-it بإجمالي 191 جيجابايت. للتحميل نستخدم hf_xet متكاملة مع huggingface_hub لإجراء إلغاء البيانات المكررة على مستوى المجموعة محليًا، ثم تجميع البيانات وتخزينها على مستوى الكتلة.
بمجرد التحميل، يمكننا أن نبدأ في رؤية بعض الأنماط الرائعة! لقد قمنا بتضمين تصور يوضح نسبة إلغاء البيانات المكررة لكل كتلة. كلما كانت الكتلة داكنة، كلما تمت الإشارة إلى أجزاء منها بشكل متكرر عبر إصدارات النماذج. إذا انتقلت إلى المساحة التي تستضيف هذا التمثيل المرئي، فإن التمرير فوق أي خلية خريطة حرارية يسلط الضوء على جميع المراجع إلى الكتلة باللون البرتقالي عبر جميع النماذج أثناء النقر على الخلية سيؤدي إلى تحديد جميع الملفات الأخرى التي تشارك الكتل:
قد لا تمثل كتلة واحدة من البيانات المكررة سوى بضع ميغابايت من المدخرات، ولكن كما ترون هناك العديد من الكتل المتداخلة! مع هذه الكتل العديدة التي تتراكم بسرعة. بدلاً من تحميل 191 جيجابايت، تم استخدام الإصدار المدعوم من Xet من gemma-2-9b-it-GGUF يقوم المستودع بتخزين 1515 كتلة فريدة بإجمالي 97 جيجابايت تقريبًا في بيئة CAS الاختبارية الخاصة بنا (توفير يصل إلى 94 جيجابايت تقريبًا).
على الرغم من أهمية تحسينات التخزين، إلا أن الفائدة الحقيقية هي ما يعنيه هذا للمساهمين في Hub. عند سرعة 50 ميجابايت/ثانية، تصل تحسينات إلغاء البيانات المكررة إلى فارق أربع ساعات في وقت التحميل؛ تسريع ما يقرب من 2x:
| الريبو | الحجم المخزن | وقت التحميل @ 50 ميجابايت/ثانية |
|---|---|---|
| إبداعي | 191 جيجابايت | 509 دقيقة |
| مدعومة من Xet | 97 جيجابايت | 258 دقيقة |
وبالمثل، يعمل التخزين المؤقت للقطعة المحلية على تسريع التنزيلات بشكل ملحوظ. إذا تم تغيير ملف أو إضافة تكميم جديد له تداخل كبير مع ذاكرة التخزين المؤقت للقطعة المحلية، فلن تضطر إلى إعادة تنزيل أي قطع لم تتغير. وهذا يتناقض مع النهج القائم على الملف حيث يجب تنزيل الملف الجديد أو المحدث بالكامل.
يوضح هذا معًا كيف يعمل إلغاء البيانات المكررة على مستوى القطعة المقترنة بالتجميع على مستوى الكتلة على تبسيط التخزين بشكل كبير، ولكن أيضًا التطوير على المركز. من خلال توفير هذا المستوى من الكفاءة في عمليات نقل الملفات، يمكن لمنشئي الذكاء الاصطناعي التحرك بشكل أسرع والتكرار بسرعة والقلق بشكل أقل بشأن الاصطدام باختناقات البنية التحتية. بالنسبة لأي شخص يدفع ملفات كبيرة إلى المركز (سواء كنت تدفع نموذجًا جديدًا لتقدير الحجم أو إصدارًا محدثًا لمجموعة تدريب)، فإن هذا يساعدك على تحويل التركيز إلى البناء والمشاركة، بدلاً من الانتظار واستكشاف الأخطاء وإصلاحها.
نحن نعمل بسرعة، ونطرح أول مستودعات مدعومة بـ Xet في الأسابيع والأشهر القادمة! وأثناء قيامنا بذلك، سنصدر المزيد من التحديثات لتوفير هذه السرعات لكل منشئ على Hub لجعل عمليات نقل الملفات غير مرئية.
تابعنا على المركز لمعرفة المزيد عن التقدم الذي أحرزناه!