Zero-Host-Copy: كيف تشغّل YOLOv8m بسرعة 165–215 إطارًا في الثانية بإخراج المعالج المركزي من الحلقة الساخنة

لقد حسّنت نموذجك وكمّمته إلى INT8، وصار الاستدلال يستغرق بضعة أجزاء من الثانية. ومع ذلك يظل معدل الإطارات بعيدًا عن المتوقع. القصة مألوفة: عنق الزجاجة ليس وحدة الحساب، بل كل ما يحيط بها. يوضح تحليل منشور على Habr كيفية معالجة ذلك عمليًا.

أين تضيع الإطارات فعلًا

في بطاقة الرسوميات المنفصلة، يدفع كل إطار عالي الدقة يُرسَل إلى الذاكرة العشوائية ثم يعود ضريبةً لناقل PCIe. وإذا أُضيف إلى ذلك تبادل النتائج الوسيطة ذهابًا وإيابًا، مثل صناديق الإحاطة (bounding boxes) في الكشف عن الكائنات، تنخفض سعة النقل بشكل ملحوظ. وكلما كان النموذج أسرع بدت هذه الكلفة أوضح: الحساب يستغرق 2 مللي ثانية، بينما يستغرق النسخ وقتًا أطول من الحساب نفسه.

فكرة Zero-Host-Copy بسيطة: منذ القراءة من القرص وفك الترميز وحتى الترميز النهائي والكتابة، تبقى البيانات في ذاكرة GPU. تعالجها بطاقة الرسوميات وحدها، وتُختزل عمليات النسخ من GPU إلى CPU والعكس إلى الحد الأدنى. وتقترب منها فكرة Zero-Copy: يُمرَّر بين مراحل خط المعالجة مؤشر إلى كتلة البيانات لا الكتلة نفسها.

القاتل الصامت: cudaMalloc

المشكلة الثانية أقل وضوحًا. يؤدي استدعاء cudaMalloc إلى مزامنة ضمنية: يضطر المعالج المركزي إلى انتظار GPU، ويتوقف خط المعالجة غير المتزامن عن كونه كذلك. وقد يتسبب استدعاء واحد في حلقة معالجة الإطارات بتراجع يظهره المحلل (profiler) على هيئة توقفات غامضة.

الحل هو دورة حياة من ثلاث مراحل:

• التهيئة. يخصص التطبيق مسبقًا مجمّعات الذاكرة والمخازن المؤقتة وقوائم الانتظار بعمق ابتدائي.
• الإحماء. يُشغَّل خط المعالجة الكامل. وإذا لزمت مخازن مؤقتة إضافية، يخصصها النظام في هذه المرحلة تحديدًا.
• العمل الفعلي. بعد الإطارات الأولى يُمنع التخصيص الديناميكي: لا cudaMalloc ولا new، بل إعادة استخدام الكتل المخصصة سابقًا فقط.

هذه في جوهرها تقنية معروفة من محركات الألعاب ومعالجة الصوت: نُنجز كل ما هو ثقيل قبل البدء، وفي الحلقة الساخنة نعيد الاستخدام فقط.

النتائج

نفّذ المؤلف خط معالجة دون DeepStream بلغة C++/CUDA الخالصة. يحقق YOLOv8m بدقة 1024x1024 وبصيغة INT8 نحو 165–215 إطارًا في الثانية على RTX 3060 Ti ونحو 38 إطارًا في الثانية على Jetson Orin Nano Super. وهي نتيجة جيدة جدًا لمنصة مدمجة بهذا الحجم من المدخلات.

القيود والخلاصة

ثمن هذا النهج هو التعقيد. فخط المعالجة bare-metal يتطلب إدارة يدوية للمجمّعات ولمزامنة التدفقات ولدورة حياة المخازن المؤقتة. وأي خطأ في حجم المجمّع سيؤدي إلى انهيار أو إلى تدهور خفي في المرحلة الساخنة. وصيانة ذلك أغلى من بناء حل على DeepStream أو على إطار عمل جاهز. إضافة إلى ذلك، جاءت الأرقام من نموذج محدد وعتاد محدد، ولا تتضمن المقالة، بحسب إعلانها، مقارنة مع الحلول الجاهزة في الظروف نفسها، لذا ينبغي التحقق من المكسب على بياناتك الخاصة.

خلاصة عملية لمن يعمل في تحليل الفيديو أو مع أجهزة الحافة (edge):

• قبل مواصلة تحسين النموذج، قِس الوقت الذي يذهب في النسخ والتخصيص.
• ابحث في الحلقة الساخنة عن كل cudaMalloc وnew والمزامنات الضمنية وانقلها إلى مرحلة التهيئة.
• صمّم خط المعالجة بحيث لا يغادر الإطار GPU: فك ترميز بالعتاد، ومعالجة مسبقة، واستدلال، ومعالجة لاحقة، وترميز.
• أضف مرحلة إحماء وتحقق من انعدام التخصيصات بعدها.

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