تقنية

الدفعة الديناميكية للاستدلال: متى ينتظر الطلب؟

وصول أ عند صفر وب عند 2 ثم إرسال دفعة وتنفيذ مفترض لخمس ميكروثوان وعودة الجوابين عند 7
رسم حسابي من إعداد بحر العلوم؛ ليس خطًا زمنيًا لخادم شغلناه.

انتظار الدفعة الديناميكية للاستدلال يمكن أن يسمح بانضمام طلب آخر قبل التنفيذ. توثق Triton جمع الطلبات ديناميكيًا للنماذج عديمة الحالة، مع إعداد تأخير في المجدول. [1]

الخلاصة السريعة

حدد شروط الجمع وحد التأخير وزمن التنفيذ مستقلين؛ حد الانتظار لتكوين دفعة ليس وعدًا بأن جواب الطلب الكامل سيصل داخل الحد نفسه.

  • الدفعة الديناميكية الموثقة تجمع طلبات استدلال لنموذج عديم الحالة؛ المثال يفترض توافق الطلبين وتوافر مثيل التنفيذ. [1]
  • في تمريننا يصل أ عند صفر وب عند 2 ميكروثانية؛ مع حد حجم اثنين وتأخير أقصى 3، نرسل الاثنين عند 2 وفق الفروض.
  • لو لم يصل ب، تنقضي مهلة الجمع عند 3 ونرسل أ وحده؛ انتهاء التأخير لا يفرض انتظار اكتمال الحجم. [1]
  • مع تنفيذ مفترض مدته 5 بعد الإرسال، يعود جوابا الدفعة عند 7؛ حد التأخير 3 ليس زمنًا كاملًا أو قياس تسريع أو ضمان مهلة عميل.

ما الذي يجمعه المجدول؟

تصف Triton دفعة تنشأ بجمع طلبات استدلال، وتخصص المجدول الديناميكي للنماذج عديمة الحالة. [1]

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

توافر المثيل شرط للخط الزمني المبسط. إذا كان مشغولًا بعمل آخر أو كانت المدخلات غير متوافقة، نحتاج عقدًا وسجلًا إضافيين. لا نجعل كلمة «ديناميكية» حلًا يجمع أي رسائل مهما اختلفت أشكالها أو معانيها.

تابع انضمام طلب قبل حد التأخير

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

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

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

هل يجب أن تبلغ كل دفعة الحجم الأقصى؟

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

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

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

احسب الجواب بعد الإرسال لا قبله

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

كلاهما يقرأ تحت حد الجمع 3، لكن زمن أ الكامل أكبر من هذا الحد. لا يوجد تعارض؛ الحد يخص انتظارًا محددًا، ولم يختزل الخمس التي افترضناها للتنفيذ. في حالة أ المنفرد مع مدة تنفيذ الخمس نفسها، تكون العودة عند 8.

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

المصادر ومتابعة القراءة

  1. NVIDIA Triton: Batchers — Dynamic / Delayed Batching (يفتح في نافذة جديدة)docs.nvidia.com

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.