TokenRouter يسرّع توجيه نماذج اللغة الكبيرة على مستوى الرموز بما يتراوح بين 2 و64 ضعفًا مقارنةً بالتشغيل التقليدي

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

لماذا نوجّه الرموز

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

يورد البحث مثالًا هو جهاز التوجيه R-Stitch. بعد كل خطوة فك ترميز يحسب إنتروبيا توزيع الرمز التالي. وإذا تجاوزت الإنتروبيا عتبة معينة (τ = 0.03 في التجارب) يُعدّ الرمز غير مؤكد، فيُستبعد ويعيد النموذج الكبير توليده. أما بقية الرموز فتبقى لدى النموذج الصغير.

على الورق يبدو هذا جميلًا. أما عمليًا فيظل الطلب يقفز بين النماذج، ويبدأ الخادم بالتعثر.

أين تنهار الخوادم المعتادة

يذكر المؤلفون ثلاث مشكلات.

• عدم تزامن الخطوات. تحتاج النماذج إلى أزمنة مختلفة لحساب الخطوة. في الدفعة المتزامنة ينتظر الجميع الأبطأ، بينما تقف الأسرع بلا عمل.
• تأخر القبول في الدفعة. يصل الطلب إلى النموذج الهدف وهو مشغول بالدفعة السابقة، فينتظر الدفعة التالية. تظهر فجوات في الجدولة وتتفتت الدفعات إلى دفعات صغيرة.
• تعقيد التنفيذ. لا توجد في المحركات الجاهزة واجهة لاتخاذ قرار «إلى أين بعد ذلك» في كل خطوة. فيلزم إعادة كتابة قدر كبير من الشيفرة وجعلها متوافقة مع التجميع المستمر للدفعات وذاكرة البادئات المؤقتة.

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

كيف يعمل TokenRouter

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

يكتب المطوّر الخوارزمية عبر ثلاث دوال:

• route(result) تُستدعى بعد كل خطوة، وبناءً على اللوغيتات والحالات المخفية والرموز المعاينة تقرر البقاء محليًا أو تمرير الطلب إلى نموذج آخر؛
• send(req) تُنشئ الرسالة الموجهة إلى النموذج الآخر: معرّف الطلب، ولاحقة الرموز التي لم يرها بعد، والحالة، والحقول الخاصة بالخوارزمية؛
• receive(peer_req) تحوّل الرسالة إلى طلب محلي. وافتراضيًا تقبل ببساطة جميع الرموز المنقولة، ونادرًا ما تحتاج إلى إعادة تعريفها.

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

ماذا أظهرت التجارب

اختُبرت خمس خوارزميات: CITER وR2R وR-Stitch وCo-LLM وME. أربع منها تعمل مع الزوج Qwen3-0.6B وQwen3-32B، بينما تعمل ME مع ثلاثة نماذج (0.6B و8B و32B). العتاد هو خادم بـ 8×A100-80G. وهناك ثلاثة أحمال: استدلال قصير (AIME2024، مخرجات حتى 2048 رمزًا)، واستدلال طويل (مخرجات حتى 8192)، ومهام وكلاء على مسارات SWE-Smith.

النتيجة: إنتاجية أعلى بمقدار 2.01–64.15 ضعفًا، وتأخير شامل (end-to-end) أقل بمقدار 2.03–63.64 ضعفًا مقارنةً بالتشغيل القياسي. وعند زيادة المخرجات من 2048 إلى 8192 رمزًا لم يتراجع أداء TokenRouter، بينما فقد التشغيل القياسي 58.1–85.2% من الإنتاجية.

ما العمل بهذا

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

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