قياس أداء استدلال نماذج اللغة الكبيرة على نطاق واسع باستخدام AIPerf

قياس استدلال LLM على نطاق واسع باستخدام AIPerf

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

هذه الفجوة هي السبب الكامل لوجود أداة قياس مخصصة لاستدلال النماذج اللغوية الكبيرة. تغطي تدوينة NVIDIA AI Blog Benchmarking LLM Inference at Scale with AIPerf (https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf) أداة AIPerf، وهي أداة بُنيت لهذه المشكلة تحديداً. يتخذ هذا المقال من تلك التدوينة مرتكزاً واقعياً ثم يشرح المنهجية حولها: كيف تؤطر قياس استدلال، وأي الأرقام تستحق الثقة، وأين يخطئ القياس بهدوء.

ملاحظة عن المصادر، تُقال بوضوح. الحقيقة الموثقة التي يقوم عليها هذا المقال هي أن NVIDIA نشرت التدوينة أعلاه عن AIPerf. التفاصيل الخاصة بالأداة — واجهتها، ونقاط النهاية المدعومة، وأنواع أحمال العمل، ومجموعة ميزاتها — تنتمي إلى تلك التدوينة وإلى وثائقها، وهي تتغير بمرور الوقت. كل ما يلي عن المنهجية هو إرشاد وتفسير، وليس ادعاءً عن البنية الداخلية لـ AIPerf. وحيث لا يستطيع هذا المقال التحقق من شيء، فإنه يقول ذلك بدلاً من التخمين.

لماذا يكسر استدلال LLM اختبار الحمل التقليدي

تفترض اختبارات الحمل التقليدية للويب أن الطلبات قصيرة ورخيصة وقابلة للتبادل. ويخرق استدلال LLM هذه الافتراضات الثلاثة دفعة واحدة.

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

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

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

ما هي AIPerf وأين تقع

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

هذه هي الفئة التي تشغلها AIPerf، وفقاً لتدوينة NVIDIA. والتضمين العملي لفريق يقيّم بنية الاستدلال التحتية واضح مباشرة: اختيار الأداة يهم أقل من الانضباط المطبق عليها. فقياس جيد التصميم يُشغَّل بأداة متواضعة يتغلب على قياس مهمل يُشغَّل بأداة متطورة في كل مرة.

وبقية هذا المقال عن ذلك الانضباط.

المقاييس المهمة فعلاً

خمسة قياسات تقوم بمعظم العمل.

الزمن حتى أول رمز (TTFT) يلتقط التعبئة المسبقة (prefill)، والاصطفاف، والجدولة — كل ما يحدث قبل أن يرى المستخدم أي شيء. وهو المحرك المهيمن على الاستجابة المُدرَكة في التطبيقات التفاعلية.

زمن الاستجابة بين الرموز (ITL)، ويُعبَّر عنه أحياناً بالزمن لكل رمز إخراج، يلتقط حلقة فك التشفير. وهو يحدد ما إذا كان الإخراج يبدو سلساً أم متقطعاً. ويُبلَّغ عنه عادةً كوسيط لأن الرمز الأول مستبعد، ولأن إيقاع فك التشفير مستقر نسبياً حتى يشبع الخادم.

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

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

الإنتاجية المفيدة (Goodput) هي المقياس الذي يحل هذا. فهي تعد فقط الطلبات التي حققت هدف مستوى خدمة محدداً. والتهيئة التي تنتج 6,000 رمز في الثانية بينما تخطئ هدف زمن الاستجابة في ثلث الطلبات لديها مشكلة في الإنتاجية المفيدة، لا انتصار في الإنتاجية.

أبلغ عن المئينات، لا عن المتوسطات. فقيمة p50 التي تبدو صحية بجانب p99 أكبر منها بأربعين مرة تصف نظاماً يكون جيداً معظم الوقت وغير قابل للاستخدام بعض الوقت — وهذا، بالنسبة لمنتج تفاعلي، نظام فاشل.

اربط دائماً حمل العمل بالرقم. فـ "5,000 رمز في الثانية" لا تعني شيئاً بدون توزيعات أطوال المطالبات والمخرجات، ومستوى التزامن، والعتاد، وإصدارات البرمجيات. وبدون ذلك، فهو رقم تسويقي، لا قياس.

تعريف حمل العمل قبل أن تقيس أي شيء

معظم القياسات السيئة تكون سيئة قبل إرسال الطلب الأول، لأن حمل العمل لم يُحدد قط.

