تصدير Hailo لنماذج Ultralytics YOLO#

تشغّل مسرّعات الذكاء الاصطناعي Hailo نماذج Hailo Executable Format (HEF) المترجمة على الأجهزة الطرفية مثل AI HAT+ وAI HAT+ 2 على Raspberry Pi. وتصدّر Ultralytics نماذج YOLO لاكتشاف الأجسام وتقسيمها والتقسيم الدلالي وتقدير العمق والتصنيف وتقدير الوضعية وOBB مباشرةً إلى HEF باستخدام Hailo Dataflow Compiler (DFC).

صُمِّم النشر على Hailo للرؤية الحاسوبية على الأجهزة الطرفية: الكاميرات والروبوتات والأنظمة الصناعية والبوابات والأجهزة الأخرى التي تحتاج إلى كشف الأجسام محليًا من دون إرسال كل إطار إلى السحابة. يحتوي ملف HEF المُصرَّف على الشبكة المكمَّمة وتخصيص العتاد والجدولة ومعالجة HailoRT اللاحقة الاختيارية اللازمة للمسرّع المحدد.

لماذا تنشر Ultralytics YOLO على Hailo؟#

يوفر الجمع بين Ultralytics YOLO ووحدة معالجة عصبية من Hailo (NPU) مسارًا عمليًا للانتقال من تدريب النماذج إلى الاستدلال بالذكاء الاصطناعي الطرفي. تشمل حالات الاستخدام الشائعة ما يلي:

• الكاميرات الذكية وتحليلات الفيديو: شغّل كشف الأجسام في الزمن الحقيقي بالقرب من الكاميرا لتطبيقات الأمن والتجزئة وحركة المرور وإشغال الأماكن.
• الروبوتات والأنظمة المستقلة: اكتشف الأشخاص والمركبات والطرود والأدوات أو العوائق من دون الاعتماد على اتصال سحابي مستمر.
• الرؤية الحاسوبية الصناعية: انشر نماذج YOLO مخصصة للفحص والعد ومراقبة السلامة ومراقبة الجودة.
• مشروعات Raspberry Pi للذكاء الاصطناعي: أضف استدلالًا بصريًا مُسرَّعًا إلى أنظمة Raspberry Pi باستخدام AI HAT+ أو AI HAT+ 2.
• البوابات الطرفية وحواسيب الذكاء الاصطناعي: عالج تدفقات فيديو أو مستشعرات متعددة محليًا مع تقليل متطلبات النطاق الترددي والحوسبة السحابية.

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

آلية عمل التصدير إلى Hailo#

تتولى Ultralytics سير عمل التصدير الكامل وراء format="hailo":

YOLO (.pt) -> ONNX -> Hailo parse -> INT8 optimization -> HEF compile

ينفّذ المُصدِّر المراحل التالية تلقائيًا:

1. يصدّر رسمًا بيانيًا ثابتًا لـ ONNX بإعدادات متوافقة مع المترجم.
2. يحدد مخرجات الرأس الخاصة ببنية النموذج.
3. ينشئ توجيهات التطبيع والتنشيط والمعالجة اللاحقة.
4. ينشئ تدفق معايرة تمثيليًا ويكمّم النموذج إلى INT8.
5. يُصرّف الرسم البياني المحسّن للمسرّع المحدد من Hailo.
6. يحفظ ملف HEF مع بيانات Ultralytics الوصفية ويحذف ملف ONNX الوسيط.

