كيف زادت ProsGrow إنتاجية المعالجة الدفعية لـ Qwen3 بنسبة 132%

المشكلة: طابور طويل مع عدد قليل جدًا من الطلبات النشطة

لا يضمن ازدحام طابور الطلبات أن تنفّذ GPU عملًا مفيدًا بكامل قدرتها المتاحة. عند تشغيل Qwen3-30B-A3B على vLLM 0.25.1، وجدت ProsGrow أن إعداد الخدمة الأولي يحد من مقدار العمل الذي يمكن تنفيذه بالتزامن ضمن دفعة من الموجّهات القصيرة. وقدّم 17,961 رمز مخرجات/ثانية رغم وفرة العمل المنتظر.

رفع تحليل الأداء وتعديل سلوك الجدولة هذا المعدل إلى 41,651 رمز مخرجات/ثانية: تحسن بنسبة 132%، أو 2.32 ضعفًا. بقيت GPU وبيئة التشغيل ونقطة التحقق والدقة وعدد الطلبات ومواصفات الموجّهات والمخرجات ثابتة. هذا تحسن مقاس مقابل إعداد ProsGrow الأولي، وليس مقابل خط أساس لـ vLLM جرى ضبطه على النحو الأمثل.

خط الأساس ← بعد ضبط ProsGrow

تحسّن وسيط زمن استجابة الطلب أيضًا من 15.91 إلى 11.70 ثانية في هذه المقارنة المضبوطة. يكشف التحسن عن قدرة يمكن استعادتها في هذا العبء؛ لكنه لا يثبت تفوقًا عامًا على محركات الاستدلال الأخرى أو بيئات النشر المحسّنة بالكامل.

لماذا كان المجدول مهمًا

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

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

المقايضة: زيادة التزامن تنتهي بزيادة الانتظار

حقق إعداد تشبّع منفصل 45,941 و46,701 رمز مخرجات/ثانية في تشغيلين منفردين، مع وسيط زمن استجابة يقارب 20 ثانية. أدت زيادة الحمل بعد نقطة التشغيل هذه إلى ارتفاع الإنتاجية بنسبة 0.91% فقط ضمن سلسلة الاختبارات نفسها، بينما ارتفع وسيط زمن الاستجابة من 20.04 إلى 29.85 ثانية. لم تعد زيادة الانتظار في الطابور تحقق زيادة ذات معنى في القدرة.

قيّدت الذاكرة الاختيار أيضًا: قلّلت أعباء الخدمة الإضافية المساحة المتاحة لذاكرة المفاتيح والقيم المؤقتة. تركت الموجّهات القصيرة مساحة كافية للإعداد المختار. أما السياقات الأطول أو أهداف الاستجابة التفاعلية فتحتاج إلى تقييم مستقل.

من ضبط GPU واحدة إلى خدمة دفعية بثماني وحدات GPU

باستخدام ثماني نسخ مستقلة، حقق تشغيلان متزامنان 362,812 و361,679 رمز مخرجات/ثانية. نستخدم النتيجة الأدنى لتقدير القدرة. أكمل كل تشغيل جميع 32,768 طلبًا و8,388,608 رمز مخرجات، دون استجابات فاشلة أو أقصر من المطلوب.

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

العلاقة بين التحسن المحلي بنسبة 132% والمقارنة العامة بنسبة 8.17%

تقيس الزيادة البالغة 132% أعلاه تعديلًا في الجدولة لطلبات قصيرة مصطفّة في الطابور. أما المقارنة بنسبة 8.17% في تقرير قدراتنا فتجيب عن سؤال مختلف: كيف يقارن أداء تشغيل محلي بمرجع عام محفوظ عند تطبيق مواصفات محددة لطلبات أطول؟

