كيف يربط JBlanked بين Flipper Zero وCardputer وPicoCalc والذكاء الاصطناعي المحلي باستخدام ZimaBoard 2

شكرًا لـ JBlanked على توثيق طريقة مختلفة لإدخال الذكاء الاصطناعي المحلي في تطوير الأجهزة المضمّنة. ففي الفيديو الكامل، يحوّل ZimaBoard 2 إلى خادم Ollama محلي، ويوصل أجهزة محمولة، بما في ذلك Cardputer-ADV وPicoCalc وFlipper Zero، ببيئة الذكاء الاصطناعي المشتركة تلك.

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

إفصاح عن التعاون: تستند هذه المقالة إلى الإعداد الذي عرضه JBlanked وإلى الوثائق العامة الخاصة بـ Picoware وFlipperHTTP. وقد تتغير إصدارات البرامج وتوافر نماذج الذكاء الاصطناعي وتوافق الأجهزة وأداء الاستدلال المحلي بمرور الوقت.

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

نظرة سريعة على إعداد الذكاء الاصطناعي المحلي

يجمع المشروع بين خادم x86 مدمج وعدة منصات مضمّنة. وبدلًا من فرض حزمة البرامج نفسها على كل جهاز، يستخدم JBlanked طبقات اتصال مختلفة تبعًا لما يدعمه كل جهاز.

لماذا استخدام ZimaBoard 2 كخادم للذكاء الاصطناعي؟

لا تكمن أهمية هذا المشروع في مجرد قدرة ZimaBoard 2 على تشغيل تطبيق للذكاء الاصطناعي، بل في الطريقة التي يغيّر بها اللوحة بنية المشاريع المضمّنة الصغيرة.

صُممت أجهزة مثل Cardputer وPicoCalc وFlipper Zero لتكون محمولة وتعتمد على عتاد مضمّن متخصص. وهي مفيدة للواجهات، والبرامج النصية، وتجارب البرامج الثابتة، وأدوات الشبكات، والتطبيقات المحمولة، لكن مواردها المدمجة محدودة بدرجة أكبر بكثير من موارد محطة عمل تقليدية للذكاء الاصطناعي.

يوفّر خادم ZimaBoard 2 المنزلي الصغير مضيفًا منفصلًا بمعمارية x86، مع اتصال شبكي سلكي، ودعم لتوصيل وحدات التخزين، وإمكانية توسعة عبر PCIe. ويجعل ذلك من الممكن إبقاء الأجهزة المحمولة صغيرة الحجم، مع نقل أعباء الخادم الأكبر إلى مكان آخر.

في سير عمل JBlanked، يشغّل ZimaBoard 2 نظام ZimaOS، بينما يوفّر Ollama خدمة نموذج اللغة المحلية. وبمجرد إتاحة هذه الخدمة على الشبكة المحلية، يمكن للأجهزة المتوافقة التواصل معها دون حاجة كل جهاز محمول إلى قدرة حوسبة وذاكرة كافيتين لاستضافة النموذج نفسه.

يعرض الفيديو أيضًا تفصيلًا مهمًا بشأن إعداد الخادم المعروض: أثناء تشغيل Ollama، تعرض لوحة معلومات نظام ZimaOS بطاقة NVIDIA GeForce RTX 3060 مع ذاكرة VRAM بسعة 12 غيغابايت. وهذا يعني أنه ينبغي فهم الأداء الظاهر في العرض ضمن سياق خادم محلي مزوّد بوحدة GPU، وليس باعتباره اختبارًا لجهاز ZimaBoard 2 يعمل بالمعالج المركزي فقط.

يعمل Ollama داخل بيئة ZimaOS. وتعرض لوحة معلومات النظام الظاهرة خلفه بطاقة NVIDIA GeForce RTX 3060 وذاكرة VRAM بسعة 12 غيغابايت، ما يوضح أن خادم الذكاء الاصطناعي المحلي المعروض مزوّد بتسريع GPU.

كيف يعمل اتصال الذكاء الاصطناعي المحلي

يمكن فهم التصميم الأساسي على أنه يتكوّن من ثلاث طبقات:

• طبقة الخادم: يشغّل ZimaBoard 2 نظام ZimaOS ويستضيف Ollama.
• طبقة Agent أو الشبكة: يرسل Picoware أو مكدس الشبكات في Flipper الطلبات بين الجهاز المضمّن والخادم المحلي.
• طبقة الجهاز: يوفر Cardputer-ADV أو PicoCalc أو Flipper Zero الواجهة المادية وينفذ الإجراءات الخاصة بالجهاز.

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

