esp32-eye: مراقب وعاء ماء القطط الذي يستدعي MiniCPM-V 4.7 مرتين

تحتفظ الآن لوحتان من ESP32-S3، وحاسوب MacBook واحد، وحجمان مختلفان من MiniCPM-V 4.7 بسجل لأي قطة شربت من وعاء الماء ومتى. تراقب لوحة كاميرا الوعاء، ويشغّل MacBook النموذج الصغير محليًا للإجابة عن سؤال واحد محدّد، ولا يُستدعى النموذج الكبير إلا بعد وقوع حدث بالفعل. يُسمى هذا البناء esp32-eye، ويوجد على github.com/emwstudio/esp32-eye، وأُتيح للعموم في 25 أكتوبر 2026. عرضته OpenBMB في الأسبوع الأول من نوفمبر، وهكذا تعرّف عليه معظم الناس.

النموذج الأساسي هو الجزء الذي يستحق الدقة بشأنه. رفعت OpenBMB نموذج MiniCPM-V 4.7 إلى Hugging Face في 6 و7 أكتوبر 2026، ونشرت بطاقة النموذج ورخصة Apache-2.0 في 12 أكتوبر، وأصدرت بيانًا صحفيًا بالإنجليزية عبر PR Newswire في 15 أكتوبر. لذا فليست هذه قصة إطلاق، ومراقب القطط ليس معيارًا من البائع. إنه أكثر تطبيق عام تفصيلًا للنموذج وثّقه أي شخص خارج المختبر حتى الآن، ويصادف أنه جهاز منزلي.

ما الذي يفعله البناء فعليًا

العتاد رخيص عمدًا وغير مريح قليلًا. تستقر كاميرا Waveshare ESP32-S3-CAM-OV5640 على حافة الوعاء وتبث إطارات JPEG بدقة 1024×768 إضافة إلى صوت الميكروفون عبر Wi-Fi. ولوحة ثانية، Waveshare ESP32-S3-Touch-AMOLED-2.16، هي شاشة المكتب: لوحة مقاس 480×480 تعرض شريط فيديو مباشرًا، وأربع بطاقات قطط، وعدًا يوميًا مقابل هدف قدره ثمانية مشروبات، وحركة إبراز صغيرة عند تأكيد قطة. والماك بوك هو العقل. يتلقى خادم FastAPI البث، ويشغّل منطق الكشف، ويكتب إلى SQLite، ويقتطع مقطع MP4 لكل حدث بخمس ثوانٍ تمهيدية، وثلاث ثوانٍ ختامية، والصوت الأصلي.

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

تُجرى قبل تشغيل أي نموذج عمليةُ مقارنة فرقٍ خلفيّ بتدرّج رمادي مقابل إطار مرجعي لِوعاء فارغ. فإذا كانت نسبة المساحة الأمامية أقل من 15 في المئة، يُستبعد الإطار دون مساس بأي شبكة عصبية. أما إذا تجاوزت 15 في المئة، يُسأل نموذج {{MiniCPM-V 4.7 1B}} المحلي سؤالاً واحداً: هل توجد قطة في هذه الصورة؟ والجواب الإيجابي مع نسبة مساحة أمامية تتجاوز 35 في المئة يُحتسب صوتاً مؤيداً واحداً. وثلاثة أصوات مؤيدة متتالية تفتح حدثاً؛ وأربعة أصوات سلبية متتالية تغلقه.

إنّ الفصل بين النموذجين هو الجانب الهندسي المثير للاهتمام

تشغيل نموذج رؤية كل 1.5 ثانية إلى الأبد فكرة سيئة، ونظام البناء يتعامل معها على هذا الأساس. يعمل نموذج 1B محليًا عبر llama.cpp بتكميم Q4_K_M على llama-server متوافق مع OpenAI على المنفذ 8080. إنه رخيص بما يكفي بحيث يستطيع المشروع تحمّل استدعائه مرارًا، لكنه لا يزال مقيّدًا بفارق الخلفية بحيث لا تكلّف الغرفة الفارغة شيئًا. وظيفة نموذج 1B ضيقة عمدًا: الحضور، لا الهوية، ولا السلوك.

