SGLang-TorchTPU يسرّع إخراج الرموز في Muse Spark Open بنحو الضعف

قرأ وكيل البرمجة المستودع، وشغّل أداة، ثم توقف قبل إجابته التالية. من السهل في مثل هذا التوقف إلقاء اللوم على حجم النموذج. لكن الخادم قد يهدر الوقت في إيصال الأوزان، والتبادل بين المسرّعات، وإعادة معالجة سياق مألوف. وهذه مشكلة ملموسة لفريق المنتج: المستخدم ينتظر بينما تنشغل البنية التحتية المدفوعة بأعمال تحضيرية.

وصف فريق SGLang-TorchTPU تشغيل Muse Spark Open بـ 816 مليار معامل على مضيف واحد بأربعة معالجات TPU v7. والنتيجة الرئيسية لطلب واحد: انخفض الزمن لكل رمز إخراج من 3.78 إلى 1.95 مللي ثانية. نُشرت القياسات وتفاصيل التنفيذ في مدونة PyTorch.

المسرّع يحتاج إلى وصول البيانات في الوقت المناسب

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

طُبّقت هنا فكرة مشابهة: جرى دمج تنفيذ 62 طبقة في برنامج واحد، وتزامن نقل البيانات مع الحسابات. وهذا يتيح تجهيز ما سيحتاجه الجزء التالي من العمل مسبقًا.

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

أما الخدمة الجماهيرية فلها مهمة مختلفة: خدمة الطابور دون ارتفاع حاد في زمن الاستجابة. لذلك فإن رقم سرعة جميلًا واحدًا لا يجيب عن سؤال: كم مستخدمًا يمكن للنظام أن يتحمل؟ المطلوب سلسلة قياسات بأحمال مختلفة وظروف متطابقة.

توقف الوكيل سبب للحفاظ على السياق

تتعلق النتيجة الثانية بالذاكرة. فقد زاد التخزين المؤقت الإضافي في الذاكرة العشوائية للمضيف معدل المعالجة في الحمل الوكيلي بنسبة تصل إلى 77%.

لنأخذ مساعدًا يبحث عن خطأ في مشروع. إنه يقرأ الملفات، ويشغّل الاختبارات، ويتلقى المخرجات، ثم يعود إلى الاستدلال. ويبقى جزء كبير من المحادثة بين هذه الإجراءات كما هو. وإذا احتفظ الخادم ببيانات السياق التي جرى تجهيزها، يمكن بدء الدور التالي بقدر أقل من العمل المتكرر.

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

ومن المناسب اختبار ذلك بسيناريو منفصل. أعطِ الوكيل وثيقة كبيرة، ونفّذ عدة أدوار قصيرة مع توقفات، وقارن زمن بدء الإجابة. ثم أعد التجربة والذاكرة ممتلئة. وبذلك يتضح أكثر إلى أي حد يعتمد سلوك الخدمة على حفظ السياق، وماذا يحدث عند إخراج الجلسات القديمة.

ما الذي يمكن نقله إلى خدمتك

لا ينبغي تحويل التسريع بنحو الضعف تلقائيًا إلى وفر في الميزانية. فمكسب البرنامج المدمج يتراجع مع زيادة عدد الطلبات المتزامنة. كما أن المؤلفين ما زالوا يخططون لنقل جزء من العمل إلى الفرع الرئيسي للمشروع.

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

وهناك أيضًا سيناريو منفصل لاختبار الطابور: يرسل مستخدم وثيقة ضخمة، ويطرح آخر سؤالًا قصيرًا. انظر كم ينتظر الثاني. تُظهر هذه التجربة بسرعة ما إذا كان توزيع الموارد يطابق جودة الخدمة الموعودة.

تكمن قيمة المنشور في مجموعة من الحلول الهندسية القابلة للتحقق. وقبل تغيير العتاد، من المفيد معرفة أين يتوقف الخادم عن العمل تحديدًا، وأي عمل يكرره، ومن يسمح له بشغل الطابور وقتًا أطول من اللازم.