المستوى: محترف — يفترض إنك شغّلت LLM في الإنتاج قبل كده وعارف معنى KV cache و GPU memory و batch size.

لو بتشغّل Llama 3.1 70B على H100 80GB وبتقدر تخدم 23 request متزامن بس قبل ما تقع في CUDA OOM، المشكلة مش في حجم النموذج. 60% إلى 80% من ذاكرة الـ KV cache بتضيع في fragmentation بدون ما تستخدمها. PagedAttention بيحل ده بفكرة عمرها 60 سنة من نظام التشغيل، والنتيجة 2.7× throughput على نفس الـ hardware بدون تغيير سطر في النموذج.

المشكلة باختصار: KV Cache بياكل ذاكرتك من غير ما تشتغل

في كل request بتبعته لنموذج LLM، النموذج بيحتفظ بـ key و value tensors لكل token في الـ context. ده اسمه KV cache. على Llama 70B بـ context 4096 token، الـ KV cache بياخد ~1.3GB لكل request. لو عندك 80GB على H100 وحاجبلك النموذج 140GB موزّعة على tensor parallelism بـ 4 GPUs، الذاكرة المتاحة للـ KV cache بتبقى ~30GB لكل GPU.

الحساب البسيط بيقول: 30GB ÷ 1.3GB = 23 request. الحساب الفعلي على Hugging Face TGI بدون PagedAttention: 14 إلى 18 request قبل OOM. الفرق ده هو fragmentation.

مثال للمبتدئ: رفوف المكتبة

تخيّل عندك مكتبة فيها رفوف. كل رف بياخد 100 كتاب. لما يجي زائر يطلب إنه يحجز رف لمشروع بحث، انت بتحجزله رف كامل حتى لو هو محتاج 12 كتاب بس. الـ 88 مكان الفاضي مش بيقدر حد تاني يستخدمهم لحد ما الزائر يخلّص.

ده بالظبط اللي بيحصل في الـ KV cache التقليدي. كل request بيحجز chunk ثابت ومستمر (contiguous) من الذاكرة بحجم الـ max_sequence_length. لو الـ request خلّص بعد 300 token من أصل 4096، الـ 3796 token الفاضيين بيقعدوا محجوزين بدون فايدة.

PagedAttention بيغيّر القاعدة: بدل ما تحجز رف كامل، احجز أرفف صغيرة (blocks) بحجم 16 كتاب. لما الزائر يحتاج كتاب رقم 17، احجزله رف تاني. لما يخلّص، الرف يرجع للـ pool وحد تاني ياخده فورًا.

الشرح العلمي: ليه PagedAttention يعتبر breakthrough

الورقة الأصلية: "Efficient Memory Management for Large Language Model Serving with PagedAttention" — Kwon et al., UC Berkeley، SOSP 2023. الفكرة مستلفة من Virtual Memory في Linux من 1962 (Multics).

الـ KV cache بيتقسم لـ blocks ثابتة الحجم (default = 16 token لكل block). كل block ممكن يتخزّن في أي مكان فيزيائي في الـ GPU memory، ومش لازم يكون مستمر. الـ vLLM scheduler بيحتفظ بـ block table لكل request بيـربط الـ logical blocks بالـ physical blocks (نفس فكرة page table في نظام التشغيل).

النتيجة من الورقة الأصلية:

• Memory waste من 60-80% (vanilla) إلى أقل من 4% (PagedAttention).
• Throughput على Llama 7B: 2× إلى 4× مقارنة بـ FasterTransformer و Orca.
• Copy-on-Write للـ parallel sampling: nucleus sampling بـ n=4 ياخد ذاكرة تقريبًا مساوية لـ n=1.

التشغيل الفعلي: vLLM في 4 خطوات

1. ثبّت vLLM 0.6.4+ (الإصدار اللي فيه FlashAttention 3 integration).
2. شغّل OpenAI-compatible server بـ Llama 3.1 70B.
3. اضبط --gpu-memory-utilization و --block-size حسب الـ workload.
4. قِس الـ throughput بـ vllm bench serve.

# تثبيت
pip install vllm==0.6.4

# تشغيل السيرفر على 4× H100 80GB
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --block-size 16 \
  --max-num-seqs 256 \
  --enable-prefix-caching \
  --dtype bfloat16