الهوية هي السؤال المكلف، ويُطرح مرة واحدة لكل حدث. عندما يُغلق حدث ما، يأخذ الخادم عينات إطارات من المقطع ويرسلها إلى MiniCPM-V 4.7 35B-A3B عبر واجهة برمجة التطبيقات السحابية الخاصة بـ ModelBest، مع صورة مرجعية لكل واحدة من القطط الأربع. يعيد النموذج الكبير معرّف القطة، وقيمة ثقة، وإجابة نعم/لا حول ما إذا كان المشهد مشهد شرب. تُستبعد الإطارات التي تفشل في فحص الشرب ولا تُحتسب. تُخزَّن الهويات الملتبسة على أنها غير معروفة بدلاً من إجبارها على أقرب قطة، وإذا فشل استدعاء السحابة ينتقل الحدث إلى مسار إعادة المحاولة بدلاً من استكماله بأثر رجعي بتخمين النموذج 1B.

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

ما تُثبته أحداث 89 وما لا تُثبته

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

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

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

لماذا لا يتعرف 1B على القطة؟

يحتوي ملف README على الجملة الأكثر فائدة في المشروع بأكمله، وهي نتيجة سلبية: مع ثلاث قطط فاتحة اللون تتشابه فيما بينها، لم يكن MiniCPM-V 4.7 1B المحلي موثوقًا في اختيار واحد من أربعة. جرّب الفريق ذلك، فوجد أن التمييز الرباعي غير موثوق، ونقل تحديد الهوية إلى 35B بدلًا من شحن تخمين.

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

ما تكلفة تشغيله، وما يحدث عند تعطّل الجزء السحابي

مرحلة واحدة فقط من هذا المسار عليها فاتورة. الـ1B هو ملف GGUF محلي على حاسوب محمول، لذا فإن التكلفة الحدية للإطار هي الكهرباء. الـ35B هو استدعاء مستضاف عبر API الخاص بـModelBest، وهي نقطة النهاية الخاصة بالبائع نفسه لا مضيف طرف ثالث، ويحتاج المشروع إلى مفتاح من أجلها. يوضح README صراحةً أن الـ35B غير منشور محليًا: فجهاز MacBook لا يحمل 35 مليار معامل، بل يحمل عميلًا.

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

هذه هي الفجوة التي يسدّها الموجّه، ويستحق الأمر الدقة بشأن ما يمكن للموجّه فعله وما لا يمكنه فعله هنا. يمنح OrcaRouter واجهة API واحدة عبر أكثر من 200 نموذج مع تمرير سعر القائمة الخاص بالمزوّد بهامش ربح 0%، إضافة إلى التحويل التلقائي عند الفشل بين المزوّدين، وهو الشكل المناسب لخط أنابيب مثل هذا. لا يحمل حاليًا MiniCPM-V 4.7، لذا فإن فرع 35B في esp32-eye سيظل يعمل على واجهة API الخاصة بالمورّد. الصيغة الصادقة للنصيحة هي: احتفظ بمسار إعادة المحاولة، وإذا أصبحت خطوة التحقق من الهوية أساسية، فضع نموذجًا ثانيًا يمكنك الوصول إليه فعليًا خلف الاستدعاء نفسه.

ما الذي لا يزال غير مؤكد؟

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

ما هو راسخ بالفعل أكثر تواضعًا وأكثر فائدة. يتوفر MiniCPM-V 4.7 بحجمين يمكن دمجهما: نموذج كثيف بسعة 1.55B يعمل داخل ملف Q4_K_M على حاسوب محمول، ومزيج خبراء متناثر بسعة 35.2B يفعّل نحو 3 مليارات معامل لكل رمز، وهو جيد بما يكفي في مهمة تحديد الهوية من بين أربعة خيارات ليُوثق به فيها. إن وعاء طعام القطط مكان غريب لإثبات ذلك، لكنه مكان حقيقي.

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