بوابة الذكاء الاصطناعي: لوحة التحكم المركزية للبنية التحتية للذكاء الاصطناعي التوليدي اليوم

مقدمة 

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

ومن المثير للاهتمام، أفاد أكثر من 50% بأن لديهم بالفعل ذكاء اصطناعي توليدي قيد التشغيل في الإنتاج، و15% آخرون يقومون بتوسيع نطاقه عبر فرق متعددة — وهي علامات واضحة على التبني القوي من قبل الشركات والنضج المتزايد في نشر تطبيقات الذكاء الاصطناعي التوليدي.

تطور بوابة نماذج اللغة الكبيرة كلوحة تحكم مركزية

ركزنا على كيف أن الـ بوابة الذكاء الاصطناعي تطورت على مدى الأشهر الستة إلى التسعة الماضية — من طبقة توجيه نماذج أساسية إلى أن أصبحت لوحة تحكم مركزية حاسمة ضمن مكدس الذكاء الاصطناعي التوليدي الحديث

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

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

الوصول إلى مجموعة الشرائح هنا

التحديات التي تواجهها الشركات التي تستخدم مزودي نماذج لغة كبيرة متعددين

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

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

تبرر هذه التحديات دور أفضل بوابات LLM كمستوى التحكم الأساسي في الأنظمة البيئية للذكاء الاصطناعي التوليدي للمؤسسات.

الوظائف الأساسية والمزايا لبوابة الذكاء الاصطناعي 

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

وظائف البوابة الرئيسية:

• طبقة واجهة برمجة تطبيقات موحدة: توفر واجهة برمجة تطبيقات واحدة ومتسقة تُخفي التفاصيل الخاصة بالمزود وآليات المصادقة. وهذا يضمن:
  
  • عدم الارتباط بمزود واحد.
  • التبديل السلس بين المزودين دون الحاجة لتغيير الكود.
  • تبسيط استخدام حزم تطوير البرامج (SDK) للمطورين.
• إدارة المفاتيح المركزية: تدير طرق مصادقة متنوعة (أدوار AWS IAM، مفاتيح OpenAI API، هويات GCP) من خلال نظام موحد. وتشمل المزايا:
  
  • إصدار مفاتيح API على مستوى المستخدم للتتبع.
  • حسابات الخدمة أو المفاتيح الافتراضية للتطبيقات.
  • سهولة تدوير المفاتيح وإدارتها.
  • تجنب المشاركة الشاملة لمفاتيح API وتتيح تحكمًا أدق في الأذونات.
• إعادة المحاولات والاستدعاءات الراجعة: يتعامل مع انقطاعات مزود الخدمة بسلاسة باستخدام سياسات تجاوز الفشل التلقائية. يضمن التراجع القابل للتكوين من نموذج إلى آخر خدمة متواصلة دون التأثير على كود التطبيق.
• تحديد المعدل وضوابط التكلفة: يتيح التطبيق الدقيق لسياسات استخدام واجهة برمجة التطبيقات (API) على أساس كل مستخدم، أو كل تطبيق، أو كل وحدة عمل. وتشمل الأمثلة:
  
  • حدود المكالمات اليومية للمطورين.
  • مستويات المستخدمين المميزين بحصص متباينة.
  • الحماية من الوكلاء الجامحين الذين يستدعون حلقات لا نهائية، مما يمنع الارتفاعات غير المتوقعة في الفواتير.
• موازنة التحميل: يقوم بأتمتة توجيه الطلبات إلى النموذج الأسرع أو الأكثر موثوقية في الوقت الفعلي، مع إجراء موازنة تحميل قائمة على زمن الاستجابة وفحوصات السلامة.
• طرح الكناري للنماذج الجديدة: يسهل الطرح التدريجي والمتحكم فيه لإصدارات النماذج الجديدة، مما يتيح الاختبار ومقارنة الأداء قبل الترحيل الكامل.

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

الفوائد الرئيسية

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

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

رؤية مستقبلية: التكامل مع خوادم MCP باستخدام بوابة الذكاء الاصطناعي

في المستقبل، ستتجاوز بوابة نماذج اللغة الكبيرة (LLM) النماذج لتشمل إدارة الأدوات والوكلاء بالكامل عبر بروتوكولات MCP و A2A -