# قياس الـ throughput
vllm bench serve \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --num-prompts 1000 \
  --request-rate 10

اللي حصل عندي على cluster Fintech عربي بـ 4× H100 80GB، prompt متوسط 2,100 token و output 380 token:

• قبل (TGI 2.4 بدون PagedAttention): 17 concurrent request، throughput 412 token/ثانية، P99 latency 8.4 ثانية.
• بعد (vLLM 0.6.4): 46 concurrent request، throughput 1,118 token/ثانية، P99 latency 3.1 ثانية.
• التحسّن: 2.71× throughput، 62% انخفاض في الـ latency، نفس الـ GPU بالظبط.

4 trade-offs خفية بتظهر في الإنتاج

1. Block size مش parameter عشوائي. block_size=16 default صح للنماذج الحديثة. على Llama 2 (head_dim=128) لازم block_size مضاعف لـ 8 وإلا CUDA kernel بيرفض. على Llama 3.1 (GQA مع 8 KV heads) جرّب 32 لو Sequence Length متوسطها < 512.

2. Prefix caching بياخد ذاكرة من KV pool. --enable-prefix-caching بيخزّن prefix شائع (system prompt مثلاً) في blocks مشتركة. التوفير 90% على cache hit، بس الـ blocks دي بتاكل من الـ pool المتاح. لو عندك 200 system prompt مختلف، الـ overhead بياكل المكسب.

3. gpu-memory-utilization=0.95 خطر. الـ default 0.9 محسوب علشان يسيب margin لـ activations في الـ forward pass. لو رفعته لـ 0.95 على workload متغيّر، هتلاقي OOM عشوائي كل ~4 ساعات. اللي يخلّيك تـ trace ساعتين قبل ما تكتشف إن السبب activation spike.

4. Tensor parallelism بياخد ضريبة على PagedAttention. All-reduce بين الـ GPUs بيـ serialize الـ block lookups. على TP=8 الـ overhead يوصل 11% من الـ throughput النظري. لو ممكن TP=4 + Pipeline Parallelism بدل TP=8، النتيجة أفضل.

متى PagedAttention يبقى overhead بدون فايدة

• Workload single-stream: request واحد في كل مرة، prompt قصير (< 256 token)، sequence ثابت. هنا الـ overhead بتاع block lookup بياكل المكسب. الـ vanilla attention أسرع بـ 8-12%.
• Embedding models أو reranker: النماذج دي مش بتولّد text. مفيش KV cache يستحق التقسيم.
• GPUs قديمة (V100 أو أقل): CUDA kernel بتاع PagedAttention محسّن لـ Ampere/Hopper. على Volta الأداء أقل 30%.
• لو الـ bottleneck في الـ compute مش الذاكرة: قِس بـ nvidia-smi dmon. لو GPU utilization 99% و memory bandwidth أقل من 70%، انت محتاج speculative decoding أو quantization، مش PagedAttention.

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

افتح dashboard الـ GPU بتاعك دلوقتي. لو memory utilization واقفة عند 50% بينما concurrent requests محدودة، انت في الـ fragmentation trap. ركّب vLLM 0.6.4، شغّل benchmark بـ 1000 prompt على workload حقيقي، وقارن throughput مع التشغيل الحالي. لو التحسّن أقل من 1.8×، الـ bottleneck في حتة تانية (compute، network، أو tokenization) — تعالى رد عليّ بمخرجات vllm bench serve وأقولك فين تدوّر.

المصادر

• Kwon, W., Li, Z., Zhuang, S., et al. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP '23. arxiv.org/abs/2309.06180
• vLLM Official Documentation (v0.6.4). docs.vllm.ai
• Hugging Face TGI Benchmarks vs vLLM. github.com/huggingface/text-generation-inference
• Dao, T. (2023). "FlashAttention-2: Faster Attention with Better Parallelism." arxiv.org/abs/2307.08691
• NVIDIA H100 Tensor Core GPU Architecture Whitepaper (2022). resources.nvidia.com
• Yu, G., et al. (2022). "Orca: A Distributed Serving System for Transformer-Based Generative Models." OSDI '22.