البنية التحتية الخفية التي تدعم الذكاء الاصطناعي المؤسسي القابل للتطوير: Tesseract Talks مع أبهيشيك شودري
.webp)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
في أحدث حلقات حوارات تيسراكت، التقى المضيف أوليفر روتشفورد بأبهيشيك تشودري، الشريك المؤسس والمدير التقني لشركة TrueFoundry، لمناقشة أحد أكبر التحديات التي تواجه الشركات اليوم: كيفية تصميم أنظمة ذكاء اصطناعي متطورة وآمنة في آن واحد دون الانهيار تحت وطأة التعقيد التشغيلي.
من انتشار النماذج وأطر عمل الوكلاء إلى الحوكمة والتحكم في التكاليف، أوضحت المحادثة شيئًا واحدًا: لم يعد الذكاء الاصطناعي للمؤسسات مجرد اختيار أفضل نموذج، بل يتعلق ببناء البنية التحتية المناسبة حوله بحيث يمكن أن تتحول التجارب إلى أنظمة إنتاج موثوقة وقابلة للتطوير.
فيما يلي المحاور الرئيسية والرؤى المستخلصة من المناقشة.
واقع بناء الذكاء الاصطناعي في بيئة متغيرة بسرعة
تعمل الشركات في بيئة ذكاء اصطناعي تتغير بوتيرة غير مسبوقة. تظهر نماذج ومقدمو خدمات جدد باستمرار، ويأتي كل منها بنقاط قوة وضعف وواجهات برمجة تطبيقات (APIs) مختلفة. في الوقت نفسه، لا تزال البروتوكولات مثل MCP (بروتوكول سياق النموذج) تتطور باستمرار، بينما تستمر أطر عمل الوكلاء مثل LangGraph وGoogle ADK وأطر عمل AWS وغيرها في التزايد.
قبل أن تبدأ الفرق في بناء تطبيقات ذات مغزى، يجب عليها اتخاذ قرارات أساسية بشأن النماذج التي ستستخدمها، وكيفية إدارة المطالبات والإصدارات، وأطر العمل التي ستعتمدها، وكيفية نشر وتوسيع نطاق ما تبنيه في النهاية. وبمجرد أن تبدأ الفرق في التعود على حزمة تقنية معينة، تتغير البيئة مرة أخرى، مع ظهور الوكلاء الصوتيون والأنظمة متعددة الوسائط مما يقدم متطلبات تقنية جديدة تمامًا.
لماذا تواجه معظم مشاريع الذكاء الاصطناعي صعوبات في مرحلة الإنتاج
كما يوضح أبهيشيك، "إن بناء عرض توضيحي يعمل في 80% من الحالات أمر سهل للغاية. تكمن المشكلة عندما تبدأ في توسيع نطاقه." بمجرد أن يتفاعل المستخدمون الحقيقيون مع الأنظمة بطرق غير متوقعة، تظهر بسرعة الحالات الهامشية والأعطال وثغرات الموثوقية. وبمجرد تعرض الأنظمة لعملاء حقيقيين، تظهر المطالبات غير المتوقعة والحالات الهامشية بسرعة ثغرات في الموثوقية.
عقبة رئيسية أخرى هي توفر النموذج وأدائه. أشار أبهيشيك: "إذا توقف مزود النموذج عن العمل، فسيتوقف تطبيقك." حتى كبار مزودي النماذج يواجهون انقطاعات وتباطؤات واضطرابات إقليمية. عندما يعتمد تطبيق بشكل مباشر على نقطة نهاية نموذج خارجية واحدة، فإن أي عدم استقرار يتحول فورًا إلى وقت تعطل يواجهه العميل، مما قد يضر بالثقة في المنتج.
التكلفة هي العامل الحاسم الثالث. على عكس البرامج التقليدية، تتحمل أنظمة الذكاء الاصطناعي تكاليف استدلال مستمرة تتناسب طرديًا مع الاستخدام. تعتمد العديد من الشركات في البداية نماذج مستضافة مغلقة المصدر لتحقيق السرعة، لتدرك لاحقًا أن تكاليف الرموز تجعل حالات استخدامها غير مستدامة اقتصاديًا. استجابة لذلك، تستثمر بعض المؤسسات في بنيتها التحتية الخاصة بوحدات معالجة الرسوميات (GPU) وتضبط نماذج مفتوحة المصدر أصغر، مقايضة الراحة قصيرة المدى بالتحكم في التكاليف على المدى الطويل وعائد استثمار يمكن التنبؤ به.
لماذا أصبحت بوابات الذكاء الاصطناعي بنية تحتية أساسية
قبل عام، قلما تحدثت الفرق عن بوابات الذكاء الاصطناعي كمكون معماري مميز. اليوم، أصبحت تتحول بسرعة إلى ممارسة معيارية لأي مؤسسة جادة في تشغيل الذكاء الاصطناعي في مرحلة الإنتاج.
وفقًا لأبهيشيك، ظهرت بوابات الذكاء الاصطناعي لحل ثلاث مشكلات أساسية تواجه المؤسسات:
- توحيد واجهات برمجة التطبيقات (API): تعمل بوابة الذكاء الاصطناعي على تجريد الاختلافات في واجهات موفري النماذج، مما يسمح للفرق بالتبديل أو التوجيه بين النماذج دون الحاجة إلى إعادة كتابة كود التطبيق.
- الأمان وإدارة المفاتيح: باستخدام بوابة الذكاء الاصطناعي، يصادق المطورون على الأنظمة الداخلية بينما تظل بيانات اعتماد الموفرين مدارة مركزيًا، ويتم تدويرها وحمايتها.
- الحوكمة وإمكانية المراقبة: يمكن فرض ضوابط الحماية، وحدود الميزانية، وسجلات التدقيق، وفحوصات الامتثال جميعًا بشكل متسق، بدلاً من الاعتماد على كل فريق تطبيق لتنفيذ أفضل الممارسات بمفرده. في بعض الحالات، أشار أبهيشيك، بمجرد التحقق من صحة الوكلاء، "الانتقال إلى الإنتاج يتم بنقرة واحدة حرفيًا."
لماذا بوابات الذكاء الاصطناعي ليست مجرد بوابات API
على الرغم من أن مصطلح "البوابة" قد يبدو مألوفًا، إلا أن بوابات الذكاء الاصطناعي تختلف بشكل كبير عن بوابات API التقليدية. صُممت البوابات التقليدية حول أنماط طلب-استجابة قصيرة الأجل وتدفقات مصادقة بسيطة. كما أنها تقيس الاستخدام من حيث الطلبات، وليس الاقتصاد القائم على الرموز المميزة الذي يدفع تكاليف الذكاء الاصطناعي.
أعباء عمل الذكاء الاصطناعي مختلفة جوهريًا. غالبًا ما يتم بث الاستجابات، ويمكن أن تكون التفاعلات طويلة الأمد، وتُدخل الأنظمة الصوتية اتصالات مستمرة وقيودًا في الوقت الفعلي. بالإضافة إلى ذلك، فإن العديد من المخاطر المتعلقة بالذكاء الاصطناعي دلالية وليست نحوية، مما يعني أن تطبيق السياسات يجب أن يعمل على مستوى المعنى، وليس مجرد الكلمات الرئيسية أو المخططات.
بينما من الممكن تقنيًا توسيع بوابات API الحالية لدعم حالات استخدام الذكاء الاصطناعي، بوابات الذكاء الاصطناعي المصممة خصيصًا مصممة من الألف إلى الياء للتعامل مع هذه الأنماط بشكل أصلي.
المستقبل: بوابات الذكاء الاصطناعي كمنسقات للذكاء الاصطناعي للمؤسسات
بالنظر إلى المستقبل، من المرجح أن يتوسع دور بوابة الذكاء الاصطناعي إلى ما هو أبعد بكثير من توجيه الطلبات. وصف أبهيشيك مستقبلاً تصبح فيه البوابة سجلًا مركزيًا للنماذج والأدوات وخوادم MCP وحتى الوكلاء أنفسهم.
في مثل هذه البيئة، يمكن أن تُعرض أنظمة المؤسسات مثل Slack وGitHub وConfluence وقواعد البيانات الداخلية جميعها كخدمات ذكاء اصطناعي قابلة للاكتشاف. عندما يطرح المستخدمون أسئلة عمل معقدة، يمكن للبوابة أن تنسق ديناميكيًا العديد من الوكلاء والأدوات لتجميع الإجابات، بدلاً من الاعتماد على تطبيقات أحادية الغرض.
بدلاً من بناء ميزات ذكاء اصطناعي معزولة، ستقوم المؤسسات بتأليف سير عمل ذكية من مكونات قابلة لإعادة الاستخدام. يعكس هذا النهج كيفية تطور منصات البرمجيات الحديثة، بالانتقال من التطبيقات المتجانسة إلى أنظمة بيئية من الخدمات القابلة للتشغيل المتبادل.
توفر بوابة ذكاء اصطناعي مخصصة مثل TrueFoundry الأساس اللازم لتجاوز مرحلة التجريب. فهي تتيح حوكمة متسقة، وتوجيهًا موثوقًا، وضوابط للتكلفة، وإمكانية مراقبة عميقة عبر مكدس الذكاء الاصطناعي بأكمله. والأهم من ذلك، أنها تسمح للمؤسسات بتوسيع نطاق الابتكار دون التضحية بالأمان أو الامتثال.
شاهد الحلقة السابقة من Tesseract Talks مع نيكونج باجاج هنا تحويل فوضى الذكاء الاصطناعي إلى تحكم: محادثة حول الذكاء الاصطناعي الوكيلي مع Tesseract Talks
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI



















.png)
.webp)










.webp)