تستخدم نماذج الكشف YOLOv8 وYOLO11 تقنية HailoRT YOLO NMS في مسار العمل المُصرَّف. يصرّف YOLO26 موترات رأس الكشف الخام: تطبق Ultralytics تقنية NMS على المخرجات الافتراضية من نوع one-to-many، أو تفك ترميز مخرجات one-to-one الخالية من NMS باستخدام nms=False. وتصرّف نماذج التجزئة والوضعية وOBB في YOLOv8/YOLO11 موترات الرأس الخام، التي تفك Ultralytics ترميزها أثناء الاستدلال، بينما تشغّل نماذج التصنيف YOLOv8/YOLO11/YOLO26 دالة softmax على الشريحة، بحيث يعيد ملف HEF احتمالات الفئات مباشرة. بالنسبة إلى التجزئة الدلالية في YOLO26، يتبع المُصدِّر إمكانات المسرّع: يعيد Hailo-8/8L (DFC v3.x) قيم logits للمُصنِّف لإجراء رفع الدقة والاختزال على المضيف، بينما يصرّف Hailo-10H/15 (DFC v5.x) رؤوس ArgMax متعددة الفئات على الشريحة ويعيد خريطة فئات مضغوطة. تستخدم الرؤوس أحادية الفئة مسار logits على المضيف في جميع الأهداف، لأنها تتطلب عتبة بدلًا من ArgMax. وتصرّف نماذج العمق YOLO26 طبقة الالتفاف الكثيفة لـ logits في a16، ثم تعيد بناء خريطة العمق المترية على المضيف (عمليتا clamp/exp ومعايرة log-affine المتعلّمة اللتان تليان الرأس)، بحيث يحتفظ المُكمِّم بأوسع نطاق لقيمة logits الخام. لا يحتاج المستخدمون إلى البحث عن عقد النهاية في ONNX أو كتابة برنامج نصي لنموذج Hailo (.alls) أو إنشاء ملف JSON يدويًا لـ NMS.

التثبيت#

ثبّت Ultralytics ونزّل حزمة DFC wheel للعتاد المستهدف من Hailo Developer Zone (يتطلب التسجيل المجاني):

pip install ultralytics
pip install /path/to/hailo_dataflow_compiler-*.whl

يستخدم Hailo-8 وHailo-8L الإصدار DFC v3.x. ويستخدم Hailo-10H وHailo-15 الإصدار DFC v5.x. ثبّت جيل المترجم المطابق للمسرّع المستهدف.

تصدير نموذج Hailo HEF#

استخدم format="hailo" وحدد المسرّع المستهدف باستخدام name:

from ultralytics import YOLO

model = YOLO("yolo11n.pt")
output = model.export(format="hailo", name="hailo8")
print(output)  # yolo11n_hailo_model/

أمر CLI المكافئ هو:

yolo export model=yolo11n.pt format=hailo name=hailo8

يقتصر التصدير إلى Hailo على INT8. وتُنزّل Ultralytics تلقائيًا مجموعة بيانات معايرة خاصة بالمهمة عندما لا يتم توفير data. بالنسبة إلى النماذج المخصصة، استخدم صورًا تمثيلية من التدريب أو التحقق:

model.export(format="hailo", name="hailo8", data="path/to/dataset.yaml")

يستخدم التصريف شكل إدخال ثابتًا. اضبط imgsz على الدقة المستخدمة على الجهاز:

model.export(format="hailo", name="hailo8", imgsz=640)

النماذج والعتاد المدعومان#

يغطي نظام Hailo مجموعة واسعة من أعباء عمل الرؤية الحاسوبية، لكن مُصدِّر Ultralytics format="hailo" يتحقق حاليًا من رؤوس YOLO القياسية للكشف والتجزئة والتجزئة الدلالية وتقدير العمق والتصنيف والوضعية وOBB. يصف جدول المهام مسارات المُصدِّر المتاحة؛ ويُدرج التحقق من العتاد أدناه على نحو منفصل.

عائلات الكشف المتخصصة مثل YOLOv10 وYOLO-World وYOLOE وRT-DETR غير مدعومة حاليًا ❌ عبر مسار format="hailo" في Ultralytics. ترفض Ultralytics هذه المهام وعائلات النماذج قبل التصريف بدلًا من إنتاج ملف HEF لم يتم التحقق من صلاحيته.

تم التحقق من الوضعية وOBB والتصنيف والتجزئة الدلالية في YOLO26 وتقدير العمق في YOLO26 (مسار Hailo-8/8L) على Hailo-8L باستخدام HailoRT 4.23 وDFC 3.33. يقبل المُصدِّر الأهداف الأخرى المدرجة، لكن مسارات المهام الجديدة هذه تتطلب التحقق باستخدام المترجم والجهاز المطابقين قبل استخدامها في الإنتاج.

حدد إحدى قيم name التالية:

إذا لم يتم تحديد name، فستُستخدم hailo8l افتراضيًا؛ اضبط name على المسرّع الذي ستنشر عليه. ثبّت جيل DFC المطابق للهدف المحدد.

أجيال عتاد Hailo وSDK#

تستخدم عائلات مسرّعات Hailo أجيالًا مختلفة من المترجمات. يجب أن يتوافق ملف HEF الناتج مع العتاد المستهدف، لذا اختر name للجهاز الذي سيشغّل الاستدلال، لا للجهاز الذي ينفّذ التصدير.