يستخدم Cardputer-ADV وPicoCalc تطبيق Picoware Agent

مشروع Picoware من تطوير JBlanked هو بيئة برمجية مفتوحة المصدر تدعم Cardputer-ADV وPicoCalc وFlipper Zero وأجهزة أخرى تعتمد على ESP32 أو Raspberry Pi Pico.

بالنسبة إلى هذه التجربة، يُعد Picoware Agent المكوّن المهم. يوفر Agent واجهة مدعومة بنموذج لغوي كبير مع سياقات تشغيل مختلفة، بدلًا من أن يعمل فقط كنافذة دردشة عامة.

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

يرسل Flipper Zero الطلبات إلى خادم الذكاء الاصطناعي المحلي

يتبع Flipper Zero نمط تفاعل مختلفًا. في الفيديو، يوضح JBlanked كيفية إعداد الجهاز حمولة طلب منظمة للنموذج المحلي من خلال لوحة تطوير مزودة بإمكانات Wi-Fi ومثبتة على Flipper.

تتضمن الحمولة الظاهرة على الشاشة حقلًا للنموذج qwen3.5:9b. يوضح هذا تقسيم المسؤوليات بوضوح: يُحضّر Flipper الطلب ويرسله، بينما يعمل نموذج اللغة المحدد على الخادم المحلي الأكثر قدرة.

يُحضّر Flipper Zero حمولة طلب لإرسالها إلى خدمة الذكاء الاصطناعي المحلية. وتُظهر الشاشة أن حقل النموذج مضبوط على qwen3.5:9b، بينما تكون لوحة تطوير مزودة بإمكانات Wi-Fi مثبتة أعلى الجهاز.

هذا التمييز مهم. لا يشغّل Flipper نموذج اللغة الكامل محليًا. يتمثل دوره في توفير الواجهة المحمولة ومسار الشبكة، بينما يعمل Ollama والنموذج المحدد على الخادم.

ما الذي يستطيع وكيل الذكاء الاصطناعي المحلي فعله فعليًا؟

يصبح ربط جهاز محمول بنموذج لغوي كبير أكثر إثارة للاهتمام عندما يستطيع النموذج فعل ما هو أكثر من الإجابة عن سؤال. يوضّح JBlanked الخادمَ المدعوم بالذكاء الاصطناعي باعتباره جزءًا من سير عمل لتطوير الأنظمة المضمّنة.

إنشاء تطبيقات Picoware

يتضمن Picoware سياق App Creator لوكيل الذكاء الاصطناعي. ويتيح ذلك للمطوّر وصف تطبيق أو تغيير باستخدام اللغة الطبيعية، والاستعانة بالنموذج للمساعدة في إنشاء تطبيق Picoware المطابق أو تعديله.

في العرض التوضيحي، يُطلب من App Creator إنشاء تطبيق بسيط يعرض التحية «hello from youtube» عند تشغيله. يعيد الوكيل وصفًا منظمًا للسلوك المطلوب وكيفية عمل الواجهة.

يعمل App Creator من Picoware على PicoCalc. ينفّذ الوكيل طلبًا لإنشاء تطبيق يعرض «hello from youtube»، بينما يوجد Flipper Zero وCardputer-ADV بجوار الجهاز.

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

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

فحص البرمجيات الثابتة ومعلومات التطوير

يمكن أيضًا استخدام سير عمل الوكيل كمساعد للتطوير. فبدلًا من التعامل مع الجهاز المحمول باعتباره عميل محادثة تقليديًا، يستطيع النظام دمج استجابات النموذج المحلي مع المعلومات التي يوفّرها الجهاز وبرمجياته الثابتة.

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

إدارة الجهاز

يتضمن إطار عمل الوكيل في Picoware أيضًا وظائف لإدارة الأجهزة. ويمكن للنموذج العمل من خلال الأدوات التي توفّرها البرمجية الثابتة، بدلًا من الاكتفاء بإرجاع نص ينفّذه المستخدم يدويًا.

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

مدير أجهزة Picoware على PicoCalc يجيب عن السؤال «كم عدد الشبكات القريبة؟». تعرض الواجهة ست شبكات Wi-Fi قريبة، موضحةً كيف يمكن للوكيل الجمع بين الذكاء الاصطناعي المحلي والمعلومات التي يحصل عليها من الجهاز.

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

