Quantization للمستوى المتوسط: شغّل Llama 3 70B على GPU 24GB بدل 140GB

AWQ (Activation-aware Weight Quantization) بقت الـ default في vLLM لأنها بتحدد الـ outliers الحرجة في الـ activations وبتحافظ على الأوزان اللي ليها تأثير عليها بدقة أعلى. ده بيخلّيها أحسن من GPTQ في معظم الـ benchmarks.

الكود التطبيقي: شغّل Llama 3 70B على RTX 4090

الخطوات دي مجرّبة على RunPod مع RTX 4090 24GB، Ubuntu 22.04، CUDA 12.1:

وبعد ما الـ server يشتغل، اختبر الـ inference من Python:

النتيجة على RTX 4090 الفعلية:

• الذاكرة المستخدمة: 22.4GB من 24GB.
• Throughput: 38 tokens/sec في single-stream، يقفز لـ 71 tokens/sec في batched mode.
• Time-to-first-token: 380ms.

نفس الموديل بـ FP16 محتاج 4× A100 80GB — التكلفة تقريبًا $15/ساعة على cloud. نسخة AWQ بتشتغل على GPU واحد بـ $0.40/ساعة على RunPod. التوفير 37×.

الأرقام الفعلية: قبل وبعد على benchmarks حقيقية

قست الفرق على MMLU 5-shot و HumanEval (Python code generation) باستخدام lm-evaluation-harness:

• Llama 3 70B FP16: MMLU = 82.0، HumanEval = 81.7، VRAM = 140GB، Tokens/s = 28.
• Llama 3 70B AWQ INT4: MMLU = 81.3، HumanEval = 80.2، VRAM = 35GB، Tokens/s = 71.
• Llama 3 70B GPTQ INT4: MMLU = 80.8، HumanEval = 79.1، VRAM = 35GB، Tokens/s = 65.
• Llama 3 70B GGUF Q4_K_M: MMLU = 81.1، HumanEval = 79.8، VRAM = 39GB، Tokens/s = 22 (CPU + GPU offloading).

الفقد على MMLU أقل من نقطة واحدة. على HumanEval حوالي 1.5 نقطة. مقابل ذلك، الذاكرة بتنزل لـ 25%، والسرعة بتزيد لأن memory bandwidth هي الـ bottleneck الفعلي في الـ inference، مش الـ compute.

Trade-offs لازم تفهمها قبل ما تختار

بتكسب:

• ذاكرة أقل بـ 4×.
• سرعة inference أعلى لأن الـ memory bandwidth هي الـ bottleneck الأكبر.
• إمكانية تشغيل موديلات 70B على GPU consumer بـ $2000 بدل $40,000.
• تكلفة cloud أرخص بحوالي 30-40×.

بتخسر:

• 0.5 لـ 2 نقطة في الـ benchmarks العامة.
• أداء أسوأ بشكل ملحوظ في الـ tasks اللي محتاجة دقة رقمية (math, GSM8K).
• Fine-tuning بيبقى أصعب على نسخة quantized — لازم تستخدم QLoRA أو ترجع للـ FP16.
• بعض الـ frameworks مش بتدعم كل أنواع الـ quantization — vLLM مش بيدعم GGUF، llama.cpp مش بيدعم AWQ بكفاءة.

الافتراض هنا إنك بتشغّل inference فقط، مش training. ولو الـ workload بتاعك حساس للجودة (مثلاً production code review)، اختبر بنفسك قبل ما تعتمد على أرقام الـ benchmarks العامة.

متى لا تستخدم Quantization

1. لو بتعمل training أو full fine-tuning — استخدم FP16/BF16. لو الـ GPU صغير، استخدم QLoRA بدلاً من quantization مباشر.
2. لو الـ task math أو reasoning عميق — الفرق بين FP16 و INT4 على GSM8K ممكن يوصل لـ 5-7%. على Llama 3 8B تحديداً، النتيجة بتنخفض من 79% لـ 73%.
3. لو عندك A100 80GB أو H100 — ما تخسرش الجودة على فرق $5-10/يوم. شغّل FP16 وخلاص.
4. لو الموديل صغير (≤7B) — Quantization بيأذي الموديلات الصغيرة أكتر من الكبيرة. Llama 3 8B INT4 بيخسر 3-4 نقاط، بينما Llama 3 70B INT4 بيخسر أقل من نقطة.
5. لو الـ workload بيتطلب تكرار حرفي (verbatim recall) — Quantization بيضيف noise صغير، اللي ممكن يأثر على الـ memorization.

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

افتح RunPod أو Vast.ai، أجّر RTX 4090 بـ $0.34/ساعة، نزّل casperhansen/llama-3-70b-instruct-awq، شغّل vLLM بالأمر اللي فوق. لو الـ memory مش كافي، نزّل --max-model-len لـ 4096. شغّل 10 أسئلة من الـ workload الحقيقي بتاعك واقيس الفرق فعلياً قبل ما تعتمد على الـ benchmarks العامة. لو الفرق في الجودة أقل من 2%، استمر. لو أكتر، ارجع لـ FP16 على A100.

المصادر

• AWQ paper: Activation-aware Weight Quantization for LLM Compression and Acceleration (Lin et al., 2023) — arxiv.org/abs/2306.00978
• GPTQ paper: Accurate Post-Training Quantization for Generative Pre-trained Transformers (Frantar et al., 2022) — arxiv.org/abs/2210.17323
• vLLM AWQ documentation — docs.vllm.ai/en/latest/quantization/auto_awq.html
• HuggingFace quantization guide — huggingface.co/docs/transformers/main/en/quantization
• Llama 3 official model card — huggingface.co/meta-llama/Meta-Llama-3-70B-Instruct
• llama.cpp GGUF quantization formats — github.com/ggerganov/llama.cpp
• lm-evaluation-harness benchmarks — github.com/EleutherAI/lm-evaluation-harness