PagedAttention في vLLM: ليه خدمة الـ LLM بتهدر 80% من ذاكرة الـ GPU وإزاي توصل throughput أعلى 24×

الأعلام المهمة هنا:

• gpu-memory-utilization: نسبة ذاكرة الكارت المسموح لـ vLLM يستغلها للـ KV cache. كل ما زادت، يقدر يخدم batch أكبر، بس بتقترب من خطر الـ OOM.
• max-num-seqs: أقصى عدد تسلسلات في الـ batch الواحد. ده اللي بيحدّد سقف التزامن.
• block-size: عدد التوكنز في البلوك. القيمة الأصغر بتقلّل الهدر الداخلي بس بتزوّد overhead إدارة الجدول.
• enable-prefix-caching: بيعيد استخدام بلوكات الـ prompt المشترك بين الطلبات، مفيد جدًا في الـ RAG و الـ system prompts الطويلة.

ولو عايز تستخدمه برمجيًا offline للـ batching بدل السيرفر:

الميزة هنا مش بس الذاكرة. لمّا التهدير بيقلّ، تقدر تحطّ تسلسلات أكتر في نفس الـ batch، والـ continuous batching بيملأ الأماكن الفاضية فور ما طلب بيخلّص بدل ما يستنى الـ batch كله. النتيجة المركّبة هي قفزة الإنتاجية.

الأرقام اللي بيحصل فعلاً

على نفس النموذج ونفس الـ GPU وتحت حِمل عالٍ، فريق vLLM قاس إنتاجية أعلى تصل لـ 24× مقارنة بـ HuggingFace Transformers وحتى 3.5× مقارنة بـ HuggingFace TGI. الفضل الأساسي إن هدر الذاكرة نزل من 60–80% لأقل من 4%، فالـ batch الفعّال بقى أكبر بكتير (المصدر: مدوّنة vLLM وورقة PagedAttention).

سيناريو واقعي: لو عندك A100 80GB بتخدم Llama-3.1-8B لخدمة chatbot، السيرفر التقليدي ممكن يسقّفك عند بضع عشرات من الطلبات المتزامنة قبل ما الذاكرة تخلص. بنفس الكارت، vLLM بيقدر يدفع المئات بسبب البلوكات المتشاركة وقلة الهدر. ده الفرق بين سيرفر واحد وأربع سيرفرات لنفس الحِمل، أي توفير مباشر في الفاتورة.

الـ trade-offs: مفيش حاجة ببلاش

• تعقيد الـ kernel. الذاكرة المبعثرة بتتطلب attention kernel مخصّص يقرأ من بلوكات غير متجاورة. ده overhead بسيط في الـ kernel نفسه، بس المكسب الصافي في الإنتاجية بيغطّيه بكتير.
• ضبط block-size. بلوك أصغر = هدر داخلي أقل بس جداول أكبر و overhead إدارة أعلى. 16 قيمة افتراضية متوازنة، لكن مش مثلى لكل الأحمال.
• خطر الـ OOM. رفع gpu-memory-utilization لـ 0.95+ بيزوّد التزامن، بس أي spike في أطوال التسلسل ممكن يفجّر الذاكرة. الافتراض إن أحمالك متوقّعة نسبيًا.
• prefix caching بياكل ذاكرة. البلوكات المتشاركة بتفضل محجوزة طول ما ليها مرجع، فهو مكسب في الحالات المتكررة وعبء في الأحمال العشوائية تمامًا.

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

PagedAttention والـ continuous batching بيلمعوا تحت تزامن عالٍ. لو حالتك واحدة من دول، المكسب هيكون هامشي أو معدوم:

• طلب واحد في المرة (batch=1) بزمن استجابة حسّاس جدًا للـ single-stream. هنا الـ batching مش بيشتغل أصلًا.
• تسلسلات قصيرة جدًا وثابتة الطول، فالهدر الأصلي بسيط ومفيش كتير تكسبه.
• النموذج لا يسع في الذاكرة حتى بعد الـ quantization، فمشكلتك مشكلة سعة مش إدارة.

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

شغّل النموذج بتاعك على vLLM مرة بـ --max-num-seqs 256 ومرة بقيمة أقل، وقيس الـ throughput بأداة زي vllm bench serve. بُص على عدّاد GPU KV cache usage في اللوج: لو قريب من 90% والـ throughput بيزيد مع رفع max-num-seqs، يبقى انت في النطاق اللي PagedAttention بتتألق فيه. لو لقيت OOM، نزّل gpu-memory-utilization خطوة وارجع قيس.

المصادر

• Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", arXiv:2309.06180, 2023 — arxiv.org/abs/2309.06180.
• vLLM Blog, "vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention" — blog.vllm.ai.
• vLLM Documentation — docs.vllm.ai.
• Red Hat Developer, "How PagedAttention resolves memory waste of LLM systems", 2025 — developers.redhat.com.