التجميع المستمر: طلبات أكثر ضمن حدود زمن الاستجابة

يتيح التجميع المستمر لوحدة معالجة الرسوميات المشتركة (GPU) استقبال طلبات جديدة بين خطوات التوليد، فلا تظل السعة التي تحررها المهام القصيرة معطّلة إلى أن تنتهي المهام الطويلة. وقد شرحت ورقة Orca التأسيسية، التي نشرها Yu وزملاؤه في مؤتمر OSDI عام 2022، هذا التحول في الجدولة. يمكن لهذه الآلية أن ترفع إجمالي عدد الرموز المولّدة في الثانية عند تزامن الطلبات، لكن زيادة انشغال الخادم لا تعني بالضرورة أن يحصل كل مستخدم على استجابة أسرع.

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

جرى التحقق من دعم الخوادم وإعداداتها الواردة أدناه بالرجوع إلى الوثائق المنشورة لدى مطوّريها في 25 أكتوبر 2026. أما مثال الجدولة فهو للتوضيح، وليس اختبار أداء على عتاد فعلي.

كيف يعمل التجميع المستمر؟

يغيّر التجميع المستمر مجموعة الطلبات النشطة بينما يستمر التوليد. يغادر الطلب الذي اكتمل، ويمكن لطلب منتظر أن يدخل عندما تسمح سعة المُجدوِل بذلك. وقد تصادف هذه الآلية أيضاً باسم in-flight batching أو iteration-level batching.

يعالج النموذج اللغوي الكبير، أو LLM، الموجّه أولاً في مرحلة المعالجة الأولية (prefill)، ثم يولّد تتمة النص في مرحلة فك الترميز (decode). وفي فك الترميز المعتاد ذي الانحدار الذاتي، ينتج كل طلب نشط رمزه التالي، أي وحدة نصية، خلال خطوة توليد. ويحدد المُجدوِل الطلبات التي ستشارك في الخطوة التالية. يشرح دليل استدلال النماذج اللغوية الكبيرة هاتين المرحلتين بمزيد من التفصيل.

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

وللتشبيه حدوده: فعلى مُجدوِل GPU أن يستوعب أيضاً معالجة الموجّهات وتخصيص الذاكرة ضمن عمله. وجود كرسي شاغر لا يعني أن أي طلب منتظر يستطيع الدخول فوراً.

ماذا أضافت ورقة Orca؟

جعلت Orca التكرار الواحد نقطة اتخاذ قرار الجدولة، بدلاً من انتظار انتهاء الطلب بأكمله. تصف ورقة OSDI 2022، التي أعدّها Gyeong-In Yu وزملاؤه، استدعاء محرك التنفيذ لتكرار واحد للنموذج، ثم إعادة النظر في تشكيل الدفعة.

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

التغيير هنا يطال نظام تقديم النموذج المحيط به. ولا يتطلب تدريب النموذج على الإجابة عن عدة أشخاص في محادثة واحدة.

ما الفرق بين التجميع الثابت والديناميكي والمستمر؟

السؤال الحاسم هو: متى يستطيع طلب جديد الانضمام إلى العمل الجاري؟ فمجرد قبول اتصالات HTTP متزامنة لا يثبت أن تنفيذ النموذج يستخدم التجميع المستمر.

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

التجميع الديناميكي في vLLM: متى يُتخذ قرار الجدولة؟

توثّق vLLM، وهي محرك لتقديم النماذج اللغوية الكبيرة، دعم التجميع المستمر. أما «التجميع الديناميكي» فتسمية أقل دقة. وتستخدم Hugging Face أيضاً تعبيري الجدولة الديناميكية والتجميع الديناميكي لوصف إدخال موجّهات جديدة بدلاً من التي اكتمل توليدها، وذلك في شرحها للتجميع المستمر. لذلك تحقّق مما إذا كان المحرك يقبل عملاً جديداً بين خطوات التوليد، ولا تكتفِ بالحكم من التسمية وحدها.

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

مثال يوضح الجدولة

يمكن لمهمة قصيرة أن تحرر سعة مفيدة بينما تستمر مهمة أطول في التنفيذ. لنتصور خادماً يتيح موضعين لفك الترميز. يحتاج الطلب A إلى 2 من الخطوات الإضافية، ويحتاج B إلى 4، بينما ينتظر C ولديه عمل يستغرق 2 من الخطوات. نتجاهل في هذا المثال المعالجة الأولية وكلفة الجدولة وتغيّر مدة الخطوة.

في الدفعة الثابتة، يبدأ A وB معاً. ينتهي A، لكن C ينتظر اكتمال B قبل أن تبدأ المجموعة التالية. أما في التجميع المستمر، فيستطيع C شغل موضع A بعد انتهائه، ومواصلة العمل بالتوازي مع B.

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

لماذا يرتفع معدل المعالجة، وأين تضع ذاكرة KV حدوده؟

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

قد تبقى GPU مشغولة حتى مع دفعة غير فعّالة. المهم هو مقدار العمل المفيد الذي يُنجز للطلبات خلال هذا النشاط، لا مدى امتلاء رسم بياني لنسبة الاستخدام.

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

كيف تحسّن PagedAttention استغلال الذاكرة؟

يحدد التجميع المستمر ما الذي يُنفّذ؛ وتغيّر PagedAttention طريقة تخزين حالة الانتباه. تصف ورقة vLLM المنشورة عام 2023، التي أعدّها Woosuk Kwon وزملاؤه، تقسيم حالة KV إلى كتل ثابتة الحجم، لا يلزم أن تشغل مواقع متجاورة في الذاكرة الفعلية. وتحافظ خريطة الكتل على الترتيب المنطقي للتسلسل.

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

