Link to this sectionتصدير Hailo لنماذج Ultralytics YOLO#

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

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

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

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

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

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

Link to this sectionكيف يعمل تصدير 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 يدوياً.

Link to this sectionالتثبيت#

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

Link to this sectionتصدير نموذج 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)

Link to this sectionالنماذج والأجهزة المدعومة#

يغطي النظام البيئي لـ 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 الذي يتطابق مع الهدف المحدد.

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

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

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

Link to this sectionملاحظات التوافق#

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

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

Link to this sectionالمعايرة وتكميم 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 الأصلي، فقم بتحسين بيانات المعايرة أولاً قبل تغيير إعدادات النموذج أو وقت التشغيل.

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

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

تتم مقارنة الاحتفاظ بكلا النموذجين عند نفس عتبة الثقة. تقوم ملفات YOLOv8 و YOLO11 HEF بدمج 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؛ أما بالنسبة للمهام الأخرى، فإن هيكل الانتباه (attention backbone) في YOLO11 أكثر حساسية لـ INT8.

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

1. قم بالمعايرة داخل النطاق دائماً. إن الضبط الدقيق باستخدام صور خارج النطاق يعادل تعطيل الضبط الدقيق تماماً: يحتفظ نموذج YOLO26n الذي تمت معايرته بـ 1238 صورة خارج النطاق بنفس الدقة (85.7%) مثل نموذج تم تجميعه بدون ضبط دقيق. مجموعة صغيرة داخل النطاق تتفوق على مجموعة كبيرة خارج النطاق.
2. اخفض conf بمقدار 0.05 تقريبًا لنشر YOLO26. تؤدي عملية التكميم (quantization) إلى خفض درجات 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 بت في التخصيص لهذا الرسم البياني، وزيادة دقة الطبقات المحيطة لا تساعد لأن matmul تعيد تكميم مدخلاتها إلى INT8 على أي حال (حماية الالتفافات العميقة والمخرجات بـ 16 بت تركت mAP دون تغيير في اختباراتنا). عندما تكون الدقة هي الأولوية ويكون النموذج قابلاً للتبديل، يتم تكميم YOLO11 حالياً بشكل أفضل من YOLO26 هنا؛ تكشف أجيال Hailo الأحدث (DFC 5.x) عن المزيد من خيارات الدقة المختلطة وقد تختلف.

Link to this sectionالملفات المُصدرة#

ينشئ التصدير دليلاً يحتوي على ملف 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 البياني الوسيط بعد التجميع.

Link to this sectionتشغيل الاستنتاج على أجهزة 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

Link to this sectionخيارات نشر Hailo#

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

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

Link to this sectionالتحقق من جهاز Hailo وملف HEF#

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

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

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

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

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

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

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

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

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

Link to this sectionوسائط التصدير#

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

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

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

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

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

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

Link to this sectionيستغرق التصدير وقتاً طويلاً#

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

Link to this sectionانخفاض دقة النموذج المكمم#

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

Link to this sectionملف HEF لا يتم تحميله على الجهاز#

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

Link to this sectionتحليل المخرجات يبدو غير صحيح#

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

Link to this sectionالأسئلة الشائعة#

Link to this sectionهل يمكنني تجميع ملف HEF على Raspberry Pi؟#

لا. قم بتشغيل DFC على نظام Linux x86_64 مدعوم وقم بنشر ملف HEF الناتج إلى Raspberry Pi.

Link to this sectionهل أحتاج إلى NVIDIA GPU؟#

تقلل وحدة معالجة الرسومات المدعومة من وقت تحسين DFC بشكل كبير. التجميع باستخدام CPU ممكن ولكنه قد يستغرق وقتاً أطول بكثير.

Link to this sectionما هي نماذج YOLO التي تدعم تصدير Hailo؟#

يدعم التصدير المباشر نماذج الاكتشاف ذات رأس الاكتشاف القياسي لـ YOLOv8 أو YOLO11 أو YOLO26، ونماذج التجزئة، وتحديد الوضعيات، وOBB لـ YOLOv8/YOLO11، ونماذج التصنيف لـ YOLOv8/YOLO11/YOLO26. يتضمن ذلك النماذج المدربة خصيصاً المبنية من تلك البنى القياسية. كما يتم دعم نماذج التجزئة الدلالية وتقدير العمق لـ YOLO26. يتم رفض تجزئة المثيلات لـ YOLO26، وتحديد الوضعيات، وOBB، جنباً إلى جنب مع YOLOv10 و YOLO-World و YOLOE و RT-DETR بدلاً من إنتاج HEF غير متحقق منه.

Link to this sectionهل يمكنني تصدير نموذج YOLO مدرب مخصصاً؟#

نعم. استخدم نفس أمر format="hailo" مع أوزان .pt المخصصة وقم بتمرير ملف YAML الخاص بمجموعة بيانات التدريب من خلال data لمعايرة INT8 ممثلة. يتم قراءة أسماء الفئات وعددها من بيانات تعريف النموذج (metadata).

Link to this sectionهل يدعم تصدير Hailo أحجام صور ديناميكية؟#

لا. يقوم DFC بتجميع شكل إدخال ثابت في ملف HEF. اختر imgsz أثناء التصدير ليتناسب مع الدقة المستخدمة في خط معالجة النشر.

Link to this sectionلماذا تنتج YOLO26 مخرجات Hailo مختلفة؟#

تستخدم YOLO26 رأس كشف مباشر بدون NMS. تقوم Ultralytics بتجميع موترات المخرجات تلك مباشرة بدلاً من إرفاق HailoRT NMS بأسلوب YOLOv8 المستخدم لـ YOLOv8 و YOLO11.

Link to this sectionما الفرق بين DFC و HailoRT؟#

يقوم مترجم تدفق بيانات Hailo بتحويل النموذج وتكميمه إلى ملف HEF خاص بالأجهزة على جهاز بناء يعمل بنظام Linux x86_64. يقوم HailoRT بتحميل وتشغيل ذلك الملف على الجهاز المستهدف.

Link to this sectionهل يجب أن أنشر ملف ONNX أم HEF؟#

انشر ملف HEF المجمع إلى بيئة تشغيل Hailo. ONNX هو تمثيل وسيط يُستخدم أثناء التصدير ويتم حذفه بعد التجميع الناجح.

Link to this sectionأين يمكنني الحصول على Hailo DFC؟#

قم بتنزيل حزمة المترجم لجيل أجهزتك من منطقة مطوري Hailo. المترجم مطلوب فقط لإنشاء HEF؛ بينما يقوم HailoRT بتشغيله على المسرع المستهدف.

Link to this sectionملخص#

يوفر تصدير 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.