لماذا تضخمت الفاتورة
عندما أضاف الفريق الذكاء الاصطناعي التوليدي (generative AI) لأول مرة، كانوا يرسلون كل طلب مستخدم إلى أحدث النماذج وأكثرها قدرة. ومع زيادة حركة المرور، ارتفعت التكاليف لكل طلب بالتوازي، وأظهر جدول بيانات المدير المالي أن الإنفاق يتجاوز معدل نمو المستخدمين. الحل السريع المعتاد — "استخدم نموذجًا أرخص فقط" — يفشل في بيئة الإنتاج لأن الاستعلامات المختلفة تتطلب مستويات مختلفة من الاستدلال. المحرك الحقيقي يكمن في كيفية إرسال الطلب، وليس في أي نموذج يتم استخدامه دائمًا.
بناء طبقة توجيه توفر المال
تعامل المهندس مع خدمة الاستدلال (inference service) كأي مكون إنتاجي آخر: تحديد الفئات، ووضع اتفاقيات مستوى الخدمة (SLAs)، وفرض ميزانيات زمن الاستجابة (latency budgets). وتتكون البنية الناتجة من أربعة أجزاء متحركة تحقق معًا خفضًا بنسبة 95%.
التوجيه المتدرج (Tiered routing)
تقوم واجهة أمامية (front-end) بسيطة بتصنيف كل طلب وارد حسب درجة صعوبته. حوالي 95% من الاستعلامات تقع في الفئة "الرخيصة" التي تشغل نموذجًا متواضعًا؛ بينما يتم تصعيد أصعب 5% فقط إلى نموذج متميز (premium model). يمكن أن يكون التصنيف قائمًا على القواعد (مثل الطول، أو وجود كلمات مفتاحية خاصة بالمجال) أو يتم تعلمه من بيانات التصعيد التاريخية. ومن خلال الاعتماد افتراضيًا على الفئة منخفضة التكلفة، انخفضت التكلفة الشهرية لروبوت الدردشة من 420 دولارًا إلى 28 دولارًا.
اختيار الحجم المناسب للنموذج (Model right-sizing)
يوفر مطابقة قدرة النموذج مع تعقيد المهمة أكبر قدر من التوفير:
- الدردشة البسيطة – استخدم نموذجًا خفيف الوزن بدلاً من النموذج الرائد (توفير بنسبة 97.5%).
- التصنيف – استبدل النموذج متوسط الحجم ببديل أرخص (توفير بنسبة 98.3%).
- التلخيص – استبدل النموذج من الفئة العليا بنموذج متوسط المدى (توفير بنسبة 97.2%).
أسماء النماذج الدقيقة ليست بالضرورة هي الأهم؛ المبدأ هو الاحتفاظ بالنموذج الأكثر قدرة كاحتياطي للاستعلامات القليلة التي تحتاج إليه حقًا.
التخزين المؤقت الذكي (Smart caching)
كل "إصابة" للتخزين المؤقت (cache hit) تلغي استدعاء الشبكة ورسوم الـ API. تقوم ذاكرة Redis المؤقتة الموزعة بتخزين الاستجابات الناجحة بالإضافة إلى الإجابات "السلبية" (مثل "لا أعرف"). عندما يظهر نفس السؤال غير القابل للإجابة مرة أخرى، يعيد النظام إجابة "لا أعرف" المخزنة مؤقتًا بدلاً من استدعاء النموذج مرة ثانية. عبر آلاف الطلبات، يقلص هذا الإجراء وحده جزءًا ملحوظًا من الفاتورة.
ضغط الأوامر (Prompt compression)
تؤدي الأوامر (prompts) الطويلة إلى زيادة استهلاك الرموز (tokens)، مما يترجم مباشرة إلى تكلفة. يقوم الفريق بتشغيل ملخص رخيص على جانب العميل أو في خطوة معالجة مسبقة، مما يقلص سياقًا مكونًا من 2000 رمز إلى حوالي 400 رمز قبل وصوله إلى النموذج المكلف. يتضاعف تقليل الرموز عبر جميع الطلبات، مما يحقق وفورات هائلة دون تغيير تجربة المستخدم النهائي.
المعالجة بالدفعات الاستراتيجية (Strategic batching)
تقوم المعالجة بالدفعات (batching) بتجميع طلبات متعددة مستقلة في استدعاء API واحد. القاعدة العامة بسيطة: إذا كان المستخدم ينتظر إجابة، فلا تستخدم المعالجة بالدفعات؛ أما إذا كان الطلب يعمل في الخلفية (تقارير ليلية، وظائف مجدولة)، فقم بتجميع كل شيء. وحدها مهام الدفعات الليلية توفر 10-20% أخرى من الإنفاق.
مراقبة حلقة التحسين
لا يمكنك تحسين ما لا يمكنك قياسه. وضع المهندس أربعة مقاييس أسبوعية:
- التكلفة لكل طلب مقسمة حسب الفئة.
- معدل إصابة التخزين المؤقت (cache-hit rate) لكل مسار توجيه.
- معدل التصعيد من الفئات الرخيصة إلى الفئات المميزة.
- الإنفاق لكل شريحة من العملاء.
تُظهر هذه الأرقام أي انحراف (drift) — على سبيل المثال، قد يشير ارتفاع معدل التصعيد إلى أن منطق التصنيف عدواني للغاية أو أن جودة النموذج الرخيص قد تدهورت. يقوم الفريق بتكرار العمل على العتبات، وتعيينات النماذج، وسياسات التخزين المؤقت كل أسبوع، مما يحول التحكم في التكاليف إلى عادة بدلاً من كونه استجابة للأزمات.
الخلاصة
إن وجود طبقة توجيه منضبطة تصنف الطلبات، وتختار الحجم المناسب للنماذج، وتستخدم التخزين المؤقت بكثافة، وتضغط الأوامر، وتجمع مهام الخلفية، يمكن أن يقلل من الإنفاق على AI-API بنسبة تصل إلى 95% مع الحفاظ على موثوقية عالية. تعامل مع حزمة الاستدلال (inference stack) كخدمة إنتاجية: حدد الفئات، وقس النتائج، وقم بالتطوير أسبوعيًا.