استخدم التشغيل وفق المواصفات العامة طلبات اصطناعية مصطفّة في الطابور وTensorRT-LLM 1.3.0rc24، مقابل الإصدار 1.1 في مرجع NVIDIA المحفوظ. بلغ متوسط زمن استجابة الطلب 173.04 ثانية تحت هذا الطابور الطويل. تمثل صفحة NVIDIA المرجعية مصدر الرقم 9,938 المحفوظ في 17 أغسطس 2026؛ ولم يعد الصف ظاهرًا عند مراجعة المصدر لاحقًا. نحتفظ به كمقارنة مؤرخة، مع تحديد عبء العمل عبر وصفة الأداء العامة.

تخص زيادة +8.17% نتيجة GPU الواحدة المنفردة. ولا تعزل هذه النتيجة، ولا الفجوة بين 85,409 و361,679 رمزًا/ثانية للعقدة، تحسنًا برمجيًا فقط: فالمقارنة الأخيرة تغيّر بيئة التشغيل وأطوال الطلبات. تصف هذه المعدلات القدرة الدفعية؛ أما الخدمة التفاعلية فتحتاج إلى هدف خاص بها لزمن الاستجابة.

ما الذي يتغير بالنسبة إلى العميل

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

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

المنهجية والقيود

• العتاد والبرمجيات: أُجريت الاختبارات في 18 أغسطس 2026 على عقدة بثماني وحدات NVIDIA RTX PRO 6000 Blackwell Server Edition GPU. استخدمت سلسلة الاختبارات المضبوطة GPU واحدة. كانت بيئة التشغيل vllm/vllm-openai:v0.25.1، مع أوزان ModelOpt NVFP4 وذاكرة مفاتيح وقيم مؤقتة بدقة FP8.
• النموذج والطلبات: استخدمت نقطة تحقق NVIDIA Qwen3-30B-A3B-FP4 المثبتة المراجعة 2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3. نتج عن تكرار موجّه لدليل تقني مع تغيير معرّف الطلب 63–66 رمز إدخال وفق ما أبلغت به API. كانت درجة الحرارة صفرًا، وعُطّل التفكير، ووصلت كل استجابة إلى حد 256 رمزًا.
• القياس: الإنتاجية هي عدد رموز المخرجات المكتملة مقسومًا على الزمن المنقضي الذي يرصده العميل، بما يشمل معالجة الموجّه وأعباء HTTP المحلية. تستخدم مقارنة 132% قياسًا واحدًا لكل إعداد. أُعيد إعداد التشبع المختار مرتين بصورة منفردة ومرتين على العقدة بتزامن؛ ولا تستغرق كل من الإعادتين الأخيرتين سوى نحو 23 ثانية.
• الجودة والتشغيل: يتحقق طول المخرجات الثابت من كمية العمل المولّد، لا من جودة المهمة. هذه قياسات تشبّع محلية على نقطة تحقق أقدم لـ Qwen3، وليست اختبار تحمل إنتاجي مستمرًا أو اتفاقية مستوى خدمة للعميل أو اختبار تكافؤ جودة. وتظل الموجّهات الممثلة وزمن الاستجابة عند p95/p99 وأعباء الشبكة والإخفاقات وجودة المجال شروطًا لقبول الإنتاج.

نستبعد أيضًا المقارنة التاريخية مع vLLM 0.23 من نسبة التحسن في العنوان لأن طلبات الموجّهات الأصلية الخام لم تُحفظ. توفر المقارنة المحلية على الإصدار نفسه خط الأساس المضبوط.

نشر Qwen3 الخاص والاستدلال الدفعي باستخدام vLLM

يمكن للفرق التي تخطط لنشر Qwen3 خاص استخدام هذا الاختبار لمناقشة قدرة الاستدلال الدفعي واستغلال GPU ووقت الانتظار المقبول في الطابور. تقيس رموز المخرجات في الثانية إنتاجية التوليد المكتمل، بينما يوضح زمن استجابة الطلب مدة انتظار المهمة وتنفيذها. ينبغي تحديد حجم نشر vLLM وفق مزيج طلبات العميل وهدف التسليم لديه.