تكلفة واجهات برمجة تطبيقات النماذج اللغوية الكبيرة (LLM APIs) على نطاق واسع: السياق، وإعادة المحاولة، وعبء التقييم

صفحة التسعير تعرض تكلفة الرمز (token). لكن فريقك المالي يدفع مقابل المعاملات (transactions). الفجوة بين هذين الرقمين هي المكان الذي تخرج فيه ميزانيات الذكاء الاصطناعي عن السيطرة.

سؤال المستخدم الواحد لا يعادل أبداً استدعاء API واحد. بل يطلق سلسلة من العمليات: النظام يسحب المستندات، ويقرر ما إذا كان سيستخدم أداة، ويقرأ ما ترجعه الأداة، ويكتب إجابة، وأحياناً يتحقق من تلك الإجابة باستخدام نموذج (model) ثانٍ. كل خطوة تعيد إرسال معظم النص نفسه. إذا كنت تضع ميزانيتك بناءً على سعر موجّه (prompt) واحد، فستكون مخطئاً بهامش كبير. وهذا الخطأ ينمو مع زيادة الاستخدام.

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

كل خطوة تعيد إرسال السياق

فكر فيما يذهب فعلياً إلى النموذج عندما يطرح المستخدم سؤالاً من 20 كلمة على مساعد المستندات. النموذج ليس لديه ذاكرة بين الاستدعاءات، لذا فإن كل طلب يحمل كل ما يحتاجه:

1. ▸التعليمات الثابتة. قواعد السلوك، والنبرة، والحدود. تتراوح عادة بين 500 إلى 2000 رمز.
2. ▸المستندات المسترجعة. الفقرات المسحوبة من قاعدة المعرفة الخاصة بك لتأسيس الإجابة. تتراوح عادة بين 2000 إلى 8000 رمز، اعتماداً على مدى دقة ضبط عملية الاسترجاع (retrieval).
3. ▸سجل المحادثة. المنعطفات السابقة، لتبقى الإجابة متماسكة. ينمو مع كل تبادل.
4. ▸السؤال نفسه. ربما 30 رمزاً.

لذا فإن السؤال المكون من 30 رمزاً يكلفك تقريباً 3000 إلى 12000 رمز إدخال (input tokens) قبل أن يكتب النموذج كلمة واحدة.

الآن أضف أداة. أي وكيل ذكاء اصطناعي (AI agent) يتحقق من نظام إدارة علاقات العملاء (CRM) يقوم بثلاثة استدعاءات على الأقل لكل سؤال. واحد ليقرر البحث عن شيء ما. وواحد ليقرأ نتيجة الـ CRM. وواحد ليكتب الرد. كل استدعاء يحمل السياق الكامل مرة أخرى، بالإضافة إلى ما أضافته الخطوة السابقة.

الحساب بسيط. التكلفة لكل سؤال هي تقريباً الخطوات × الرموز لكل خطوة × السعر لكل رمز. معظم الميزانيات تحسب المصطلح الأخير فقط. وكيل (agent) من ثلاث خطوات مع 12000 رمز من السياق يعالج أكثر من 36000 رمز إدخال لكل سؤال. هذا أكثر من ألف ضعف طول السؤال نفسه.

هذه التكلفة خطية، وليست أسية. هذا خبر جيد، لأن التكاليف الخطية يمكن التنبؤ بها. الخطر يكمن فقط في التنبؤ من الوحدة الخاطئة.

إعادة المحاولة: التكلفة التي لا تنتج شيئاً

المضاعف أعلاه يفترض نجاح كل خطوة. في بيئة الإنتاج (production)، بعضها لا ينجح. قد يرجع النموذج بيانات مشوهة، أو يستدعي أداة بمعامل خاطئ، أو يطلب سجلاً غير موجود.

معظم أطر عمل الوكيل (agent frameworks) تتعامل مع هذا عن طريق إرسال الخطأ مرة أخرى إلى النموذج ومطالبته بالمحاولة مرة أخرى. هذا سلوك منطقي. لكن كل إعادة محاولة تعيد إرسال السياق بأكمله بالإضافة إلى رسالة الخطأ. مع 15000 رمز من السياق وحد أقصى لخمس محاولات إعادة، يمكن لفشل واحد عنيد أن يستهلك حوالي 80000 رمز. ولا يحصل العميل على أي شيء مقابل ذلك.

هناك شيئان يجعلان إعادة المحاولة خطيرة مالياً بدلاً من كونها مجرد إهدار:

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

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

فحوصات الجودة هي فاتورة ثانية

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

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

النمط الصحيح يفصل بين مرحلتين:

• ▸قبل الإطلاق: قيّم كل شيء. تحتاج إلى تغطية كاملة لوضع المعيار، باستخدام مجموعة اختبار ثابتة من 100 سؤال تظل كما هي من إصدار لآخر.
• ▸في بيئة الإنتاج: قيّم عينة. معاملة واحدة من كل عشر أو عشرين هي نقطة بداية شائعة. أضف كل معاملة أبلغ عنها المستخدم، وكل تشغيل طويل بشكل غير عادي، وكل حالة وصلت إلى الحد الأقصى لإعادة المحاولة.

