أبرز النقاط
- عمليات prefill الطويلة تحجب توليد التوكنات للمستخدمين الآخرين وتضرب p99 بشدة
- chunked prefill يقسّم المدخلات الطويلة لأجزاء صغيرة تتداخل مع decode فتنخفض فترات التوقف
- PagedAttention يحلّ مشكلة الذاكرة لا الجدولة — لذا تحتاج كلتا التقنيتين معاً
إليك سيناريو تكرّر معي أكثر من مرة: أختبر نموذجاً، تبدو الأرقام رائعة، p50 منخفض وسرعة توليد التوكنات عالية. ثم تصل حركة المرور الحقيقية ويقفز p99 فجأة إلى خمسة أو عشرة أضعاف ما قسته. النموذج ذاته، والـGPU ذاتها — فما الذي حدث؟
الإجابة المختصرة: اختبار الأداء كان نظيفاً أكثر من اللازم. معظم اختبارات الحمل ترسل طلبات بمعدل ثابت وأحجام متقاربة، بينما حركة المرور الفعلية تأتي دفعات غير منتظمة، تمزج مطالبات قصيرة بأخرى ضخمة، وتشارك الـGPU بين عشرات المستخدمين في الوقت نفسه. تحت هذا الضغط، يوجد عامل واحد يؤذي الذيل أكثر من القدرة الحسابية الخام: عملية prefill طويلة تحجب عمليات decode الجارية.
لماذا لا تكفي الدُفعات المستمرة وحدها؟
إذا كنت تخدم نماذج لغوية كبيرة، فقد انتقلت حتماً من الـstatic batching التقليدي. في تلك الطريقة القديمة يجمع الخادم دفعة، يشغّلها، ولا يسمح لأي طلب بالمغادرة حتى ينتهي أبطأ طلب في المجموعة — أي أن الطلبات السريعة تبقى عالقة تنتظر البطيئة، ما يهدر وقت الـGPU ويضرب زمن الاستجابة.
الدُفعات المستمرة (continuous batching) عالجت جزءاً كبيراً من ذلك. بدلاً من تثبيت مجموعة واحدة طوال التشغيل، يعيد المجدول قراره قبل كل خطوة: الطلب المنتهي يغادر فوراً ويحرّر ذاكرته، والطلب المنتظر يدخل حالما تتوفر مساحة. هذه الفكرة جاءت من ورقة Orca عام 2022 ويستخدمها vLLM وأغلب الخوادم الحديثة.
لكنها تترك فجوة — وتلك الفجوة هي موطن الذيل (tail latency). السبب أن prefill وdecode نوعان مختلفان جذرياً من العمل:
- Prefill: يعالج كل توكنات المدخلات دفعة واحدة، عبء حسابي مكثّف.
- Decode: يولّد توكناً واحداً في كل خطوة، أخفّ وأسرع بكثير.
حتى مع الدُفعات المستمرة، يميل الخادم لتشغيل prefill كوحدة واحدة كبيرة. حين تدخل مطالبة طويلة إلى الدفعة، تستغرق تلك التكرارة وقتاً، وكل عمليات decode الجارية تنتظر. المستخدمون الذين كانوا يستلمون توكناتهم بسلاسة يواجهون توقفاً مفاجئاً — وهذا التوقف هو الـp99 الذي يظهر في لوحة المراقبة.
ما الذي يفعله PagedAttention حقاً؟
PagedAttention — الابتكار الأساسي في vLLM من فريق UC Berkeley عام 2023 — يعامل ذاكرة KV cache كذاكرة افتراضية في نظام تشغيل: بدلاً من حجز كتلة كبيرة لكل تسلسل، يقسّم الذاكرة إلى كتل صغيرة يمكن أن تتوزع في أي مكان على الـGPU. النتيجة؟ تقليل الهدر الناتج عن التجزئة، والقدرة على إبقاء تسلسلات أكثر في الذاكرة، ومشاركة الـcache بين تسلسلات ذات بادئة مشتركة.
لكن أين يدخل زمن الاستجابة؟ بشكل غير مباشر فقط. قبل PagedAttention كانت الذاكرة هي العائق الأول، لأن كل تسلسل يحتاج حجزاً مسبقاً لأسوأ طول محتمل. حين تزول هذه القيود، يصبح الحدّ الجديد هو الجدولة نفسها — وهنا يظهر دور chunked prefill.
كيف يعمل chunked prefill — ولماذا يكلّفك إن لم تضبطه؟
الفكرة بسيطة: بدلاً من تشغيل prefill لمطالبة طويلة ككتلة واحدة، نقسّمها إلى أجزاء صغيرة (chunks). بين كل جزء وآخر يستطيع المجدول إدخال خطوات decode للمستخدمين الآخرين. النتيجة أن فترات التوقف تتقلص بشكل ملموس.
- تقليل 2-4× في زمن الاستجابة للطلبات ذات السياق الطويل وفق تقارير المستخدمين.
- زيادة استخدام GPU لأن decode وprefill يتداخلان بدل الانتظار.
- مفاضلة: أجزاء أصغر تعني حمل جدولة أعلى؛ الضبط (chunk size) يعتمد على طول المدخلات النموذجي في حمولتك.
لتفعيل chunked prefill في vLLM، تضيف الخيار --enable-chunked-prefill مع تحديد حجم الجزء المناسب. ابدأ بقيمة افتراضية ثم راقب p99 وعدّلها حسب توزيع أطوال مطالباتك.
سياسة الجدولة: القرارات التي تشكّل الذيل
vLLM يدعم سياسات جدولة متعددة — أبسطها FCFS (First Come First Served). لكن حين تختلط أطوال المطالبات بشدة، قد تستفيد من سياسات ترجّح الطلبات القصيرة أو تحدّ من طول prefill المسموح في كل تكرارة. الهدف واحد: منع طلب واحد ضخم من احتكار الـGPU لفترة تكفي لرفع p99 للجميع.
كيف تحدد أين يقع عنق الزجاجة فعلياً؟
قبل تغيير أي إعداد، اجمع البيانات. راقب:
- توزيع أطوال المدخلات: هل لديك مطالبات طويلة متطرفة؟
- نسبة وقت prefill إلى decode في كل دفعة.
- استخدام ذاكرة KV cache — هل تقترب من الحدّ؟
- طول قائمة الانتظار وزمن الانتظار فيها.
إن كان prefill يستهلك وقتاً غير متناسب وp99 أعلى بكثير من p50، فالحلّ غالباً chunked prefill. إن كانت الذاكرة هي العائق، ابدأ بتفعيل PagedAttention (مفعّل افتراضياً في vLLM) وتأكد من عدم الإفراط في حجم الدفعة.
رأي Logicity
المشكلة الحقيقية ليست في vLLM بحدّ ذاته، بل في الفجوة بين اختبارات الأداء المثالية وحركة المرور الإنتاجية الفوضوية. إن كنت تقارن بين حلول الاستضافة، لاحظ أن خدمات مثل Anyscale Endpoints وTogether AI وModal تقدّم طبقات جدولة مُدارة فوق vLLM مع chunked prefill مفعّل افتراضياً — مقابل تسعير يبدأ غالباً من $0.0002 لكل ألف توكن. أما إن كنت تدير البنية التحتية بنفسك، فخصّص وقتاً لضبط chunk size بناءً على توزيع أطوال مطالباتك الفعلي، لأن الإعداد الافتراضي قد لا يناسب حمولتك.
أسئلة شائعة
الأسئلة الشائعة
ما الفرق بين p50 وp99 في زمن الاستجابة؟
p50 هو الزمن الذي تنتهي عنده 50% من الطلبات، أي الوسيط. p99 هو الزمن الذي تنتهي عنده 99% من الطلبات — يمثّل أسوأ 1% من التجارب. في الإنتاج، p99 هو ما يشعر به المستخدمون الأكثر تضرراً.
هل يحلّ PagedAttention مشكلة زمن الاستجابة مباشرة؟
لا. PagedAttention يحلّ مشكلة إدارة الذاكرة ويسمح بدفعات أكبر، لكنه لا يعالج جدولة prefill/decode. تحتاج chunked prefill وسياسة جدولة مناسبة لمعالجة الذيل.
كيف أختار حجم chunk المناسب في chunked prefill؟
ابدأ بالقيمة الافتراضية (غالباً 512 أو 1024 توكن)، ثم راقب p99. إن بقي مرتفعاً مع مطالبات طويلة، قلّل الحجم. إن زاد الحمل الإضافي للجدولة، ارفعه. الضبط يعتمد على توزيع أطوال مطالباتك.
هل أستطيع استخدام vLLM على GPU واحدة فقط؟
نعم، vLLM يعمل على GPU واحدة. لكن مع حمولات كبيرة قد تحتاج توزيع tensor parallelism على عدة GPUs لتجنب اختناق الذاكرة والحساب.
الخلاصة
p99 المرتفع في الإنتاج ليس لغزاً — إنه نتيجة مباشرة لعمليات prefill طويلة تحتكر الـGPU وتحجب decode للمستخدمين الآخرين. الحلول موجودة: chunked prefill يقسّم العمل، وسياسات الجدولة تمنع الاحتكار، وPagedAttention يزيل قيود الذاكرة ليفسح المجال لهذه التحسينات. الخطوة الأولى دائماً: اجمع بيانات حمولتك الحقيقية قبل أن تبدأ الضبط.
هل تحتاج مساعدة في التطبيق؟
إن كنت تواجه تحديات في ضبط vLLM أو تحتاج استشارة حول بنية خدمة النماذج اللغوية، تواصل مع فريق Logicity للحصول على توجيه تقني متخصص.
عمر حسن
كاتب تقني وابتكار
أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.
