لماذا لم يتفوق ضبط حجم الدفعة (batch size) الديناميكي على الجدولة الثابتة: تحليل صادق لفشل حلقة التحكم (control loop) في خدمة vLLM متعددة المستأجرين (multi-tenant)

إذا كنت تدير مجموعة (cluster) لخدمة vLLM على Kubernetes تتقاسم فيها عدة جهات مستأجرة (tenants) وحدات معالجة رسوميات (GPU) عالية الأداء مثل H200، وكنت تعتقد أن التحكم الثابت في القبول (static admission control) الخاص بـ Kueue “كافٍ”، فهذا المقال موجه إليك. بل يستحق القراءة أكثر إذا كنت تفترض أن “قيام عميل نموذج لغوي كبير (LLM agent) بضبط معاملات الخدمة (serving parameters) في الوقت الفعلي أمر أفضل دائماً بلا شك.” فهذه الورقة البحثية تُظهر أن هذا الافتراض ليس صحيحاً دائماً، وتفعل ذلك بأسباب محددة تماماً.

الإشكالية: القبول ثابت بينما الحمل فعلي في الوقت الحقيقي

أصبحت مشكلة خدمة الاستدلال (inference) لنماذج لغوية كبيرة لعدة مستأجرين على وحدات معالجة رسوميات مشتركة تحدياً تشغيلياً شائعاً الآن. تتقاسم عدة جهات مستأجرة، تختلف فيما بينها من حيث تقطّع حركة المرور (traffic burstiness) وطول التسلسلات (sequence length) ومستويات اتفاقية مستوى الخدمة (SLO)، مسرّعاً واحداً عالي السعة مثل H200 في الوقت ذاته. في المنصات القائمة على Kubernetes، عادة ما يقرر مجدوِل قائم على الحصص والطوابير (quota and queue based scheduler) مثل Kueue أي الأعمال يُسمح لها بالدخول إلى المجمع (pool)، لكن المعاملات الخاصة بزمن الخدمة، مثل حجم الدفعة (batch size) والعدد الأقصى للتسلسلات المتزامنة (max concurrent sequences)، وهي التي تحدد كيفية تقاسم الطلبات التي دخلت بالفعل لسعة المحرك المحدودة، تظل عادة مثبتة بشكل ثابت وقت النشر (deployment).

تطرح هذه الورقة البحثية السؤال الذي يترتب طبيعياً على ذلك. في مجمع H200 متعدد المستأجرين تديره Kueue، حين تتشارك عدة جهات مستأجرة خادم استدلال vLLM واحداً، هل يستطيع عميل نموذج لغوي كبير يراقب قياسات ذاكرة وحدة معالجة الرسوميات وزمن الاستجابة عن بعد (telemetry) في الوقت الفعلي، ويعيد ضبط حجم الدفعة والعدد الأقصى للتسلسلات المتزامنة لكل مستأجر عبر الإنترنت (online)، أن يحسّن فعلياً جبهة باريتو (Pareto frontier) للإنتاجية (throughput) وزمن الاستجابة عند المئين 99 (p99 latency) والتكلفة، مقارنة بالتحكم الثابت في القبول لدى Kueue؟ ولكي يجيب المؤلفون عن هذا السؤال، صمموا بروتوكولاً تجريبياً كاملاً يُفترض تشغيله على وحدة H200 واحدة، لكنهم يوضحون منذ البداية أن التنفيذ نفسه لم يتم لعدم توفر الوصول إلى سياق مجموعة Kubernetes المستهدفة. لذلك، لا يظهر في هذه الورقة أي رقم واحد لمعدل إنتاجية أو زمن استجابة قِيس على عتاد حقيقي. وبدلاً من ذلك، تقدم الورقة ثلاثة أشياء: صياغة رياضية لحلقة التحكم (control loop) الخاصة بمسألة الضبط الديناميكي لحجم الدفعة والتزامن (concurrency) عبر الإنترنت، وبروتوكولاً قابلاً للتكرار (reproducible) يمكن تنفيذه فور استعادة الوصول إلى المجموعة، ومحاكاة قائمة انتظار (queuing simulation) حتمية تختبر بنية ثلاث سياسات تحكم مختلفة تحت الضغط.

صياغة مسألة الضبط كحلقة تحكم

