تعرض AWS كيف يسرع الفك التنبئي على Trainium2 الإنشاء في vLLM

أظهرت AWS طريقة عملية لتسريع والتقليل من تكاليف استدلال نماذج اللغة الكبيرة على Trainium2 للسيناريوهات التي تولد فيها النموذج عدداً أكبر بكثير من الرموز عما تستقبله كمدخل. يتعلق الأمر بـ speculative decoding: بدلاً من إجبار نموذج كبير على إنتاج رموز بشكل متسلسل واحداً تلو الآخر، يربط النظام نموذج مسودة صغير يقترح بسرعة عدة رموز تالية في المرة الواحدة، بينما يتحقق النموذج الأساسي target-model منها في مسار واحد. إذا تطابقت التنبؤات، ينفق الخدمة خطوات متسلسلة أقل تكلفة، مما يقلل زمن الانتظار بين الرموز ويستخدم المسرع بشكل أفضل.

هذا مهم بشكل خاص لأحمال العمل decode-heavy — مساعدات الكتابة، وكلاء البرمجة، وتوليد التقارير، والمستندات القالبية والمهام الأخرى ذات الإجابات الطويلة. في الإنتاج الانحداري الذاتي القياسي، يتم حساب كل رمز جديد بشكل منفصل، لذلك يقرأ المسرع باستمرار KV-cache من الذاكرة ويؤدي عملاً مفيداً نسبياً قليلاً لكل خطوة. بسبب ذلك، يصطدم الاستدلال غالباً بحدود نطاق الذاكرة بدلاً من الحسابات البحتة.

يستهدف speculative decoding بالضبط هذا الاختناق: يؤدي target-model خطوات فك التشفير المتسلسلة بتكرار أقل، والتحقق من الدفعات يجعل الحمل أكثر كثافة. ومع ذلك، للطريقة متطلبات. يجب أن تستخدم نماذج draft و target نفس المحلل والمفردات، ويفضل أن تنتمي إلى نفس الأسرة المعمارية حتى يتمكن النموذج الصغير من التنبؤ بشكل أفضل باستمرار النموذج الأساسي.

المعامل الرئيسي هو عدد speculative tokens. إذا كانت النافذة صغيرة جداً، يكون الكسب غير ملحوظ تقريباً؛ إذا كانت كبيرة جداً، فإن الرفضات المبكرة والتحقق غير الضروري تستهلك الفائدة. في اختبارهم، استخدمت AWS نموذج target Qwen3-32B ونموذج draft Qwen3-1.

7B، يعملان عبر vLLM على مثيل trn2.48xlarge. بالنسبة لـ speculative decoding، اختاروا fused speculation في NeuronX Distributed Inference، حيث يتم ترجمة كلا النموذجين معاً لأداء أفضل.

تم نشر تكوينات الخط الأساسي و speculative في مجموعة واحدة Amazon EKS مع الحفاظ على كل شيء متطابق: تخصيص المسرع، tensor parallelism، طول السياق، حدود الدفعة وصورة Neuron. كان الفرق الوحيد هو إضافة نموذج draft والمعامل num_speculative_tokens. تم تطبيق الحمل على كلا الخدمتين عبر llmperf، وتم إرسال TTFT وinter-token latency والكمون من النهاية إلى النهاية إلى CloudWatch للمقارنة.

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

في النهاية، حددت بنية الطلب النتيجة. في السيناريوهات القابلة للتنبؤ — النص المتكرر، والتسلسلات الرقمية، والكود البسيط — أظهر speculative decoding فوائد واضحة. في مثل هذه الحالات، غالباً ما يتنبأ نموذج draft بما كان سيخرجه target-model على أي حال، لذا يتخطى النظام جزءاً كبيراً من الخطوات المتسلسلة.

في الاختبارات، انخفض inter-token latency إلى حوالي 15 ميلي ثانية لكل رمز، وظلت منحنى الكمون من النهاية إلى النهاية باستمرار أقل من الأساس. على الطلبات المفتوحة والأقل حتمية، الصورة مختلفة: يختلف نموذج draft بشكل متكرر عن target-model، يتم رفض الرموز، وتختفي الفائدة المحتملة. بالنسبة لهذه الموجهات، ظل inter-token latency حول 45 ميلي ثانية لكل رمز، وأظهرت التكوينات speculative والأساسية كمون من النهاية إلى النهاية متطابق تقريباً.

TTFT — الوقت حتى الرمز الأول — تغير بقليل لأن speculative decoding لا يسرع مرحلة prefill، حيث يقوم النموذج بترميز السياق المدخل. تظهر الفائدة الرئيسية لاحقاً، في مرحلة فك التشفير، من خلال تقليل عدد خطوات فك التشفير المتسلسلة المكلفة للنموذج الهدف. الاستنتاج العملي من المقالة بسيط: speculative decoding على Trainium2 ليس زراً عاماً للتسريع، بل تحسين موجه لنوع حمل عمل محدد.

إذا كان منتجك يولد بشكل متكرر مخرجات منظمة وقابلة للتنبؤ — الكود، واستخراج البيانات، والتقارير القالبية، والتكوينات — فإن هذا النمط يمكن أن يقلل مباشرة تكلفة الرمز المخرج ويزيد من الإنتاجية دون فقدان الجودة. إذا كان لديك في المقام الأول دردشة مفتوحة مع توليد حر، قد تكون التأثيرات ضئيلة. لذلك، فإن تنفيذ هذا المخطط يستحق العناء فقط بعد إجراء اختبارات قياسية على موجهاتك الخاصة، وتحديد نموذج draft متوافق ونافذة speculative token مناسبة للسيناريوهات الفعلية، بدلاً من الاعتماد على معايير معزولة عن منتجك.