DuoLM يسرّع توصيات LLM بمقدار 60 مرة: 26 400 تقييم في الثانية على وحدة H100 واحدة

تصطدم أنظمة التوصية القائمة على النماذج اللغوية الكبيرة بحدود الحساب. فلتقييم مئات المرشحين لمستخدم واحد، يجب تمرير النصوص الكاملة للأوصاف عبر النموذج مع سجل المستخدم، وتنفد الطاقة الاستيعابية للخوادم سريعًا. يقترح مؤلفو DuoLM، وهم Jiang Wu وYutong Song وHongbo Wang وGuanghe Cao وJeff Lei Liang، إلغاء العمل المكرر بالكامل. على بطاقة H100 واحدة، يحتسب نظامهم نحو 26 400 تقييم مرشّح في الثانية. وهذا أسرع بنحو 60 مرة من النموذج المعلّم المنشور على vLLM مع automatic prefix caching، مع جودة توصيات قابلة للمقارنة.

نموذجان بدلًا من موجّه طويل واحد

يتلقى المُرتِّب التقليدي القائم على LLM كل شيء دفعة واحدة: نص العنصر وسجل المستخدم وردود أفعاله. ويجب إعادة معالجة النص لكل زوج «مستخدم — مرشّح»، مع أن وصف المنتج أو المقطع المصوّر لا يعتمد على المستخدم.

يقسّم DuoLM المهمة إلى جزأين. الأول مُرمِّز (encoder) مبني على LLM، يقرأ وصف العنصر ويضغطه في تمثيل مضغوط. تتم هذه العملية دون اتصال (offline)، ثم يُخزَّن الناتج مؤقتًا ويصلح لأي عدد من المستخدمين. والثاني مُرتِّب شخصي، وهو LLM أيضًا. يتلقى هذا المُرتِّب تمثيلات المرشحين الجاهزة وسجل المستخدم وردود فعله، ثم يُصدر التوصية.

يُدرَّب النموذجان معًا بأسلوب end to end، وبإشارتين: تسميات التوصية، والتقطير (distillation) من «خبير» هو نموذج معلّم يرى النص الكامل. يتعلم المُرمِّز ضغط الأوصاف بحيث لا يضرّ فقدان المعلومات بالترتيب النهائي، ويتعلم المُرتِّب العمل مع المدخل المضغوط.

وقت التشغيل: توكنات افتراضية وCUDA Graphs

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

• تُخزَّن تمثيلات العناصر مباشرةً على GPU وتُمرَّر إلى النموذج عبر معرّفات token افتراضية، فيتعامل المُرتِّب مع التضمينات (embeddings) كما يتعامل مع التوكنات العادية، دون نسخ زائد؛
• يتشارك عدة مرشحين ضمن الطلب الواحد حساب سجل المستخدم: إذ تُحتسب بادئته مرة واحدة، لا لكل مرشّح على حدة؛
• تقلّل إعادة تشغيل CUDA Graph الكلفة الإضافية لإطلاق النوى (kernels)، وهذا مهم حين تكون الحسابات نفسها قصيرة.

وبذلك يقلّص النموذج ووقت التشغيل معًا العمل المكرر في كل مرحلة من مراحل خط التوصية.

ماذا تعني 26 400 تقييم في الثانية

أبرز معطيات العمل:

• البنية: مُرمِّز LLM لتمثيلات العناصر المضغوطة، ومُرتِّب شخصي LLM؛
• التدريب: end to end، بتسميات التوصية والتقطير (distillation) من معلّم يرى النص الكامل؛
• الاستدلال: معرّفات token افتراضية، وحساب مشترك للسجل، وإعادة تشغيل CUDA Graph؛
• العتاد: وحدة GPU واحدة من طراز H100؛
• الإنتاجية: نحو 26 400 تقييم مرشّح في الثانية؛
• التسريع: نحو 60 مرة مقارنةً بالمعلّم على vLLM مع automatic prefix caching؛
• الجودة: قابلة للمقارنة مع النموذج المعلّم الخبير.

ما يجعل المقارنة لافتة أن خط الأساس ليس تشغيلًا ساذجًا، بل vLLM مع prefix caching، أي حزمة محسَّنة أصلًا. ومع ذلك يتأخر عن DuoLM بمقدار رتبة عشرية، لأنه يخزّن البوادئ مؤقتًا لكنه لا يستبدل نصوص العناصر الطويلة بمتجهات قصيرة.

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

والقيود واضحة أيضًا. فالمكسب يتوقف على نسبة العناصر المُعاد استخدامها، وعلى مدى احتفاظ التمثيل المضغوط بالتفاصيل. وقد قيست الجودة المعلنة على بنشماركات مقارنةً بالمعلّم، لا في اختبار A/B حي على حركة الإنتاج. لكن المخطط نفسه، «مُرمِّز دون اتصال ومُرتِّب أثناء الطلب ووقت تشغيل مصمَّم لهما»، يبدو قابلًا للتكرار: فشيفرة المشروع منشورة على GitHub، ويمكن التحقق من فارق الـ60 ضعفًا على بياناتكم الخاصة دون إعادة كتابة البنية التحتية كلها.