يعمل المترجم على Linux x86_64، بينما يعمل ملف HEF الناتج على جهاز Hailo عبر HailoRT. يتيح هذا الفصل إجراء التصريف على محطة عمل أو عبر منصة Ultralytics، ثم نشر مُنتَج التشغيل الصغير على مضيف طرفي من نوع ARM أو x86.

ملاحظات التوافق#

يتخصص تصريف Hailo في العتاد ويستخدم شكل إدخال ثابتًا. ضع القيود التالية في الحسبان:

• يجب أن يطابق name المحدد مسرّع النشر.
• ينبغي أن تمثل صور المعايرة ظروف الإضاءة ووجهات النظر والأجسام والخلفيات المتوقعة في بيئة الإنتاج.
• يُصرّف كل ملف HEF وفق imgsz ثابت. لمعالجة دقات متعددة، غيّر حجم الإطارات على المضيف إلى الحجم المُصرَّف أو صرّف ملف HEF منفصلًا لكل دقة.
• تُدعم أعداد الفئات المخصصة، لأن Ultralytics تنشئ إعدادات المعالجة اللاحقة من البيانات الوصفية للنموذج.
• تُدعم نماذج الكشف ذات رؤوس Detect القياسية في Ultralytics، ونماذج التجزئة والوضعية وOBB في YOLOv8/YOLO11، ونماذج التصنيف في YOLOv8/YOLO11/YOLO26، ونماذج التجزئة الدلالية وتقدير العمق في YOLO26؛ أما تجزئة الكائنات والوضعية والصندوق المحيط الموجّه في YOLO26، إلى جانب عمليات التصدير لـ YOLO-World وYOLOE وYOLOv10 وRT-DETR، فغير مدعومة حاليًا.
• تُصرّف ملفات Hailo-8/8L وHailo-10H/15 باستخدام أجيال DFC مختلفة، ولا يمكن استخدام أحدها بدل الآخر.

المعايرة والتكميم إلى INT8#

يستخدم تصدير Hailo HEF التكميم إلى INT8 لملاءمة شبكة YOLO بكفاءة مع المسرّع. تقدّر مجموعة بيانات المعايرة نطاقات التنشيط؛ ولا تعيد تدريب النموذج أو تتطلب تسميات أثناء التصريف.

عند حذف data، تستخدم Ultralytics مجموعة بيانات معايرة خفيفة خاصة بالمهمة، مثل COCO128 للكشف، وcityscapes8 للتجزئة الدلالية، أو depth8 لتقدير العمق. ويُعدّ رأس العمق الكثيف حساسًا بوجه خاص لنطاق المعايرة: فمعايرة نموذج عمق بصور كشف غير ذات صلة تؤدي إلى تسطيح الخريطة المتوقعة، بينما تحسّن المجموعات الأكبر من الصور المنتمية إلى النطاق نفسه دقة النتائج. بالنسبة إلى نموذج رؤية حاسوبية مخصص، وجّه data إلى YAML مجموعة بيانات النموذج ليعاين المُصرِّف صورًا تمثيلية من نطاق النشر الفعلي:

model.export(format="hailo", name="hailo8", data="my_dataset.yaml")

يحدد fraction النسبة أو عدد الصور المستخدمة للمعايرة. تحدد قوائم [train, val, test] حدًا لكل تقسيم، وتُبقي القوائم ذات العنصرين test كاملًا، بينما يتخطى 0 الاختبار. لا تفيد زيادة الصور إلا إذا كانت تمثل نطاق النشر. قد تؤدي الصور الخارجة عن النطاق إلى خفض الدقة بعد التكميم وزيادة وقت التحسين. إذا فقد HEF بدقة INT8 دقته مقارنةً بنموذج PyTorch الأصلي، فحسّن بيانات المعايرة أولًا قبل تغيير إعدادات النموذج أو بيئة التشغيل.

توقعات الدقة حسب عائلة النموذج#

عند القياس على Hailo-8L باستخدام معايرة من النطاق نفسه (COCO128، 128 صورة)، تحتفظ صادرات HEF بدقة INT8 بالنسب التالية من mAP50 لنماذج PyTorch، وفق بروتوكول التقييم نفسه:

تقارن نسبة الاحتفاظ بالنموذجين عند عتبة الثقة نفسها. تُضمّن ملفات HEF لـ YOLOv8 وYOLO11 قيمة conf وقت التصدير (الافتراضية 0.25) في NMS على الشريحة، لذا فإن التحقق بمقارنة خط أساس PyTorch عند عتبته الافتراضية المنخفضة يدمج جزءًا أكبر من منحنى الدقة والاستدعاء ويبالغ في تقدير فجوة التكميم.

إلى جانب الكشف، جرى التحقق من مسارات التصدير الخاصة بالتجزئة وتقدير الوضعية وOBB والتصنيف على الجهاز Hailo-8L نفسه (DFC 3.33، HailoRT 4.23). وقورن كل ملف HEF بدقة INT8 بنقطة تحقق PyTorch الخاصة به على تقسيم التحقق نفسه، باستخدام معايرة من النطاق نفسه:

جرت معايرة التجزئة وتقدير الوضعية وOBB باستخدام مجموعة البيانات الافتراضية لكل مهمة من النطاق نفسه (COCO128-seg وCOCO8-pose وDOTA128)؛ أما التصنيف فتمت معايرته باستخدام ImageNet100. وينبغي مراعاة نقطتين ناتجتين عن هذه الإعدادات الافتراضية: لا يضم COCO8-pose سوى 8 صور، لذا اعتبر نتائج تقدير الوضعية استرشادية واستخدم data= أكبر للإنتاج، كما أن DOTA8 يصل إلى تشبع mAP50 قرب 100% لكلا النموذجين، ولهذا يُقيّم OBB باستخدام DOTA128. والتصنيف هو المهمة الوحيدة التي يحتفظ فيها YOLO11 بنتائج أفضل من YOLOv8؛ أما في المهام الأخرى، فالعمود الفقري Attention في YOLO11 أكثر حساسية لـ INT8.

تُستخلص ثلاث قواعد عملية من قياسات الجهاز:

1. عاير باستخدام بيانات من النطاق نفسه دائمًا. إن الضبط الدقيق باستخدام صور من خارج النطاق يعادل تعطيل الضبط الدقيق تمامًا: إذ يحتفظ YOLO26n، عند معايرته باستخدام 1,238 صورة من خارج النطاق، بالدقة نفسها (85.7%) التي يحققها عند تصريفه دون ضبط دقيق. مجموعة صغيرة من النطاق نفسه أفضل من مجموعة كبيرة من خارجه.
2. اخفض conf بنحو 0.05 عند نشر YOLO26. يخفض التكميم درجات YOLO26 بنحو 0.05 في المتوسط، لذا فإن العتبة المضبوطة في PyTorch تُسقط اكتشافات صحيحة عند تشغيل HEF. يؤدي استخدام conf=0.20 على الجهاز إلى مطابقة عدد الاكتشافات في PyTorch عند conf=0.25، كما أن الخفض قليلًا أكثر (إلى نحو conf=0.15) يستعيد فعليًا كامل فجوة mAP50 المتبقية، على حساب زيادة الاكتشافات منخفضة الثقة. يعيد التكميم أيضًا ترتيب نحو 20% من الاكتشافات، وهو أثر دائم في ترتيبها لا تعالجه أي عتبة؛ لكن إعادة الترتيب هذه لا تحول دون استعادة mAP50 عند العتبة الأقل.
3. عقوبة Attention بنيوية على Hailo-8/8L (DFC 3.33). تُصرَّف كتل Attention إلى عمليات matmul تُبقي مدخلات التنشيط بدقة INT8 في كل وضع يتيحه المُصرِّف لها؛ ويفشل وضع خرج 16 بت في تخصيص الذاكرة لهذا المخطط، كما أن رفع دقة الطبقات المحيطة لا يفيد، لأن عملية الضرب المصفوفي تعيد تكميم مدخلاتها إلى INT8 على أي حال (لم يؤدِّ الحفاظ على الالتفافات العمقية والخرج بدقة 16 بت إلى تغيير mAP في اختباراتنا). عندما تكون الدقة هي الأولوية ويكون بالإمكان استبدال النموذج، يحقق YOLO11 حاليًا تكميمًا أفضل من YOLO26 على هذا الجهاز؛ أما أجيال Hailo الأحدث (DFC 5.x) فتتيح خيارات أكثر للدقة المختلطة، وقد تختلف نتائجها.

الملفات المُصدَّرة#

