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

تعمل مسرعات Hailo AI على تشغيل نماذج تنسيق القابلة للتنفيذ المجمعة من Hailo (HEF) على أجهزة الحافة مثل Raspberry Pi AI Kit وAI HAT+. يقوم Ultralytics بتصدير نماذج الكشف والتجزئة والتجزئة الدلالية وتخمير العميق والتصنيف ووضعية الجسم وOBB الخاصة بـ YOLO مباشرةً إلى تنسيق HEF باستخدام محول تدفق بيانات Hailo (DFC).

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

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

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

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

يمكن للاستنتاج المحلي تحسين الخصوصية ووقت الاستجابة لأن الصور تظل على جهاز النشر. تعتمد الإنتاجية الفعلية، وزمن الوصول، واستهلاك الطاقة على حجم نموذج 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، لذلك يختار المُصدِّر مخرجًا مختلفًا مسار معايرة تلقائيًا. تقوم تجزئة YOLOv8/YOLO11 ووضعيتها وOBB بتجميع موترات الرأس الخام، والتي يقوم Ultralytics بفك ترميزها عند الاستدلال، ويعمل تصنيف YOLOv8/YOLO11/YOLO26 على وظيفة softmax على الشريحة بحيث يُرجع HEF احتمالات الفئات مباشرةً. بالنسبة للتجزئة الدلالية YOLO26، يتبع المُصدِّر المسرع: تُرجع Hailo-8/8L (DFC v3.x) قيم منطق المُصنِّف لأعلى العينة والاختزال للمضيف، بينما تقوم Hailo-10/15 (DFC v5.x) بتجميع رؤوس ArgMax متعددة الفئات على الشريحة وتُرجع خريطة فئات مدمجة. تستخدم رؤوس الفئة الواحدة مسار منطق المضيف على كل هدف لأنها تتطلب عتبة بدلاً من ArgMax. تقوم نماذج العميق YOLO26 بتجميع التشفير المنطقي الكثيف في a16 وإعادة بناء خريطة العميق المترية على المضيف (معايرة التثبيت/الأسية ولوغاريتم التآلف المُتعلمة التي تتبع الرأس)، بحيث يحتفظ المُكمِّم بأوسع نطاق له على المنطق الخام. لا يحتاج المستخدمون إلى العثور على عقد ONNX النهائية، أو كتابة نص برمجي لنموذج Hailo (.alls)، أو إنشاء NMS JSON يدويًا.

التثبيت#

ثبّت 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-10 و Hailo-15 إصدار DFC v5.x. ثبّت إصدار المترجم الذي يتطابق مع المسرع المستهدف.

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

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

from ultralytics import YOLO

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

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

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

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

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

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

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

النماذج والأجهزة المدعومة#

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

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

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

حدد أحد قيم name هذه:

hailo8l هو الافتراضي. قم بتثبيت إصدار DFC الذي يطابق الهدف المحدد.

أجيال أجهزة و SDK الخاص بـ Hailo#

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

يعمل المترجم على Linux x86_64، بينما يعمل ملف HEF الناتج على جهاز Hailo من خلال HailoRT. يسمح لك هذا الفصل بالتجميع على محطة عمل أو في منصة Ultralytics ونشر ملف وقت التشغيل الصغير على مضيف حافة ARM أو x86.

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

تجميع Hailo خاص بالأجهزة ويستخدم شكل إدخال ثابتاً. ضع هذه القيود في الاعتبار:

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

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

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

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

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

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

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

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

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

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

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

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

1. قم بالمعايرة داخل النطاق دائماً. إن الضبط الدقيق باستخدام صور خارج النطاق يعادل تعطيل الضبط الدقيق تماماً: يحتفظ نموذج YOLO26n الذي تمت معايرته بـ 1238 صورة خارج النطاق بنفس الدقة (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. عقوبة الانتباه هيكلية على Hailo-8/8L (DFC 3.33). تتجمع كتل الانتباه إلى عمليات 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 تكوين HailoRT NMS المُنشأ لنماذج الكشف YOLOv8 وYOLO11. اكتشاف YOLO26 وجميع المهام بخلاف الاكتشاف (التجزئة، الدلالية، العمق، التصنيف، الوضعية، OBB) لا تستخدم هذا الملف.

يتم إزالة رسم ONNX البياني الوسيط بعد التجميع.

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

قم بتثبيت HailoRT على الجهاز المستهدف. يمكن لمستخدمي Raspberry Pi AI Kit وAI HAT+ اتباع دليل برمجيات Raspberry Pi AI:

sudo apt install hailo-all
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")

بالنسبة لنماذج الكشف، يقوم الخلفي بتحويل إخراج HailoRT NMS لنماذج YOLOv8 وYOLO11 وفك ترميز مخرجات YOLO26 الفردية تلقائيًا. وهو يفك ترميز موترات التجزئة والوضعية وOBB الخام، ويُرجع احتمالات التنسيق على الشريحة، وينتج خرائط الفئات الدلالية من خلال تقليل المضيف على Hailo-8/8L وجميع رؤوس الفئة الواحدة أو ArgMax على الشريحة لرؤوس Hailo-10/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 هو نفس ملف النموذج القابل للنشر عبر العديد من واجهات وقت تشغيل Hailo. اختر الواجهة التي تناسب التطبيق:

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

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

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

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

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

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

اختر تنسيق تصدير بناءً على الأجهزة التي ستنفذ النموذج:

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

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

اختيارات النموذج وخط المعالجة غالباً ما تكون أكثر أهمية من خيارات المترجم:

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

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

لتصدير الاكتشاف، تتلقى YOLOv8 وYOLO11 ميزة HailoRT NMS، بينما تحتفظ YOLO26 بمخرجاتها الفردية الخالية من NMS. تستخدم التجزئة والوضعية وOBB موترات الرأس الخام، ويُرجع التصنيف الاحتمالات على الشريحة، وتُرجع التجزئة الدلالية منطق خام على Hailo-8/8L وجميع رؤوس الفئة الواحدة أو خرائط الفئات المُخبأة لرؤوس Hailo-10/15 متعددة الفئات. يُرجع تقدير العمق منطق العمق الخام، والذي يقوم Ultralytics بفك ترميزه إلى خريطة عمق مترية عند الاستدلال. لا تقم بتمرير end2end؛ يتم رفض التجاوزات الصريحة. الأشكال الديناميكية، والدفعات الأكبر من واحد، وUltralytics NMS المدمج، وFP16، وFP32 غير مدعومة أيضًا.

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

خطأ في استيراد مترجم تدفق بيانات Hailo (DFC)#

إذا أفاد التصدير بأن hailo_sdk_client مفقود، فقم بتثبيت حزمة DFC لجهاز الأجهزة المستهدف في نفس بيئة Python مثل Ultralytics. تتطلب Hailo-8/8L وHailo-10/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.
4. انسخ HEF وmetadata.yaml إلى جهاز الحافة الذي تعمل بالطاقة بواسطة Hailo.
5. تشغيل الاستدلال باستخدام HailoRT، أو Raspberry Pi Picamera2، أو خط أنابيب فيديو GStreamer.

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

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