لماذا يُعدّ خادم ذكاء اصطناعي محلي مشترك مفيدًا للأجهزة الصغيرة

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

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

واجهة خلفية واحدة للذكاء الاصطناعي، وأجهزة متعددة للصنّاع

من الأفكار الأكثر فائدة في تجربة JBlanked أن ZimaBoard 2 ليس مرتبطًا بواجهة أمامية واحدة. إذ يمكن لـ PicoCalc وCardputer-ADV المشاركة عبر Picoware، بينما يستطيع Flipper Zero التواصل مع بيئة الذكاء الاصطناعي المحلية نفسها من خلال سير عمل الشبكات الخاص به.

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

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

ما الذي تُثبته هذه التجربة—وما الذي لا تُثبته

يُعدّ مشروع JBlanked عرضًا مفيدًا لكيفية دمج الذكاء الاصطناعي المحلي في التطوير المضمّن، لكن من المهم التمييز بين بنية النظام والضمانات المتعلقة بالأداء أو الأمان.

محلي لا يعني انعدام الإعداد

يؤدي تشغيل Ollama محليًا إلى إلغاء الحاجة لإرسال كل طلب استدلال إلى خدمة روبوت محادثة مستضافة، لكن النظام الكامل لا يزال يحتاج إلى تخطيط اعتيادي للخادم والشبكة.

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

يُعد إعداد المُسرّع مهمًا أيضًا. تحتوي بطاقة RTX 3060 الظاهرة في لوحة معلومات ZimaOS الخاصة بـJBlanked على ذاكرة VRAM بسعة 12GB، لذا يجب أن يراعي اختيار النموذج ذاكرة GPU المتاحة، ودعم بيئة التشغيل، ومتطلبات الأداء لحِمل العمل المستهدف.

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

من ينبغي له التفكير في إعداد كهذا؟

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

قد يكون مفيدًا لـ:

• مطوّرو Cardputer وPicoCalc الذين يبنون تطبيقات Picoware.
• مستخدمو Flipper Zero الذين يجرّبون أدوات متصلة بالشبكة.
• المطورون المضمنون الذين يريدون مساعدة الذكاء الاصطناعي بالقرب من أجهزتهم الاختبارية.
• مستخدمو المختبرات المنزلية الذين يبحثون عن مهمة عملية إضافية لخادم محلي.
• الصانعون الذين يريدون مشاركة عدة أجهزة منخفضة استهلاك الطاقة لخلفية ذكاء اصطناعي واحدة.

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

يصبح نهج ZimaBoard 2 أكثر إقناعًا عندما يكون الهدف إبقاء خدمة الذكاء الاصطناعي داخل مختبرك المنزلي نفسه وإتاحة هذه الخدمة لعدة مشاريع مستقلة.

أنشئ محورًا للذكاء الاصطناعي المحلي في مختبرك المخصص للصنّاع

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

مع استضافة ZimaOS لـ Ollama على ZimaBoard 2، وتوفير Picoware لواجهة مدعومة بالذكاء الاصطناعي لأجهزة مثل PicoCalc وCardputer-ADV، وسير عمل قادر على الاتصال بالشبكة يضم Flipper Zero في البيئة نفسها، يتحول النظام إلى محور مرن للذكاء الاصطناعي المحلي من أجل التجارب المضمنة.

توضح العروض التوضيحية الأربعة أيضًا سبب ضرورة تقييم الخادم كنظام متكامل. توفر الأجهزة المحمولة الواجهات والوظائف الخاصة بالعتاد، بينما يوفر Ollama طبقة تقديم النموذج، وتوفر وحدة معالجة الرسومات الظاهرة في ZimaOS موارد حوسبة إضافية لحمل الذكاء الاصطناعي المحلي.

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

شاهد الفيديو الكامل لـ JBlanked لرؤية الإعداد وسير عمل الجهاز مباشرةً، أو استكشف مشروع Picoware على GitHub إذا أردت فهم كيفية تكامل الوكيل والأجهزة المدعومة.

هل تريد رؤية ما يفعله منشئون آخرون باستخدام خوادم مدمجة وذكاء اصطناعي محلي وعتاد غير مألوف؟ انضم إلى مجتمع ZimaSpace على Discord لاستكشاف المزيد من المشاريع، ومقارنة الإعدادات، ومشاركة تجاربك الخاصة.