تحليل زمن الاستدلال وضبطه

لا يمكنك ضبط ما لا تقيسه. قبل تغيير الإعدادات، سجّل أرقام زمن الاستجابة والإنتاجية الفعلية تحت حمل تثق به. 📏

يأتي Triton مزودًا بأداة perf_analyzer التي ترسل عددًا كبيرًا من الطلبات إلى نموذجك، وتعرض زمن الاستجابة والإنتاجية لكي تقارن بين الإعدادات.

توجّه perf_analyzer إلى نموذج، فيرسل طلبات اصطناعية ثم يطبع عدد عمليات الاستدلال في الثانية وتفاصيل زمن الاستجابة.

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

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

تخفي المتوسطات المشكلات. راقب زمن الاستجابة p95، وهو القيمة التي يتجاوزها أداء 95% من الطلبات، لأن المستخدمين يشعرون فعليًا بزمن الاستجابة في الحالات الطرفية.

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

إذا كانت وحدة GPU قليلة الاستخدام، فأضف نسخة. وإذا كانت الذاكرة محدودة أو توقفت الإنتاجية عن التحسن، فأزل نسخة. غيّر معاملًا واحدًا في كل مرة ثم أعد القياس.

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

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

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

لماذا نفضّل زمن الاستجابة p95 على متوسط زمن الاستجابة عند الضبط؟

استخدمت perf_analyzer لاختبار نطاق التزامن، وقرأت منحنى الإنتاجية وزمن الاستجابة عند p95، وضبطت تأخير قائمة الانتظار وعدد النسخ ضمن ميزانية محددة، مع تغيير واحد في كل مرة. 🙌