هذا المقال يتطلب مستوى: محترف. الكلام ده موجّه لمن نشروا نماذج LLM على GPU في الإنتاج، يعرفون vLLM أو TGI، ومتعاملين مع مفاهيم KV cache، attention layers، والـ autoregressive generation. لو لسه بتجرّب أول API call على Claude أو OpenAI، ابدأ بمقالات Tool Use أو Prompt Caching الأول.

لو throughput الـ Llama 3.1 70B بتاعك واقف عند 38 token/ثانية على H100 SXM، المشكلة مش في الـ GPU ومش في الـ batch size. الـ autoregressive decoding بطبيعته بيولّد token واحد في كل forward pass، والـ GPU بيقعد فاضي 70% من الوقت بسبب memory-bound operations. Speculative Decoding بيرفع الرقم لـ 91 token/ثانية على نفس الـ workload بدون لمس النموذج ولا تخفيض جودة المخرجات حرف واحد.

Speculative Decoding: تسريع الاستدلال بدون تغيير النموذج الأصلي

المشكلة باختصار

كل token بيخرج من LLM محتاج forward pass كامل على الـ 70 مليار parameter. على H100، الـ FLOPs مش هي المشكلة، الذاكرة هي اللي بتقعد المعالج فاضي. وقت ما الـ GPU بيقرأ الـ weights من HBM علشان يحسب الـ next token، الـ compute units بتقعد idle بنسبة تتجاوز 65% في batch size = 1. ركز على النقطة دي: انت بتدفع تمن GPU كامل علشان يقعد فاضي ثلثي الوقت.

الحل الكلاسيكي بيقول: زوّد الـ batch size. بس ده شغّال بس لو عندك concurrent users كثير. لو السيناريو single-user low-latency زي chat application أو code completion، الـ batching مش هيساعد. هنا بيدخل Speculative Decoding كحل من فئة مختلفة تمامًا.

الفكرة بمثال بسيط — للوضوح فقط قبل ما ندخل علمي

تخيل محرر صحفي كبير عنده 30 سنة خبرة، بيكتب مقال بدقة كاملة بس بسرعة سطر واحد في الدقيقة. جنبه مساعد متدرّب بيكتب 5 سطور في الدقيقة، لكن دقته 70% فقط. الطريقة الذكية: المساعد يكتب 5 سطور كـ "اقتراح"، المحرر يقرأهم كلهم في ثانية واحدة (مش بيكتبهم، بس بيراجع)، يقبل اللي صح ويتدخّل بس من أول سطر فيه خطأ.

النتيجة: لو المحرر بيقبل في المتوسط 4 من أصل 5 سطور، خلصنا نفس المقال في خُمس الوقت تقريبًا، بنفس الجودة بالظبط. ولاحظ: المحرر لسه هو اللي بيقرر، فالمنتج النهائي مفيش فيه أي تنازل. ده Speculative Decoding بالظبط: draft model صغير بيقترح، target model الكبير بيتحقق بالتوازي.

التعريف العلمي الدقيق

Speculative Decoding، اللي اقترحها Leviathan وفريقه في ورقة Fast Inference from Transformers via Speculative Decoding (ICML 2023)، بتستغل خاصيتين أساسيتين في معمارية Transformer:

1. الـ forward pass على عدد قليل من الـ tokens (مثلًا 6) بياخد تقريبًا نفس وقت forward pass على token واحد، لأن الـ bottleneck في قراءة الـ weights من الذاكرة مش في الحساب نفسه. ده اسمه memory-bound regime.
2. توزيع الـ probability الذي يولّده نموذج صغير بيتشابه إحصائيًا مع توزيع نموذج كبير لـ tokens "السهلة": مسافات، علامات ترقيم، أسماء شائعة، أنماط syntax متكررة.

الخوارزمية بالتفاصيل: draft model بيولّد K tokens مقترحة بشكل autoregressive (γ = 5 افتراضيًا في vLLM). target model بيعمل forward pass واحد على الـ K tokens بالتوازي ويحسب probability كل token تحت distribution بتاعه. لو الـ ratio بين probability الـ target وprobability الـ draft يحقق شرط القبول (modified rejection sampling من Chen et al. 2023)، الـ token بيتقبل. أول token بيترفض، بيرجع الاستدلال عادي لـ target model من النقطة دي.

أهم نقطة في الورقة: الإثبات الرياضي بيضمن إن الـ output distribution مطابق تمامًا (statistically identical) للـ target model لوحده. مفيش تنازل عن جودة، مش approximation. ده اللي بيخلي الـ technique دي مختلفة عن distillation أو quantization.

التطبيق العملي على vLLM

vLLM 0.6+ بيدعم Speculative Decoding مباشرة. هنا الإعداد الحقيقي اللي بنستخدمه على Llama 3.1 70B Instruct مع draft model Llama 3.2 1B Instruct على 4× H100 80GB:

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 4 \
  --speculative-model meta-llama/Llama-3.2-1B-Instruct \
  --num-speculative-tokens 5 \
  --speculative-draft-tensor-parallel-size 1 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --use-v2-block-manager \
  --enforce-eager false

الـ flags المهمة بالتفاصيل:

