وكلاء Together AI يسرّعون نماذج LLM المفتوحة بما يصل إلى 2,6 مرة في عدد التوكنات بالثانية خلال يوم واحد

قدّمت Together AI، التي تعالج تريليونات التوكنات يوميًا، نظام Together Compiler (TKCC). وفيه يختار وكلاء الذكاء الاصطناعي باستمرار التحسينات اللازمة لتشغيل النماذج (الاستدلال) بما يناسب نموذجًا محددًا وبطاقات رسوميات محددة وحجم الطلب الحالي. المشكلة أن ذلك لم يعد ممكنًا يدويًا: فمعماريات النماذج متباينة، والعتاد متباين، والحِمل يتغير كل يوم.

تخيّل أنك تريد اختبار تعديل واحد في نواة الانتباه (attention kernel). عادةً يتطلب ذلك إعادة تشغيل محرك مثل vLLM أو SGLang أو TRT-LLM، ويستغرق التشغيل الكامل 467 ثانية، أي نحو 8 دقائق. أما TKCC فيشغّل المحرك مرة واحدة ويستبدل الكود أثناء التشغيل، فيبدأ الاختبار خلال 9 ثوانٍ.

والنتيجة: في أقل من 24 ساعة رفع النظام عدد التوكنات في الثانية (TPS، المقياس الرئيسي لسرعة الاستدلال) بما يصل إلى 2,6 مرة على النماذج المفتوحة Kimi K3 وGLM 5.3 وMiniMax M3.1-Flash وDeepSeek v4.

1-Flash. وعدد التوكنات لكل بطاقة رسوميات هو التكلفة المباشرة لتشغيل الخدمة.

لماذا لا يستقر حجم الطلب

يستعرض الفريق ملاحظات من بيئة الإنتاج. ففي ساعات العمل في بلد ما تكون الأوامر (prompts) أطول منها في بلد آخر: 97 ألف توكن مقابل 70 ألفًا، أي بفارق 1,4 مرة. وبعد صدور نموذج جديد يبدأ الناس بالدردشة معه وتقييمه، ثم بعد أسبوعين تقريبًا يزداد طول الأوامر بنسبة 80% مع انتقال المستخدمين إلى سيناريوهات الوكلاء. وتحدث أيضًا طفرات مفاجئة: يتضاعف طول الأوامر فجأة، وتنخفض نسبة الإصابات في الذاكرة المؤقتة (cache).

كل تحوّل من هذه التحولات يغيّر التحسين الذي يتفوق على غيره. ففي نماذج MoE تكتسب أهمية خاصة عدم تساوي التحميل بين الخبراء، وفي الانتباه المتناثر (sparse attention) تكتسب أهمية خاصة البيانات الفعلية عند الإدخال. أما القواعد الإرشادية الثابتة (heuristics) ومترجمات ML الكلاسيكية فتتعامل مع ذلك بشكل ضعيف. ومن بين أشهر عشرة نماذج LLM مفتوحة على OpenRouter لا يوجد نموذجان بمعمارية واحدة، بينما يتنوع العتاد بين H100 وB200 وB300 وNVL72 وGroq.

كيف يعمل Together Compiler

يتلقى النظام مدخلات ثلاثة: شكل حجم الطلب، والنموذج، والعتاد. ثم يولّد عدة وكلاء متغيرات من التحسينات لمحرك الاستدلال، ويتبادلون الأفكار عبر «لوحة رسائل» مشتركة.

الفكرة الأولى هي «المحركات الدائمة». فاختناق الأنظمة السابقة القائمة على الوكلاء هو سرعة التجارب، ويبيّن جدول Together السبب: تحميل الأوزان وتسخين نوى JIT والضبط التلقائي (autotuning) تستهلك دقائق في كل تجربة. أما المحرك الدائم فيبدأ مرة واحدة، ثم يستبدل المرشّح بالتمرير الأمامي (forward pass) للنموذج أثناء التشغيل. وبذلك يُجرى من التجارب عدد أكبر بـ252 مرة مقارنة بأنظمة الوكلاء الأساسية.

الفكرة الثانية هي التوازن بين سرعة القياس ودقته. فاختبار نوى منفردة على بيانات عشوائية سريع لكنه مضلِّل: ففي MoE وsparse-attention يتوقف الفائز على التوزيع الفعلي للمدخلات. لذلك جاءت المحركات على مستويين. المحركات «السريعة» تحمّل بضع طبقات وتصلح لقياسات متكررة بضوضاء قليلة. أما المحركات «البطيئة» فتحمّل طبقات كثيرة وتتحقق مما إذا كان المكسب يصمد على البيانات الفعلية.

والجزء الثالث نموذج تكلفة خاص لاختيار التوازي (TP وEP وDCP وغيرها من مخططات تقسيم النموذج على وحدات GPU). يجمع هذا النموذج بين المواصفات المعلنة للعتاد والاختبارات المصغّرة (microbenchmarks) وقياسات التمريرات الأمامية الفعلية، ويستبعد بسرعة التكوينات الضعيفة. وبحسب رسوم المؤلفين البيانية، يخسر الاختيار المبني على المواصفات أمام التوزيع المقيس، ويتوقف أفضل توزيع على عدد الطلبات المتزامنة.

ماذا تقول الأرقام

• ما يصل إلى 2,6 مرة توكنات أكثر في الثانية قياسًا بأفضل التكوينات المنشورة في اختبار SemiAnalysis InferenceX (AgentX).
• أرقام قياسية لزمن الاستجابة المنخفض عند حجم دفعة 1: 1111 توكن/ث على MiniMax M3.1-Flash و1205 على DeepSeek v4.1-Flash. وقد اختار نموذج التكلفة الخاص تكوين التوازي لهما، ولم يعتمد على توصية InferenceX.
• في الاختبار المرجعي للنوى العملاقة (megakernels)، Llama 1B مع حجم دفعة 1، يتفوق TKCC بـ1,7 مرة على النوى العملاقة المفتوحة، ويحتفظ بتفوقه مع زيادة طول التسلسل (على H100 وB200).
• خارج نطاق LLM: على قواعد كود مفتوحة للتنبؤ بالطقس والمعادلات التفاضلية والسلاسل الزمنية والأحياء، حقق TKCC مكسبًا أكبر من Claude Code مع الأمر /goal على ثلاثة من أربعة نماذج.

ماذا يعني ذلك للممارسين

بالنسبة لمن يشغّلون الاستدلال لديهم، الإشارة واضحة: التحسين ليس اختيارًا لمرة واحدة للإعدادات، بل إعادة ترجمة (recompilation) مستمرة تواكب انجراف حجم الطلب. وزيادة التوكنات على البطاقة نفسها تعني إما أسطول GPU أصغر وإما هامشًا أكبر لتحمّل الحِمل.

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