مهندس في Eltex يشرح كيفية تشغيل التعلّم الاتحادي على أجهزة الحافة بذاكرة 256 ميغابايت

يُناقَش التعلّم الاتحادي عادةً في سياق الهواتف الذكية والسيارات وشبكات إنترنت الأشياء الكبيرة، لكن العائق الرئيسي في الواقع العملي غالبًا ما يكون أبسط بكثير: الجهاز ببساطة لا يملك ذاكرة كافية. وهذا بالضبط ما تركّز عليه مادة مهندس Eltex ألكسندر لوشكاريف، التي أُعدّت استنادًا إلى مداخلته في مؤتمر AiConf. يبدو الموضوع ضيقًا، لكنه يمسّ عمليًا أي مشروع يريد نقل تعلّم الآلة من السحابة إلى حافة الشبكة وتشغيله على عتاد محدود الموارد جدًا.

تتناول المادة سيناريوهات يقل فيها حجم الذاكرة العشوائية في جهاز الحافة عن 256 ميغابايت. بالنسبة إلى فرق الخوادم يبدو ذلك قيدًا شبه متطرف، لكنه واقعي تمامًا في الإلكترونيات الصناعية والبوابات ومعدات الاتصالات والأنظمة المدمجة ووحدات التحكم المتخصصة. وفي هذه الظروف لا تقتصر المهمة على أخذ نموذج جاهز وتحميله في الذاكرة. فالمطلوب استيعاب النموذج نفسه والبيانات والمخازن المؤقتة وعمليات النظام ومنطق تبادل التحديثات في آن واحد، دون المساس باستقرار الجهاز.

تكمن أهمية التعلّم الاتحادي في هذا السياق في أنه يتيح تدريب النماذج أو مواصلة تدريبها دون نقل البيانات الخام إلى مركز موحّد. فالحسابات تُنفَّذ محليًا، ولا تُرسَل إلى الخارج سوى المعاملات أو التغييرات الطارئة عليها. يساعد هذا النهج على التحكم بشكل أفضل في الخصوصية، ويقلل الاعتماد على قناة اتصال دائمة، ويجعل سيناريوهات الحافة أكثر قابلية للتطبيق. لكن له وجهًا آخر: فعميل FL المحلي يحتاج بحد ذاته إلى ذاكرة وقدرة حسابية وتنظيم دقيق لخط المعالجة (pipeline). وكلما ضعف الجهاز، اضطر المطورون إلى التقتير في كل ميغابايت.

يتبيّن من وصف الجزء الأول أن المادة تعالج الجانب الهندسي من هذه المشكلة، لا النظرية المجردة. وهذا أكثر المواضع إيلامًا لفرق تطبيق تعلّم الآلة على الأطراف: فقد يكون النموذج دقيقًا في المختبر، لكنه يصبح عديم الفائدة في بيئة الإنتاج إذا لم يتسع في الذاكرة أو تسبّب في تدهور أداء بقية الخدمات. وفي مثل هذه الأجهزة لا يهم حجم الأوزان وحده، بل أيضًا ذروات استهلاك الذاكرة المؤقتة أثناء الاستدلال (inference) وإعداد الدفعات (batches) وتسلسل التحديثات (serialization) والتبادل عبر الشبكة. وحتى لو بدا النموذج مضغوطًا في حالته الساكنة، فقد يجعل سلوكه أثناء التشغيل (runtime) إطلاقه مستحيلًا.

بهذا المعنى، فإن الصياغة المتعلقة بجهاز يبدو فيه 1 غيغابايت ترفًا تصف بدقة الفجوة بين حزمة تعلّم الآلة المعتادة وعالم الأنظمة المدمجة الحقيقي. فكثير من الأدوات والممارسات المألوفة في تطوير الخوادم تتوقف عن العمل هنا دون تكييف. إذ لا يمكن زيادة حجم الدفعة (batch size) بلا حدود، ولا الاحتفاظ بنسخ زائدة من التنسورات (tensors)، ولا الاتكال على هامش واسع من ذاكرة النظام. وأي خطأ في تقدير ملف الموارد يتحول سريعًا إلى إعادة تشغيل أو تجمّد أو التخلي عن الوظيفة التي أُدخل النموذج من أجلها أصلًا.

ومن المهم بشكل خاص أن الحديث لا يدور عن مجرد تشغيل الاستدلال على جهاز صغير، بل عن التعلّم الاتحادي تحديدًا. وهو نمط أكثر تعقيدًا: إذ يتعين على النظام أن يتلقى النموذج العالمي دوريًا، وينفّذ خطوات التدريب محليًا، ويحتفظ بالحالات الوسيطة، ثم يرسل النتيجة إلى الخادم. وعندما تكون الذاكرة شحيحة، تجب إعادة النظر في كل شيء حرفيًا: حجم النموذج وصيغة تمثيل البيانات وتواتر المزامنة ومدة الجلسات المحلية، وأحيانًا بنية العميل نفسها.

يتضح من الإعلان أن المؤلف يطرح السؤال الصحيح: قبل مناقشة جودة النموذج، يجب معرفة ما إذا كان تشغيله ممكنًا على عتاد حافة حقيقي دون أعطال ودون تنازلات دائمة في الموثوقية. وهذه إشارة مهمة للسوق. فالاهتمام بالذكاء الاصطناعي على حافة الشبكة يتزايد، لكن التطبيق الفعلي يصطدم لا بالعروض التجريبية اللامعة، بل بقيود الذاكرة والطاقة والاستقرار. لذلك تفيد مثل هذه المواد مهندسي تعلّم الآلة، وكذلك فرق الواجهة الخلفية (backend) والأنظمة المدمجة والمنتج: فهي تعيد النقاش من مستوى الوعود إلى مستوى هندسة الأنظمة.

وإذا كان الجزء الأول يضع إطار المشكلة، فالخلاصة الرئيسية واضحة منذ الآن: في تعلّم الآلة على الحافة، لا يفوز النموذج الأكثر رواجًا، بل النموذج الذي يستطيع الجهاز فعلًا تحمّله.