نستخدم OpenAI Triton لإنشاء بعض نوى وحدة معالجة الرسومات. يتيح Triton توليد وحدات نواة سريعة لوحدة معالجة الرسومات (GPU) لبعض عمليات الدمج، ولكن علينا ضبط بعض المَعلمات لكل عملية دمج.
ويمكن أن يستغرق ذلك وقتًا طويلاً في حال إجراء العديد من عمليات الدمج، لذلك نوفّر طريقة لتحميل نتائج الضبط التلقائي هذه، مع مواصلة تنفيذ خطوات الدمج الأخرى بشكلٍ طبيعي. تظلّ ذاكرات التخزين المؤقت للضبط التلقائي مفيدة إذا أجرينا بعض التغييرات: ستستخدم عمليات الدمج المتوفّرة في ذاكرة التخزين المؤقت ذاكرة التخزين المؤقت، وسيتم ضبط عمليات الدمج الأخرى تلقائيًا كالمعتاد.
القيمة المقترَحة: دليل ذاكرة التخزين المؤقت
--xla_gpu_per_fusion_autotune_cache_dir=your/directory
استخدام ذاكرة التخزين المؤقت للتوليف التلقائي لكل دمج في الدليل المحدد. سيكون هناك ملف واحد لكل اندماج مميز.
تتمثل الميزة الرئيسية لهذا النهج في أنّه يمكنك استخدام دليل ذاكرة التخزين المؤقت نفسه لعمليات متعددة من XLA (لتصاميم مختلفة)، وستزداد ذاكرة التخزين المؤقت مع كل دمج جديد يتم العثور عليه، ما يؤدي إلى تسريع عمليات التشغيل اللاحقة. تتوفّر أيضًا ميزة dasar تتيح تشغيل عدّة نُسخ من XLA باستخدام دليل التخزين المؤقت نفسه بالتزامن.
ستقرأ XLA النتائج الحالية عند الحاجة إليها وتكتب نتائج جديدة بعد تحديدها.
- يجب أن يكون الدليل متوفّرًا قبل تشغيل XLA ويجب أن يكون قابلاً للكتابة.
- على المستخدم معالجة إيقاف ذاكرة التخزين المؤقت:
- يُرجى استخدام دليل فارغ إذا كنت تريد البدء بذاكرة تخزين مؤقت فارغة.
- على المستخدم التحقّق من إصدار XLA:
- إذا أردت استخدام ذاكرات تخزين مؤقت منفصلة لإصدارات مختلفة من XLA، يُرجى استخدام أدلة مختلفة.
تكون ذاكرة التخزين المؤقت غير مفعَّلة تلقائيًا (في حال عدم تقديم المَعلمة).
التقييد: ليس مضمونًا أن يعمل هذا بشكل جيد مع طريقة التخزين المؤقت الأخرى الموضحة أدناه.
البديل: تحميل جميع النتائج من مستوى HLO معيّن أو تفريغها في ملف واحد
يمكن تفريغ/تحميل نتائج التوليف التلقائي باستخدام المَعلمات التالية:
--xla_gpu_dump_autotune_results_to=
--xla_gpu_load_autotune_results_from=
إذا حدّدنا ملفًا بتنسيق .txt أو .textproto، سيتم تفريغ ذاكرة التخزين المؤقت بتنسيق textproto، وإلا سيتم تفريغها بتنسيق ثنائي protobuf.
في الاختبارات
يمكن أيضًا استخدام الضبط التلقائي الدائم في الاختبارات. ويُنصح باستخدامه إذا كانت الاختبارات كبيرة جدًا، خاصةً إذا كان أداء بيئة الاختبار محدودًا.
ولا تعمل هذه الميزة بشكل جيد إلا إذا كانت ذاكرة التخزين المؤقت للضبط التلقائي تحتوي على نتائج تم إنشاؤها على النوع نفسه من وحدة معالجة الرسومات التي يتم فيها إجراء الاختبارات.
جعل الاختبار يستخدِم ميزة "الضبط التلقائي" الدائم
لنفترض الآن أنّ الاختبار المعني يستخدم دائمًا نوع وحدة معالجة الرسومات نفسه.
علينا تصدير نتائج الضبط التلقائي من الاختبار، على سبيل المثال من خلال تحديد هذه المَعلمات لأمر الاختبار:
--test_env=XLA_FLAGS=--xla_gpu_dump_autotune_results_to=TEST_UNDECLARED_OUTPUTS_DIR/autotune_cache.textproto --test_sharding_strategy=disabledيجب إيقاف التجزئة للحصول على ذاكرة تخزين مؤقتة واحدة للتحسين التلقائي لجميع الاختبارات.
بعد ذلك، علينا تحميل ذاكرة التخزين المؤقت هذه إلى مستودع الرموز البرمجية.
ثم يتعين علينا إضافة ذاكرة التخزين المؤقت إلى تبعيات البيانات الخاصة بهدف الاختبار، وتحميلها باستخدام متغير بيئة.
data = ["test_autotune_cache.textproto"], env = {"XLA_FLAGS": "--xla_gpu_load_autotune_results_from=" + "$(execpath test_autotune_cache.textproto)"},(لا مانع من استخدام التقسيم في الاختبارات التي تُحمّل نتائج الضبط التلقائي).
يُرجى أيضًا الاطّلاع على أمثلة الاختبارات في xla/service/gpu/tests/BUILD:
- load_autotune_results_using_execpath_test
- load_autotune_results_from_test_workspace_test
- dump_autotune_results_to_test_outputs_test
إيقاف ذاكرة التخزين المؤقت
في حال إجراء العديد من التغييرات على أحد النماذج، من المحتمل أن لا تتضمن ذاكرة التخزين المؤقت بعد ذلك جميع عمليات الدمج، ما سيؤدي إلى إبطاء الاختبار. في هذه الحالة، علينا إعادة إنشاء ذاكرة التخزين المؤقت للضبط التلقائي.
وينطبق الأمر نفسه إذا بدأنا باستخدام نوع جديد من وحدات معالجة الرسومات لإجراء الاختبارات.
قد تصبح ذاكرة التخزين المؤقت أيضًا قديمة إذا تطوّر مُجمِّع XLA وأنشأ عمليات دمج مختلفة.