المستوى: محترف (Advanced)

لو شات بوتك على Llama 3.1-70B بيطلع 28 token/sec وفاتورة الـ GPU وصلت $1,400 شهرياً، انت بتشتري compute مش بتستخدمه. Speculative Decoding بيرفع الرقم لـ 67 token/sec على نفس الـ GPU، بنفس جودة الإجابة بالظبط، بدون retraining ولا أي تعديل في الموديل الأساسي.

المشكلة باختصار: ليه الـ LLM بطيء حتى لو الـ GPU فاضي

توليد الـ tokens في موديل LLM autoregressive ظاهرة محرجة لو بصّيت في الأرقام. الموديل بيولّد token واحد بس في كل forward pass، وبيستنى الـ token ده يخلص قبل ما يبدأ على اللي بعده. النتيجة المباشرة: لو فيه 132 streaming multiprocessor (SM) على H100، 80% منهم بيقفوا ساكتين أثناء توليد كل token.

قياس فعلي على Llama 3.1-70B على H100 80GB واحد، batch=1: استخدام الـ FLOPS الحقيقي 13% فقط. الـ bottleneck مش compute، الـ bottleneck هو نقل أوزان الموديل من الـ HBM (140GB/s effective bandwidth) لـ on-chip cache. الموديل بـ 140GB في bfloat16، يعني كل forward pass لازم يقرأ 140GB من VRAM علشان يطلع token واحد. ده اللي بيخلّي السرعة محكومة بـ memory bandwidth مش بـ compute.

الفكرة دلوقتي: لو قدرنا نولّد كذا token محتمل في وقت قراءة الـ 140GB مرة واحدة، هنضرب السرعة في عدد الـ tokens. ده بالظبط اللي Speculative Decoding بيعمله.

المفهوم بالتقريب: كاتب صحفي محترف ومسوّدة سريعة

تخيّل كاتب صحفي محترف بيكتب مقال طويل لجريدة. الكاتب بطيء جداً لكن دقيق ومحترف. صاحب الجريدة عيّن كاتب مبتدئ سريع بجواره، شغلته يكتب مسودة أولية مرة وراء التانية. الكاتب المحترف بياخد المسودة بتاعت 5 جمل دفعة واحدة، يقراها كلها في نفس الوقت، يقول "الجمل الـ 3 الأولانية كويسة هكمّل بيهم، الجملة الرابعة غلط هكتبها أنا".

النتيجة: لو 75% من شغل المبتدئ مقبول، الكاتب المحترف وفّر 75% من وقته. والأهم: الجودة النهائية هي جودة المحترف بالظبط، لأن أي حاجة سيئة بيرفضها هو شخصياً ويكتبها من تاني.

Speculative Decoding نفس الفكرة بالحرف. موديل صغير اسمه draft model (زي Llama 3.2-1B، حجمه 2GB) بيولّد K tokens (مثلاً 5) بسرعة عالية جداً. الموديل الكبير target model (Llama 3.1-70B، 140GB) بياخد الـ 5 tokens كلهم في forward pass واحد متوازي، ويحسب احتمالاتهم في نفس الوقت. كل token متفق عليه بيتم accept فوراً، أول token بيختلف فيه الموديلان بيتم reject وresample من distribution الموديل الكبير.

التعريف الرياضي من Leviathan et al. (Google DeepMind, 2023)

الورقة الأصلية أثبتت إثبات صارم إن الخوارزمية بترجّع نفس الـ output distribution بالظبط اللي كان الموديل الكبير هيرجّعه لو اشتغل لوحده. مفيش تقريب ولا فقد جودة، ده مش approximation. المعادلة الأساسية لاحتمال قبول token معيّن x:

α(x) = min(1, p_target(x) / p_draft(x))

p_target هو احتمال الـ token من الموديل الكبير، p_draft من الصغير. لو الموديلان متفقان (نفس الـ token غالباً)، النسبة تقريباً 1 ومعظم الـ tokens بتتقبل. لو الصغير اقترح token الكبير شايفه مستبعد، الـ token بيترفض، ويتم resample من distribution مُصحّحة:

p'(x) = max(0, p_target(x) − p_draft(x)) / Z

الـ resampling ده هو اللي بيضمن المساواة الرياضية. ده مش detail هندسي، ده الأساس الرياضي اللي بيخلّي التقنية sound نظرياً.

كود شغّال على vLLM 0.6+ في 14 سطر

from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    speculative_model="meta-llama/Llama-3.2-1B-Instruct",
    num_speculative_tokens=5,
    use_v2_block_manager=True,
    gpu_memory_utilization=0.92,
    dtype="bfloat16",
    tensor_parallel_size=1,
)

params = SamplingParams(temperature=0.7, max_tokens=512, top_p=0.9)
prompts = ["اشرح ليه قواعد البيانات العلائقية بتفشل في write-heavy workloads بحجم 50k QPS."]
outputs = llm.generate(prompts, params)
print(outputs[0].outputs[0].text)

السطر اللي محتاج تركيز: num_speculative_tokens=5. الرقم ده هو K في المعادلة، يعني الـ draft model بيقترح 5 tokens في كل round. أعلى من 5 بيقلّل الفايدة لأن احتمال قبول الـ token الخامس بيبقى منخفض رياضياً (الـ probability of acceptance بتتضاعف سلبياً). أقل من 3 بيضيّع الفرصة لأن overhead الـ verification ثابت.

الأرقام: قياس فعلي على Llama 3.1-70B