ينشئ التصدير مجلدًا يحتوي على ملف HEF القابل للنشر وبيانات Ultralytics الوصفية:

yolo11n_hailo_model/
├── yolo11n.hef
├── metadata.yaml
└── nms_config.json

• *.hef هو النموذج المُصرَّف الذي يحمّله HailoRT.
• يحفظ metadata.yaml أسماء النموذج والمهمة وحجم الإدخال والخطوة ومعلومات هدف Hailo.
• يسجل nms_config.json إعدادات NMS المُنشأة لـ HailoRT في نماذج الكشف YOLOv8 وYOLO11. لا تستخدم نماذج الكشف YOLO26 وجميع المهام غير المتعلقة بالكشف (التجزئة، والدلالية، والعمق، والتصنيف، وتقدير الوضعية، وOBB) هذا الملف.

تُحذف مخططات ONNX الوسيطة بعد التصريف.

تشغيل الاستدلال على أجهزة Hailo#

ثبّت HailoRT على الجهاز المستهدف. يمكن لمستخدمي Raspberry Pi AI HAT+ وAI HAT+ 2 اتباع دليل برمجيات Raspberry Pi AI. لا يمكن تثبيت مجموعتي الحزم معًا على Raspberry Pi OS، لذا شغّل الكتلة المطابقة لأجهزتك فقط، ثم أعد التشغيل.

لـ AI HAT+ (Hailo-8 / Hailo-8L):

sudo apt install dkms
sudo apt install hailo-all
sudo reboot

لـ AI HAT+ 2 (Hailo-10H، أو Raspberry Pi OS Trixie أو إصدار أحدث):

sudo apt install dkms
sudo apt install hailo-h10-all
sudo reboot

بعد إعادة التشغيل، تحقق من اكتشاف المسرّع:

hailortcli fw-control identify

انسخ مجلد التصدير كاملًا إلى الجهاز كي يبقى metadata.yaml بجوار HEF. تستخدم Ultralytics HailoRT لتشغيل predict وval مباشرةً من مجلد التصدير:

from ultralytics import YOLO

model = YOLO("yolo11n_hailo_model")
results = model.predict("path/to/image.jpg")

بالنسبة إلى نماذج الكشف، تحوّل الواجهة الخلفية مخرجات NMS في HailoRT الخاصة بـ YOLOv8/YOLO11 وتفك ترميز أيٍّ من رأسي YOLO26 تلقائيًا. وتمر مخرجاتها الافتراضية من نمط واحد إلى متعدد عبر NMS الخاص بالمُتنبئ. كما تفك ترميز موترات التجزئة وتقدير الوضعية وOBB الخام، وتعيد احتمالات التصنيف المحسوبة على الشريحة، وتنشئ خرائط الفئات الدلالية عبر الاختزال على المضيف في Hailo-8/8L ولجميع الرؤوس أحادية الفئة، أو عبر ArgMax على الشريحة لرؤوس Hailo-10H/15 متعددة الفئات. وتظل TAPPAS وGStreamer وأداة picamera2.devices.Hailo المساعدة في Raspberry Pi متاحة لمسارات العمل الخاصة بالتطبيقات.

لنشر GStreamer، مرّر HEF إلى hailonet:

gst-launch-1.0 filesrc location=video.mp4 ! decodebin ! videoconvert ! \
  hailonet hef-path=yolo11n_hailo_model/yolo11n.hef ! \
  hailofilter function-name=yolov8 ! hailooverlay ! autovideosink

خيارات النشر على Hailo#

يُعد HEF ملف النموذج القابل للنشر نفسه عبر عدة واجهات تشغيل من Hailo. اختر الواجهة التي تناسب التطبيق:

أبقِ metadata.yaml مع HEF عندما يحتاج التطبيق إلى أسماء الفئات أو حجم الإدخال أو الخطوة أو معلومات النموذج الأخرى الخاصة بـ Ultralytics. ولا يحل HEF نفسه محل منطق التطبيق الخاص بالتقاط الصور من الكاميرا أو التصور أو التتبع أو التنبيهات أو التخزين.

التحقق من جهاز Hailo وملف HEF#

قبل دمج كاميرا أو مسار فيديو، تحقّق من بيئة التشغيل والمسرّع كلٍّ على حدة:

hailortcli fw-control identify
hailortcli parse-hef yolo11n_hailo_model/yolo11n.hef

