AWS تستعرض كيف يسرّع speculative decoding على Trainium2 عملية التوليد في vLLM

عرضت AWS طريقة عملية لتسريع استدلال LLM على Trainium2 وخفض تكلفته في السيناريوهات التي يولّد فيها النموذج توكنات أكثر بكثير مما يستقبله في المدخلات. والحديث هنا عن speculative decoding: فبدلًا من إجبار النموذج الكبير على إخراج توكن واحد في كل خطوة بالتسلسل، يربط النظام نموذج مسودة (draft) صغيرًا يقترح بسرعة عدة توكنات تالية دفعة واحدة، ثم يتحقق النموذج الأساسي (target) منها في تمريرة واحدة. وإذا تطابقت التوقعات، تقلّ الخطوات التسلسلية المكلفة التي تنفقها الخدمة، ويقلّ التأخير بين التوكنات، ويُستغل المسرّع بصورة أفضل.

وتزداد أهمية ذلك في الأعباء الثقيلة على مرحلة decode، مثل مساعدي الكتابة ووكلاء البرمجة (coding agents) وتوليد التقارير والمستندات القالبية وغيرها من المهام ذات الإجابات الطويلة. ففي التوليد الانحداري الذاتي المعتاد يُحسب كل توكن جديد على حدة، فيقرأ المسرّع KV-cache من الذاكرة باستمرار ويؤدي عملًا مفيدًا قليلًا نسبيًا في كل خطوة. ولهذا يصطدم الاستدلال غالبًا بعرض نطاق الذاكرة لا بالحوسبة الخالصة. ويستهدف speculative decoding هذا الاختناق تحديدًا: إذ ينفّذ النموذج الأساسي خطوات decode تسلسلية أقل، ويجعل التحقق من حزمة توكنات الحمل أكثر كثافة.

لكن لهذا النهج متطلبات. يجب أن يستخدم نموذجا المسودة والأساسي المُجزّئ (tokenizer) والمفردات نفسيهما، والأفضل أن ينتميا إلى عائلة معمارية واحدة كي يخمّن النموذج الصغير استمرار النموذج الأساسي بدقة أكبر. والمعامل الرئيسي هو عدد التوكنات التخمينية (speculative tokens). فإذا كانت النافذة صغيرة جدًا يكاد المكسب لا يُلاحظ، وإذا كانت كبيرة جدًا فإن الانحرافات المبكرة والتحقق الزائد يلتهمان الأثر.

في اختبارها استخدمت AWS النموذج الأساسي Qwen3-32B ونموذج المسودة Qwen3-1.7B، وشغّلتهما عبر vLLM على نسخة Trn2 من نوع trn2.48xlarge. واختارت لـ speculative decoding نمط fused speculation في NeuronX Distributed Inference، حيث يُجمَّع النموذجان معًا لتحسين الأداء. ونشرت AWS الإعدادين، الأساسي والتخميني، في عنقود Amazon EKS واحد، وأبقت كل شيء متطابقًا: تخصيص المسرّعات، وتوازي التنسور (tensor parallelism)، وطول السياق، وحدود الدفعات (batch limits)، وصورة Neuron. وكان الفارق الوحيد إضافة نموذج المسودة والمعامل num_speculative_tokens. وجرى توجيه الحمل إلى الخدمتين عبر llmperf، وأُرسلت قياسات TTFT والتأخير بين التوكنات (inter-token latency) والتأخير الكلي إلى CloudWatch للمقارنة.

واختبرت AWS على حدة نموذج Qwen3-0.6B الأصغر، لكن معدل القبول (acceptance rate) لديه كان أقل بنحو 60 في المئة تقريبًا، وكان ذلك كافيًا لفقدان معظم المكسب. وفي نطاق من 5 إلى 15 توكنًا تخمينيًا، كان الإعداد ذو السبعة توكنات أفضل نقطة في هذه الاختبارات، مع أن المؤلفين يشددون على أن القيمة المثلى تتوقف بدرجة كبيرة على بنية الـ prompts.

وبنية الطلب هي التي حدّدت النتيجة في النهاية. ففي السيناريوهات القابلة للتنبؤ، مثل النص المتكرر والمتتاليات الرقمية والشيفرة البسيطة، أظهر speculative decoding فائدة واضحة. ففي هذه الحالات يخمّن نموذج المسودة غالبًا ما كان النموذج الأساسي سيُخرجه أصلًا، فيتخطى النظام جزءًا كبيرًا من الخطوات التسلسلية. وفي الاختبارات انخفض inter-token latency إلى نحو 15 مللي ثانية لكل توكن، وظل منحنى التأخير الكلي أدنى من خط الأساس (baseline) باستمرار.

أما في الطلبات المفتوحة الأقل حتمية فالصورة مختلفة: يخالف نموذج المسودة النموذج الأساسي أكثر، وتُرفض التوكنات، ويتلاشى المكسب المحتمل. وفي هذه الـ prompts بقي inter-token latency عند نحو 45 مللي ثانية لكل توكن، وأظهر الإعدادان، التخميني والأساسي، تأخيرًا كليًا متقاربًا جدًا. أما TTFT، أي الزمن حتى أول توكن، فلم يتغير تقريبًا، لأن speculative decoding لا يسرّع مرحلة prefill التي يرمّز فيها النموذج سياق الإدخال. ويظهر المكسب الرئيسي لاحقًا، في مرحلة decode، بفضل تقليل عدد الخطوات التسلسلية المكلفة للنموذج الأساسي.

والخلاصة العملية من المقال بسيطة: speculative decoding على Trainium2 ليس زر تسريع شاملًا، بل تحسين موضعي يناسب نوعًا محددًا من الأعباء. فإذا كان منتجك يولّد في الغالب مخرجات مهيكلة ومتوقعة، مثل الشيفرة واستخراج البيانات والتقارير القالبية وملفات الإعداد، فقد يخفّض هذا النمط تكلفة توكن المخرجات مباشرة ويرفع الإنتاجية دون خسارة في الجودة. أما إذا كان استخدامك في الغالب دردشة مفتوحة بتوليد حر، فقد يكون الأثر ضئيلًا. لذلك ينبغي اعتماد هذا المخطط فقط بعد إجراء قياسات على prompts خاصة بك، مع اختيار نموذج مسودة متوافق وضبط نافذة التوكنات التخمينية وفق السيناريوهات الفعلية، لا استنادًا إلى benchmarks منفصلة عن المنتج.