تصوغ الورقة مسألة الضبط الديناميكي عبر الإنترنت لحجم الدفعة والتزامن الخاصين بكل مستأجر باعتبارها مسألة تحكم مغلقة الحلقة (closed loop control) في زمن منفصل (discrete time)، ذات بنية شبيهة بعملية قرار ماركوف (Markov decision process). تتكون الحالة (state) من عمق طابور كل مستأجر، ونسبة استخدام ذاكرة وحدة معالجة الرسوميات، ومئينات زمن الاستجابة الأخيرة (p50/p95/p99)، والحد الأقصى الحالي للتزامن. أما الفعل (action) فهو زيادة أو نقصان محدودة النطاق في تزامن كل مستأجر. وتُصاغ دالة المكافأة (reward function) بطرح عقوبة على تجاوز زمن الاستجابة عند المئين 99 لاتفاقية مستوى الخدمة، وبند التكلفة، من الإنتاجية، بحيث تُحسَّن الإنتاجية وزمن الاستجابة والتكلفة معاً ضمن نطاق آمن. وبناءً على هذه الصياغة، يقترح المؤلفون أيضاً طريقة دمج العميل في عملية النشر الفعلية. فالعميل لا يحل محل قبول المهام (job admission) الخاص بـ Kueue، بل يعمل كعامل جانبي (sidecar) داخله، ويضبط فقط طريقة تقاسم الأعمال التي قُبلت بالفعل لسعة المحرك. والنقطة الجوهرية أن الرافعة التي يتم التحكم بها ليست معامل max_num_seqs الداخلي لمحرك vLLM، بل تزامن القبول (admission concurrency) الخاص بكل مستأجر من جهة العميل. ولأن إصدارات vLLM الإنتاجية لا تُعرِّض معاملات المحرك كمقبض (knob) يمكن تغييره في الوقت الفعلي دون إعادة تشغيل، فإن هذا التصميم يعكس القيد العملي القائل بأن النقطة الوحيدة القابلة فعلياً للضبط هي عدد الطلبات المتزامنة الواردة إلى الخادم.

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

التحذير الذي كشفته المحاكاة: التحكم الديناميكي الساذج كان أسوأ من الثابت

لسد الفراغ الناتج عن عدم تنفيذ البروتوكول التجريبي، بنى المؤلفون محاكاة لقائمة انتظار (queuing simulation) في زمن منفصل، ثابتة البذرة (seed fixed)، مكتوبة بالكامل باستخدام مكتبة Python القياسية فقط. وعلى نموذج مبسّط يتشارك فيه مستأجران مجمعاً محدوداً من الفتحات (slots)، شغّلوا ثلاث سياسات على مدى 20 بذرة عشوائية (seed) و1800 ثانية لكل منها، وأخذوا المتوسط. تُثبّت السياسة الثابتة الحد الأقصى لتزامن كل مستأجر عند 4. أما السياسة الديناميكية الساذجة فتراقب نسبة استخدام ذاكرة وحدة معالجة الرسوميات وزمن الاستجابة عند المئين 99 ضمن نافذة مدتها 6 ثوانٍ كل 3 ثوانٍ، وتضبط المستأجرَين معاً بزيادة أو نقصان مقداره 1. أما سياسة العميل المتمايز (differentiated agent) فهي نموذج بديل (surrogate model) يحاكي استدلالاً أكثر تطوراً للعميل، من خلال مراعاة نسبة التراكم (backlog ratio) لكل مستأجر بشكل مستقل.

جاءت النتائج مخالفة للتوقعات. فقد كانت السياسة الثابتة الأفضل في كل من الإنتاجية (0.686 طلب/ثانية) وعدد الطلبات المُسقَطة (بمتوسط 1.9 طلب)، بينما انخفضت إنتاجية السياسة الديناميكية الساذجة إلى 0.515 طلب/ثانية مع إسقاط 309.5 طلباً في المتوسط. وكان أداء نموذج العميل المتمايز البديل أفضل من السياسة الديناميكية الساذجة (إنتاجية 0.601 طلب/ثانية، وإسقاط 154.7 طلباً)، لكنه ظل غير قادر على مجاراة السياسة الثابتة، كما ارتفع زمن الاستجابة عند المئين 99 في كلا الشكلين الديناميكيين مقارنة بالسياسة الثابتة (11.75 ثانية)، إذ بلغ 12.79 ثانية و13.25 ثانية على التوالي.

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

كان زمن الاستجابة عند المئين 99 للسياسة الثابتة هو الأدنى، ولم يتمكن أي من المتحكمين الديناميكيين من تقليل زمن الاستجابة في الذيل (tail latency) ضمن نطاق هذه المحاكاة. هذه نتائج محاكاة بمتوسط 20 بذرة عشوائية، وليست قِيماً مقيسة فعلياً على عتاد.

