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

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

لماذا يزداد الثقل؟

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

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

ما الذي اقترحه openLight؟

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

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

ولا يوفر هذا النهج الموارد فحسب، بل يوفر الوقت أيضًا. ففي مثال المؤلف، استغرق المسار عبر نموذج Ollama المحلي مع qwen2.5:0.5b ما مقداره 42,55 ثانية، في حين استغرق السيناريو نفسه عبر OpenAI gpt-4o-mini ما مقداره 3,28 ثانية. غير أن الاستنتاج الأهم لا يتعلق بمقارنة النماذج؛ بل بأن الأوامر الأكثر تكرارًا لا ينبغي أصلًا أن تمرّ في كل مرة بالدورة الكاملة عبر LLM إذا كان النظام قادرًا على فهمها مسبقًا.

كيف يمرّ الطلب؟

مسار الرسالة خطي وشفاف: يصل الطلب من Telegram، ويمرّ بالمصادقة والحفظ، ثم يبحث النظام أولًا عن تطابق مباشر مع skill معروف. فإذا وُجد هذا التطابق، يُنفَّذ الأمر فورًا. وإن لم يوجد، يُستدعى مصنِّف LLM ليقرر الخطوة التالية: متابعة الحوار أو اختيار المهارة المناسبة. وقبل التشغيل، يخضع الـ skill لفحص إضافي للحفاظ على السيطرة على التنفيذ.

كانت الفكرة ألا يتحول الوكيل إلى «LLM لكل شيء».

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

ماذا يعني ذلك؟

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