من منظور التحول الطوري بين السيليكون والكربون: أربعة تكاليف خفية وراء فقدان السيطرة على تكاليف واجهات برمجة النماذج اللغوية الكبيرة ومنطق التوجيه الطبقي

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

الفخ الأول: التضخّم غير المنضبط لنافذة السياق

أكثر مصادر التكلفة التي يسهل تجاهلها في المحادثات متعددة الجولات هو إعادة إرسال الرسائل التاريخية بالكامل. لنفترض سيناريو خدمة عملاء، حيث يبلغ متوسط سياق كل جولة 800 توكن، وعندما يصل المستخدم إلى الجولة العشرين، يقترب الإدخال في الطلب الواحد من 16000 توكن. بحساب سعر إدخال GPT-4o البالغ 2.5 دولار لكل مليون توكن، تبلغ تكلفة الإدخال للطلب الواحد حوالي 0.04 دولار، وإذا كان هناك 50 ألف استدعاء يومياً فذلك 2000 دولار. الأمر الأكثر إيلاماً هو أن 70% من هذه الـ 16000 توكن قد تكون أحاديث جانبية لا صلة لها بالموضوع منذ ثلاث جولات.

فكرة التحسين هي النافذة المنزلقة مع ضغط الملخصات. احتفظ بالنص الأصلي لآخر N جولة، واضغط المحادثات الأقدم باستخدام نموذج خفيف إلى ملخص لا يتجاوز 200 توكن. في مشروعنا، غيّرنا النافذة من "الكامل" إلى "آخر 6 جولات + ملخص"، فانخفض توكن الإدخال للطلب الواحد من 12000 إلى حوالي 3500، وانخفضت تكلفة الإدخال بنسبة سبعين بالمئة مباشرة. انتبه إلى أن الملخص نفسه يجب أن يمر عبر نموذج رخيص، فاستخدام نموذج رائد للتلخيص يعادل عدم التوفير.

الفخ الثاني: استخدام النموذج الرائد في الأعمال الخشنة

هذا هو الهدر الأكثر شيوعاً والأكثر ظلماً. تصنيف النوايا، الحكم على المشاعر، تلخيص المحتوى، تحويل الصيغ — هذه المهام يمكن إنجازها بدقة تتجاوز 95% باستخدام DeepSeek-V3 أو Qwen-Max، لكن كثيراً من الفرق تسلك الطريق الأسهل وتستخدم Claude 4 Sonnet أو GPT-4o في كل شيء. ما هو فرق السعر؟ سعر إدخال النموذج الرائد غالباً ما يكون 10 إلى 20 ضعف سعر النموذج الخفيف.

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

from openai import OpenAI

client = OpenAI(
    api_key="your-token8341-key",
    base_url="https://api.token8341.com/v1"  # غيّر سطراً واحداً، متوافق مع OpenAI SDK
)

# المهام الخفيفة تمر عبر النموذج الرخيص
resp = client.chat.completions.create(
    model="deepseek-v3",
    messages=[{"role": "user", "content": "حدد مشاعر هذا التعليق: الشحن سريع لكن التغليف تالف"}],
    max_tokens=16
)
print(resp.choices[0].message.content)

يمكن أن تبدأ استراتيجية التوجيه بالقواعد: وسم نوع المهمة، التصنيف/التلخيص/الاستخراج يمر عبر الخفيف، توليد الكود/الاستدلال المعقد يمر عبر الرائد. بعد فترة من التشغيل، أحصِ معدل الإصابة الفعلي لكل نموذج ثم عدّل، لا تبدأ مباشرة بتوجيه دلالي معقد، فتكلفة صيانته قد تتجاوز المال الموفَّر.

الفخ الثالث: فقدان السيطرة على آلية إعادة المحاولة

إعادة المحاولة عند انتهاء المهلة هي مضخّم خفي. كثير من SDK تعيد المحاولة 2 إلى 3 مرات افتراضياً، وإذا كانت عتبة انتهاء المهلة قصيرة جداً (مثلاً 10 ثوانٍ) بينما تأخر P99 الفعلي هو 25 ثانية، فسيُعاد عدد كبير من الطلبات بعد انتهاء المهلة، فيتحول الاستدعاء الواحد إلى ثلاثة. الأسوأ أن طلبات إعادة المحاولة نفسها تستهلك التزامن، وقد تثير تحديد المعدل، وتحديد المعدل يثير إعادة المحاولة، فيتشكّل انهيار جليدي.

لقد وقعنا في هذا مرة: تأخر P99 لواجهة معينة 28 ثانية، وعتبة انتهاء المهلة 15 ثانية، وإعادة المحاولة 3 مرات، فبلغ حجم الاستدعاء الفعلي 2.4 ضعف حجم الأعمال. لاحقاً ضبطنا عتبة انتهاء المهلة على P99 مضافاً إليه 30%، وغيّرنا إعادة المحاولة إلى تراجع أسي بحد أقصى مرة واحدة، فانخفض حجم الاستدعاء إلى 1.1 ضعف. inoltre، يجب التمييز بين أنواع الأخطاء في إعادة المحاولة، فأخطاء 429 و5xx فقط يُعاد المحاولة فيها، وخطأ 400 في المعاملات لن يفيد معه إعادة المحاولة ولو عشرة آلاف مرة.

الفخ الرابع: غياب تجميع الاستخدام والتنبيهات

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

الطريقة هي الوسم بالأبعاد: كل استدعاء يحمل ثلاث وسوم هي team وfeature وuser_id، وتُسجَّل في السجلات أو قاعدة السلاسل الزمنية. ميزة استخدام بوابة واجهات برمجة الذكاء الاصطناعي كمدخل موحّد تكمن هنا، فجميع الاستدعاءات تمر عبر طبقة وكيلة، ويُنجَز الوسم وتجميع الاستخدام على جانب البوابة، دون تعديل كود كل جهة أعمال. ننصح بضبط عتبات التنبيه على مستويين، تحذير عند بلوغ الاستخدام اليومي 60% من الميزانية، وتفعيل التخفيض عند بلوغ 85% (مثلاً التحويل التلقائي للوظائف غير الأساسية إلى النموذج الخفيف).

مقارنة التكاليف ومرجع الاختيار

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

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

المؤلف: تشن جينغ شينغ

تاريخ النشر: 3 أكتوبر 2026