يتحقق المؤلفون من أن هذه النتيجة تعكس الديناميكيات الفعلية للنموذج وليست مجرد خطأ برمجي (bug)، ويتتبعون السبب عبر أربع خطوات. أولاً، بما أن زمن الخدمة (service time) يتبع توزيعاً أسياً (exponential distribution)، فإن الذيل ثقيل بطبيعته أصلاً. فتوزيع أسي بمتوسط 2.5 ثانية يُنتج زمن استجابة عند المئين 99 يقارب 11.5 ثانية حتى دون أي انتظار في الطابور على الإطلاق، وهو رقم لا يختلف كثيراً عن الـ 11.75 ثانية التي سجّلتها السياسة الثابتة. أي أن معظم زمن الاستجابة في الذيل الملاحَظ لا ينبع من الازدحام، بل من تباين زمن الخدمة نفسه. ثانياً، عتبة التقييد (throttle threshold) مضبوطة عند 6 ثوانٍ، أي ضعف نافذة الـ 3 ثوانٍ، وهي أقل بكثير من زمن الاستجابة الجوهري عند المئين 99 البالغ 11.5 ثانية. وزمن الاستجابة عند المئين 99 المقدَّر ضمن نافذة قصيرة، اعتماداً على عدد قليل من الطلبات المكتملة فقط، يحمل ضوضاء (noise) كبيرة وينحاز نحو هذا الذيل الجوهري، لذا يتجاوز العتبة كثيراً حتى في حالات الحمل الخفيف فعلياً. ثالثاً، ولأن هذا التقييد الكاذب (false positive throttle) يخفض المستأجرَين معاً، فإن المستأجر غير المزدحم يُقيَّد أيضاً مع المستأجر المزدحم، وتحت مهلة زمنية صارمة (hard timeout) مدتها 3 ثوانٍ، يتحول كل تقييد غير ضروري مباشرة إلى إسقاط للطلب. رابعاً، ورغم أن قاعدة التوسّع (scaling rule) تسمح بالتعافي، فإن تكلفة التقييد والإسقاط أكبر بشكل غير متناظر من مكسب التوسّع، وبالتالي تنخفض الإنتاجية الصافية.

متطلبات التصميم المستخلصة من الفشل

لا يعني هذا التشخيص أن الضبط الديناميكي عديم الفائدة في حد ذاته. بل يعني أن اجتماع إشارة عالية الضوضاء ومنحازة نحو الذيل، وتقييد يربط المستأجرين معاً، ومهلة زمنية صارمة، يمكن أن يجعل التحكم الساذج بعتبة ثابتة أسوأ فعلياً من التحكم الثابت. من هنا، يستخلص المؤلفون أربعة متطلبات تصميم يجب أن يستوفيها أي متحكم عميل فعّال. يجب تقدير إشارة الازدحام بشكل متين اعتماداً على سجل قياسات أطول أمداً وتقديرات ثقة (confidence estimates)، بدلاً من مئينات خام ضمن نافذة قصيرة. ويجب أن تكون القرارات متمايزة لكل مستأجر، لا مبنية على إشارة عامة تجمع المستأجرين معاً. كما يجب مراعاة التكلفة غير المتناظرة بين التقييد والتوسّع بشكل صريح، والاستفادة من سياق إضافي لا يمكن التعبير عنه بعتبة رقمية ثابتة، مثل التعرف على أنماط التدفقات المفاجئة (burst patterns) أو بيانات وصفية خاصة باتفاقية مستوى الخدمة لكل مستأجر. والواقع أن استعادة نموذج العميل المتمايز البديل لنحو نصف الخسارة مقارنة بالمتحكم الساذج، تشير إلى أن هذا الاتجاه قد يكون صحيحاً بالفعل. غير أن المؤلفين يوضحون بصراحة أنه، بما أن كلاً من درجة الترابط ونوع الإشارة تغيّرا في آن واحد، فلا يمكن لهذه التجربة وحدها أن تفصل أيّهما ساهم في هذا التعافي.

ما تتركه هذه الورقة للشركة والمجتمع والعلم

