TokenRouter يسرّع التوجيه على مستوى الرمز بين النماذج حتى 64 ضعفًا

أصدر فريق مختبر thu-nics (جامعة تسينغخوا) نظام TokenRouter، وهو نظام يتيح لنموذجين لغويين، كبير وصغير، تقاسم توليد واحد: فعند كل رمز تالٍ يُحسم من سيكتبه. ويعني الرقم الرئيسي «حتى 64 ضعفًا» نسبة إنتاجية TokenRouter (عدد الرموز في الثانية عبر جميع الطلبات المتوازية) إلى التطبيقات الرسمية لخوارزميات التوجيه القائمة. ولم يأتِ هذا المكسب من رياضيات جديدة لاختيار النموذج، بل من الهندسة: فقد أزال المؤلفون الأعباء الإضافية التي تلتهم في التطبيقات الخام معظم الوقت.

توجيه الطلبات مجال ناضج، أما توجيه الرموز فلا

يلاحظ كاتب المنشور الأصلي في @gonzo_ML أن توجيه الطلبات إلى نماذج مختلفة ممارسة قديمة. وتعمل شركته Intento في ذلك منذ نحو عشر سنوات. لذلك فاجأه تقييم OpenRouter والصفقة مع Stripe: فبحسب Menlo Ventures، تشتري عملاقة المدفوعات خدمة تجميع النماذج هذه.

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

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

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

أين تضيع الرموز في الثانية

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

بُني TokenRouter فوق SGLang، وهو محرك مفتوح المصدر لتشغيل LLM، ويتألف من عدة أجزاء:

• واجهة API من ثلاث دوال. تُوصف خوارزمية التوجيه عبر واجهة صغيرة، ولذلك تُوصَل أجهزة توجيه مختلفة دون إعادة كتابة بيئة التشغيل.
• خوادم فرعية غير متزامنة. لكل نموذج خادم فرعي خاص به، وتعمل الخوادم بالتوازي دون أن ينتظر بعضها بعضًا.
• الاحتفاظ بذاكرة KV-cache بين الاستدعاءات. تخزّن KV-cache الحالات الوسيطة المحسوبة مسبقًا للسياق. ولو لم تُحفظ، لوجب حساب السياق من جديد عند كل تبديل للنموذج.
• مجدوِل للتجميع المؤجل في دفعات قائم على سلاسل ماركوف. تعالج بطاقة الرسوميات حزمة من الطلبات بكفاءة أكبر من معالجتها واحدًا واحدًا. ويحاكي المجدوِل تدفق الطلبات إلى كل خادم فرعي ويقرر ما إذا كان من المجدي الانتظار قليلًا ريثما تكتمل الدفعة.

وقاس الباحثون بشكل منفصل مساهمة CUDA graphs في R2R، وهو أحد أجهزة التوجيه القائمة على مستوى الرمز. وCUDA graphs تقنية من NVIDIA: تُسجَّل سلسلة عمليات GPU مرة واحدة ثم تُشغَّل كاملة، دون إهدار الوقت على استدعاءات منفردة. ومن إجمالي التسريع البالغ 2,76x، نسب 1,71x إلى CUDA graphs.

الأرقام في رياضيات الأولمبياد والشيفرة الوكيلية

اختُبر النظام على خمس خوارزميات توجيه، وعلى نوعين من المهام: مهام الاستدلال في AIME2024 (مسائل الأولمبياد الأمريكي للرياضيات) والسيناريوهات الوكيلية في SWE-Smith (مجموعة مهام تعديل الشيفرة للوكلاء البرمجيين).

مع 4 طلبات متوازية:

• TokenRouter: 76,6–290,3 رمز/ث بحسب الخوارزمية.
• خط الأساس على مستوى الرمز في SGLang: 4,5–63,1 رمز/ث.
• التطبيقات الرسمية: 0,7–78,3 رمز/ث.
• التحسن: من 2,01x إلى 64,15x.

وعلى جهاز التوجيه R2R تحديدًا:

• 8 طلبات: 134,9 → 372,5 رمز/ث (2,76x).
• 16 طلبًا: يتفوق TokenRouter على R2R بمقدار 3,61x عند درجة التوازي نفسها.
• مقابل R2R بطلب واحد، يبلغ المكسب 18,58x، بينما ترتفع سرعة المستخدم الواحد بمقدار 1,13x.

ويبيّن آخر زوج من الأرقام المعنى العملي: يمكن تحميل النظام بعدد كبير من المستخدمين دون أن تنخفض سرعة أي منهم.

ما الفائدة عمليًا وأين العيب

يُظهر المؤلفون أنه يمكن إخفاء التوجيه على مستوى الرمز خلف نقطة نهاية واحدة متوافقة مع OpenAI. فبالنسبة للعميل هي API عادية، أما في الداخل فيتقاسم نموذجان التوليد. ومن حيث نسبة السرعة إلى الدقة، قد يتفوق هذا النهج على أجهزة التوجيه على مستوى الطلب مثل RouteLLM. وبالنسبة للشركات التي تدفع مقابل الاستدلال، هذه رافعة جديدة: ينخفض سعر الرمز بقدر حصة الرموز «السهلة»، وتبقى الجودة محفوظة عند المفترقات الصعبة.

هناك قيدان ينبغي للمهندس أخذهما في الحسبان قبل التطبيق:

• يضطر كل خادم فرعي إلى تخزين KV-cache للتسلسل بأكمله. ويُستهلك من ذاكرة بطاقات الرسوميات ما يقارب الضعف، إذ توجد الذاكرة المؤقتة للنموذجين الصغير والكبير معًا.
• لم يُختبر حلّال ماركوف في المجدوِل إلا حتى 4 طلبات متوازية. وكيف سيتصرف مع مئات الجلسات في بيئة الإنتاج غير معروف حتى الآن. أما أرقام 8 و16 طلبًا فقد جاءت من R2R.

والشيفرة نفسها متاحة للعموم (thu-nics/TokenRouter). ويمكن للفرق التي تشغّل نماذجها الخاصة أن تختبر النهج على أحمالها. والدرس الرئيسي من هذا العمل عملي: فكرة توجيه الرموز معروفة منذ زمن، لكن دون هندسة أنظمة دقيقة يضيع مكسبها في الطبقة المحيطة.