البنية التحتية المشتركة أو المخصصة لعمليات التضمين وإعادة الترتيب: كيف تختار حسب حِمل العمل

شكل الطلب: الشكل أهم من الحجم

أجرت Cohere تحليلاً حول الاختيار بين البنية التحتية المشتركة (shared، الدفع حسب الاستخدام الفعلي) والمخصصة (dedicated) لعمليات التضمين وإعادة الترتيب. النتيجة الأساسية: يقارن الناس عادةً سعر الرمز الواحد وعدد الطلبات في الدقيقة فقط، لكن هذه المقاييس لا تقول شيئاً تقريباً عن الاختيار الصحيح. المنطق بسيط: شكل الطلب ← نمط حركة البيانات ← معدل الاستخدام ← قرار النشر.

يمكن لنموذج التضمين نفسه أن يقوم بأعمال مختلفة تماماً. في موقع تجارة إلكترونية، يُستخدم التضمين بطريقتين: فهرسة الكتالوج (مئات أوصاف المنتجات دفعة واحدة، حوالي 150 كلمة أي نحو 200 رمز لكل نص) ومعالجة طلب بحث (طلب واحد قصير بينما ينتظر المستخدم أمام مؤشر التحميل). تُحسِّن المعالجة الدُفعية الإنتاجية والتكلفة، بينما يُحسِّن طلب البحث سرعة الاستجابة. هذه متطلبات متعارضة، ولا تستطيع بنية تحتية واحدة خدمة الحالتين بفعالية.

تضيف إعادة الترتيب معلمة بالغة الأهمية: عدد المرشّحين المطلوب إعادة ترتيبهم. يُعيد البحث المتجهي 50 منتجاً، ويعيد المُرتِّب تقييم كل منها بالنسبة إلى الطلب. يقارن النموذج الطلب بكل مرشح على حدة، فتتزايد كمية العمل بشكل مباشر مع عدد المرشحين. الشكل النموذجي: طلب من 20 رمزاً بالإضافة إلى 50 وثيقة بـ 200 رمز لكل منها، أي نحو 11,000 رمز لكل عملية. إذا رفعت عدد المرشحين من 20 إلى 100، لن يلاحظ المستخدم أي فرق، لكن الحِمل سيرتفع من 4,400 إلى 22,000 رمز. هذا قرار يتعلق بعمق البحث، لا بتوسيع الخدمة حسب عدد المستخدمين.

نمط حركة البيانات وزمن الاستجابة: ما يحدد السعة الفعلية

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

السؤال الأساسي ليس «ما هو ذروة حركة البيانات؟» بل «إلى أي درجة يُستخدم السعة بشكل قابل للتنبؤ ومستمر؟» خدمة تستقبل 10,000 طلب في الثانية لمدة 5 دقائق يومياً لها اقتصاد مختلف تماماً عن خدمة تستقبل 100 طلب في الثانية باستمرار.

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

نقطة التعادل الاقتصادية ومنطق الاختيار

حسبت Cohere نقاط التحول الاقتصادي باستخدام وحدة معالجة رسوميات واحدة من نوع NVIDIA A10، مع تسعير استهلاكي نموذجي (دون خصومات، وبحركة بيانات على مدار الساعة طوال الأسبوع):

• تضمين الاستعلام (Query Embedding) (طلب واحد، 8 رموز): نقطة التعادل عند عشرات آلاف الطلبات في الدقيقة تقريباً
• تضمين الكتالوج (Catalog Embedding) (100 نص × 200 رمز، أي 20,000 رمز لكل طلب): نقطة التعادل عند نحو 20 طلباً في الدقيقة
• تضمين الوثائق الطويلة (Long-document Embedding) (100 نص × 1,000 رمز، أي 100,000 رمز لكل طلب): نقطة التعادل عند نحو 4 طلبات في الدقيقة
• إعادة الترتيب (Reranking) (طلب واحد + 50 وثيقة، 11,000 رمز): نقطة التعادل عند نحو 29 طلباً في الدقيقة

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