بالنسبة إلى ThakiCloud، ما تتركه هذه الدراسة الآن ليس توفيراً مؤكداً في التكلفة، بل بروتوكولاً تجريبياً قابلاً للتكرار وقابلاً للتطبيق مباشرة على مجموعتنا من H200 متعددة المستأجرين، وتحذيراً محدداً من أن نهجاً ساذجاً قد يؤدي في الواقع إلى خسارة. وقد اكتمل الهيكل التجريبي (harness) نفسه بالفعل، بحيث يكفي، فور استعادة الوصول إلى المجموعة، استبدال دالة قرار عميل نموذج لغوي كبير فعلية داخل هذا البروتوكول. وعلى نطاق أوسع، كلما تطورت منهجيات تقليل هدر الموارد في مجمعات وحدات معالجة الرسوميات المشتركة، انفتح مسار عملي أمام المؤسسات الصغيرة أيضاً للوفاء باتفاقيات مستوى الخدمة على مجموعات مشتركة، وهو ما يفيد كفاءة الطاقة والتكلفة في بنية الاستدلال التحتية بشكل عام. أما من الناحية العلمية، فإن الإسهام يكمن في الصياغة الصريحة لحلقة تحكم يراقب فيها عميل نموذج لغوي كبير قياسات النظام في الوقت الفعلي ويعيد ضبط معاملات الخدمة الفائقة (serving hyperparameters) عبر الإنترنت، وفي التشخيص الكمي لأنماط فشلها من خلال محاكاة قابلة للتكرار. وتُعد هذه الورقة أيضاً جزءاً من سلسلة الأبحاث التي واصلتها ThakiCloud على نفس الأساس القائم على Kueue ووحدات معالجة الرسوميات. فمقارنة بـ ABJ-Gate، التي تجدول ميزانية أخذ العينات لنموذج الحَكَم (judge model)، وبـ Attested Confidential Sovereign Inference، التي تتناول التصديق عن بعد (remote attestation) لبيئة تنفيذ موثوقة (TEE) عند لحظة القبول، وبورقة “Escalate or Act?” التي تتناول قرارات ثنائية بين التصعيد أو التحرك إزاء حوادث منفصلة نادرة، تتميز هذه الورقة عنها جميعاً بتناولها مسألة مختلفة نوعياً، وهي التحكم المتعدد الأهداف في الوقت الفعلي الذي يُعاد ضبطه باستمرار على مدى ثوانٍ.

القيود

القيود التي تكشفها هذه الورقة عن نفسها واضحة. وأهمها أنه لا يوجد أي تحقق فعلي على عتاد حقيقي بأي شكل من الأشكال، إذ لم يُنفَّذ البروتوكول التجريبي بسبب تعذر الوصول إلى سياق المجموعة المستهدفة، ولم يُقَس أي رقم في الورقة على وحدة معالجة رسوميات فعلية. كما تبسّط المحاكاة الرموز (tokens) وذاكرة التخزين المؤقت KV إلى مجرد عدد فتحات عددي واحد (single scalar slot count)، دون أن تنمذج ديناميكيات مرحلتَي التعبئة المسبقة وفك الترميز (prefill/decode) أو ضغط الذاكرة، بل إن إشارة استخدام الذاكرة نفسها ليست سوى قيمة بديلة (proxy) لإشغال الفتحات، لا قياساً فعلياً لذاكرة الجهاز. كما اقتصر اختبار أنواع المستأجرين على نمطين اصطناعيين فقط لحركة المرور، لذا قد لا تعمم أنماط الفشل المكتشفة على مزيج آخر من حركة المرور. وسياسة العميل داخل المحاكاة أيضاً نموذج بديل مكتوب يدوياً وليس نموذجاً لغوياً كبيراً فعلياً، ولأن درجة الترابط ونوع الإشارة تغيّرا معاً في آن واحد، فلا يوجد حتى الآن دليل مُتحقَّق منه على أن عميلاً فعلياً قائماً على نموذج لغوي كبير سيستوفي متطلبات التصميم المستخلصة في القسم الرابع. ويوضح المؤلفون أيضاً بصراحة أنهم اكتفوا بالإبلاغ عن المتوسط والانحراف المعياري عبر 20 بذرة عشوائية، دون إجراء أي اختبار للدلالة الإحصائية (statistical significance). ولهذه الأسباب، تضع هذه الورقة نفسها لا كنتيجة مُتحقَّق منها، بل كصياغة رياضية وبروتوكول ومحاكاة تحذيرية.

يمكن الاطلاع على صفحة تفاصيل الورقة البحثية من هنا: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-21-agent-dynamic-batch-tuning-vllm