Raspberry Pi 5 وopenLight: لماذا تُرهق وكلاء AI التقليديون العتاد الصغير

معظم وكلاء الذكاء الاصطناعي الشهيرة لا تعمل بشكل جيد على Raspberry Pi 5 ليس لأن النموذج ضعيف جداً، بل لأن المجموعة البرمجية الكاملة المحيطة به مصممة للخوادم من البداية. قام مؤلف المقالة بتحليل هذه المشكلة عملياً وبناء محرك تشغيل خفيف الوزن خاص به يسمى openLight، يزيل الطبقات غير الضرورية ويحتفظ فقط بما هو مطلوب فعلاً للمهام النموذجية.

لماذا يصبح كل شيء أثقل وزناً

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

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

ما اقترحه openLight

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

• ملف تنفيذي واحد بدون تغليف معقد
• تنفيذ بلغة Go بدلاً من مجموعة Python ثقيلة
• SQLite للتخزين بدلاً من خدمة قاعدة بيانات منفصلة
• الحد الأدنى من التبعيات والبدء السريع
• التحقق من المهارة قبل تنفيذ الأمر

يوفر هذا النهج ليس فقط توفير الموارد، بل أيضاً ميزة زمنية. في مثال المؤلف، المسار عبر نموذج Ollama المحلي مع qwen2.5:0.5b استغرق 42.55 ثانية، في حين أن نفس السيناريو عبر OpenAI gpt-4o-mini استغرق 3.28 ثواني. لكن الاستنتاج الرئيسي ليس حتى في مقارنة النماذج: الأوامر الأكثر تكراراً لا يجب أن تمر عبر دورة الذكاء الاصطناعي الكاملة في كل مرة إذا كان بإمكان النظام فهمها مسبقاً.

كيف يتدفق الطلب

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

كانت الفكرة هي عدم تحول الوكيل إلى "ذكاء اصطناعي لكل شيء". تم اختيار

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

ماذا يعني هذا

تُظهر قصة openLight بشكل جيد إلى أين يمكن حقاً أن يتحرك وكلاء الذكاء الاصطناعي خارج مراكز البيانات والسيناريوهات التوضيحية. على الأجهزة الصغيرة، الفائز ليس المجموعة "الأذكى"، بل تلك التي تعرف متى لا تستدعي النموذج. بالنسبة إلى Raspberry Pi والبنية التحتية المنزلية، هذا تحول مهم: يمكن أن يكون الوكيل المفيد ليس منصة ضخمة، بل طبقة تنفيذية صغيرة بقواعد واضحة واستخدام موجه للذكاء الاصطناعي.