تعزل قياسات الأداء الخاصة بالجهاز استدلال Hailo عن فك ترميز الفيديو وتغيير حجم الصور والرسم وإدخال/إخراج التطبيق. قِس التطبيق كاملًا على نحو منفصل عند تقدير زمن الاستجابة من البداية إلى النهاية أو عدد الإطارات في الثانية.

المعايير المرجعية#

أجرى فريق Ultralytics قياسًا معياريًا لنماذج YOLO26، وقارن السرعة والدقة بين PyTorch وHailo.

الأداء

Raspberry Pi 5 + AI HAT+ (Hailo-8)ستتوفر أجهزة أخرى قريبًا!

النموذج	التنسيق	الحالة	الحجم (MB)	metrics/mAP50-95(B)	وقت الاستدلال (ms/im)
YOLO26n	PyTorch	✅	5.3	0.477	364.6
YOLO26n	Hailo	✅	7.3	0.455	21.7

النموذج	التنسيق	الحالة	الحجم (MB)	metrics/mIoU	وقت الاستدلال (ms/im)
YOLO26n-sem	PyTorch	✅	3.3	0.611	831.2
YOLO26n-sem	Hailo	✅	6.2	0.611	34.8

النموذج	التنسيق	الحالة	الحجم (MB)	metrics/delta1	metrics/abs_rel	metrics/rmse	وقت الاستدلال (ms/im)
YOLO26n-depth	PyTorch	✅	12.4	0.8535	0.0983	0.2047	2133.4
YOLO26n-depth	Hailo	✅	9.9	0.8241	0.1232	0.2554	29.6

النموذج	التنسيق	الحالة	الحجم (MB)	acc (top1)	acc (top5)	وقت الاستدلال (ms/im)
YOLO26n-cls	PyTorch	✅	5.5	0.431	0.716	33.8
YOLO26n-cls	Hailo	✅	3.5	0.441	0.716	2.0

ملاحظة

أُجري التحقق من صحة المعايير المذكورة أعلاه باستخدام COCO128 للكشف، وCityscapes8 للتجزئة الدلالية، وDepth8 لتقدير العمق، وImageNet100 للتصنيف. لا تحتوي Cityscapes8 وDepth8 إلا على 4 صور تحقق لكل منهما، لذا ينبغي اعتبار قيم دقة التجزئة الدلالية وتقدير العمق نتائج لاختبار أولي، لا قياسات للاحتفاظ بالدقة؛ تحقّق من النتائج باستخدام مجموعة بيانات كاملة مثل Cityscapes أو NYU Depth V2 قبل استخلاص استنتاجات بشأن الدقة. لا يشمل زمن الاستدلال المعالجة المسبقة أو اللاحقة.

مقارنة Hailo بصيغ تصدير YOLO الأخرى#

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

لا تفترض أن Hailo أسرع أو أكثر كفاءة في استهلاك الطاقة لمجرد كونه NPU. بالنسبة إلى عمليات النشر الجديدة من نوع M.2، يُعد DeepX خيارًا أقوى لتحقيق أداء أعلى مع YOLO وأداء أفضل لكل واط، بينما تستهدف Axelera إنتاجية أعلى بكثير للتدفقات المتعددة. ويُعد Rockchip خيارًا شائعًا أقل تكلفة عبر SBCs والأنظمة المضمنة. لا يمكن مقارنة أرقام TOPS والطاقة التي يعلنها الموردون مباشرةً بوصفها معايير أداء للتطبيقات، لذا تحقّق من الأجهزة المرشحة قبل الشراء باستخدام نقطة تحقق YOLO نفسها وحجم الإدخال والدقة والمضيف ومسار الفيديو الكامل.

تحسين أداء الرؤية الحاسوبية على Hailo#

غالبًا ما يكون لاختيارات النموذج ومسار العمل أثر أكبر من أعلام المُصرِّف:

• ابدأ بنموذج YOLO صغير، ولا تزد حجم النموذج إلا عندما تتطلب الدقة ذلك.
• اختر أدنى قيمة ثابتة لـ imgsz تضمن الحفاظ على الأجسام المهمة للتطبيق.
• استخدم صور معايرة من الكاميرا والبيئة الفعليتين متى أمكن.
• أبقِ شبكة Hailo نشطة عبر الإطارات بدلًا من إعادة فتح HEF مع كل استدلال.
• افصل زمن استدلال الجهاز عن المعالجة المسبقة وفك ترميز الفيديو والمعالجة اللاحقة والتصور وإدخال/إخراج الشبكة.
• استخدم مسار معالجة متدفقًا مثل GStreamer لأحمال الفيديو المستمرة.
• تحقّق من صحة ملف HEF المُصدَّر على المسرّع وإصدار HailoRT نفسيهما المستخدمين في بيئة الإنتاج.

