يمكن أن تكون بنيات حمل العمل التي تتضمن خدمة Azure OpenAI بسيطة مثل تطبيق عميل واحد أو أكثر يستهلك مباشرة نشر نموذج Azure OpenAI واحد مباشرة، ولكن لا يمكن تصميم جميع أحمال العمل بهذه البساطة. تتضمن السيناريوهات الأكثر تعقيدا طبولوجيا مع عملاء متعددين أو عمليات نشر Azure OpenAI متعددة أو مثيلات Azure OpenAI متعددة. في هذه الحالات، يمكن أن يكون إدخال بوابة أمام Azure OpenAI مفيدا لتصميم حمل العمل.
تحل مثيلات Azure OpenAI المتعددة أو عمليات نشر النموذج متطلبات محددة في بنية حمل العمل. يمكن تصنيفها في أربعة طبولوجيا رئيسية.
- عمليات نشر نماذج متعددة في مثيل Azure OpenAI واحد
- مثيلات Azure OpenAI المتعددة في منطقة واحدة واشتراك واحد
- مثيلات Azure OpenAI المتعددة في منطقة واحدة عبر اشتراكات متعددة
- مثيلات Azure OpenAI المتعددة عبر مناطق متعددة
هذه الطوبولوجيا من تلقاء نفسها لا تتطلب استخدام بوابة. يعتمد اختيار البوابة على ما إذا كان حمل العمل يستفيد من تضمينه في البنية. توضح هذه المقالة التحديات التي يعالجها كل مخطط من المخططات الأربعة، وفوائد وتكاليف تضمين بوابة في كل طوبولوجيا.
تلميح
ما لم يذكر خلاف ذلك، فإن الإرشادات التالية مناسبة لكل من البوابات المستندة إلى Azure API Management أو بوابات التعليمات البرمجية المخصصة. تمثل الرسومات التخطيطية للبنية مكون البوابة بشكل عام في معظم الحالات لتوضيح ذلك.
عمليات نشر نماذج متعددة في مثيل Azure OpenAI واحد
تفاصيل الطوبولوجيا لتوزيعات نماذج متعددة
- عمليات نشر نموذج Azure OpenAI: متعددة
- مثيلات Azure OpenAI: واحدة
- الاشتراكات: اشتراك واحد
- المناطق: واحدة
حالات استخدام المخططات لنشر نماذج متعددة
يدعم المخطط الذي يتضمن مثيل Azure OpenAI واحد ولكنه يحتوي على أكثر من نموذج واحد تم نشره بشكل متزامن حالات الاستخدام التالية:
كشف قدرات نموذج مختلفة، مثل
gpt-35-turboوgpt-4و و نماذج دقيقة مخصصة.كشف إصدارات نماذج مختلفة، مثل
0613،1106و، ونماذج مخصصة دقيقة لدعم تطور حمل العمل أو عمليات النشر الزرقاء والأخضر.كشف الحصص النسبية المختلفة المعينة (30,000 Token-Per-Minute (TPM)، 60,000 TPM) لدعم تقييد الاستهلاك عبر عملاء متعددين.
تقديم بوابة لتوزيع نماذج متعددة
يهدف إدخال بوابة في هذا المخطط في المقام الأول إلى تجريد العملاء بعيدا عن التحديد الذاتي لمثيل نموذج معين بين عمليات النشر المتوفرة على المثيل. تسمح البوابة للتحكم من جانب الخادم بتوجيه طلب عميل إلى نموذج معين دون الحاجة إلى إعادة نشر التعليمات البرمجية للعميل أو تغيير تكوين العميل.
البوابة مفيدة بشكل خاص عندما لا تتحكم في التعليمات البرمجية للعميل. كما أنه مفيد عند نشر تكوين العميل أكثر تعقيدا أو خطورة من نشر التغييرات على تكوين توجيه البوابة. يمكنك تغيير النموذج الذي يشير إليه العميل استنادا إلى استراتيجية الإطلاق الأزرق والأخضر لإصدارات النموذج، مثل طرح نموذج جديد مضبط أو الانتقال من الإصدار X إلى X+1 من نفس النموذج.
يمكن أيضا استخدام البوابة كنقطة إدخال API واحدة تمكن البوابة من تحديد العميل. يمكن بعد ذلك تحديد توزيع النموذج الذي يتم استخدامه لخدمة المطالبة استنادا إلى هوية هذا العميل أو معلومات أخرى في طلب HTTP. على سبيل المثال، في حل متعدد المستأجرين، قد يقتصر المستأجرون على معدل نقل محدد، وتنفيذ البنية هو نشر نموذج لكل مستأجر بحصص نسبية محددة. في هذه الحالة، سيكون التوجيه إلى نموذج المستأجر مسؤولية البوابة استنادا إلى المعلومات في طلب HTTP.
تلميح
نظرا لتطبيق مفاتيح واجهة برمجة التطبيقات والتحكم في الوصول استنادا إلى الدور (RBAC) في Azure على مستوى مثيل Azure OpenAI وليس مستوى توزيع النموذج، فإن إضافة بوابة في هذا السيناريو تتيح لك نقل الأمان إلى البوابة. توفر البوابة بعد ذلك تجزئة إضافية بين النماذج المنشورة بشكل متزامن والتي لن يكون من الممكن التحكم فيها من خلال إدارة الهوية والوصول (IAM) في Azure OpenAI أو جدار حماية IP.
يسمح استخدام بوابة في هذا المخطط بتعقب الاستخدام المستند إلى العميل. ما لم يكن العملاء يستخدمون أساسيات خدمة Microsoft Entra مميزة، فلن تتمكن سجلات الوصول ل Azure OpenAI من تمييز عملاء متعددين. وجود بوابة أمام النشر يعطي حمل العمل الخاص بك فرصة لتتبع الاستخدام لكل عميل عبر عمليات توزيع النماذج المتاحة المختلفة لدعم نماذج الاسترداد أو العرض.
تلميحات لمخطط عمليات توزيع النماذج المتعددة
في حين أن البوابة في وضع يسمح لها بالتغيير الكامل للنموذج المستخدم، مثل
gpt-35-turbogpt-4، فمن المحتمل أن يعتبر هذا التغيير تغييرا فاصلا للعميل. لا تدع الإمكانات الوظيفية الجديدة للبوابة تشتت انتباهك عن تنفيذ ممارسات النشر الآمنة لحمل العمل هذا دائما.عادة ما يكون هذا المخطط بسيطا بما يكفي لتنفيذه من خلال نهج إدارة واجهة برمجة تطبيقات Azure بدلا من حل التعليمات البرمجية المخصص.
لدعم استخدام SDKs الأصلي مع مواصفات واجهات برمجة تطبيقات Azure OpenAI المنشورة، حافظ على توافق واجهة برمجة التطبيقات مع واجهة برمجة تطبيقات Azure OpenAI. يشكل هذا الموقف مصدر قلق أكبر عندما لا يقوم فريقك بتأليف جميع التعليمات البرمجية لعملاء حمل العمل. عند تحديد تصميم واجهة برمجة تطبيقات HTTP للبوابة، ضع في اعتبارك فوائد الحفاظ على توافق Azure OpenAI HTTP API.
بينما يدعم هذا المخطط تقنيا بيانات اعتماد العميل التمريرية (رموز الوصول المميزة أو مفتاح API) لمثيل Azure OpenAI، فكر بشدة في تنفيذ إنهاء بيانات الاعتماد وإعادة تأسيسها. بهذه الطريقة يتم تفويض العميل في البوابة، ثم يتم تفويض البوابة من خلال Azure RBAC إلى مثيل Azure OpenAI.
إذا تم تصميم البوابة لاستخدام بيانات اعتماد المرور، فتأكد من أن العملاء لا يمكنهم تجاوز البوابة أو أي قيود نموذج استنادا إلى العميل.
نشر البوابة الخاصة بك في نفس المنطقة مثل مثيل Azure OpenAI.
انشر البوابة في مجموعة موارد مخصصة في الاشتراك المنفصل عن مثيل Azure OpenAI. يمكن أن يساعد عزل الاشتراك من الأطراف الخلفية في دفع نهج APIOps من خلال الفصل بين الاهتمامات.
نشر البوابة في شبكة ظاهرية تحتوي على شبكة فرعية لنقطة النهاية الخاصة الخاصة بمثيل Azure OpenAI Azure Private Link. تطبيق قواعد مجموعة أمان الشبكة (NSG) على تلك الشبكة الفرعية للسماح فقط للبوابة بالوصول إلى نقطة النهاية الخاصة هذه. يجب عدم السماح بجميع الوصول إلى مستوى البيانات الأخرى إلى مثيلات Azure OpenAI.
أسباب لتجنب بوابة لتوزيع نماذج متعددة
إذا كان التحكم في تكوين عملائك سهلا أو أسهل من التحكم في التوجيه على مستوى البوابة، فقد لا يستحق التأثير الإضافي للموثوقية والأمان والتكلفة والصيانة والأداء للبوابة المكون المعماري المضاف.
أيضا، يمكن أن تستفيد بعض سيناريوهات حمل العمل من الترحيل من نهج نشر نموذج متعدد إلى نهج نشر مثيل Azure OpenAI متعدد. على سبيل المثال، ضع في اعتبارك مثيلات Azure OpenAI المتعددة إذا كان لديك العديد من العملاء الذين يجب أن يستخدموا RBAC مختلفة أو مفاتيح وصول للوصول إلى نموذجهم. يمكن استخدام عمليات نشر متعددة في مثيل Azure OpenAI واحد ومعالجة تجزئة الهوية المنطقية على مستوى البوابة، ولكن قد يكون مفرطا عندما يتوفر نهج تجزئة التحكم في الوصول استنادا إلى الدور الفعلي باستخدام مثيلات Azure OpenAI المميزة.
مثيلات Azure OpenAI المتعددة في منطقة واحدة واشتراك واحد
تفاصيل المخطط لمثيلات متعددة في منطقة واحدة واشتراك واحد
- عمليات نشر نموذج Azure OpenAI: واحد أو أكثر
- مثيلات Azure OpenAI: متعددة
- الاشتراكات: اشتراك واحد
- المناطق: واحدة
حالات استخدام المخطط لمثيلات متعددة في منطقة واحدة واشتراك واحد
يدعم المخطط الذي يتضمن مثيلات Azure OpenAI متعددة في منطقة واحدة واشتراك واحد حالات الاستخدام التالية:
تمكين حدود تجزئة الأمان، مثل المفتاح أو التحكم في الوصول استنادا إلى الدور لكل عميل
تمكين نموذج استرداد سهل للعملاء المختلفين
تمكين استراتيجية تجاوز الفشل لتوفر Azure OpenAI، مثل انقطاع النظام الأساسي الذي يؤثر على مثيل معين أو تكوين خاطئ للشبكة أو نشر محذوف عن طريق الخطأ
تمكين استراتيجية تجاوز الفشل لتوفر الحصة النسبية ل Azure OpenAI، مثل إقران كل من مثيل يستند إلى PTU ومثيل قائم على الاستهلاك للامتداد
تقديم بوابة لمثيلات متعددة في منطقة واحدة واشتراك واحد
قد لا يكون النموذج متاحا للعميل لعدة أسباب. تتضمن هذه الأسباب الاضطرابات في خدمة Azure OpenAI أو طلبات تقييد Azure OpenAI أو المشكلات المتعلقة بعمليات حمل العمل مثل التكوين الخاطئ للشبكة أو الحذف غير المقصود لتوزيع نموذج. لمواجهة هذه التحديات، يجب تنفيذ منطق إعادة المحاولة وكسر الدوائر.
يمكن تنفيذ هذا المنطق في جانب العملاء أو الخادم في البوابة. يؤدي تنفيذ المنطق في البوابة إلى تجريد المنطق بعيدا عن العملاء، ما يؤدي إلى عدم تكرار التعليمات البرمجية ومكان واحد لاختبار المنطق. بغض النظر عما إذا كنت تملك التعليمات البرمجية للعميل أم لا، يمكن أن يزيد هذا التحول من موثوقية حمل العمل.
يتيح لك استخدام بوابة مع مثيلات Azure OpenAI متعددة في منطقة واحدة والاشتراك التعامل مع جميع النهايات الخلفية على أنها عمليات نشر نشطة-نشطة وليس فقط استخدامها في عمليات تجاوز الفشل النشطة-السلبية. يمكنك نشر نفس النموذج المستند إلى PTU عبر مثيلات Azure OpenAI المتعددة واستخدام البوابة لتحميل التوازن بينها.
إشعار
الحصص النسبية المستندة إلى الاستهلاك هي مستوى الاشتراك، وليس مستوى مثيل Azure OpenAI. لا تحقق موازنة التحميل مقابل المثيلات المستندة إلى الاستهلاك في نفس الاشتراك إنتاجية إضافية.
أحد الخيارات التي يمتلكها فريق حمل العمل عند توفير Azure OpenAI هو تحديد ما إذا كان نموذج الفوترة ومعدل النقل يستند إلى PTU أو يستند إلى الاستهلاك. استراتيجية تحسين التكلفة لتجنب الهدر من خلال وحدة معالجة الرسومات (PTU) غير المستخدمة هي تحت توفير مثيل PTU قليلا وأيضا نشر مثيل قائم على الاستهلاك جنبا إلى جنب معها. الهدف من هذا المخطط هو أن يستهلك العملاء أولا جميع وحدات PTU المتوفرة ثم "الاندفاع" إلى التوزيع المستند إلى الاستهلاك للإفراط. يستفيد هذا الشكل من تجاوز الفشل المخطط له من نفس السبب كما هو مذكور في الفقرة الافتتاحية من هذا القسم: الحفاظ على هذا التعقيد خارج التعليمات البرمجية للعميل.
عند مشاركة بوابة، فإنها في وضع فريد لالتقاط تفاصيل حول جميع عمليات نشر النموذج التي يتفاعل معها العملاء. في حين أن كل مثيل من Azure OpenAI يمكنه التقاط بيانات تتبع الاستخدام الخاصة به، فإن القيام بذلك داخل البوابة يتيح لفريق حمل العمل نشر بيانات تتبع الاستخدام واستجابات الأخطاء عبر جميع النماذج المستهلكة إلى متجر واحد، ما يجعل لوحة المعلومات والتنبيه الموحدين أسهل.
تلميحات للمثيلات المتعددة في منطقة واحدة وطوبولوجيا الاشتراك
تأكد من أن البوابة تستخدم المعلومات المتوفرة
Retry-Afterفي استجابة HTTP من Azure OpenAI عند دعم سيناريوهات تجاوز الفشل في البوابة. استخدم هذه المعلومات الموثوقة للتحكم في تنفيذ قاطع الدائرة. لا تصل باستمرار إلى نقطة نهاية تقوم بإرجاع429 Too Many Requests. بدلا من ذلك، قم بكسر الدائرة لمثيل النموذج هذا.محاولة التنبؤ بأحداث التقييد قبل حدوثها عن طريق تتبع استهلاك النموذج من خلال الطلبات السابقة ممكنة في البوابة، ولكنها محفوفة بحالات الحافة. في معظم الحالات، من الأفضل عدم محاولة التنبؤ، ولكن استخدام رموز استجابة HTTP لدفع قرارات التوجيه المستقبلية.
عند الترتيب الدوري أو تجاوز الفشل إلى نقطة نهاية مختلفة، بما في ذلك نقل PTU إلى الاستهلاك، تأكد دائما من أن نقاط النهاية هذه تستخدم نفس النموذج في نفس الإصدار. على سبيل المثال، لا تتجاوز الفشل من
gpt-4إلىgpt-35-turboأو من الإصدار X إلى الإصدار X+1 أو موازنة التحميل بينهما. يمكن أن يؤدي تغيير الإصدار هذا إلى سلوك غير متوقع في العملاء.يمكن تنفيذ موازنة التحميل ومنطق تجاوز الفشل داخل نهج إدارة واجهة برمجة تطبيقات Azure. قد تكون قادرا على توفير نهج أكثر تعقيدا باستخدام حل بوابة يستند إلى التعليمات البرمجية، ولكن إدارة واجهة برمجة التطبيقات كافية لحالة الاستخدام هذه.
نشر البوابة الخاصة بك في نفس المنطقة مثل مثيل Azure OpenAI.
نشر البوابة في مجموعة موارد مخصصة في الاشتراك المنفصل عن مثيلات Azure OpenAI. يمكن أن يساعد عزل البوابة عن الأطراف الخلفية في دفع نهج APIOps من خلال الفصل بين الاهتمامات.
قم بتقسيم جميع نقاط النهاية الخاصة بمثيل Azure OpenAI الخاص إلى شبكة فرعية واحدة على الشبكة الظاهرية للبوابة. تطبيق قواعد NSG على تلك الشبكة الفرعية للسماح فقط للبوابة بالوصول إلى نقاط النهاية الخاصة هذه. يجب عدم السماح بجميع الوصول إلى مستوى البيانات الأخرى إلى مثيلات Azure OpenAI.
لتبسيط المنطق في التعليمات البرمجية لتوجيه البوابة، استخدم نفس اسم توزيع النموذج لتقليل الفرق بين مسارات HTTP. على سبيل المثال، يمكن استخدام اسم
gpt4-v1النموذج على جميع مثيلات التحميل المتوازنة أو غير المباشرة، سواء كانت قائمة على الاستهلاك أو مستندة إلى PTU.
أسباب لتجنب بوابة لمثيلات متعددة في منطقة واحدة واشتراك واحد
لا تحسن البوابة نفسها القدرة على استرداد النماذج مقابل عملاء مختلفين لهذا المخطط المحدد. في هذا المخطط، يمكن منح العملاء حق الوصول إلى مثيلات Azure OpenAI المخصصة الخاصة بهم، والتي من شأنها أن تدعم قدرة فريق حمل العمل لديك على إجراء استرداد أو عرض. يدعم هذا النموذج هوية فريدة ومحيط الشبكة، لذلك لن تحتاج البوابة إلى تقديمها خصيصا للتجزئة.
إذا كان لديك عدد قليل من العملاء في المنطقة التي تتحكم فيها في التعليمات البرمجية، وكان العملاء قابلين للتحديث بسهولة، يمكن إضافة المنطق الذي يجب عليك إنشاءه في البوابة مباشرة إلى التعليمات البرمجية. ضع في اعتبارك استخدام نهج البوابة لتجاوز الفشل أو موازنة التحميل في المقام الأول عندما لا تملك التعليمات البرمجية للعميل أو يكون التعقيد أكثر من اللازم بالنسبة للعملاء للتعامل معه.
مثيلات Azure OpenAI المتعددة في منطقة واحدة عبر اشتراكات متعددة
تفاصيل المخطط لمثيلات Azure OpenAI المتعددة في منطقة واحدة عبر اشتراكات متعددة
- عمليات نشر نموذج Azure OpenAI: واحد أو أكثر
- مثيلات Azure OpenAI: متعددة
- الاشتراكات: متعددة
- المناطق: واحدة
حالات استخدام المخطط لمثيلات Azure OpenAI المتعددة في منطقة واحدة عبر اشتراكات متعددة
يدعم المخطط الذي يتضمن مثيلات Azure OpenAI متعددة في منطقة واحدة عبر اشتراكات متعددة حالات الاستخدام التالية:
يتضمن جميع حالات الاستخدام المدرجة لمثيلات Azure OpenAI المتعددة في منطقة واحدة واشتراك واحد.
يمكنك من الحصول على المزيد من الحصص النسبية المستندة إلى الاستهلاك، لأن حد الاشتراك هو عامل متاح لنموذج الاستهلاك. يمكنك استخدام هذه الحصة الإضافية لدعم الاستهلاك المتزامن للغاية.
تقديم بوابة لمثيلات متعددة في منطقة واحدة واشتراكات متعددة
تنطبق نفس الأسباب التي يتم تناولها في تقديم بوابة لمثيلات متعددة في منطقة واحدة والاشتراك على هذا المخطط.
بالإضافة إلى هذه الأسباب، تدعم إضافة بوابة في هذا المخطط أيضا فريقا مركزيا يوفر نموذج "Azure OpenAI كخدمة" لمؤسستهم. نظرا لأن الحصة النسبية المستندة إلى الاستهلاك مرتبطة بالاشتراك، يجب على الفريق المركزي الذي يوفر خدمات Azure OpenAI التي تستخدم النموذج المستند إلى الاستهلاك توزيع مثيلات Azure OpenAI عبر اشتراكات متعددة للحصول على الحصة النسبية المطلوبة. لا يزال منطق البوابة كما هو إلى حد كبير.
تلميحات للمثيلات المتعددة في منطقة واحدة وطوبولوجيا اشتراكات متعددة
من الناحية المثالية، يجب أن تكون جميع الاشتراكات مدعومة بنفس مستأجر Microsoft Entra لدعم التناسق في Azure RBAC وAzure Policy.
نشر البوابة الخاصة بك في نفس المنطقة مثل مثيل Azure OpenAI.
نشر البوابة في اشتراك مخصص منفصل عن مثيلات Azure OpenAI. يساعد هذا في فرض تناسق في معالجة مثيلات Azure OpenAI ويوفر تجزئة منطقية للواجبات بين عمليات توزيع Azure OpenAI وتوجيهها.
عند توجيه الطلبات من البوابة عبر الاشتراكات، تأكد من إمكانية الوصول إلى نقاط النهاية الخاصة. يمكنك استخدام التوجيه الانتقالي من خلال مركز إلى نقاط نهاية خاصة للنهايات الخلفية في المحاور الخاصة بها. قد تتمكن من عرض نقاط النهاية الخاصة لخدمات Azure OpenAI مباشرة في اشتراك البوابة باستخدام اتصالات Private Link عبر الاشتراكات. يفضل اتصالات Private Link عبر الاشتراك إذا كانت البنية والمؤسسة تدعمان هذا النهج.
أسباب لتجنب بوابة لمثيلات متعددة في منطقة واحدة واشتراكات متعددة
تنطبق جميع الأسباب لتجنب بوابة لمثيلات متعددة في منطقة واحدة والاشتراك على هذا المخطط.
مثيلات Azure OpenAI المتعددة عبر مناطق متعددة
تفاصيل المخطط لمثيلات Azure OpenAI المتعددة عبر مناطق متعددة
- عمليات نشر نموذج Azure OpenAI: متعددة
- مثيلات Azure OpenAI: متعددة
- الاشتراكات: اشتراك واحد أو أكثر
- المناطق: متعددة
حالات استخدام المخطط لمثيلات Azure OpenAI المتعددة عبر مناطق متعددة
يدعم المخطط الذي يتضمن مثيلات Azure OpenAI المتعددة المنتشرة عبر منطقتين أو أكثر من مناطق Azure حالات الاستخدام التالية:
يتضمن جميع حالات الاستخدام المدرجة لمثيلات Azure OpenAI المتعددة في منطقة واحدة عبر اشتراكات متعددة.
تمكين استراتيجية تجاوز الفشل لتوفر الخدمة، مثل استخدام أزواج عبر المناطق.
تمكين موقع البيانات وتصميم التوافق.
تمكين توفر النموذج المختلط. بعض المناطق لديها نماذج مختلفة وحصص مختلفة متاحة للنماذج.
على الرغم من عدم اختلاف مناطق Azure تقنيا، إلا أن هذا المخطط قابل للتطبيق أيضا عندما يكون لديك نموذج الذكاء الاصطناعي مكشوف في حالة تداخل، مثل الموقع المحلي أو في سحابة أخرى.
تقديم بوابة لمثيلات متعددة في مناطق متعددة
بالنسبة للبنى المهمة للأعمال التي يجب أن تنجو من انقطاع إقليمي كامل، تساعد البوابة العالمية الموحدة على التخلص من منطق تجاوز الفشل من التعليمات البرمجية للعميل. يتطلب هذا التنفيذ أن تظل البوابة غير متأثرة بانقطاع إقليمي.
لا يعد التحميل عبر المناطق أمرا نموذجيا، ولكن يمكن استخدامه استراتيجيا لدمج الحصص النسبية المتاحة في عمليات التوزيع المستندة إلى الاستهلاك عبر المناطق. لا يتطلب هذا السيناريو أن تظل البوابة غير متأثرة بانقطاع إقليمي، لكننا نوصي بها للحصول على أقصى قدر من موثوقية حمل العمل.
استخدام Azure API Management (نشر منطقة واحدة)
في هذا المخطط، يتم استخدام Azure API Management خصيصا لتقنية البوابة. هنا، يتم نشر APIM في منطقة واحدة. من مثيل البوابة هذا، يمكنك إجراء موازنة تحميل نشطة-نشطة عبر المناطق. تشير النهج الموجودة في البوابة إلى جميع مثيلات Azure OpenAI. تتطلب البوابة خط رؤية الشبكة لكل نهاية خلفية عبر المناطق، إما من خلال تناظر الشبكة الظاهرية عبر المناطق أو نقاط النهاية الخاصة. تتطلب المكالمات من هذه البوابة إلى مثيل Azure OpenAI في منطقة أخرى المزيد من زمن انتقال الشبكة ورسوم الخروج.
يجب أن تحترم بوابتك إشارات الاختناق والتوفر من مثيلات Azure OpenAI وإزالة الأطراف الخلفية المعيبة من التجمع حتى تصبح آمنة لقراءة مثيل Azure OpenAI المعيب أو المقيد. يجب أن تعيد البوابة محاولة الطلب الحالي مقابل مثيل خلفي آخر في التجمع عند الخطأ، قبل الرجوع إلى إرجاع خطأ بوابة. يجب أن يشير التحقق من صحة البوابة إلى أنه غير سليم عندما لا تتوفر مثيلات Azure OpenAI الخلفية.
إشعار
تقدم هذه البوابة نقطة واحدة عالمية من الفشل الإقليمي في البنية الخاصة بك لأن أي انقطاع للخدمة على مثيلات البوابة يجعل جميع المناطق غير قابلة للوصول. لا تستخدم هذا المخطط لأحمال العمل المهمة للأعمال أو حيث تكون موازنة التحميل المستندة إلى العميل كافية.
نظرا لأن هذا المخطط يقدم نقطة فشل واحدة (البوابة)، فإن فائدة هذه البنية المحددة محدودة إلى حد ما. هذا النموذج يفسح المجال للفوترة المستندة إلى الاستهلاك في Azure OpenAI عند التنبؤ بتخصيص PTU قد يكون صعبا للغاية.
تحذير
لا يمكن استخدام هذا النهج في السيناريوهات التي تتضمن الامتثال لسيادة البيانات إذا كانت منطقة Azure OpenAI تمتد على حدود جيوسياسية.
متغير نشط-سلبي
يمكن أيضا استخدام هذا النموذج لتوفير نهج نشط-سلبي للتعامل على وجه التحديد مع الفشل الإقليمي ل Azure OpenAI فقط. في هذا الوضع، تتدفق نسبة استخدام الشبكة عادة من البوابة إلى مثيل Azure OpenAI في نفس المنطقة مثل خدمة إدارة واجهة برمجة التطبيقات. سيتعامل هذا المثيل من Azure OpenAI مع جميع تدفق نسبة استخدام الشبكة المتوقع دون حدوث حالات فشل إقليمية. يمكن أن يكون مستندا إلى PTU أو يستند إلى الاستهلاك، اعتمادا على نموذج الفوترة المفضل لديك. في حالة الفشل الإقليمي ل Azure OpenAI فقط، يمكن للبوابة إعادة توجيه حركة المرور إلى منطقة أخرى مع Azure OpenAI المنشور بالفعل في وضع الاستهلاك.
استخدام Azure API Management (نشر متعدد المناطق)
لتحسين موثوقية البنية السابقة المستندة إلى إدارة واجهة برمجة تطبيقات Azure، تدعم إدارة واجهة برمجة التطبيقات نشر مثيل إلى مناطق Azure متعددة. يمنحك خيار النشر هذا وحدة تحكم واحدة، من خلال مثيل APIM واحد، ولكنه يوفر بوابات منسوخة نسخا متماثلا في المناطق التي تختارها. في هذا المخطط، يمكنك نشر مكونات البوابة في كل منطقة تحتوي على مثيلات Azure OpenAI التي توفر بنية بوابة نشطة- نشطة.
يتم نسخ نهج مثل منطق التوجيه ومعالجة الطلب إلى كل بوابة فردية. يجب أن يكون لكل منطق النهج منطق شرطي في النهج للتأكد من أنك تستدعي مثيلات Azure OpenAI في نفس المنطقة مثل البوابة الحالية. لمزيد من المعلومات، راجع توجيه استدعاءات واجهة برمجة التطبيقات إلى خدمات الواجهة الخلفية الإقليمية. ثم يتطلب مكون البوابة خط رؤية الشبكة فقط إلى مثيلات Azure OpenAI في منطقته الخاصة، عادة من خلال نقاط النهاية الخاصة.
إشعار
لا يحتوي هذا المخطط على نقطة فشل عالمية لمنظور معالجة نسبة استخدام الشبكة، ولكن البنية تعاني جزئيا من نقطة فشل واحدة في أن وحدة التحكم في إدارة واجهة برمجة تطبيقات Azure موجودة في منطقة واحدة فقط. تقييم ما إذا كان تقييد مستوى التحكم قد ينتهك معايير عملك أو المهام الحرجة.
توفر API Management توجيه اسم المجال المؤهل بالكامل (FQDN) خارج الصندوق استنادا إلى أقل زمن انتقال. استخدم هذه الوظيفة المضمنة المستندة إلى الأداء لنشر البوابة النشطة-النشطة. تساعد هذه الوظيفة المضمنة في معالجة الأداء ومعالجة انقطاع البوابة الإقليمية. يدعم الموجه العمومي المضمن أيضا اختبار التعافي من الكوارث حيث يمكن محاكاة المناطق من خلال تعطيل البوابات الفردية. تأكد من أن العملاء يحترمون وقت البقاء (TTL) على FQDN ولديهم منطق إعادة المحاولة المناسب للتعامل مع تجاوز فشل DNS الأخير.
إذا كنت بحاجة إلى إدخال جدار حماية تطبيق ويب في هذه البنية، فلا يزال بإمكانك استخدام حل توجيه FQDN المضمن كأصل خلفي للموجه العمومي الذي ينفذ جدار حماية تطبيق ويب. سيفوض الموجه العمومي مسؤولية تجاوز الفشل إلى APIM. بدلا من ذلك، يمكنك استخدام FQDNs البوابة الإقليمية كأعضاء تجمع الخلفية. في هذه البنية الأخيرة، استخدم نقطة النهاية المضمنة على /status-0123456789abcdef كل بوابة إقليمية أو نقطة نهاية واجهة برمجة تطبيقات صحية مخصصة أخرى لدعم تجاوز الفشل الإقليمي. إذا لم تكن متأكدا، فابدأ بنهج FQDN الخلفي أحادي الأصل.
تعمل هذه البنية بشكل أفضل إذا كان بإمكانك التعامل مع المناطق على أنها متاحة بالكامل أو غير متوفرة بالكامل. وهذا يعني أنه إذا كانت بوابة إدارة واجهة برمجة التطبيقات أو مثيل Azure OpenAI غير متوفر، فأنت تريد عدم توجيه نسبة استخدام الشبكة للعميل إلى بوابة إدارة واجهة برمجة التطبيقات في تلك المنطقة. ما لم يتم إجراء حكم آخر، إذا كانت البوابة الإقليمية لا تزال تقبل نسبة استخدام الشبكة أثناء عدم توفر Azure OpenAI، يجب نشر الخطأ إلى العميل. لتجنب خطأ العميل، راجع نهجا محسنا في البوابة Active-active بالإضافة إلى متغير Azure OpenAI النشط-السلبي.
إذا كانت المنطقة تواجه انقطاعا في بوابة APIM أو تم وضع علامة عليها على أنها غير صحية، تحتاج المناطق المتبقية المتوفرة إلى استيعاب 100٪ من نسبة استخدام الشبكة من تلك المناطق الأخرى. وهذا يعني أنك بحاجة إلى الإفراط في توفير مثيلات Azure OpenAI المستندة إلى PTU للتعامل مع الاندفاع الجديد لنسبة استخدام الشبكة أو استخدام نهج نشط-سلبي لتجاوز الفشل. استخدم حاسبة سعة Azure OpenAI لتخطيط السعة.
تأكد من أن مجموعة الموارد التي تحتوي على Azure API Management هي نفس موقع مثيل APIM نفسه لتقليل نصف قطر الانفجار من انقطاع إقليمي ذي صلة يؤثر على قدرتك على الوصول إلى موفر الموارد للبوابات الخاصة بك.
تحذير
لا يمكن استخدام هذا النهج في السيناريوهات التي تتضمن توافق موقع البيانات إذا كانت أي منطقة بوابة تمتد على حدود جيوسياسية.
بوابة نشطة-نشطة بالإضافة إلى متغير Azure OpenAI النشط-السلبي
يتناول القسم السابق توفر البوابة من خلال توفير مخطط بوابة نشط-نشط. يجمع هذا المخطط بين البوابة النشطة-النشطة وطوبولوجيا Azure OpenAI الفعالة من حيث التكلفة. يمكن أن تؤدي إضافة منطق نشط-سلبي إلى البوابة للفشل في توزيع Azure OpenAI المستند إلى الاستهلاك من التوزيع المستند إلى PTU إلى زيادة موثوقية حمل العمل بشكل كبير. لا يزال هذا النموذج يسمح للعملاء باستخدام حل توجيه FQDN المضمن في APIM للتوجيه المستند إلى الأداء.
تحذير
لا يمكن استخدام هذا النهج النشط-النشط بالإضافة إلى النشط-السلبي في السيناريوهات التي تتضمن توافق موقع البيانات إذا كانت أي منطقة تمتد على حدود جيوسياسية.
استخدام بوابة مخصصة مرمزة
إذا كانت قواعد التوجيه لكل بوابة معقدة جدا بالنسبة لفريقك بحيث لا يمكن اعتبارها معقولة كنهج APIM، فأنت بحاجة إلى نشر الحل الخاص بك وإدارته. يجب أن تكون هذه البنية توزيعا متعدد المناطق للبوابة الخاصة بك، مع وحدة مقياس واحدة متوفرة بشكل كبير لكل منطقة. تحتاج إلى واجهة عمليات النشر هذه باستخدام Azure Front Door (Anycast) أو Azure Traffic Manager (DNS)، عادة باستخدام التوجيه المستند إلى زمن الانتقال والفحوصات الصحية المناسبة لتوفر البوابة.
استخدم Azure Front Door إذا كنت تحتاج إلى جدار حماية تطبيق ويب والوصول العام إلى الإنترنت. استخدم Traffic Manager إذا لم تكن بحاجة إلى جدار حماية تطبيق ويب وكان DNS TTL كافيا. عند واجهة مثيلات البوابة باستخدام Azure Front Door (أو أي وكيل عكسي)، تأكد من عدم إمكانية تجاوز البوابة. اجعل مثيلات البوابة متاحة فقط من خلال نقطة النهاية الخاصة عند استخدام Azure Front Door وإضافة التحقق من X_AZURE_FDID صحة رأس HTTP في تنفيذ البوابة.
ضع الموارد لكل منطقة المستخدمة في البوابة المخصصة في مجموعات الموارد لكل منطقة. يؤدي القيام بذلك إلى تقليل نصف قطر الانفجار للانقطاع الإقليمي ذي الصلة مما يؤثر على قدرتك على الوصول إلى موفر الموارد لموارد البوابة الخاصة بك في تلك المنطقة.
يمكنك أيضا التفكير في واجهة تنفيذ منطق البوابة باستخدام APIM، للمزايا الأخرى لإدارة واجهة برمجة التطبيقات، مثل TLS أو المصادقة أو التحقق من الصحة أو موازنة التحميل ذهابا وإيابا. يؤدي القيام بذلك إلى نقل مخاوف واجهة برمجة التطبيقات الشائعة من التعليمات البرمجية المخصصة في البوابة الخاصة بك ويتيح لبوابة عنوان مثيل Azure OpenAI وتوجيه توزيع النموذج على وجه التحديد.
للامتثال لموقع البيانات، تأكد من أن كل حدود جيوسياسية لها توزيعها المعزول لهذه البنية وأن العملاء يمكنهم الوصول إلى نقطة النهاية المصرح بها فقط.
أسباب لتجنب بوابة لمثيلات متعددة في مناطق متعددة
لا تنفذ بوابة موحدة عبر المناطق الجيوسياسية عند الحاجة إلى موقع البيانات والامتثال. سيؤدي القيام بذلك إلى انتهاك متطلبات موقع البيانات. استخدم البوابات القابلة للتوجيه بشكل فردي لكل منطقة، واتبع الإرشادات الواردة في أحد الأقسام السابقة.
إذا لم يكن من المتوقع أن يفشل العملاء بين المناطق ولديك القدرة على منح العملاء بوابة معينة لاستخدامها، فاستخدم بدلا من ذلك بوابات متعددة، واحدة لكل منطقة، واتبع الإرشادات الموجودة في أحد الأقسام السابقة. لا تربط توفر مناطق أخرى بالمنطقة التي تحتوي على بوابتك كنقطة فشل واحدة.
لا تنفذ بوابة موحدة إذا لم يكن النموذج والإصدار متوفرين في جميع المناطق التي تعرضها البوابة. يجب توجيه العملاء إلى نفس النموذج وإصدار النموذج نفسه. بالنسبة إلى بوابات التحميل متعددة المناطق وتجاوز الفشل، تحتاج إلى اختيار نموذج مشترك وإصدار نموذج متوفر عبر جميع المناطق المعنية. لمزيد من المعلومات، راجع توفر النموذج. إذا لم تتمكن من توحيد إصدار النموذج والنموذج، فإن فائدة البوابة محدودة.
التوصيات العامة
بغض النظر عن الطوبولوجيا التي يحتاجها حمل العمل الخاص بك، هناك بعض التوصيات الشاملة التي يجب مراعاتها عند بناء حل البوابة.
التفاعلات ذات الحالة
عندما يستخدم العملاء ميزات Azure OpenAI ذات الحالة، مثل واجهة برمجة تطبيقات المساعدين، تحتاج إلى تكوين بوابتك لتثبيت عميل في نهاية خلفية معينة أثناء هذا التفاعل. يمكن تحقيق ذلك عن طريق تخزين بيانات المثيل في ملف تعريف الارتباط. في هذه السيناريوهات، ضع في اعتبارك إرجاع استجابة Azure OpenAI API مثل 429 إلى عميل مثبت بدلا من إعادة توجيهها إلى مثيل Azure OpenAI مختلف. يسمح القيام بذلك للعميل بمعالجة عدم التوفر المفاجئ بشكل صريح مقابل إخفائه وتوجيهه إلى مثيل نموذج ليس له تاريخ.
عمليات التحقق من سلامة البوابة
هناك منظوران للتحقق من الصحة يجب أخذهما في الاعتبار، بغض النظر عن الطبولوجيا.
إذا كانت البوابة الخاصة بك مبنية حول الترتيب الدوري أو تنفيذ تجاوز فشل توفر الخدمة بدقة، فأنت تريد طريقة لاستخراج مثيل (أو نموذج) Azure OpenAI من حالة التوفر. لا يوفر Azure OpenAI أي نوع من نقاط نهاية فحص السلامة لمعرفة ما إذا كانت متوفرة للتعامل مع الطلبات بشكل استباقي. يمكنك إرسال انتقالات اصطناعية من خلالها، ولكن ذلك يستهلك سعة النموذج. ما لم يكن لديك مصدر إشارة موثوق به آخر لمثيل Azure OpenAI وتوافر النموذج، فمن المحتمل أن تفترض بوابتك أن مثيل Azure OpenAI قد تم إعداده ثم التعامل مع 429رموز 500503 حالة HTTP و و كإشارة إلى انقطاع الدائرة للطلبات المستقبلية على هذا المثيل أو النموذج لبعض الوقت. بالنسبة لحالات التقييد، احترم دائما البيانات الموجودة في Retry-After العنوان الموجود في استجابات 429 واجهة برمجة تطبيقات Azure OpenAI لرمز الاستجابة في منطق كسر الدائرة. إذا كنت تستخدم Azure API Management، فقيم باستخدام وظيفة قاطع الدائرة المضمنة.
قد يرغب عملاؤك أو فريق عمليات حمل العمل في الكشف عن فحص الصحة على بوابتك لأغراض التوجيه أو الاستبطان الخاصة بهم. إذا كنت تستخدم APIM، فقد لا يكون الإعداد الافتراضي /status-0123456789abcdef مفصلا بما فيه الكفاية لأنه في الغالب يعالج مثيل بوابة APIM، وليس النهايات الخلفية. ضع في اعتبارك إضافة واجهة برمجة تطبيقات مخصصة للتحقق من الصحة يمكنها إرجاع بيانات ذات معنى إلى العملاء أو أنظمة إمكانية المراقبة على توفر البوابة أو مسارات محددة في البوابة.
ممارسات النشر الآمن
يمكنك استخدام تطبيقات البوابة لتنسيق عمليات النشر الزرقاء والأخضر للنماذج المحدثة. يتم تحديث نماذج Azure OpenAI بإصدارات نموذج جديدة ونماذج جديدة، وقد يكون لديك نماذج جديدة دقيقة.
بعد اختبار تأثيرات التغيير في ما قبل الإنتاج، قم بتقييم ما إذا كان يجب "اقتطاع" عملاء الإنتاج إلى إصدار النموذج الجديد أو تحويل حركة المرور بدلا من ذلك. يسمح نمط البوابة الموضح سابقا للواجهة الخلفية بنشر كلا النموذجين بشكل متزامن. يمنح توزيع النماذج بشكل متزامن القدرة على البوابة لإعادة توجيه نسبة استخدام الشبكة استنادا إلى ممارسة النشر الآمن لفريق حمل العمل المتمثلة في الإطلاق التدريجي.
حتى إذا كنت لا تستخدم عمليات النشر الزرقاء والأخضر، يجب تعريف نهج APIOps لحمل العمل الخاص بك وأتمتته بشكل كاف مع معدل تغيير المثيل الخلفي وتوزيع النموذج.
ما يكفي من التنفيذ
تساعد العديد من السيناريوهات المقدمة في هذه المقالة على زيادة الهدف المحتمل على مستوى الخدمة (SLO) لحمل العمل الخاص بك عن طريق تقليل تعقيد العميل وتنفيذ تقنيات موثوقة للحفاظ على الذات. يعمل آخرون على تحسين أمان حمل العمل عن طريق نقل عناصر التحكم في الوصول إلى نماذج محددة بعيدا عن Azure OpenAI. تأكد من أن إدخال البوابة لا ينتهي به الأمر إلى مواجهة هذه الأهداف. فهم مخاطر إضافة نقطة فشل واحدة جديدة إما من خلال أخطاء الخدمة أو مشكلات التكوين التي يسببها الإنسان في البوابة، أو منطق التوجيه المعقد، أو مخاطر تعريض المزيد من النماذج للعملاء غير المصرح لهم مما هو مقصود.
سيادة البيانات
يجب تقييم النهج المختلفة النشطة والنشطة-السلبية من منظور توافق موقع البيانات لحمل العمل الخاص بك. سيكون العديد من هذه الأنماط قابلا للتطبيق على بنية حمل العمل الخاص بك إذا بقيت المناطق المعنية ضمن الحدود الجيوسياسية. لدعم هذا السيناريو، تحتاج إلى التعامل مع الحدود الجغرافية السياسية كطوابع معزولة وتطبيق المعالجة النشطة-النشطة أو النشطة-السلبية حصريا داخل هذا الطابع.
وعلى وجه الخصوص، فإن أي توجيه قائم على الأداء يحتاج إلى فحص شديد للامتثال لسيادة البيانات. في سيناريوهات سيادة البيانات، لا يمكنك خدمة العملاء بجغرافية أخرى والبقاء متوافقين. يجب أن تفرض جميع بنيات البوابة التي تتضمن موقع البيانات أن العملاء يستخدمون نقاط النهاية فقط في منطقتهم الجيوسياسية. يجب حظر العملاء من استخدام نقاط نهاية البوابة الأخرى والبوابة نفسها لا تنتهك ثقة العميل من خلال تقديم طلب عبر الجيوسياسية. الطريقة الأكثر موثوقية لتنفيذ هذا التقسيم هي بناء بنيتك حول بوابة مستقلة تماما ومتاحة للغاية لكل منطقة جيوسياسية.
تخويل Azure OpenAI
تحتاج البوابة إلى المصادقة مع جميع مثيلات Azure OpenAI التي تتفاعل معها. ما لم تصمم البوابة لإجراء مصادقة مرورية، يجب أن تستخدم البوابة هوية مدارة لبيانات الاعتماد الخاصة بها. لذلك يحتاج كل مثيل Azure OpenAI إلى تكوين RBAC الأقل امتيازا للهويات المدارة للبوابات. بالنسبة إلى بنيات active-active وتجاوز الفشل، تأكد من أن هوية البوابة لديها أذونات مكافئة عبر جميع مثيلات Azure OpenAI المعنية.
نهج Azure
يعد الاتساق بين عمليات نشر النموذج ومثيلات Azure OpenAI أمرا مهما في المواقف النشطة-النشطة أو النشطة-السلبية. استخدم نهج Azure للمساعدة في فرض التناسق بين مثيلات Azure OpenAI المختلفة أو عمليات نشر النموذج. إذا كانت النهج المضمنة ل Azure OpenAI غير كافية لضمان الاتساق بينها، ففكر في إنشاء نهج مخصصة تم إنشاؤها بواسطة المجتمع أو استخدامها.
تكرار البوابة
على الرغم من أنه ليس خاصا بأطراف خلفية متعددة، يجب دائما بناء تنفيذ بوابة كل منطقة مع التكرار وأن يكون متاحا بشكل كبير داخل وحدة المقياس. اختر المناطق ذات مناطق التوفر وتأكد من انتشار البوابة عبرها. نشر مثيلات متعددة من البوابة بحيث تقتصر نقطة الفشل الفردية على انقطاع إقليمي كامل وليس خطأ مثيل حساب واحد في البوابة الخاصة بك. بالنسبة لإدارة واجهة برمجة التطبيقات، انشر وحدتين أو أكثر عبر منطقتين أو أكثر. بالنسبة لتطبيقات التعليمات البرمجية المخصصة، انشر ثلاثة مثيلات على الأقل مع توزيع أفضل جهد عبر مناطق التوفر.
تطبيقات البوابة
لا يقدم Azure حلا تسليم المفتاح أو بنية مرجعية لبناء مثل هذه البوابة. كما هو مذكور في مقالة المقدمة، يجب على فريق حمل العمل إنشاء هذه البوابة وتشغيلها. فيما يلي بعض الأمثلة على نماذج التنفيذ المدعومة من المجتمع والتي تغطي بعض حالات الاستخدام المذكورة سابقا. ضع في اعتبارك الإشارة إلى نماذج GitHub هذه عند إنشاء إثبات المفهوم الخاص بك.
| تنفيذ | مثال |
|---|---|
| إدارة Azure API | موازنة التحميل الذكية ل Azure OpenAI باستخدام Azure API Management - يحتوي مستودع GitHub هذا على نموذج التعليمات البرمجية للنهج وإرشادات النشر في اشتراكك. تحجيم Azure OpenAI باستخدام Azure API Management - يحتوي مستودع GitHub هذا على نموذج التعليمات البرمجية للنهج وإرشادات ل PTU وتسرب الاستهلاك. تحتوي مجموعة أدوات بوابة GenAI على مثال لنهج إدارة واجهة برمجة التطبيقات جنبا إلى جنب مع إعداد اختبار التحميل لاختبار سلوك النهج. |
| التعليمات البرمجية المخصصة | موازنة التحميل الذكية ل Azure OpenAI باستخدام Azure Container Apps يحتوي مستودع GitHub هذا على نموذج التعليمات البرمجية C# وإرشادات لإنشاء الحاوية ونشرها في اشتراكك. |
الخطوات التالية
يوفر وجود تنفيذ بوابة لحمل العمل الخاص بك فوائد تتجاوز ميزة التوجيه الخلفي المتعددة التكتيكية الموضحة في هذه المقالة. تعرف على التحديات الرئيسية الأخرى التي يمكن للبوابة حلها.