أضافت Microsoft فئة AI Gateway tier مخصصة إلى Azure API Management (APIM). تشير هذه الخطوة إلى أن استدعاءات LLM تُعامل الآن كعبء عمل منفصل، وليس مجرد نقطة نهاية API أخرى.
لماذا تكسر حركة مرور LLM البوابات التقليدية
يمكن أن تكلف مطالبة (prompt) واحدة مئة ضعف تكلفة مطالبة أخرى، ومع ذلك ترى بوابة API القياسية كلتيهما كطلب واحد. تقوم البوابة باحتساب عدد الاستدعاءات، وليس عدد الـ tokens التي يعالجها النموذج. الطلب الذي يرسل بضع مئات من الـ tokens والطلب الذي يرسل آلاف الـ tokens يولدان مقاييس عدد طلبات متطابقة، على الرغم من أن الأخير قد يكلف أضعافاً مضاعفة.
أربع حقائق تجعل القيود القائمة على الطلبات عديمة الفائدة للذكاء الاصطناعي:
- التكلفة ≠ عدد الطلبات. ترتبط الفوترة بالـ tokens، وليس بعدد استدعاءات HTTP التي تقوم بها.
- حجم الـ tokens يتفاوت بشكل كبير. قد يكون أحد الاستعلامات سؤالاً قصيراً، بينما قد يتضمن استعلام آخر مستنداً طويلاً.
- اختيار النموذج يغير السعر. تفرض نماذج LLM المختلفة أسعاراً مختلفة لكل token.
- البث (Streaming) يخفي الفاتورة النهائية. عندما يتم بث الاستجابات، لا يُعرف إجمالي عدد الـ tokens حتى ينتهي البث.
إذا استمررت في قياس الطلبات فقط، فستنتهي ببيانات مراقبة لا تخبرك شيئاً عن الإنفاق الفعلي.
ما الذي تغيره فئة AI Gateway
معظم السياسات اللازمة لضبط استخدام الـ tokens موجودة بالفعل في فئات APIM القياسية — وهي مكتوبة كقواعد XML ومعروضة في لوحات تحكم مخصصة. تقوم فئة AI بتجميع تلك القدرات نفسها في تجربة مصممة خصيصاً لهذا الغرض:
- عزل التوسع (Isolation of scaling) لحركة مرور الذكاء الاصطناعي.
- تكوين مبسط يلغي الحاجة إلى سياسات XML المصنوعة يدوياً.
التحول الجوهري هو تحول تشغيلي: لم يعد عليك كتابة كود معقد أو صيانة لوحات تحكم منفصلة لفرض ميزانيات الـ tokens. توفر هذه الفئة واجهة جاهزة لتلك الضوابط.
متى تنتقل – دليل قائم على حركة المرور
- الذكاء الاصطناعي يمثل جزءاً صغيراً من حركة المرور لديك. استمر في استخدام فئة APIM الحالية وأضف سياسات الـ tokens إذا كنت بحاجة إلى تحكم دقيق.
- الذكاء الاصطناعي يهيمن على استدعاءاتك. انتقل إلى فئة AI لعزل التوسع والحفاظ على حوكمة التكاليف بشكل منظم.
- تريد تجنب الأعباء الهندسية الإضافية. تلغي الأدوات المدمجة في هذه الفئة الوقت المستغرق في بناء وصيانة سياسات مخصصة.
أكبر مصروف ليس سعر الاشتراك؛ بل هو الساعات الهندسية المستغرقة في سد الثغرات في بوابة عامة لجعلها تفهم اقتصاديات الـ tokens.
خطة العمل لمرحلة المعاينة (Preview-phase)
لا تزال Microsoft تقدم فئة AI في مرحلة المعاينة. تعامل معها كبيئة اختبار، وليس كإطلاق للإنتاج.
- اختر عبء عمل ذكاء اصطناعي داخلي عالي الحجم. اختر الخدمة التي تولد أكبر قدر من حركة مرور الـ tokens.
- قم بتوجيه عبء العمل هذا عبر فئة AI. استخدم التكوين الجديد لتتبع استخدام الـ tokens لكل مستهلك.
- اجمع بيانات إنفاق الـ tokens لبضعة أسابيع. قارن أعداد الـ tokens والتكاليف المرتبطة بها مع مراقبتك الحالية.
- استخدم الخط المرجعي (baseline) لتحديد الميزانية. قرر ما إذا كانت فوائد التحكم في التكلفة التي توفرها هذه الفئة تفوق قيود مرحلة المعاينة.
لا تنقل أعباء عمل الإنتاج الحرجة (mission-critical) إلى خدمة المعاينة حتى تنتقل إلى مرحلة التوفر العام (general availability).
وجهة نظر مغايرة: ليس الجميع بحاجة إلى فئة منفصلة
إذا كانت مؤسستك تقوم فقط باستدعاءات عرضية لـ LLM، فقد لا تكون التكلفة الإضافية لفئة AI مبررة. يمكنك تحقيق حوكمة على مستوى الـ tokens باستخدام إطار السياسات الحالي، وإن كان ذلك بجهد يدوي أكبر. تبرز أهمية هذه الفئة عندما تكون حركة مرور الذكاء الاصطناعي جزءاً كبيراً ومتنامياً من واجهة الـ API الخاصة بك.
الخلاصة
تقر فئة AI Gateway بأن حركة مرور LLM تسلك سلوكاً مختلفاً جوهرياً عن استدعاءات API التقليدية. ومن خلال التحول من عد الطلبات إلى الحوكمة القائمة على الـ tokens، فإنها تمنح المطورين طريقة عملية لإبقاء إنفاق الذكاء الاصطناعي تحت السيطرة دون الغرق في الكود المخصص. بالنسبة للفرق التي يكون استخدامها للذكاء الاصطناعي كبيراً بالفعل — أو من المتوقع أن ينمو — فإن اختبار المعاينة الآن يمكن أن يساعد في بناء خط مرجعي لإنفاق الـ tokens.