وسيطات التصدير#

تحصل صادرات الكشف في YOLOv8/YOLO11 على HailoRT NMS. يستخدم YOLO26 افتراضيًا مخرجات خامًا من نوع one-to-many لإجراء NMS على المضيف؛ ويحدد nms=False مخرجاته one-to-one الخالية من NMS. تستخدم مهام التقسيم والتقدير الوضعي وOBB موترات الرأس الخام، ويعيد التصنيف احتمالات محسوبة على الشريحة، بينما يعيد التقسيم الدلالي القيم اللوغاريتمية الخام على Hailo-8/8L وجميع الرؤوس أحادية الفئة، أو خرائط الفئات المضمّنة للرؤوس متعددة الفئات في Hailo-10H/15. يعيد تقدير العمق القيمة اللوغاريتمية الخام للعمق، التي تفكّها Ultralytics إلى خريطة عمق مترية أثناء الاستدلال. لا تُدعم الأشكال الديناميكية أو NMS المضمّن من Ultralytics أو FP16 أو FP32.

استكشاف أخطاء تصدير Hailo وإصلاحها#

خطأ استيراد Hailo Dataflow Compiler#

إذا أفاد التصدير بأن hailo_sdk_client غير موجود، فثبّت حزمة DFC بصيغة wheel الخاصة بجيل العتاد المستهدف في بيئة Python نفسها التي تستخدمها Ultralytics. يتطلب Hailo-8/8L وHailo-10H/15 جيلين مختلفين من المترجم.

نظام التشغيل أو البنية غير المدعومين#

يُدعم تجميع HEF على Linux x86_64. أجرِ التصدير عبر منصة Ultralytics أو استخدم محطة عمل متوافقة إذا كان جهازك المحلي يعمل بنظام macOS أو Windows أو Raspberry Pi أو نظام ARM آخر.

يستغرق التصدير وقتًا طويلًا#

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

انخفاض دقة النموذج المُكمَّم#

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

تعذّر تحميل HEF على الجهاز#

تأكد من أن name يطابق بنية Hailo الفعلية، وأن حزم برنامج تشغيل الجهاز والبرامج الثابتة وHailoRT متوافقة فيما بينها. افحص الملف باستخدام hailortcli parse-hef وتحقق من المسرّع باستخدام hailortcli fw-control identify.

يبدو تحليل المخرجات غير صحيح#

احتفظ بـ metadata.yaml بجوار ملف HEF حتى تتمكن Ultralytics من اختيار مسار المعالجة اللاحقة المطابق لـ YOLOv8 أو YOLO11 أو YOLO26. يجب أيضًا أن تطابق تطبيقات HailoRT المخصصة المعالجة اللاحقة لعائلة النموذج المُصدَّر.

الملخص#

يوفر تصدير Ultralytics إلى Hailo مسارًا مباشرًا من نموذج YOLO المدرَّب إلى ملف HEF جاهز للنشر:

1. حمّل نموذج كشف أو تصنيف YOLOv8 أو YOLO11 أو YOLO26، أو نموذج تقسيم أو تقدير وضعي أو OBB من YOLOv8/YOLO11، أو نموذج تقسيم دلالي أو تقدير عمق من YOLO26.
2. صدّر باستخدام format="hailo" وحدد البنية المستهدفة.
3. أجرِ المعايرة والتجميع محليًا باستخدام DFC المطابق، أو استخدم التصدير المُدار في منصة Ultralytics.
4. انسخ HEF وmetadata.yaml إلى جهاز الحافة المزوّد بـ Hailo.
5. شغّل الاستدلال باستخدام HailoRT أو Raspberry Pi Picamera2 أو مسار فيديو GStreamer.

للاطلاع على أهداف نشر أخرى للرؤية الحاسوبية، راجع وضع التصدير ووضع قياس الأداء ودليل التكاملات. تشمل أدلة العتاد ذات الصلة DeepX وAxelera وONNX وOpenVINO وTensorRT وNCNN وRKNN وSony IMX500 وQualcomm QNN.

الأسئلة الشائعة#