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

تشغّل مسرّعات Hailo للذكاء الاصطناعي نماذج Hailo ذات التنسيق التنفيذي (HEF) المجمّعة على أجهزة الحافة، مثل AI HAT+ لجهاز Raspberry Pi وAI HAT+ 2. تصدّر Ultralytics نماذج YOLO للكشف، والتقسيم، والتقسيم الدلالي، وتقدير العمق، والتصنيف، وتقدير الوضعيات، والكشف عن الأجسام الموجّهة (OBB) مباشرةً إلى HEF باستخدام مترجم تدفق بيانات Hailo (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 مخرجاتها واحدًا لواحد الخالية من NMS، لذلك يحدّد المُصدِّر مخرجًا ومسار تكميم مختلفين تلقائيًا. وتجمّع نماذج التقسيم والوضعيات و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 طبقة الالتفاف الكثيفة الخاصة بـlogit في a16، ثم تعيد بناء خريطة العمق المعيارية على المضيف (أي clamp/exp ومعايرة log-affine المتعلّمة التي تتبع الرأس)، ولذلك يحتفظ المُكمِّم بأوسع نطاق له على logit الخام. لا يحتاج المستخدمون إلى البحث عن عقد ONNX الطرفية، أو كتابة برنامج نصي لنموذج Hailo (.alls)، أو إنشاء JSON لـNMS يدويًا.

التثبيت#

ثبّت Ultralytics ونزّل حزمة DFC لعُدّة العتاد المستهدفة من منطقة مطوّري Hailo (يتطلب ذلك تسجيلًا مجانيًا):

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 غير مدعومة حاليًا ❌ عبر مسار Ultralytics format="hailo". وترفض 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 تنشئ إعدادات المعالجة اللاحقة من البيانات الوصفية للنموذج.
• تُدعَم نماذج الكشف ذات رؤوس Ultralytics القياسية Detect، ونماذج التجزئة والوضعية وOBB في YOLOv8/YOLO11، ونماذج التصنيف في YOLOv8/YOLO11/YOLO26، ونماذج التجزئة الدلالية وتقدير العمق في YOLO26؛ بينما لا تُدعَم حاليًا تجزئة الكائنات والوضعية وصندوق الإحاطة الموجّه في YOLO26، إلى جانب عمليات تصدير YOLO-World وYOLOE وYOLOv10 وRT-DETR.
• تُجمَّع artifacts الخاصة بـ 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؛ أما في المهام الأخرى فعمود YOLO11 الفقري القائم على Attention أكثر حساسية لـ 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 بت في التخصيص لهذا الرسم البياني، كما أن رفع دقة الطبقات المحيطة لا يساعد لأن عملية matmul تعيد تكميم مدخلاتها إلى INT8 على أي حال (ولم يؤدِّ الحفاظ على الالتفافات depthwise وخرجها عند 16 بت إلى تغيير mAP في اختباراتنا). عندما تكون الدقة هي الأولوية ويكون النموذجان قابلين للتبادل، يكمّم YOLO11 حاليًا بصورة أفضل من YOLO26 هنا؛ أما أجيال Hailo الأحدث (DFC 5.x) فتتيح خيارات أكثر للدقة المختلطة وقد تختلف نتائجها.

الartifacts المُصدَّرة#

ينشئ التصدير مجلدًا يحتوي على 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 واحدًا لواحد تلقائيًا. كما تفك ترميز موترات التجزئة والوضعية وOBB الخام، وتعيد احتمالات التصنيف على الشريحة، وتنتج خرائط الفئات الدلالية عبر الاختزال على المضيف في Hailo-8/8L وجميع الرؤوس ذات الفئة الواحدة، أو عبر ArgMax على الشريحة لرؤوس Hailo-10H/15 متعددة الفئات. وتظل TAPPAS وGStreamer ومساعد Raspberry Pi picamera2.devices.Hailo متاحة لمسارات العمل الخاصة بالتطبيقات.

لنشر باستخدام 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 artifact النموذج نفسه القابل للنشر عبر عدة واجهات لوقت تشغيل Hailo. اختر الواجهة التي تلائم التطبيق:

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

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

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

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

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

مقارنة 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 تقنية NMS من HailoRT، بينما تحافظ YOLO26 على مخرجاتها أحادية الاقتران الخالية من NMS. تستخدم نماذج التجزئة والوضعية وOBB موترات الرأس الخام، وتعيد نماذج التصنيف احتمالات على الشريحة، بينما تعيد نماذج التجزئة الدلالية القيم اللوغاريتمية الخام على Hailo-8/8L، وجميع الرؤوس أحادية الفئة، أو خرائط الفئات المضمّنة لرؤوس Hailo-10H/15 متعددة الفئات. يعيد تقدير العمق القيمة اللوغاريتمية الخام للعمق، التي تفكّكها Ultralytics إلى خريطة عمق متريّة أثناء الاستدلال. لا تمرّر end2end؛ إذ تُرفض التجاوزات الصريحة. الأشكال الديناميكية، و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 Platform، أو استخدم محطة عمل متوافقة إذا كان الكمبيوتر المحلي يعمل بنظام 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 Platform.
4. انسخ HEF وmetadata.yaml إلى الجهاز الطرفي المدعوم من Hailo.
5. شغّل الاستدلال باستخدام HailoRT أو Raspberry Pi Picamera2 أو مسار فيديو GStreamer.

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

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