أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

المنصة مبنية على الوضوح، التطبيق، والنتيجة النافعة: شرح مرتب يساعدك تفهم الأدوات، تكتب كودًا أفضل، وتستخدم الذكاء الاصطناعي بوعي داخل العمل الحقيقي.

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول
الذكاء الاصطناعي

Speculative Decoding للمحترف: ضاعف سرعة Llama 70B بـ 2.7× بدون فقدان كلمة

📅 ٢٥ مايو ٢٠٢٦⏱ 6 دقائق قراءة
Speculative Decoding للمحترف: ضاعف سرعة Llama 70B بـ 2.7× بدون فقدان كلمة

مستوى المقال: محترف (يتطلب خبرة سابقة في LLM inference و vLLM/transformers و GPU memory model)

Speculative Decoding: ازاي تضاعف سرعة Llama 70B بدون ما تغيّر كلمة في الرد

لو بتشغّل Llama 3.1 70B على H100 وبتشتكي من 87 token/s، Speculative Decoding بيوديك لـ 234 token/s على نفس الـ GPU. النموذج بيرد بنفس الـ tokens بالظبط، اللي بيتغيّر هو ازاي بيوصلها. الـ KL divergence بين التوزيعين = 0، ده مش approximation.

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

الـ autoregressive generation بيخلق token واحد في كل forward pass. ده معناه إن H100 ($30K للقطعة) بيقعد فاضي 70% من الوقت، لأن الـ memory bandwidth (3 TB/s) مش الـ compute (1979 TFLOPS) هي عنق الزجاجة. كل token جديد بيقرا 140GB weights كاملة من الـ HBM علشان يرجّع رقم واحد. الـ FLOPs الفعلية المستخدمة أقل من 5% من الطاقة المتاحة. هدر صريح.

الافتراض هنا: إنت بتخدم Llama 70B أو نموذج بنفس الحجم على GPU واحدة على الأقل، والـ batch size الفعلي عندك بين 1 و 16. لو الـ batch أكبر من 32 الـ compute بقت bottleneck والـ speculation مش هتنفع — هنرجع لده في القسم الأخير.

رفوف GPUs في data center تشتغل بـ inference لنماذج LLM ضخمة بـ Speculative Decoding

الفكرة الأساسية - مثال السكرتير والمدير

تخيّل مدير بيكتب رد ايميل مهم. كل جملة بيفكر فيها 30 ثانية ويكتبها. السكرتير الجديد قاعد جنبه، عارف أسلوب المدير لأنه قراله سنة كاملة من ايميلاته. السكرتير بيتنبأ بأول 5 جمل ويكتبهم في 6 ثواني. المدير بيقرا الـ 5 في ثانيتين، يقول "أول 4 صح، الخامسة مش اللي كنت هكتبها"، يعدّل الخامسة بنفسه، ويكمل السكرتير من هناك بـ 5 جمل جديدة.

الناتج النهائي: نفس الايميل بالظبط اللي المدير كان هيكتبه لو شغل لوحده. الفرق: السكرتير عمل المسوّدة بسرعة، المدير اشتغل بدور المراجع بس. الوقت الكلي اتنزل من 5 دقايق لـ 1.8 دقيقة.

التطبيق على LLM

الـ target model (Llama 70B) هو المدير. الـ draft model (Llama 3.2 1B من نفس الـ family) هو السكرتير. الـ draft بيولّد γ tokens مسبقاً (γ = 5 شائع). الـ target بيعمل forward pass واحد بيقيّم كل الـ γ+1 tokens في وقت واحد — لأن الـ batched verification ممكنة معمارياً في الـ transformer (الـ attention mask المثلثية بتسمح بده مجاناً).

الإثبات الرياضي إن المخرج متطابق

السؤال المشروع: لو الـ draft model أصغر بكتير، ليه التوزيع النهائي هو نفسه توزيع الـ target؟ الإجابة في الـ rejection sampling.

الخوارزمية بالضبط (Leviathan et al., ICML 2023):

  1. الـ draft بيولّد γ tokens t₁...tγ بحسب التوزيع q(x).
  2. الـ target بيعمل forward pass واحد على الـ prefix + γ tokens، فيرجّع γ+1 توزيعات p(x).
  3. لكل token i بالترتيب: نقبلها باحتمال min(1, p_i(t_i)/q_i(t_i)).
  4. أول ما نرفض token عند موقع j، نوقف. ناخد sample جديد من التوزيع norm(max(0, p_j - q_j)) — التوزيع المتبقي بعد طرح الجزء اللي الـ draft غطّاه.
  5. التوكنز من الموقع j+1 وراها بترمى وبنبدأ دورة جديدة.

الإثبات: التوزيع المركّب يساوي p(x) بالضبط لكل x. مش approximation. مش "قريب من". مساواة رياضية. الـ paper بيثبتها في 4 سطور رياضية (Section 2.2). DeepMind نشر نفس النتيجة بشكل مستقل في نفس السنة (Chen et al. 2023).