ابدأ بطول الإدخال. المطالبات الحقيقية ليست موحدة؛ فمساعد محادثة مزود بالاسترجاع ينتج توزيعاً بذيل طويل. والاختبارات الاصطناعية التي تستخدم طول مطالبة ثابتاً واحداً مفيدة لعزل المتغيرات ومضللة عندما تُقدَّم كممثلة.

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

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

يُعرف نمط الفشل هذا بالإغفال المنسق، وهو الطريقة الأكثر شيوعاً التي تجعل بها قاعدة قياس للاستدلال تجمّل نظاماً. إذا كان اختبارك يسأل فقط "ما مدى سرعة هذا الطلب؟" ولا يسأل أبداً "كم كان المستخدم سينتظر طلبه؟"، فأنت قست زمن الخدمة، لا زمن الاستجابة.

وأخيراً، قرر مسح التزامن مسبقاً. نقطة تزامن واحدة لا تخبرك تقريباً بأي شيء؛ شكل المنحنى هو النتيجة.

مثال عملي: بناء خطة قياس

السيناريو أدناه توضيحي. والأرقام خيارات تصميمية، وليست نتائج مقيسة.

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

الخطوة الأولى: صِغ الهدف كقيد، لا كأمنية. على سبيل المثال: p95 TTFT أقل من 800 مللي ثانية وp95 لزمن الاستجابة بين الرموز أقل من 50 مللي ثانية، بشكل مستدام عند 40 طلباً في الثانية. وكتابة هذا أولاً تمنع النتيجة الشائعة المتمثلة في تشغيل قياس ثم تقرير أي رقم بدا مثيراً للإعجاب.

الخطوة الثانية: ابنِ المسح. شغّل عند مستويات تزامن 1 و8 و32 و128 و512. واحتفظ بكل مستوى لمدة نافذة ثابتة طويلة بما يكفي للوصول إلى الحالة المستقرة. حافظ على توزيع طول المطالبة متطابقاً عبر المستويات كي تعكس التغيرات في المنحنى الحمل، لا المحتوى.

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

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

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

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

أين تخطئ قياسات الاستدلال

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

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

عدم تطابق المرمِّزات. فعد الرموز بمرمِّز مختلف عن الذي يستخدمه الخادم ينتج أرقام إنتاجية خاطئة بنسبة قليلة في المئة ولا تُسوّى أبداً.

تهيئة تنزلق بين التشغيلات. فمقارنة تشغيل متوازٍ بثماني طرق مقابل تشغيل بأربع طرق، أو تشغيل بمعاملات أخذ عينات مختلفة، ينتج فرقاً لا علاقة له بالتغيير قيد الاختبار.

يُذاب الذيل في المتوسط. فالإبلاغ عن متوسط زمن الاستجابة يخفي بالضبط السلوك الذي يولّد شكاوى المستخدمين وتذاكر الحوادث.

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

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

توسيع نطاق القياس نفسه

فوق بضع مئات من التدفقات المتزامنة، يصبح القياس نظاماً موزعاً ويرث مشكلات الأنظمة الموزعة.

المئينات لا تُتوسط. فدمج p99 لثلاثة مولّدات حمل بأخذ متوسطها لا معنى له حسابياً. ويتطلب التجميع الصحيح توزيعات زمن استجابة مدموجة أو رسوماً بيانية مجمعة تُجمع من كل عامل — وهو تفصيل يفسد النتائج بصمت في تقييمات حذرة في ما عدا ذلك.

محاذاة الساعة مهمة للسبب نفسه. فإذا اختلف العمال حول الوقت الحالي، يصبح توقيت كل طلب مشوشاً عند النطاق الذي تكون فيه الدقة أهم ما يكون.

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

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

تفسير النتائج والإبلاغ عنها

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

جدول مختصر يعمل جيداً، والجدول أدناه قالب بقيم بديلة، وليس بيانات مقيسة:

مخرج هذا التمرين ليس رقماً. بل نطاق تشغيل موثق: مدى الحمل الذي يتصرف فيه النظام كما وُعد، ووصف لما يحدث خارجه.

حدود مفتوحة

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

عامل النتائج المنشورة، بما فيها المواتية، كفرضيات عن نشرك لا كاستنتاجات عنه.

الخاتمة

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

توجد AIPerf لجعل ذلك القياس عملياً على نطاق واسع. الأدوات تقصّر المسافة بين سؤال وجواب؛ لكنها لا تقرر أي سؤال تطرح. ذلك القرار — الهدف، وحمل العمل، ونقطة التشغيل التي تقبل إطلاقها — يبقى لك.