هذا يحافظ على أهمية القياس دون الدفع مقابله في كل استعلام روتيني. نادراً ما يحتاج التقييم إلى إجابة فورية، وتقوم Azure OpenAI Batch API من Microsoft بإرجاع الإكمالات في غضون 24 ساعة بخصم 50% على التسعير القياسي العالمي. بالنسبة للوكلاء، يجب على المقيّم أيضاً قراءة استدعاءات الأداة والمسار الذي اتخذه الوكيل، وهو إدخال أكبر مرة أخرى. يمكنك معرفة ما يجب تتبعه وكيفية تسجيله في تقييمات الوكيل في بيئة الإنتاج.

التخزين المؤقت للموجّه يعمل فقط إذا كان الموجّه مرتباً لذلك

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

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

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

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

الافتراضات: 1000 سؤال، يحتاج كل منها إلى استرجاع مستندات واستدعاء أداة واحد (ثلاثة استدعاءات للنموذج). تسعير توضيحي قدره 3 دولارات لكل مليون رمز إدخال، و15 دولاراً لكل مليون رمز إخراج، وإدخال مخزن مؤقتاً بعُشر معدل الإدخال. تحقق من الأسعار الحالية لأي عائلة نماذج تستخدمها.

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

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

معادلة وضع الميزانية

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

Monthly cost = Q × [ (S + R) × (U × Pin + C × Pcache) + O × Pout ] + Q × E × J

• ▸Q: الأسئلة شهرياً
• ▸S: استدعاءات النموذج لكل سؤال
• ▸U: رموز الإدخال غير المخزنة مؤقتاً لكل استدعاء
• ▸R: متوسط إعادة المحاولة لكل سؤال
• ▸C: الرموز المخزنة مؤقتاً لكل استدعاء
• ▸O: رموز الإخراج لكل سؤال
• ▸E: حصة الزيارات التي تقيمها
• ▸J: تكلفة تقييم معاملة واحدة
• ▸Pin, Pcache, Pout: أسعار مزودك لكل رمز

إذا لم تكن لديك قيم حقيقية لـ R بعد، فلا تخمن رقماً منخفضاً. قم بقياسه في مشروع تجريبي مع تشغيل التتبع. تسجل أدوات مثل Langfuse التكلفة لكل معاملة، حتى تتمكن من رؤية الخطوة التي تستهلك الأموال.

الأسئلة الشائعة

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

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

س: هل سيوفر الانتقال إلى نموذج مفتوح الأوزان مستضاف ذاتياً المال؟ إنه يغير تكلفتك من تكلفة لكل رمز إلى تكلفة خادم ثابتة. يؤتي هذا ثماره عندما تكون الزيارات ثابتة وعالية بما يكفي لإبقاء وحدات معالجة الرسومات مشغولة. مع الزيارات المتقطعة أو المنخفضة، فإنك تدفع مقابل الأجهزة الخاملة على مدار الساعة، مما قد يكلف أكثر من الـ API. يشرح مقالنا حول الاستضافة المحلية نقطة التعادل حيث تتفوق تكلفة الـ GPU الثابتة على التسعير لكل رمز.

ما يجب طلبه قبل التوسع

إذا كنت تمول النظام، فهذه شروط معقولة لتضعها لفريقك أو المورد الخاص بك:

1. ▸الإبلاغ عن التكلفة لكل معاملة، وليس إجمالي الإنفاق فقط. بدون ذلك، لا يمكن لأحد التمييز بين قاعدة مستخدمين متنامية وحلقة إعادة محاولة.
2. ▸وجود حدود قصوى لإعادة المحاولة وميزانيات الرموز لكل معاملة في الكود. وليس في مستند تخطيط.
3. ▸محتوى الموجّه الثابت يأتي أولاً. اطلب رؤية تخطيط الموجّه.
4. ▸تقييم الإنتاج يتم عبر عينات. التقييم الكامل مكانه في مرحلة الاختبار.
5. ▸توجيه الطلبات البسيطة إلى نماذج أصغر. يتم حجز النموذج المتقدم للعمل الذي يحتاجه.

غالباً ما تتعثر المشاريع التجريبية للذكاء الاصطناعي عندما يتبين أن التكلفة لكل معاملة غير معروفة أو لا يمكن تبريرها. معظم هذه الضوابط رخيصة البناء في البداية ومكلفة عند التعديل التحديثي. إذا كان لديك بالفعل نظام قيد التشغيل وكانت الفاتورة ترتفع بشكل أسرع من الاستخدام، فإن خدمة تدقيق الذكاء الاصطناعي من Verel Systems تحدد أين تذهب رموز كل معاملة. بتكلفة ثابتة تبلغ 2500 دولار.