Runpod توضح كيف تساعد GuideLLM على استخلاص أقصى أداء من vLLM

أصدرت Runpod في مدونتها دليلاً حول الجمع بين vLLM وGuideLLM. الفكرة بسيطة: قبل طرح النموذج أمام المستخدمين، شغّلوا عليه محاكاة لحركة مرور حقيقية وراقبوا ثلاثة أرقام: الزمن حتى أول توكن، والتأخير بين التوكنات، والإنتاجية. هذه الأرقام تحدد عدد وحدات GPU التي ستحتاجونها، وما ستدفعونه مقابل مليون توكن. المنشور الأصلي قصير، وهو أقرب إلى إعلان عن دليل عملي، ولذلك لا يتضمن نتائج قياس (بنشمارك) محددة على البطاقات. لكن المنهجية نفسها تستحق التوقف عندها.

لماذا لا يعني «سريع على حاسوبي المحمول» شيئاً

أصبح vLLM منذ وقت طويل أحد المحركات القياسية لاستدلال (inference) النماذج المفتوحة. يعتمد على الدفعات المستمرة (continuous batching) وPagedAttention لإدارة KV-cache، ويعمل بكفاءة عالية مع عدد قليل من الطلبات. تبدأ المشكلات تحت الحمل. فعندما تصل عشرات الطلبات في وقت واحد بأطوال prompt مختلفة، يمتلئ الكاش وتطول الطوابير، وقد يتضاعف زمن أول توكن عدة مرات.

لا يكشف طلب واحد منفرد هذه المشكلة. المطلوب مولّد حمل يتصرف كما يتصرف المستخدمون: طلبات لا تصل واحداً تلو الآخر بل على موجات، وبأطوال مختلفة للـprompt والإجابة. وهذا ما صُمّمت GuideLLM من أجله. إنها أداة مفتوحة المصدر من منظومة vLLM. تتصل بنقطة نهاية (endpoint) متوافقة مع OpenAI، وترسل طلبات اصطناعية أو طلبات تحددونها بأنفسكم، ثم تجمع الإحصاءات.

كيف تبدو جولة الاختبار

المخطط على Runpod نمطي. تشغّلون pod أو عامل serverless مع vLLM، وتحصلون على عنوان نقطة النهاية، ثم تشغّلون GuideLLM منه أو من جهاز آخر. بعد ذلك تحددون ملف الحمل: طول المدخلات والمخرجات بالتوكنات، ونمط إرسال الطلبات، والمدة. عادةً تتوافر أنماط عدة: معدل ثابت، وتدفق بواسوني (Poisson)، ونمط أقصى إنتاجية، والتشغيل المتسلسل الذي لا يتعرض فيه الخادم للإجهاد. وللاستكشاف الأول يناسب نمط sweep، إذ يمر بحمل متصاعد ويبيّن النقطة التي ينكسر عندها منحنى التأخير. تتغير الأسماء الدقيقة للخيارات (flags) من إصدار إلى آخر، والأفضل مطابقتها مع الوثائق.

في النهاية تحصلون على تقرير يتضمن المؤشرات التالية:

• TTFT، الزمن حتى أول توكن: يحدد مدى استجابة المحادثة في نظر المستخدم؛
• ITL، التأخير بين التوكنات: تتوقف عليه سلاسة البث (streaming)؛
• التأخير الكلي للطلب كاملاً: مهم لواجهات API وسلاسل الوكلاء (agents)؛
• عدد الطلبات في الثانية التي يتحملها الخادم قبل أن يتدهور أداؤه؛
• التوكنات في الثانية لكل بطاقة، وهي القيمة الأساسية لحساب التكلفة؛
• عدد الطلبات المتزامنة التي تبدأ عندها الطوابير بالنمو.

جوهر الأمر في المقارنة. فإذا كان TTFT ضمن القيمة المستهدفة عند حمل معين ثم يرتفع بعده، فهذا هو سقف التشغيل الفعلي للإعداد الحالي.

التطبيق العملي: من المقاييس إلى فاتورة GPU

الخطوات كما يلي.

1. صِفوا حركة المرور الفعلية لديكم: متوسط طول الـprompt وأقصاه، وطول الإجابة، وذروة الحمل. وإذا لم تتوافر سجلات بعد، فاعتمدوا تقديرات متحفظة ثم دقّقوها لاحقاً. 2. حدّدوا القيم المستهدفة لـTTFT وITL. وهي تختلف بين واجهة المحادثة والمعالجة الدفعية للمستندات. 3. شغّلوا sweep على عدة إعدادات: وحدات GPU مختلفة، وتكميماً (quantization) مختلفاً، وقيماً مختلفة لأقصى طول للسياق ولحصة الذاكرة المخصصة لـKV-cache. 4. لكل إعداد، حدّدوا أقصى حمل تتحقق عنده الأهداف، ثم اقسموا السعر بالساعة للبطاقة على عدد التوكنات الناتج. هذا هو السعر الحقيقي للتوكن. 5. في نشر serverless، تحققوا أيضاً من البدء البارد (cold start) ومن السلوك عند النمو الحاد في الطابور، فالبنشمارك الثابت لن يُظهرهما.

ثمة تحفظ. الحمل الاصطناعي يبقى نموذجاً لا واقعاً. فإذا كان لدى مستخدميكم prompts نظامية طويلة ذات بادئة مشتركة، فإن تفعيل التخزين المؤقت للبادئة (prefix caching) سيغيّر الصورة، ويجب بناء الاختبار مع مراعاة ذلك. كما أن النتائج مرتبطة بإصدار vLLM وبرامج التشغيل (drivers) والبطاقة المحددة، لذا يُستحسن تكرار الاختبار بعد كل تحديث.

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