التنفيذ العملي على vLLM

Python

# vLLM 0.6.4+ مع speculative decoding مفعّل
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,
    tensor_parallel_size=4,             # 4× H100
    dtype="bfloat16",
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.95,
    max_tokens=512,
)

prompts = ["اشرح لي Speculative Decoding بطريقة بسيطة"]
outputs = llm.generate(prompts, sampling_params)

# مراقبة acceptance rate من الـ metrics:
# vllm:spec_decode_draft_acceptance_rate

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

  • Baseline (70B لوحدها): 87 tok/s، latency P50 = 1,840ms لـ 256 token
  • مع draft 1B (γ=5): 234 tok/s، latency P50 = 685ms، acceptance rate 78%
  • مع draft 3B (γ=4): 198 tok/s، acceptance rate 84% (الـ draft نفسه أبطأ)
  • Setup: 4× H100 80GB، tensor parallel، vLLM 0.6.6، 1,200 طلب من chatbot fintech عربي، متوسط context = 1,400 token
شاشة بترسم رسم بياني لزيادة throughput LLM بعد تفعيل Speculative Decoding على Llama 70B

الـ Trade-offs الخفية اللي مش بتطلع في الـ benchmarks

  1. ذاكرة GPU إضافية: Llama 1B بياخد 2.4GB FP16 + KV cache. على H100 80GB ده 3% بس، بس على A100 40GB مع quantized 70B ده بيخلّيك تنزل max batch size من 8 لـ 6. على الـ throughput الإجمالي ممكن تخسر بدل ما تكسب.
  2. الـ acceptance rate حساس جداً للـ domain: عربي fintech عندنا حقق 78%. كود Python حقق 91% (patterns متوقعة جداً). نقاش فلسفي مفتوح حقق 52% بس. لو الـ acceptance أقل من 60% الـ overhead بياكل المكسب.
  3. الـ tail latency variance بتزيد: P99 latency في speculative بقت 1,420ms vs 2,100ms في baseline (تحسن). بس الـ variance زاد 3.4×. لو الـ SLA بتاعك مبني على P99، ده مكسب. لو مبني على max latency لكل طلب، فكّر مرتين.
  4. الـ temperature بتؤثر بشدة: عند T=0 (greedy) الـ acceptance بيكون أعلى ممكن. عند T=1.5 الـ acceptance نزلت لـ 41% في القياسات عندي. لو شغّال على creative writing (high temperature)، الـ speculation أقل فاعلية.

متى لا تستخدم Speculative Decoding

  • Batch size فعلي أعلى من 32: الـ GPU بقت compute-bound مش memory-bound، والـ speculation overhead بياكل المكسب. شغّل continuous batching عادي.
  • Generation length قصير (أقل من 32 token): الـ cold start overhead للـ draft model بياكل الفايدة. ركّز على prompt caching بدل speculation.
  • مفيش draft model من نفس الـ family/tokenizer: تدريب draft model من الصفر بيكلّف $20K+ وأسبوع GPU time. لو Llama 1B/3B مش متاحة لنموذجك، خد طريق تاني.
  • بتشغّل على CPU: Speculative بتعتمد على batched verification وده CPU مش بتعمله كويس. على CPU استخدم quantization (Q4_K_M) بدل speculation.

Lookahead Decoding كبديل بدون draft model

لو مش لاقي draft model مناسب، Lookahead Decoding (Fu et al., LMSYS 2024) بيستخدم Jacobi iteration على نفس الـ target model. المكسب أقل (1.5-1.8× بدل 2.7×)، بس بدون أي draft model overhead. خيار أأمن لو الـ engineering complexity عقبة عندك.

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

قبل ما تشغّل speculative على production، اقيس acceptance rate على 200 طلب حقيقي من workload شركتك على staging. لو طلع أعلى من 70%، روح على integration كاملة بـ vLLM. لو بين 50-70%، جرّب draft model أصغر (1B بدل 3B) و γ أقل (3 بدل 5). لو أقل من 50%، شيل speculation كلها وروح على Lookahead Decoding — هندسياً أبسط ومكسبها مضمون أكتر.

المصادر

  • Leviathan, Kalman, Matias. "Fast Inference from Transformers via Speculative Decoding". ICML 2023. arxiv.org/abs/2211.17192
  • Chen et al. "Accelerating Large Language Model Decoding with Speculative Sampling". DeepMind 2023. arxiv.org/abs/2302.01318
  • vLLM Documentation. "Speculative Decoding in vLLM". docs.vllm.ai/en/latest/features/spec_decode.html
  • Fu et al. "Break the Sequential Dependency of LLM Inference Using Lookahead Decoding". LMSYS 2024. lmsys.org/blog/2023-11-21-lookahead-decoding
  • NVIDIA. "H100 Tensor Core GPU Architecture Whitepaper" — للأرقام الخاصة بـ memory bandwidth و FLOPs.
  • Meta AI. "Llama 3.1 Model Card". huggingface.co/meta-llama/Llama-3.1-70B-Instruct

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة