تعرض خدمة Azure OpenAI واجهات برمجة تطبيقات HTTP التي تسمح لتطبيقاتك بإجراء عمليات التضمين أو الإكمال باستخدام نماذج لغة OpenAI. تستدعي التطبيقات الذكية واجهات برمجة تطبيقات HTTP هذه مباشرة من العملاء أو المنسقين. تتضمن أمثلة العملاء تعليمة الدردشة البرمجية لواجهة المستخدم وتدفقات معالجة البيانات المخصصة. تتضمن أمثلة المنسقين LangChain وKernel الدلالي وAzure التعلم الآلي تدفق المطالبة. عندما يتصل حمل العمل الخاص بك بمثيل واحد أو أكثر من مثيلات Azure OpenAI، يجب أن تقرر ما إذا كان هؤلاء المستهلكون يتصلون مباشرة أو من خلال بوابة واجهة برمجة تطبيقات الوكيل العكسي.
استخدم هذا الدليل للتعرف على التحديات الرئيسية عبر الركائز الخمس لإطار عمل Azure Well-Architected الذي تواجهه إذا كان تصميم حمل العمل الخاص بك يتضمن الوصول المباشر من المستهلكين إلى واجهات برمجة تطبيقات مستوى بيانات Azure OpenAI. ثم تعرف على كيفية إدخال بوابة في البنية الخاصة بك يمكن أن يساعد في حل تحديات الوصول المباشر هذه، مع إدخال تحديات جديدة. توضح هذه المقالة النمط المعماري ولكن ليس كيفية تنفيذ البوابة.
نظرا لأنه يمكن استخدام بوابة لحل سيناريوهات معينة قد لا تكون موجودة في كل حمل عمل، راجع التأكد من رؤية إرشادات سيناريو محددة، والتي تبحث في حالة الاستخدام المحددة هذه للبوابة بمزيد من التعمق.
التحديات الرئيسية
دون بوابة واجهة برمجة التطبيقات أو القدرة على إضافة منطق إلى واجهات برمجة تطبيقات HTTP Azure OpenAI، يجب على العميل التعامل مع منطق عميل واجهة برمجة التطبيقات، والذي يتضمن آليات إعادة المحاولة أو قاطعات الدوائر. يمكن أن يكون هذا الموقف صعبا في السيناريوهات التي لا تتحكم فيها مباشرة في التعليمات البرمجية للعميل، أو عندما تقتصر التعليمات البرمجية على استخدام SDK محدد. يمثل العديد من العملاء أو مثيلات وتوزيعات Azure OpenAI المتعددة تحديات إضافية، مثل تنسيق عمليات النشر الآمنة وإمكانية المراقبة.
يوفر هذا القسم أمثلة على تحديات هيكلية رئيسية محددة قد تواجهها إذا كانت بنيتك تدعم الوصول المباشر إلى Azure OpenAI من المستهلكين فقط. يتم تنظيم التحديات باستخدام ركائز Azure Well-Architected Framework.
تحديات الموثوقية
وتعتمد موثوقية عبء العمل على عدة عوامل، بما في ذلك قدرته على الحفاظ على الذات والاسترداد الذاتي، والتي غالبا ما تنفذ من خلال آليات النسخ المتماثل وتجاوز الفشل. بدون بوابة، يجب معالجة جميع مخاوف الموثوقية حصريا باستخدام منطق العميل وميزات خدمة Azure OpenAI. يتم اختراق موثوقية حمل العمل عندما لا يتوفر تحكم موثوقية كاف في أي من هذين السطحين.
التكرار: الفشل بين مثيلات Azure OpenAI المتعددة استنادا إلى توفر الخدمة هو مسؤولية العميل التي تحتاج إلى التحكم فيها من خلال التكوين والمنطق المخصص.
توسيع النطاق للتعامل مع الارتفاعات: تجاوز الفشل في مثيلات Azure OpenAI ذات السعة عند تقييدها هي مسؤولية عميل أخرى تحتاج إلى التحكم فيها من خلال التكوين والمنطق المخصص. تحديث تكوينات عميل متعددة لمثيلات Azure OpenAI الجديدة يمثل مخاطر أكبر ولديه مخاوف تتعلق بالوقت المناسب. وينطبق الشيء نفسه على تحديث التعليمات البرمجية للعميل لتنفيذ التغييرات في المنطق، مثل توجيه الطلبات ذات الأولوية المنخفضة إلى قائمة انتظار أثناء فترات الطلب المرتفع.
موازنة التحميل أو التقييد: تقوم واجهات برمجة تطبيقات Azure OpenAI بتقييد الطلبات عن طريق إرجاع رمز استجابة خطأ HTTP 429 إلى الطلبات التي تتجاوز الرمز المميز لكل دقيقة (TPM) أو الطلبات لكل دقيقة (RPM) في نموذج الدفع أولا بأول. تقوم واجهات برمجة تطبيقات Azure OpenAI أيضا بتقييد الطلبات التي تتجاوز سعة وحدات الإنتاجية المقدمة (PTU) لنموذج الفوترة المقدم مسبقا. يتم ترك معالجة منطق التراجع وإعادة المحاولة المناسب حصريا لتطبيقات العميل.
التحديات الأمنية
يجب أن تساعد عناصر التحكم في الأمان في حماية سرية حمل العمل وتكامله وتوافره. بدون بوابة، يجب معالجة جميع مخاوف الأمان حصريا في منطق العميل وميزات خدمة Azure OpenAI. قد تتطلب متطلبات حمل العمل أكثر مما هو متاح لتجزئة العميل أو التحكم في العميل أو ميزات أمان الخدمة للاتصال المباشر.
إدارة الهوية - نطاق المصادقة: يمكن تأمين واجهات برمجة تطبيقات مستوى البيانات التي يعرضها Azure OpenAI بإحدى طريقتين: مفتاح API أو التحكم في الوصول المستند إلى الدور (RBAC) في Azure. في كلتا الحالتين، تحدث المصادقة على مستوى مثيل Azure OpenAI، وليس مستوى النشر الفردي، مما يقدم تعقيد لتوفير الوصول الأقل امتيازا وتجزئة الهوية لنماذج نشر محددة.
إدارة الهوية - موفرو الهوية: يجب على العملاء الذين لا يمكنهم استخدام الهويات الموجودة في مستأجر Microsoft Entra الذي يدعم مثيل Azure OpenAI مشاركة مفتاح API واحد للوصول الكامل. تحتوي مفاتيح واجهة برمجة التطبيقات على قيود فائدة الأمان وهي إشكالية عند مشاركة عملاء متعددين ومشاركة جميعهم نفس الهوية.
أمان الشبكة: اعتمادا على موقع العميل بالنسبة إلى مثيلات Azure OpenAI، قد يكون الوصول العام إلى الإنترنت إلى نماذج اللغة ضروريا.
سيادة البيانات: تشير سيادة البيانات في سياق Azure OpenAI إلى المتطلبات القانونية والتنظيمية المتعلقة بتخزين البيانات ومعالجتها داخل الحدود الجغرافية لبلد أو منطقة معينة. يحتاج حمل العمل الخاص بك إلى ضمان الترابط الإقليمي حتى يتمكن العملاء من الامتثال لقوانين موقع البيانات والسيادة. تتضمن هذه العملية عمليات توزيع Azure OpenAI متعددة.
تحديات تحسين التكلفة
تستفيد أحمال العمل عندما تقلل البنيات من الهدر وتعظيم الأداة المساعدة. تعد نمذجة التكلفة القوية ومراقبتها مطلبا مهما لأي حمل عمل. بدون بوابة، يمكن تحقيق استخدام PTU أو تتبع التكلفة لكل عميل بشكل موثوق حصريا من تجميع بيانات تتبع استخدام مثيل Azure OpenAI.
تتبع التكلفة: تقتصر القدرة على توفير منظور مالي لاستخدام Azure OpenAI على البيانات المجمعة من بيانات تتبع استخدام مثيل Azure OpenAI. عند الحاجة إلى إجراء استرداد أو عرض، تحتاج إلى سمة استخدام بيانات تتبع الاستخدام مع عملاء مختلفين عبر أقسام مختلفة أو حتى عملاء لسيناريوهات متعددة المستأجرين.
استخدام معدل النقل المقدم: يريد حمل العمل الخاص بك تجنب الهدر من خلال الاستخدام الكامل لمعدل النقل المقدم الذي دفعت ثمنه. وهذا يعني أنه يجب الوثوق بالعملاء وتنسيقهم لاستخدام عمليات نشر النماذج المستندة إلى PTU قبل الامتداد إلى أي عمليات نشر نموذج قائمة على الاستهلاك.
تحديات التميز التشغيلي
بدون بوابة، تقتصر إمكانية المراقبة والتحكم في التغيير وعمليات التطوير على ما يوفره الاتصال المباشر من عميل إلى خادم.
التحكم في الحصة النسبية: يتلقى العملاء 429 رمز استجابة مباشرة من Azure OpenAI عند تقييد واجهات برمجة تطبيقات HTTP. مشغلو حمل العمل مسؤولون عن ضمان توفر حصة نسبية كافية للاستخدام المشروع وأن العملاء الذين يسيئون التصرف لا يستهلكون بشكل زائد. عندما يتكون حمل العمل الخاص بك من عمليات نشر نماذج متعددة، قد يكون من الصعب تصور فهم استخدام الحصة النسبية وتوافر الحصة النسبية.
المراقبة وإمكانية المراقبة: تتوفر مقاييس Azure OpenAI الافتراضية من خلال Azure Monitor. ومع ذلك، هناك زمن انتقال مع توفر البيانات ولا يوفر مراقبة في الوقت الحقيقي.
ممارسات النشر الآمنة: تتطلب عملية GenAIOps التنسيق بين العملاء والنماذج التي يتم نشرها في Azure OpenAI. بالنسبة لنهج النشر المتقدمة، مثل الأزرق والأخضر أو الكناري، يجب معالجة المنطق على جانب العميل.
تحديات كفاءة الأداء
بدون بوابة، يضع حمل العمل الخاص بك المسؤولية على العملاء ليكونوا متصرفين بشكل فردي بشكل جيد وأن يتصرفوا بإنصاف مع العملاء الآخرين مقابل القدرة المحدودة.
تحسين الأداء - حركة المرور ذات الأولوية: تحديد أولويات طلبات العملاء بحيث يكون للعملاء ذوي الأولوية العالية وصول تفضيلي على العملاء ذوي الأولوية المنخفضة سيتطلب تنسيقا واسعا ومن المحتمل أن يكون غير معقول من العميل إلى العميل. قد تستفيد بعض أحمال العمل من وجود طلبات ذات أولوية منخفضة في قائمة الانتظار لتشغيلها عندما يكون استخدام النموذج منخفضا.
تحسين الأداء - توافق العميل: لمشاركة السعة، يجب أن يتصرف العملاء بشكل جيد. مثال على ذلك هو عندما يضمن العملاء تعيين
max_tokensوbest_ofإلى القيم المعتمدة. بدون بوابة، يجب أن تثق بالعملاء للعمل في أفضل مصلحة للحفاظ على سعة مثيل Azure OpenAI الخاص بك.تقليل زمن الانتقال: في حين أن زمن انتقال الشبكة عادة ما يكون مكونا صغيرا من تدفق طلب المطالبة والإكمال الإجمالي، فقد يكون ضمان توجيه العملاء إلى نقطة نهاية الشبكة والنموذج القريب منهم مفيدا. بدون بوابة، سيحتاج العملاء إلى تحديد نقاط نهاية توزيع النموذج التي يجب استخدامها وبيانات الاعتماد الضرورية لواجهة برمجة تطبيقات مستوى بيانات Azure OpenAI المحددة.
حل
الشكل 1: البنية المفاهيمية للوصول إلى Azure OpenAI من خلال بوابة
لمعالجة العديد من التحديات المدرجة في التحديات الرئيسية، يمكنك إدخال بوابة وكيل عكسي لفصل التطبيق الذكي من Azure OpenAI. يتيح لك إلغاء تحميل البوابة هذه نقل المسؤولية والتعقيد وإمكانية الملاحظة بعيدا عن العملاء ويوفر لك فرصة لزيادة Azure OpenAI من خلال توفير قدرات أخرى غير مضمنة. في ما يلي بعض الأمثلة:
إمكانية تنفيذ المصادقة الموحدة.
القدرة على التحكم في الضغط على النماذج من خلال تحديد المعدل.
المراقبة الشاملة والمتعددة النماذج.
القدرة على تقديم تجميع البوابة والتوجيه المتقدم إلى خدمات متعددة، مثل توجيه الرسائل ذات الأولوية المنخفضة إلى قائمة انتظار لتسوية التحميل المستندة إلى قائمة الانتظار أو الحساب لتنفيذ المهام.
موازنة التحميل التي تستخدم مراقبة نقطة النهاية الصحية للتوزيع فقط إلى نقاط النهاية الصحية عن طريق تقسيم الدائرة على عمليات نشر النموذج غير المتوفرة أو ذات التحميل الزائد.
تحتوي بعض السيناريوهات المحددة على مزيد من الإرشادات المتاحة التي تتناول مباشرة بوابة API ومثيلات Azure OpenAI. يتم سرد هذه السيناريوهات في قسم الخطوات التالية.
الاعتبارات
عند تقديم مكون جديد في البنية الخاصة بك، تحتاج إلى تقييم المقايضات المقدمة حديثا. عند إدخال بوابة API بين عملائك و مستوى بيانات Azure OpenAI لمعالجة أي من التحديات الرئيسية، فإنك تقدم اعتبارات جديدة في البنية الخاصة بك. قم بتقييم ما إذا كان تأثير حمل العمل عبر هذه الاعتبارات المعمارية يبرر القيمة المضافة أو أداة البوابة.
الموثوقيه
تضمن الموثوقية أن التطبيق الخاص بك يفي بالالتزامات التي قطعتها على عملائك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للموثوقية.
يمكن أن يقدم حل البوابة نقطة فشل واحدة. قد يكون لهذا الفشل أصله في توفر الخدمة للنظام الأساسي للبوابة، أو انقطاعات بسبب عمليات نشر التعليمات البرمجية أو التكوين، أو حتى نقاط نهاية API الهامة التي تم تكوينها بشكل خاطئ في البوابة الخاصة بك. تأكد من تصميم التنفيذ الخاص بك لتلبية متطلبات توفر حمل العمل الخاص بك. ضع في اعتبارك قدرات المرونة والتسامح مع الخطأ في التنفيذ عن طريق تضمين البوابة في تحليل وضع الفشل لحمل العمل.
قد يتطلب الحل الخاص بك قدرات توجيه عمومية إذا كانت بنيتك تتطلب مثيلات Azure OpenAI في مناطق متعددة. يمكن أن يزيد هذا الموقف من تعقيد المخطط من خلال إدارة أسماء المجالات المؤهلة بالكامل الإضافية وشهادات TLS ومكونات التوجيه العمومية.
هام
لا تنفذ بوابة إذا كان القيام بذلك سيعرض للخطر قدرة حمل العمل الخاص بك على تحقيق الأهداف المتفق عليها على مستوى الخدمة (SLOs).
الأمان
عند النظر في كيفية استفادة بوابة واجهة برمجة التطبيقات من البنية الخاصة بك، استخدم قائمة اختيار مراجعة التصميم للأمان لتقييم تصميمك. تحتاج إلى معالجة اعتبارات الأمان، مثل ما يلي:
تتم زيادة مساحة سطح حمل العمل مع إضافة البوابة. توفر مساحة السطح هذه اعتبارات إضافية لإدارة الهوية والوصول (IAM) لموارد Azure، وزيادة جهود التقوية، وأكثر من ذلك.
يمكن أن تعمل البوابة كتحول حدود شبكة بين مساحة شبكة العميل ومساحة شبكة Azure OpenAI الخاصة. على الرغم من أن البوابة تجعل نقطة نهاية Azure OpenAI التي كانت تواجه الإنترنت في السابق خاصة من خلال استخدام Azure Private Link، فإنها الآن تصبح نقطة الدخول الجديدة ويجب تأمينها بشكل كاف.
البوابة في وضع فريد لرؤية بيانات الطلب الأولية والاستجابات التي تمت صياغتها من نموذج اللغة، والتي يمكن أن تتضمن بيانات سرية من أي مصدر. يتم الآن توسيع نطاق توافق البيانات والنطاق التنظيمي إلى هذا المكون الآخر.
يمكن للبوابة توسيع نطاق تخويل العميل والمصادقة خارج معرف Microsoft Entra ومصادقة مفتاح API، وربما عبر موفري هوية متعددين (IdP).
يجب أن يتم أخذ سيادة البيانات في الاعتبار في تنفيذك في عمليات التنفيذ متعددة المناطق. تأكد من أن منطق الحوسبة والتوجيه الخاص بالبوابة يلتزم بمتطلبات السيادة الموضوعة على حمل العمل الخاص بك.
هام
لا تقم بتنفيذ بوابة إذا كان القيام بذلك سيترك حمل العمل الخاص بك غير قادر على حماية سرية نفسه أو تكامله أو توفر بياناته أو بيانات مستخدميه.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم لتحسين التكلفة.
تحتوي جميع بوابات واجهة برمجة التطبيقات المنفذة على تكاليف وقت التشغيل التي تحتاج إلى الموازنة والحساب. عادة ما تزيد هذه التكاليف مع الميزات المضافة لمعالجة موثوقية البوابة نفسها وأمانها وأدائها جنبا إلى جنب مع التكاليف التشغيلية المقدمة مع إدارة APIOps المضافة. يجب قياس هذه التكاليف المضافة مقابل القيمة الجديدة التي يتم تسليمها من النظام مع البوابة. تريد الوصول إلى نقطة تفوق فيها الإمكانات الجديدة المقدمة باستخدام بوابة تكلفة تنفيذ البوابة وصيانتها. اعتمادا على علاقة حمل العمل الخاص بك بمستخدميه، قد تتمكن من استخدام الاسترداد.
التميز التشغيلي
عند النظر في كيفية استفادة بوابة واجهة برمجة التطبيقات من بنيتك، استخدم قائمة اختيار مراجعة التصميم للتميز التشغيلي لتقييم تصميمك. تحتاج إلى معالجة اعتبارات التميز التشغيلي مثل ما يلي:
يجب مراقبة البوابة نفسها من خلال حل مراقبة حمل العمل الخاص بك وربما من قبل العملاء. وهذا يعني أنه يجب تضمين حساب البوابة والعمليات في النمذجة الصحية لحمل العمل.
تحتاج ممارسات النشر الآمنة الآن إلى معالجة نشر البنية الأساسية لبوابة API والرمز أو تكوين توجيه البوابة. يحتاج حل أتمتة البنية الأساسية والبنية الأساسية كتعليق برمجي (IaC) إلى التفكير في كيفية التعامل مع بوابتك كمورد طويل الأمد في حمل العمل.
تحتاج إلى إنشاء أو توسيع نهج APIOps الخاص بك لتغطية واجهات برمجة التطبيقات المكشوفة في البوابة.
كفاءة الأداء
عند النظر في كيفية استفادة بوابة واجهة برمجة التطبيقات من البنية الخاصة بك، استخدم قائمة اختيار مراجعة التصميم لكفاءة الأداء لتقييم تصميمك. تحتاج إلى معالجة اعتبارات كفاءة الأداء مثل ما يلي:
يمكن أن تقدم خدمة البوابة ازدحاما في معدل النقل. تأكد من أن البوابة لديها أداء كاف للتعامل مع الحمل المتزامن الكامل ويمكنها بسهولة التوسع بما يتماشى مع توقعات النمو الخاصة بك. تأكد من المرونة في الحل بحيث يمكن للبوابة تقليل العرض، أو تقليصه، عندما يكون الطلب منخفضا، مثل استخدام يوم العمل.
تحتوي خدمة البوابة على معالجة يجب أن تنفذها لكل طلب، وتقدم زمن انتقال إضافي لكل استدعاء API. يجب تحسين منطق التوجيه الخاص بك للحفاظ على أداء الطلبات بشكل جيد.
في معظم الحالات، يجب أن تكون البوابة قريبة جغرافيا من كل من المستخدمين ومثيلات Azure OpenAI لتقليل زمن الانتقال. في حين أن زمن انتقال الشبكة عادة ما يكون نسبة مئوية صغيرة من الوقت في استدعاءات API الإجمالية لنماذج اللغة، فقد يكون عاملا تنافسيا لحمل العمل الخاص بك.
تقييم تأثير البوابة على ميزات Azure OpenAI، مثل استجابات الدفق أو تثبيت المثيل للتفاعلات ذات الحالة، مثل واجهة برمجة تطبيقات المساعدين.
هام
لا تنفذ بوابة إذا كان القيام بذلك يجعل تحقيق أهداف الأداء المتفاوض عليها مستحيلا أو المساومة للغاية على المقايضات الأخرى.
خيارات التنفيذ
لا يقدم Azure حلا للمفتاح البديل مصمما خصيصا لواجهة برمجة تطبيقات HTTP الخاصة ب Azure OpenAI أو واجهات برمجة التطبيقات الأخرى لاستدلال نموذج اللغة المخصصة. ولكن لا تزال هناك العديد من الخيارات لفريق حمل العمل الخاص بك لتنفيذها، مثل بوابة في Azure.
استخدام Azure API Management
Azure API Management هي خدمة مدارة من قبل النظام الأساسي مصممة لإلغاء تحميل المخاوف الشاملة لواجهات برمجة التطبيقات المستندة إلى HTTP. يعتمد على التكوين ويدعم التخصيص من خلال نظام نهج معالجة الطلبات الواردة والصادرة. وهو يدعم النسخ المتماثلة عالية التوفر والتكرار في المنطقة وحتى النسخ المتماثلة متعددة المناطق باستخدام وحدة تحكم واحدة.
يجب تنفيذ معظم منطق توجيه البوابة ومعالجة الطلب في نظام النهج لإدارة واجهة برمجة التطبيقات. يمكنك الجمع بين النهج المضمنة، مثل الحد من استخدام الرمز المميز لواجهة برمجة تطبيقات Azure OpenAI أو إصدار مقاييس لاستهلاك رموز Azure OpenAI المميزة والنهج المخصصة الخاصة بك. يمكن العثور على بعض النهج والسيناريوهات المخصصة على سبيل المثال في مستودع GitHub لمستودع مجموعة أدوات بوابة APIM.
استخدم دليل خدمة إطار عمل جيد التصميم لإدارة واجهة برمجة التطبيقات عند تصميم حل يتضمن إدارة واجهة برمجة تطبيقات Azure.
استخدام Azure API Management لتنفيذ البوابة الخاصة بك هو النهج المفضل عموما لإنشاء وتشغيل بوابة Azure OpenAI. يفضل ذلك لأن الخدمة عبارة عن نظام أساسي كخدمة (PaaS) تقدم قدرات مدمجة غنية، وقابلية وصول عالية، وخيارات شبكات. كما أن لديها نهج APIOps قوية لإدارة واجهات برمجة التطبيقات الخاصة بك الإكمال.
استخدام التعليمة البرمجية المخصصة
يتطلب نهج التعليمات البرمجية المخصصة فريق تطوير البرامج لإنشاء حل مخصص مرمز ونشر هذا الحل على نظام أساسي لتطبيق Azure من اختيارهم. يمكن أن يكون بناء حل مدار ذاتيا للتعامل مع منطق البوابة مناسبا لفرق حمل العمل التي تجيد إدارة الشبكة ورمز التوجيه.
يمكن لحمل العمل عادة استخدام الحوسبة التي هم على دراية بها، مثل استضافة التعليمات البرمجية للبوابة على Azure App Service أو Azure Container Apps أو Azure Kubernetes Service.
يمكن أيضا أن تكون عمليات نشر التعليمات البرمجية المخصصة أمام إدارة واجهة برمجة التطبيقات عند استخدام إدارة واجهة برمجة التطبيقات حصريا لإمكانيات بوابة HTTP API الأساسية الخاصة بها بين عملائك والرمز المخصص الخاص بك. بهذه الطريقة، تتفاعل التعليمات البرمجية المخصصة حصريا مع واجهات برمجة تطبيقات AZURE OpenAI HTTP استنادا إلى منطق العمل الضروري.
يمكن اعتبار استخدام تقنية بوابة غير تابعة ل Microsoft، وهي منتج أو خدمة لا يوفرها Azure في الأصل، كجزء من هذا النهج.
مثال على البنية
الشكل 2: مثال على بنية الوصول إلى Azure OpenAI من خلال بوابة تستند إلى إدارة واجهة برمجة تطبيقات Azure
الخطوات التالية
تعرف على سيناريو محدد حيث يتم استخدام نشر بوابة بين تطبيق ذكي وتوزيع Azure OpenAI لمعالجة متطلبات حمل العمل:
تعرف على طرق تنفيذ التسجيل والمراقبة لنماذج Azure OpenAI.
الموارد ذات الصلة
- خدمة Azure OpenAI
- بوابة واجهة برمجة التطبيقات في Azure APIM
- مسرع المنطقة المنتقل إليها لإدارة واجهة برمجة التطبيقات الذي يغطي سيناريوهات الذكاء الاصطناعي التوليدية
- مجموعة أدوات بوابة APIM