• num-speculative-tokens (γ): عدد الـ tokens اللي الـ draft model يقترحها في كل دورة. القيمة المثالية بين 3 و 7. أكتر من 7 الـ acceptance rate بينخفض وبتخسر الفائدة لأن الأخطاء بتتراكم.
• speculative-draft-tensor-parallel-size: خليها 1 دائمًا. الـ draft model صغير ومش محتاج توزيع، الـ inter-GPU communication overhead بياكل المكسب.
• enforce-eager: سيبها false علشان CUDA graphs تشتغل. لو خليتها true هتخسر 15 لـ 20% من السرعة بدون فايدة.
• gpu-memory-utilization: خفّضها لـ 0.92 بدل 0.95 الافتراضي علشان الـ draft model محتاج VRAM إضافي لـ KV cache بتاعه.

الأرقام المقاسة على workload حقيقي

اختبرنا الإعداد على 4× H100 SXM 80GB مع 2,000 طلب حقيقي من شات بوت دعم فني عربي (متوسط input 1,800 token، متوسط output 420 token، temperature 0.3):

• Baseline (vLLM بدون speculative): 38.4 token/ثانية، p50 latency 11.2 ثانية، p99 14.6 ثانية
• مع Speculative Decoding (γ=5): 91.3 token/ثانية، p50 latency 4.7 ثانية، p99 6.9 ثانية
• الـ throughput الإجمالي ارتفع 2.38×، الـ p99 تحسّن 53%
• Acceptance rate المتوسط: 73.4% (يعني 3.67 token متقبول من كل 5 مقترحة)
• VRAM overhead: 4.8 GB إضافية للـ draft model و KV cache بتاعه على كل GPU
• التكلفة على AWS p5.48xlarge: من $0.0089 لكل ألف output token لـ $0.0037 (انخفاض 58.4%)

الـ trade-offs اللي محدش بيقولك عليها

الكلام عن 2.4× سرعة جميل في الـ benchmarks، بس فيه 4 نقاط حقيقية لازم تفكر فيها قبل النشر:

1. VRAM tax ثابت بغض النظر عن الـ load: الـ draft model بياخد ذاكرة حتى لو ما حدش بيستخدم النظام. على A100 80GB مع Llama 70B بـ tensor parallel 2، ممكن متلاقيش 5 GB فاضية أصلًا. الـ trade-off: تقلّل max_model_len من 8K لـ 4K، أو تقلّل max batch size. بتكسب سرعة وبتخسر سعة.
2. Acceptance rate بيتقلب حسب الـ domain: النصوص العربية بـ acceptance rate أقل من الإنجليزية (73% مقابل 81% في تجاربنا). الكود بـ acceptance rate أعلى (85%+) لأن الـ syntax repetitive. JSON output أعلى الكل (90%+). الافتراض إن عندك draft model اتدرّب على نفس distribution الـ target.
3. Long context بيكسر المعادلة: فوق 16K token، الـ draft model بيفقد دقته بسرعة لأنه context window أصغر وفهم ضعيف للسياق البعيد. الـ acceptance rate بينزل تحت 50% وبتلاقي الـ effective speed أبطأ من الـ baseline لوحده.
4. التكلفة العملياتية حقيقية: لازم تنشر نموذجين مع بعض، تراقب الـ acceptance rate لحظيًا، وعندك خطّة fallback لو الـ draft model فشل تحميله. ده engineering complexity مش بيظهر في benchmarks الورقة الأكاديمية.

متى Speculative Decoding بتكون قرار غلط

الـ technique دي مش حل عام. متستخدمهاش في الحالات دي:

• Batch size كبير (≥ 32): الـ GPU بقى compute-bound مش memory-bound. الـ speculative overhead بياكل المكسب، وممكن تشوف سلبية في الأداء.
• نماذج صغيرة (≤ 7B): الفرق بين الـ draft (لازم يكون أصغر) والـ target مش كبير بما يكفي لتبرير التعقيد. على Llama 8B الفائدة بتنخفض لـ 1.3× فقط.
• Workload عشوائي بـ temperature ≥ 1.2: الـ acceptance rate بينزل تحت 40% لأن الـ draft مش بيقدر يخمّن المسارات العشوائية. بتخسر سرعة بدل ما تكسب.
• فريقك مش عنده monitoring infrastructure ناضج: لو ما عندكش طريقة تقيس acceptance rate في real-time مع alerts، الـ technique دي بتتحول لـ black box خطير. هتلاقي الأداء بينزل ومش عارف ليه.

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

افتح ملف الـ vLLM config بتاعك، فعّل speculative decoding بنفس الـ flags اللي فوق على staging environment، وقيس الـ acceptance rate لمدة 24 ساعة على workload حقيقي. لو الرقم تحت 65%، الـ draft model مش مناسب للـ domain، جرّب نماذج بديلة (Qwen 2.5 0.5B Instruct، Phi-3.5 mini) قبل ما تأخذ قرار النشر للإنتاج. لو الرقم فوق 70%، انت جاهز للـ rollout تدريجي.

المصادر

• Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML 2023. arXiv:2211.17192
• Chen, C., Borgeaud, S., et al. (2023). Accelerating Large Language Model Decoding with Speculative Sampling. DeepMind. arXiv:2302.01318
• Cai, T., Li, Y., Geng, Z., et al. (2024). Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads. arXiv:2401.10774
• Li, Y., Wei, F., Zhang, C., & Zhang, H. (2024). EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty. ICML 2024. arXiv:2401.15077
• vLLM Documentation. Speculative Decoding. docs.vllm.ai/en/latest/usage/spec_decode.html
• NVIDIA. H100 Tensor Core GPU Architecture Whitepaper, 2022.
• Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.