وتبقى السعة الفعلية هي الحد. فالتوزيع الأفضل لا يتيح استيعاب عدد غير محدود من المحادثات الطويلة. وفي vLLM، قد يؤدي نقص مساحة KV إلى الإيقاف الاستباقي (preemption): إيقاف طلب مؤقتاً ثم إعادة حساب حالته لاحقاً، مما قد يطيل زمن اكتماله. وتشرح وثائق تحسين الأداء هذا السلوك.

ماذا يحدث لزمن الاستجابة؟

قد يقلّ الانتظار في الطابور مع التجميع المستمر، بينما تتباطأ التجربة بعد بدء التنفيذ عندما تكبر الدفعات أو تزدحم. تابع المراحل كلّاً على حدة:

• زمن ظهور أول رمز، أو TTFT: المدة التي ينتظرها المستخدم قبل أن يبدأ ظهور المخرجات.
• الفاصل الزمني بين الرموز: الفجوات بين الرموز بعد بدء البث المتتابع.
• زمن الاستجابة الكلي: المدة التي يستغرقها الطلب كاملاً.

يمكن للطلب الجديد تفادي انتظار انتهاء دفعة ثابتة بأكملها. لكن معالجة موجّه جديد كبير قد تنافس الطلبات الموجودة في مرحلة فك الترميز. وتعتمد تجزئة المعالجة الأولية (Chunked prefill) على تقسيم معالجة الموجّه إلى أجزاء أصغر، ليتمكن المُجدوِل من التناوب بينها وبين التوليد الجاري.

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

التجميع المستمر في النماذج اللغوية: ماذا يتغير مع حجم الحمل؟

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

في التطبيقات التفاعلية، راقب p95، أي المئين 95، إلى جانب الوسيط. فقد يخفي المتوسط الجيد بطئاً تعانيه أقلية من الجلسات. حدّد TTFT وفجوات البث المقبولة انطلاقاً من تجربة المنتج، ثم قِس السعة ضمن تلك الحدود.

خوادم النماذج اللغوية التي تدعم التجميع المستمر وحدودها

توثّق الخوادم الأربعة أدناه دعم التجميع المستمر أو in-flight batching. لكن هذه القدرة المشتركة لا تجعل مُجدوِلاتها أو ميزانيات ذاكرتها أو دعمها للنماذج متكافئة.

التجميع المستمر في vLLM

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

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

SGLang

تدعم SGLang التجميع المستمر، وتوفر إعدادات صريحة للتحكم في قبول الطلبات. وتعرّف وثائق معاملات الخادم كلاً من --max-running-requests و--chunked-prefill-size، وميزانية أوزان النموذج ومجمّع ذاكرة KV التي يتحكم فيها --mem-fraction-static.

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

NVIDIA TensorRT-LLM

تنص NVIDIA TensorRT-LLM صراحة على أن in-flight batching هو نفسه التجميع المستمر والتجميع على مستوى التكرار. وتصف وثائق الميزة معالجة تسلسلات مرحلة السياق ومرحلة التوليد معاً، باستخدام موترات إدخال مرصوصة في التنفيذ الموثّق.

حد الطلبات وميزانية الرموز قيدان منفصلان. وتفصل وثائق مُجدوِل PyTorch أيضاً بين حجز الموارد، بما فيها سعة KV، وبين اختيار الطلبات التي تسمح الموارد بتنفيذها. ولا يستطيع مُجدوِل التجميع أثناء التنفيذ قبول عمل لا يجتاز فحوص السعة هذه.

Hugging Face Text Generation Inference

تدعم Hugging Face Text Generation Inference التجميع المستمر، لكن وضع الصيانة الذي دخل فيه المشروع يغيّر حسابات اختياره لنشر جديد. تقول وثائقه إن المشروع يقبل الآن إصلاحات طفيفة وتحسينات للوثائق وأعمال صيانة محدودة، وتوصي بالاعتماد مستقبلاً على محركات بديلة، منها vLLM وSGLang.

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

أين تبدأ المبالغة في الوعود؟

لا يمنح التجميع المستمر معامل تسريع ثابتاً يمكن نقله من بيئة إلى أخرى. تقيّم ورقتا Orca وPagedAttention أنظمة وأعباء عمل محددة. ولا تعزل نتائجهما تحسناً عاماً يصلح للتطبيق على أي نموذج أو GPU أو نقطة وصول لدى مزوّد.

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

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

ما الذي ينبغي تغييره في العمل بدءاً من الأسبوع المقبل؟

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

1. 1

   حدّد التجربة المطلوبة قبل زيادة الطلبات المتزامنة

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

2. 2

   أعد تشغيل مزيج ممثّل للطلبات

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

3. 3

   سجّل معدل المعالجة مع طابور الانتظار وزمن الاستجابة

   قِس إجمالي رموز المخرجات في الثانية، والطلبات المكتملة والمنتظرة، وحالات الفشل، وTTFT، والفواصل الزمنية بين الرموز. وتوفر vLLM مقاييس مقابلة، منها vllm:num_requests_waiting وvllm:time_to_first_token_seconds وvllm:inter_token_latency_seconds، في وثائق مقاييس بيئة الإنتاج.

4. 4

   اعتمد أعلى حمل يظل محققاً للأهداف

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

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

لشروح عملية عن البنية التحتية للذكاء الاصطناعي وما ينبغي تغييره في منظومتك التقنية، اشترك في النشرة البريدية.