مفوَّضو وحدة معالجة الرسومات في LiteRT

يمكن أن يؤدي استخدام وحدات معالجة الرسومات (GPU) لتشغيل نماذج تعلُّم الآلة (ML) إلى تحسين أداء النموذج وتجربة المستخدم لتطبيقاتك التي تستخدم تعلُّم الآلة بشكل كبير. تتيح LiteRT استخدام وحدات معالجة الرسومات وغيرها من المعالِجات المتخصصة من خلال برنامج تشغيل الأجهزة الذي يُعرف باسم المفوّضون. يمكن أن يؤدي تفعيل استخدام وحدات معالجة الرسومات مع تطبيقات LiteRT ML إلى توفير المزايا التالية:

  • السرعة: تم تصميم وحدات معالجة الرسومات (GPU) لتحقيق سرعة نقل بيانات عالية لأحمال العمل المتوازية بشكل كبير. ويجعل هذا التصميم هذه المعالِجات مناسبة تمامًا للشبكات العصبية العميقة التي تتألف من عدد كبير من المشغّلات، يعمل كل منها على موترات الإدخال التي يمكن معالجتها بالتوازي، ما يؤدي عادةً إلى تقليل وقت الاستجابة. في أفضل الحالات، قد يكون تشغيل النموذج على وحدة معالجة الرسومات سريعًا بما يكفي لتفعيل التطبيقات في الوقت الفعلي التي لم يكن من الممكن استخدامها سابقًا.
  • كفاءة استهلاك الطاقة: تنفّذ وحدات معالجة الرسومات عمليات حسابية خاصة بتعلُّم الآلة بطريقة فعالة ومحسّنة للغاية، وعادةً ما تستهلك طاقة أقل وتنتج حرارة أقل من المهام نفسها التي يتم تنفيذها على وحدات المعالجة المركزية.

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

إتاحة عمليات تعلُّم الآلة على وحدة معالجة الرسومات

هناك بعض القيود على عمليات تعلُّم الآلة في TensorFlow، أو العمليات، التي يمكن تسريعها باستخدام أداة التفويض لوحدة معالجة الرسومات في LiteRT. يتيح المفوّض العمليات التالية بدقة الفاصلة العائمة 16 بت و32 بت:

  • ADD
  • AVERAGE_POOL_2D
  • CONCATENATION
  • CONV_2D
  • DEPTHWISE_CONV_2D v1-2
  • EXP
  • FULLY_CONNECTED
  • LOGICAL_AND
  • LOGISTIC
  • LSTM v2 (Basic LSTM only)
  • MAX_POOL_2D
  • MAXIMUM
  • MINIMUM
  • MUL
  • PAD
  • PRELU
  • RELU
  • RELU6
  • RESHAPE
  • RESIZE_BILINEAR v1-3
  • SOFTMAX
  • STRIDED_SLICE
  • SUB
  • TRANSPOSE_CONV

بشكلٍ تلقائي، لا تتوافق جميع العمليات إلا مع الإصدار 1. يؤدي تفعيل دعم التكميم إلى تفعيل الإصدارات المناسبة، مثل ADD v2.

تحديد المشاكل المتعلّقة بتوافق وحدة معالجة الرسومات وحلّها

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

WARNING: op code #42 cannot be handled by this delegate.

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

أمثلة على النماذج

تم تصميم نماذج الأمثلة التالية للاستفادة من تسريع وحدة معالجة الرسومات باستخدام LiteRT، وهي متوفّرة كمرجع ولأغراض الاختبار:

التحسين لوحدات معالجة الرسومات

يمكن أن تساعدك التقنيات التالية في الحصول على أداء أفضل عند تشغيل النماذج على أجهزة وحدة معالجة الرسومات باستخدام أداة LiteRT GPU المساعدة:

  • عمليات إعادة التشكيل: قد تكون بعض العمليات التي تتم بسرعة على وحدة المعالجة المركزية (CPU) مكلفة جدًا بالنسبة إلى وحدة معالجة الرسومات (GPU) على الأجهزة الجوّالة. تتطلّب عمليات إعادة التشكيل تكلفة عالية، بما في ذلك BATCH_TO_SPACE وSPACE_TO_BATCH وSPACE_TO_DEPTH وما إلى ذلك. عليك فحص استخدام عمليات إعادة التشكيل عن كثب، مع الأخذ في الاعتبار أنّه ربما تم تطبيقها فقط لاستكشاف البيانات أو للتكرارات الأولى من نموذجك. ويمكن أن تؤدي إزالتها إلى تحسين الأداء بشكل كبير.

  • قنوات بيانات الصور: على وحدة معالجة الرسومات، يتم تقسيم بيانات الموتر إلى 4 قنوات، وبالتالي، فإنّ عملية حسابية على موتر بالشكل [B,H,W,5] تؤدي تقريبًا الأداء نفسه على موتر بالشكل [B,H,W,8]، ولكنّها أسوأ بكثير من [B,H,W,4]. إذا كان جهاز الكاميرا الذي تستخدمه يتوافق مع إطارات الصور بتنسيق RGBA، ستكون عملية إدخال البيانات ذات الأربع قنوات أسرع بكثير، لأنّها تتجنّب نسخ البيانات من ذاكرة RGB ذات الثلاث قنوات إلى ذاكرة RGBX ذات الأربع قنوات.

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

دعم متقدّم لوحدة معالجة الرسومات

يمكنك استخدام تقنيات إضافية ومتقدّمة مع معالجة وحدة معالجة الرسومات (GPU) لتحقيق أداء أفضل لنماذجك، بما في ذلك التكميم والتسلسل. توضّح الأقسام التالية هذه الأساليب بمزيد من التفصيل.

استخدام النماذج الكمّية

يوضّح هذا القسم كيف تساهم وحدة معالجة الرسومات في تسريع النماذج الكمية ذات 8 بت، بما في ذلك ما يلي:

لتحسين الأداء، استخدِم نماذج تتضمّن موترات إدخال وإخراج ذات نقطة عائمة.

كيف يتم ذلك؟

بما أنّ الخلفية المستندة إلى وحدة معالجة الرسومات لا تتيح سوى تنفيذ الأعداد العشرية، فإنّنا نشغّل النماذج الكمية من خلال منحها "عرضًا عشريًا" للنموذج الأصلي. على مستوى عالٍ، يتضمّن ذلك الخطوات التالية:

  • يتم إلغاء تحديد كمية الموتر الثابتة (مثل الأوزان/الانحيازات) مرة واحدة في ذاكرة وحدة معالجة الرسومات. تحدث هذه العملية عندما يكون المفوّض مفعّلاً في LiteRT.

  • المدخلات والمخرجات لبرنامج وحدة معالجة الرسومات، إذا تم تحديد الكمية بـ 8 بت، يتم إلغاء تحديد الكمية وتحديدها (على التوالي) لكل استنتاج. يتم تنفيذ هذه العملية على وحدة المعالجة المركزية باستخدام النواة المحسّنة في LiteRT.

  • يتم إدراج محاكيات التكميم بين العمليات لمحاكاة السلوك المكمَّم. هذا الأسلوب ضروري للنماذج التي تتوقّع فيها العمليات أن تتبع الحدود التي تم تعلّمها أثناء التكميم.

للحصول على معلومات حول تفعيل هذه الميزة باستخدام وحدة معالجة الرسومات (GPU)، يُرجى الاطّلاع على ما يلي:

تقليل وقت التهيئة باستخدام التسلسل

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

C++‎

    TfLiteGpuDelegateOptionsV2 options = TfLiteGpuDelegateOptionsV2Default();
    options.experimental_flags |= TFLITE_GPU_EXPERIMENTAL_FLAGS_ENABLE_SERIALIZATION;
    options.serialization_dir = kTmpDir;
    options.model_token = kModelToken;

    auto* delegate = TfLiteGpuDelegateV2Create(options);
    if (interpreter->ModifyGraphWithDelegate(delegate) != kTfLiteOk) return false;

Java

    GpuDelegate delegate = new GpuDelegate(
      new GpuDelegate.Options().setSerializationParams(
        /* serializationDir= */ serializationDir,
        /* modelToken= */ modelToken));

    Interpreter.Options options = (new Interpreter.Options()).addDelegate(delegate);

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

  • خزِّن بيانات التسلسل في دليل لا يمكن للتطبيقات الأخرى الوصول إليه. على أجهزة Android، استخدِم getCodeCacheDir() الذي يشير إلى موقع جغرافي خاص بالتطبيق الحالي.
  • يجب أن يكون الرمز المميز للطراز فريدًا للجهاز الخاص بهذا الطراز. يمكنك حساب رمز مميّز للنموذج من خلال إنشاء بصمة من بيانات النموذج باستخدام مكتبات مثل farmhash::Fingerprint64.