الـ KV Cache وPagedAttention: ليه سيرفر الـ LLM بيخنق عند 10 مستخدمين

# تثبيت وتشغيل سيرفر متوافق مع OpenAI API
pip install vllm

vllm serve meta-llama/Meta-Llama-3-8B-Instruct \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --enable-prefix-caching \
  --max-num-seqs 256

الأسطر المهمة: --gpu-memory-utilization 0.90 بيقول لـ vLLM ياخد 90% من الذاكرة كـ KV Cache pool مشترك بين كل الطلبات. --enable-prefix-caching بيعيد استخدام الكتل لو كذا طلب بيشتركوا في نفس البداية (زي نفس الـ system prompt). --max-num-seqs بيحدد أقصى عدد طلبات متوازية في الدفعة.

الأرقام: قد إيه بيفرق فعلًا

على نفس كرت الشاشة، وبنفس مستوى الـ latency، النتايج المقاسة بتتراكم على تلات مستويات:

• الدفعات المستمرة (continuous batching) لوحدها بتوصّل لحوالي 5 أضعاف مقارنة بحلقة PyTorch ساذجة، لأنها بتضيف طلبات جديدة للدفعة فور ما يخلّص أي طلب بدل ما تستنى الدفعة كلها.
• إضافة PagedAttention بتضاعف الاستفادة من الذاكرة، فبيقفز عدد الطلبات المتوازية والإنتاجية توصل حوالي 14 ضعف.
• مع prefix caching فوقهم، الرقم الرسمي من إطلاق vLLM بيوصل حتى 23–24 ضعف على مسارات تمثيلية.

ورقة vLLM الأصلية بتذكر تحسّن إنتاجية 2 لـ 4 أضعاف مقارنة بأنظمة متقدمة زي FasterTransformer وOrca عند نفس الـ latency. الرقم 24× بيكون مقارنة بالتنفيذ الساذج مش بالأنظمة المحسّنة. خلّي بالك إن الأرقام دي تعتمد على شكل الحِمل: طلبات قصيرة كتير بتستفيد أكتر من طلبات طويلة قليلة.

الـ trade-offs اللي لازم تعرفها

مفيش حل ببلاش. لمّا تعلّي --gpu-memory-utilization لـ 0.95 عشان تكسب سعة كاش أكبر، بتقلل الهامش المتاح لعمليات الـ CUDA المؤقتة، فممكن تقابل OOM تحت الضغط أو مع سياقات طويلة مفاجئة. المكسب: طلبات متوازية أكتر. الخسارة: هامش أمان أقل. القاعدة العملية: ابدأ بـ 0.90 وراقب الـ OOM قبل ما تعلّيه.

الـ prefix caching بيكسّبك سرعة كبيرة لو طلباتك بتشترك في بادئة طويلة، لكنه بياكل من الـ pool. لو طلباتك متنوعة وبلا بادئة مشتركة، بتدفع تكلفة إدارة من غير مكسب يُذكر.

متى لا تستخدم هذه الطريقة

لو عندك مستخدم واحد أو اتنين بس (batch size = 1)، مكسب PagedAttention بيبقى هامشي؛ الفايدة الأساسية بتظهر مع التوازي العالي. لو بتخدم عبر API خارجي (OpenAI أو Anthropic)، الموضوع ده متكفّل بيه من عندهم ومش شغلك. ولو الـ workload بتاعك offline batch (مش زمن حقيقي)، ممكن تكتفي بإعدادات throughput بسيطة من غير ما تدخل في ضبط الذاكرة الدقيق.

الخطوة التالية

شغّل سيرفرك الحالي وابعت 100 طلب متوازي بـ ab أو vllm bench، وسجّل الـ throughput والـ P95 latency. بعدين علّي --gpu-memory-utilization من القيمة الحالية لـ 0.90 وفعّل --enable-prefix-caching، وأعد نفس القياس. لو الإنتاجية اتحسّنت والـ latency ثابت، انت كسبت سعة مجانية. لو قابلت OOM، نزّل القيمة 0.05 وكرّر.

المصادر

• Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (vLLM), SOSP 2023 — الورقة الأصلية اللي قاست الهدر 60–80% ونزّلته لأقل من 4%.
• vLLM Documentation — أوامر vllm serve، ضبط gpu-memory-utilization، وprefix caching.
• معايير إنتاج على كروت H100 (2025–2026) لتقدير مكاسب الدفعات المستمرة وchunked prefill التراكمية.