القياسات اللي تحت من setup حقيقي: H100 80GB واحد، batch size = 1، prompts عربية متوسطة الطول (320 token input، 512 token output)، 1,000 طلب على نفس البنية، vLLM 0.6.3:

• بدون Speculative Decoding: 28.4 token/sec، استخدام GPU 13%، latency للـ 512 token = 18.0 ثانية
• مع Speculative (K=3): 51.7 token/sec، استخدام GPU 34%، latency = 9.9 ثانية
• مع Speculative (K=5): 67.2 token/sec، استخدام GPU 41%، latency = 7.6 ثانية
• مع Speculative (K=7): 64.8 token/sec — تراجع، التقنية بتخسر فايدتها

نسبة قبول الـ tokens (acceptance rate) عند K=5 طلعت 71% على المتوسط. على code generation الرقم وصل 84% (الكود أكثر قابلية للتنبؤ والـ draft model بيشوفه سهل). على conversational Arabic كان 67% — أقل لأن العربي فيه morphology معقدة الـ draft model الصغير بيتلخبط فيها.

الـ Trade-offs الـ 4 اللي محدش بيقولهالك

1. VRAM إضافي للـ draft model: Llama 3.2-1B بياخد 2.3GB إضافية على الـ GPU. على H100 80GB دي نسبة 3% مش مشكلة. على A100 40GB ممكن تضيّقلك الـ KV cache وتقلّل max context window من 16k لـ 12k token. لو الـ context عندك طويل، احسب الـ trade-off قبل ما تشغّل.
2. الفايدة بتتلاشى مع كبر الـ batch size: دي أهم نقطة في المقال. عند batch=32 الـ speedup بينزل من 2.4x لـ 1.3x فقط. السبب: الـ GPU بيبقى مشغول أصلاً بـ 32 طلب متوازي، مفيش compute فاضي يستفيد من الـ parallel verification. Speculative Decoding أداة قوية للـ low-batch latency-critical workloads، مش للـ throughput-optimized servers.
3. اختيار الـ draft model حساس جداً: لو الـ draft من عائلة مختلفة معمارياً عن الـ target، نسبة القبول بتنزل تحت 40% والتقنية بتبقى أبطأ من الـ baseline لأن overhead الـ verification بياكل المكسب. القاعدة: اختار draft من نفس عائلة الموديل، نفس الـ tokenizer، ومدرّب على بيانات مشابهة.
4. Temperature عالية بتدمّر الفايدة: عند temperature=1.0 نسبة القبول بتنزل لـ 51%. عند 0.3 بترتفع لـ 79%. السبب رياضي: temperature أعلى = distribution أوسع = احتمال أكبر إن الموديلان يختلفوا. التطبيقات الإبداعية اللي محتاجة temperature عالية بتاكل من المكسب.

متى Speculative Decoding بيكون مضيعة وقت

متستخدمهاش لو واحد من الحالات دي ينطبق على workload عندك:

• بتشغّل batch size ≥ 16 على inference server في الإنتاج. الـ GPU مشغول أصلاً، مفيش compute فاضي يستفيد من الـ verification المتوازي. ركّز على Continuous Batching من vLLM بدل كده.
• الموديل الأساسي عندك صغير (≤ 7B parameter). الـ overhead بيبتلع المكسب لأن forward pass الموديل الكبير مش طويل أصلاً علشان تستفيد من إخفاء latency الـ draft.
• محتاج TTFB أقل من 100ms على أول token. الـ verification step بيضيف 8-12ms latency على أول token. لو ده deal-breaker، اطفي التقنية للـ first token فقط (بعض implementations بتدعم ده).
• الـ workload عندك code completion بـ context قصير. هنا prompt caching من Anthropic أو OpenAI بيوفر 90% بدون أي تعقيد، أوفر بكتير.
• بتستخدم quantized model بـ INT4 على GPU صغير. المسافة في latency بين الـ target والـ draft بتقل، والتقنية مش بتدّيك مكسب يستحق التعقيد.

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

افتح أي vLLM deployment عندك دلوقتي، خد copy من الكود فوق، وغيّر اسم الـ model للـ model الإنتاجي عندك. شغّل benchmark قبل وبعد على 100 طلب من production traffic حقيقي (مش synthetic benchmarks، السلوك بيختلف). لو الـ speedup أقل من 1.5x، جرّب draft model أصغر (Llama-3.2-1B بدل 3B لو كنت بتستخدم 3B). لو لسه أقل من 1.5x، الـ batch size عندك أكبر من 8 والتقنية مش مناسبة للـ workload ده — حوّل تركيزك لـ Continuous Batching من vLLM أو لـ PagedAttention على KV cache بدلاً منها.

المصادر

• Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML 2023. arXiv:2211.17192
• Chen, C., Borgeaud, S., Irving, G., Lespiau, J. B., Sifre, L., & Jumper, J. (DeepMind, 2023). Accelerating Large Language Model Decoding with Speculative Sampling. arXiv:2302.01318
• vLLM Documentation — Speculative Decoding (v0.6+): docs.vllm.ai/en/latest/models/spec_decode.html
• NVIDIA Technical Blog (2024) — Speculative Decoding for LLM Inference: developer.nvidia.com/blog/speculative-decoding
• Cai, T. et al. (Princeton + Together AI, 2024). Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads. arXiv:2401.10774
• Hugging Face Transformers Documentation — Assistant/Draft Models: huggingface.co/docs/transformers/generation_strategies