• ما هو خادم MCP؟
  
  • يكشف خادم MCP عن واجهات برمجة تطبيقات المنتجات (مثل قنوات Slack، الرسائل، المستخدمين) بشكل يمكن للوكلاء المعتمدين على نماذج اللغة الكبيرة (LLM) اكتشافه واستهلاكه.
  • مثال: يكشف خادم MCP الخاص بـ Slack عن واجهات برمجة تطبيقات لقراءة القنوات والرسائل وإرسالها، وكلها مفهومة لوكيل LLM.
• تفاعل الوكيل مع خوادم MCP:
  
  • يستعلم الوكلاء خادم MCP لتحديد الأدوات المتاحة.
  • بناءً على طلب باللغة الطبيعية، يخطط الوكيل بشكل مستقل ويستدعي التسلسل الصحيح للأدوات (مثل استرداد الرسائل، تلخيصها، إنشاء مهام Jira).
• تكامل البوابة مع MCP:
  
  • ستعمل البوابة كنقطة وصول موحدة لكل من نماذج LLM وخوادم MCP داخل المؤسسة.
  • سيتمكن المستخدمون من إصدار أوامر باللغة الطبيعية (مثل "إنشاء مهام في Jira بناءً على رسائل Slack الخاصة بي") عبر الأدوات المتكاملة دون الحاجة إلى برمجة.
  • ستتم إدارة المصادقة بسلاسة، وموحّدة عبر موفري الهوية الحاليين مثل Okta أو Azure AD.
  • يمكّن هذا التكامل المستخدمين غير التقنيين من أتمتة العمليات التجارية بسهولة.

اقرأ المزيد عن هذا في مدونتنا المفصلة حول خادم MCP وبوابة الذكاء الاصطناعي.

• حالات الاستخدام المحتملة:
  
  • تحليل وتصنيف التنبيهات من خلال دمج بيانات Datadog وواجهة برمجة تطبيقات GitHub.
  • جدولة مهام سير العمل المتكررة باستخدام أدوات برمجية متعددة للمؤسسات.
  • التدقيق والحوكمة المركزيان لجميع أنشطة الوكلاء واستدعاءات الأدوات.

بنية بوابة الذكاء الاصطناعي

تعمل بوابة الذكاء الاصطناعي كطبقة وكيل حيوية بين التطبيقات ومقدمي نماذج اللغة (LLM). نظرًا لأن البوابة تقع في المسار الحرج لحركة مرور الإنتاج، يجب تصميمها مع مراعاة المبادئ الأساسية التالية:

الأولويات المعمارية الرئيسية:

1. التوفر العالي: يجب ألا تصبح البوابة نقطة فشل واحدة. حتى في مواجهة مشكلات التبعية (مثل انقطاع قواعد البيانات أو قوائم الانتظار)، يجب أن تستمر في خدمة حركة المرور بسلاسة.
2. زمن الاستجابة المنخفض: نظرًا لأنها تقع في مسار كل طلب استدلال، يجب أن تضيف البوابة أقل قدر من النفقات العامة لضمان تجربة مستخدم سريعة الاستجابة.
3. الإنتاجية العالية وقابلية التوسع: يجب أن يتوسع النظام خطيًا مع الحمل وأن يكون قادرًا على التعامل مع آلاف الطلبات المتزامنة مع استخدام فعال للموارد.
4. لا توجد تبعيات خارجية في المسار الحرج: يجب نقل أي عمليات مقيدة بالشبكة أو بالقرص إلى أنظمة غير متزامنة لمنع اختناقات الأداء.
5. اتخاذ القرارات في الذاكرة: الفحوصات الحيوية مثل تحديد المعدل, موازنة التحميل, المصادقة, و التفويض يجب أن تتم جميعها في الذاكرة لتحقيق أقصى سرعة وموثوقية.
6. فصل مستوى التحكم ومستوى الوكيل: يجب فصل تغييرات التكوين وإدارة النظام عن توجيه حركة المرور الحية، مما يتيح عمليات نشر عالمية مع عزل الأخطاء الإقليمي.

تجسد بوابة الذكاء الاصطناعي من TrueFoundry جميع مبادئ التصميم المذكورة أعلاه، وهي مصممة خصيصًا لزمن انتقال منخفض وموثوقية عالية وقابلية توسع سلسة.

بنية بوابة الذكاء الاصطناعي من TrueFoundry

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

بوابة الذكاء الاصطناعي من True Foundry

• دعم مزودين متعددين: أضف وادِر النماذج بسهولة من AWS و GCP و OpenAI و Anthropic و DeepInfra، بالإضافة إلى الخيارات المخصصة/المستضافة ذاتيًا.
• بيئة اختبار موحدة: اختبر وشغّل المطالبات على أي نموذج من خلال واجهة واحدة. يمكن تهيئة مفاتيح API وأسماء النماذج دون الحاجة إلى تغييرات في الكود.
• إدارة المطالبات مع الضوابط الوقائية: يعرض تنقيحًا للبيانات الحساسة في الوقت الفعلي أثناء إرسال المطالبات، مدمجًا مع خادم الضوابط الوقائية المركزي.
• مقاييس مفصلة وقابلية ملاحظة:
  
  • تتبع مباشر لمن يستدعي أي نموذج.
  • إحصائيات زمن الاستجابة المفصلة بما في ذلك "وقت أول رمز" و "زمن الاستجابة بين الرموز" (بالغة الأهمية لمراقبة أداء نماذج اللغة الكبيرة LLM).
  • إحصائيات تحديد المعدل، والعودة الاحتياطية، وتشغيل الضوابط الوقائية.
  • سجلات التدقيق لجميع أزواج الطلب والاستجابة، قابلة للتصدير لأغراض الامتثال.
• إعدادات المسؤول القابلة للتكوين: حدد حدود المعدل حسب المطور أو الفريق، وعيّن سياسات العودة الاحتياطية، والتوجيه القائم على زمن الاستجابة، وأدر الضوابط الوقائية مركزيًا.
• خارطة طريق تكامل خادم MCP: معاينة للوظائف القادمة التي تدعم جميع خوادم MCP الداخلية لأدوات مثل Gmail و Slack و Confluence و Jira و GitHub وواجهات برمجة التطبيقات المخصصة.

جلسة أسئلة وأجوبة مباشرة: تتناول قابلية التوسع والتكامل والاستفسارات الفنية

تختتم الجلسة بأسئلة وأجوبة من الجمهور تغطي:

• قابلية توسع البوابة: مصممة لتكون قابلة للتوسع أفقيًا؛ تُظهر معايير الأداء أن وحدة معالجة مركزية واحدة يمكنها التعامل مع 350 طلبًا في الثانية (RPS)، مما يتطلب عمليات نشر توسعية لمعدلات أعلى.
• زمن الاستجابة والاستقرار: توفر البوابة آليات استدعاء وإعادة محاولة لزيادة الموثوقية وتُبدّل النماذج تلقائيًا عندما يواجه المزودون انقطاعات.
• حدود حجم إدخال النموذج: لا تستطيع النماذج التعامل مع المدخلات الكبيرة جدًا (مثل 500 ميجابايت)؛ يوصى باستخدام أنظمة التوليد المعزز بالاسترجاع (RAG).
• تكاملات الأطر: متوافقة مع أطر عمل بناء الوكلاء الرئيسية مثل LangChain و LangGraph باستخدام واجهات برمجة تطبيقات قياسية متوافقة مع OpenAI دون الحاجة إلى حزم تطوير برامج (SDK) خاصة.
• دعم لغات البرمجة: تم بناء البوابة باستخدام أطر عمل خفيفة الوزن وعالية الأداء (Hono، مشابهة لتلك المستخدمة في Cloudflare workers)، وهي محايدة للغة لعملاء واجهة برمجة التطبيقات (Python، JavaScript، Go، إلخ).
• التكيف السريع مع واجهات برمجة تطبيقات النماذج الجديدة: تحديثات مستمرة لدعم المعلمات الخاصة بالموردين والمدخلات متعددة الوسائط مع توثيق دقيق.
• أدوات الحوكمة والتدقيق: القدرة على تصدير بيانات مفصلة عن زمن الاستجابة والاستخدام والتكلفة لعمليات التدقيق المتوافقة مع احتياجات الحوكمة.

يرجى التواصل معنا عبر support@truefoundry.com للحصول على عرض توضيحي مفصل أو احجز عرضًا توضيحيًا اليوم.