تصدير 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 ووحدة معالجة عصبية (NPU) من Hailo مسارًا عمليًا من تدريب النموذج إلى الاستدلال باستخدام الذكاء الاصطناعي على الحافة. وتشمل حالات الاستخدام الشائعة ما يلي:

• الكاميرات الذكية وتحليلات الفيديو: شغّل كشف الأجسام في الزمن الحقيقي بالقرب من الكاميرا لتطبيقات الأمن والتجزئة وحركة المرور وإشغال الأماكن.
• الروبوتات والأنظمة المستقلة: اكتشف الأشخاص والمركبات والطرود والأدوات أو العوائق من دون الاعتماد على اتصال سحابي مستمر.
• الرؤية الحاسوبية الصناعية: انشر نماذج 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_w16، ثم تعيد بناء خريطة العمق المترية على المضيف (عمليتا 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 بالنسب التالية من mAP₅₀ لنموذج 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 تُشبِع mAP₅₀ إلى ما يقارب 100% لكلا النموذجين، ولهذا تُقيَّم OBB على DOTA128. ويُعد التصنيف أيضًا المهمة الوحيدة التي يحتفظ فيها YOLO11 بأداء أفضل من YOLOv8؛ أما في المهام الأخرى، فعمود الانتباه في 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) يستعيد عمليًا كامل الفجوة المتبقية في mAP₅₀، مقابل زيادة الاكتشافات منخفضة الثقة. ويعيد التكميم أيضًا ترتيب نحو 20% من الاكتشافات — وهو أثر دائم على الترتيب لا تعالجه أي عتبة — لكن إعادة الترتيب هذه لا تحول دون استعادة mAP₅₀ عند العتبة الأقل.
3. عقوبة الانتباه بنيوية على Hailo-8/8L (DFC 3.33). تُترجم كتل الانتباه إلى عمليات matmul التي تُبقي مدخلات التنشيط INT8 في جميع الأنماط التي يوفرها المترجم لهذه العمليات؛ ويفشل نمط خرج 16 بت في تخصيص الموارد لهذا الرسم البياني، كما أن رفع دقة الطبقات المحيطة لا يفيد لأن عملية الضرب المصفوفي تعيد تكميم مدخلاتها إلى INT8 على أي حال (لم يؤدِ الحفاظ على الالتفافات العمقية وطبقات الخرج بدقة 16 بت إلى تغيير mAP في اختبارات Ultralytics). عندما تكون الدقة هي الأولوية ويمكن استبدال النموذج، يحقق 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 تلقائيًا؛ وتمر مخرجات YOLO26 الافتراضية من نوع one-to-many عبر 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 خيارًا شائعًا أقل تكلفة عبر الحواسيب أحادية اللوحة والأنظمة المضمنة. ولا يمكن مقارنة أرقام 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.

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