Mengakses Azure OpenAI dan model bahasa lainnya melalui gateway

Azure OpenAI Service mengekspos API HTTP yang memungkinkan aplikasi Anda melakukan penyematan atau penyelesaian dengan menggunakan model bahasa OpenAI. Aplikasi cerdas memanggil API HTTP ini langsung dari klien atau orkestrator. Contoh klien termasuk kode UI obrolan dan alur pemrosesan data kustom. Contoh orkestrator termasuk alur permintaan LangChain, Semantic Kernel, dan Azure Pembelajaran Mesin. Saat beban kerja Anda tersambung ke satu atau beberapa instans Azure OpenAI, Anda harus memutuskan apakah konsumen ini terhubung secara langsung atau melalui gateway API proksi terbalik.

Gunakan panduan ini untuk mempelajari tentang tantangan utama di lima pilar Azure Well-Architected Framework yang Anda temui jika desain beban kerja Anda mencakup akses langsung dari konsumen Anda ke API sarana data Azure OpenAI. Kemudian pelajari cara memperkenalkan gateway ke dalam arsitektur Anda dapat membantu mengatasi tantangan akses langsung ini, sambil memperkenalkan tantangan baru. Artikel ini menjelaskan pola arsitektur tetapi tidak cara mengimplementasikan gateway.

Karena gateway dapat digunakan untuk memecahkan skenario tertentu yang mungkin tidak ada di setiap beban kerja, lihat pastikan untuk melihat Panduan skenario tertentu, yang melihat kasus penggunaan spesifik gateway secara lebih mendalam.

Tantangan utama

Tanpa gateway API atau kemampuan untuk menambahkan logika ke API HTTP Azure OpenAI, klien harus menangani logika klien API, yang mencakup mekanisme coba lagi atau pemutus sirkuit. Situasi ini bisa menantang dalam skenario di mana Anda tidak secara langsung mengontrol kode klien, atau ketika kode dibatasi untuk penggunaan SDK tertentu. Beberapa klien atau beberapa instans dan penyebaran Azure OpenAI menghadirkan tantangan lebih lanjut, seperti koordinasi penyebaran dan pengamatan yang aman.

Bagian ini menyediakan contoh tantangan arsitektur utama tertentu yang mungkin Anda hadapi jika arsitektur Anda hanya mendukung akses langsung ke Azure OpenAI dari konsumen. Tantangan diatur dengan menggunakan pilar Azure Well-Architected Framework.

Tantangan keandalan

Keandalan beban kerja tergantung pada beberapa faktor, termasuk kapasitasnya untuk pelestarian diri dan pemulihan mandiri, yang sering diimplementasikan melalui mekanisme replikasi dan failover. Tanpa gateway, semua masalah keandalan harus ditangani secara eksklusif dengan menggunakan logika klien dan fitur Azure OpenAI Service. Keandalan beban kerja disusupi ketika tidak ada cukup kontrol keandalan yang tersedia di salah satu dari dua permukaan tersebut.

• Redundansi: Failover antara beberapa instans Azure OpenAI berdasarkan ketersediaan layanan adalah tanggung jawab klien yang perlu Anda kontrol melalui konfigurasi dan logika kustom.

• Peluasan skala untuk menangani lonjakan: Melakukan failover ke instans Azure OpenAI dengan kapasitas saat dibatasi adalah tanggung jawab klien lain yang perlu Anda kontrol melalui konfigurasi dan logika kustom. Memperbarui beberapa konfigurasi klien untuk instans Azure OpenAI baru menghadirkan risiko yang lebih besar dan memiliki masalah ketepatan waktu. Hal yang sama berlaku untuk memperbarui kode klien untuk menerapkan perubahan logika, seperti mengarahkan permintaan prioritas rendah ke antrean selama periode permintaan tinggi.

• Penyeimbangan beban atau pembatasan: Permintaan pembatasan API Azure OpenAI dengan mengembalikan kode respons kesalahan HTTP 429 ke permintaan yang melebihi Token-Per-Menit (TPM) atau Requests-Per-Minute (RPM) dalam model bayar sesuai penggunaan. API Azure OpenAI juga membatasi permintaan yang melebihi kapasitas unit throughput (PTU) yang disediakan untuk model penagihan yang telah disediakan sebelumnya. Menangani logika back-off dan coba lagi yang sesuai dibiarkan secara eksklusif untuk implementasi klien.

Tantangan keamanan

Kontrol keamanan harus membantu melindungi kerahasiaan, integritas, dan ketersediaan beban kerja. Tanpa gateway, semua masalah keamanan harus ditangani secara eksklusif dalam logika klien dan fitur Azure OpenAI Service. Persyaratan beban kerja mungkin menuntut lebih dari apa yang tersedia untuk segmentasi klien, kontrol klien, atau fitur keamanan layanan untuk komunikasi langsung.

• Manajemen identitas - cakupan autentikasi: API sarana data yang diekspos oleh Azure OpenAI dapat diamankan dengan salah satu dari dua cara: kunci API atau kontrol akses berbasis peran Azure (RBAC). Dalam kedua kasus, autentikasi terjadi di tingkat instans Azure OpenAI, bukan tingkat penyebaran individual, yang memperkenalkan kompleksitas untuk memberikan akses hak istimewa paling sedikit dan segmentasi identitas untuk model penyebaran tertentu.

• Manajemen identitas - penyedia identitas: Klien yang tidak dapat menggunakan identitas yang terletak di penyewa Microsoft Entra yang mendukung instans Azure OpenAI harus berbagi satu kunci API akses penuh. Kunci API memiliki batasan kegunaan keamanan dan bermasalah ketika beberapa klien terlibat dan semuanya berbagi identitas yang sama.

• Keamanan jaringan: Bergantung pada lokasi klien relatif terhadap instans Azure OpenAI Anda, akses internet publik ke model bahasa mungkin diperlukan.

• Kedaulatan data: Kedaulatan data dalam konteks Azure OpenAI mengacu pada persyaratan hukum dan peraturan yang terkait dengan penyimpanan dan pemrosesan data dalam batas geografis negara atau wilayah tertentu. Beban kerja Anda perlu memastikan afinitas regional sehingga klien dapat mematuhi hukum residensi dan kedaulatan data. Proses ini melibatkan beberapa penyebaran Azure OpenAI.

Tantangan pengoptimalan biaya

Beban kerja mendapat manfaat ketika arsitektur meminimalkan limbah dan memaksimalkan utilitas. Pemodelan dan pemantauan biaya yang kuat adalah persyaratan penting untuk beban kerja apa pun. Tanpa gateway, pemanfaatan PTU atau pelacakan biaya per klien dapat dicapai secara otoritatif secara eksklusif dari menggabungkan telemetri penggunaan instans Azure OpenAI.

• Pelacakan biaya: Mampu memberikan perspektif keuangan tentang penggunaan Azure OpenAI terbatas pada data yang dikumpulkan dari telemetri penggunaan instans Azure OpenAI. Ketika diharuskan untuk melakukan penagihan balik atau showback, Anda perlu mengaitkan telemetri penggunaan tersebut dengan berbagai klien di berbagai departemen atau bahkan pelanggan untuk skenario multipenyewa.

• Pemanfaatan throughput yang disediakan: Beban kerja Anda ingin menghindari limbah dengan sepenuhnya menggunakan throughput yang disediakan yang Anda bayarkan. Ini berarti bahwa klien harus dipercaya dan dikoordinasikan untuk menggunakan penyebaran model berbasis PTU sebelum meluap ke penyebaran model berbasis konsumsi apa pun.

Tantangan keunggulan operasional

Tanpa gateway, pengamatan, kontrol perubahan, dan proses pengembangan terbatas pada apa yang disediakan oleh komunikasi klien-ke-server langsung.

• Kontrol kuota: Klien menerima 429 kode respons langsung dari Azure OpenAI saat API HTTP dibatasi. Operator beban kerja bertanggung jawab untuk memastikan bahwa kuota yang cukup tersedia untuk penggunaan yang sah dan bahwa klien yang tidak berperilaku tidak mengkonsumsi secara berlebihan. Ketika beban kerja Anda terdiri dari beberapa penyebaran model, memahami penggunaan kuota dan ketersediaan kuota mungkin sulit untuk divisualisasikan.

• Pemantauan dan pengamatan: Metrik default Azure OpenAI tersedia melalui Azure Monitor. Namun, ada latensi dengan ketersediaan data dan tidak memberikan pemantauan real time.

• Praktik penyebaran yang aman: Proses GenAIOps Anda memerlukan koordinasi antara klien dan model yang disebarkan di Azure OpenAI. Untuk pendekatan penyebaran tingkat lanjut, seperti biru-hijau atau kenari, logika perlu ditangani di sisi klien.

Tantangan efisiensi performa

Tanpa gateway, beban kerja Anda bertanggung jawab pada klien untuk bertempur baik secara individual dan bertepak lumayan dengan klien lain terhadap kapasitas terbatas.

• Pengoptimalan performa - lalu lintas prioritas: Memprioritaskan permintaan klien sehingga klien prioritas tinggi memiliki akses preferensial daripada klien berprioritas rendah akan memerlukan koordinasi klien-ke-klien yang tidak masuk akal, dan mungkin tidak masuk akal. Beberapa beban kerja mungkin mendapat manfaat dari permintaan prioritas rendah yang diantrekan untuk dijalankan saat pemanfaatan model rendah.

• Pengoptimalan performa - kepatuhan klien: Untuk berbagi kapasitas, klien harus berperilaku baik. Contohnya adalah ketika klien memastikan bahwa max_tokens dan best_of diatur ke nilai yang disetujui. Tanpa gateway, Anda harus mempercayai klien untuk bertindak demi kepentingan terbaik dalam mempertahankan kapasitas instans Azure OpenAI Anda.

• Minimalkan latensi: Meskipun latensi jaringan biasanya merupakan komponen kecil dari alur permintaan permintaan dan penyelesaian keseluruhan, memastikan bahwa klien dirutekan ke titik akhir jaringan dan model yang dekat dengan mereka mungkin bermanfaat. Tanpa gateway, klien harus memilih sendiri titik akhir penyebaran model mana yang akan digunakan dan kredensial apa yang diperlukan untuk API sarana data Azure OpenAI tertentu.

Solusi

Gambar 1: Arsitektur konseptual mengakses Azure OpenAI melalui gateway

Untuk mengatasi banyak tantangan yang tercantum dalam Tantangan utama, Anda dapat menyuntikkan gateway proksi terbalik untuk memisahkan aplikasi cerdas dari Azure OpenAI. Offloading gateway ini memungkinkan Anda mengalihkan tanggung jawab, kompleksitas, dan pengamatan jauh dari klien dan memberi Anda kesempatan untuk menambah Azure OpenAI dengan menyediakan kemampuan lain yang tidak dibangun. Beberapa contohnya adalah:

• Potensi untuk menerapkan autentikasi federasi.

• Kemampuan untuk mengontrol tekanan pada model melalui pembatasan laju.

• Pemantauan lintas pemotongan dan lintas model.

• Kemampuan untuk memperkenalkan agregasi gateway dan perutean tingkat lanjut ke beberapa layanan, seperti merutekan pesan berprioritas rendah ke antrean untuk perataan beban berbasis antrean atau untuk menghitung untuk melakukan tugas.

• Penyeimbangan beban yang menggunakan pemantauan titik akhir kesehatan untuk merutekan hanya ke titik akhir kesehatan dengan pemutusan sirkuit pada penyebaran model yang tidak tersedia atau kelebihan beban.

Beberapa skenario tertentu memiliki lebih banyak panduan yang tersedia yang secara langsung membahas gateway API dan instans Azure OpenAI. Skenario tersebut tercantum di bagian Langkah berikutnya.

Pertimbangan

Ketika Anda memperkenalkan komponen baru ke dalam arsitektur Anda, Anda perlu mengevaluasi tradeoff yang baru diperkenalkan. Saat Anda menyuntikkan gateway API antara klien Anda dan sarana data Azure OpenAI untuk mengatasi salah satu tantangan utama, Anda memperkenalkan pertimbangan baru ke dalam arsitektur Anda. Evaluasi dengan cermat apakah dampak beban kerja di seluruh pertimbangan arsitektur ini membenarkan nilai tambah atau utilitas gateway.

Keandalan

Keandalan memastikan bahwa aplikasi Anda memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

• Solusi gateway dapat memperkenalkan satu titik kegagalan. Kegagalan ini dapat berasal dari ketersediaan layanan platform gateway, gangguan karena penyebaran kode atau konfigurasi, atau bahkan titik akhir API penting yang salah dikonfigurasi di gateway Anda. Pastikan Anda merancang implementasi untuk memenuhi persyaratan ketersediaan beban kerja Anda. Pertimbangkan kemampuan ketahanan dan toleransi kesalahan dalam implementasi dengan menyertakan gateway dalam analisis mode kegagalan beban kerja.

• Solusi Anda mungkin memerlukan kemampuan perutean global jika arsitektur Anda memerlukan instans Azure OpenAI di beberapa wilayah. Situasi ini dapat semakin mempersulit topologi melalui manajemen nama domain ekstra yang sepenuhnya memenuhi syarat, sertifikat TLS, dan komponen perutean global yang lebih banyak.

Keamanan

Saat mempertimbangkan bagaimana gateway API menguntungkan arsitektur Anda, gunakan daftar periksa Tinjauan desain untuk Keamanan untuk mengevaluasi desain Anda. Anda perlu mengatasi pertimbangan keamanan, seperti berikut ini:

• Area permukaan beban kerja ditingkatkan dengan penambahan gateway. Area permukaan itu membawa pertimbangan manajemen identitas dan akses tambahan (IAM) sumber daya Azure, peningkatan upaya pengerasan, dan banyak lagi.

• Gateway dapat bertindak sebagai transisi batas jaringan antara ruang jaringan klien dan ruang jaringan Azure OpenAI privat. Meskipun gateway membuat titik akhir Azure OpenAI yang menghadap internet sebelumnya privat melalui penggunaan Azure Private Link, gateway sekarang menjadi titik masuk baru dan harus diamankan secara memadai.

• Gateway berada dalam posisi unik untuk melihat data permintaan mentah dan respons yang diformulasikan dari model bahasa, yang dapat menyertakan data rahasia dari salah satu sumber. Kepatuhan data dan cakupan peraturan sekarang diperluas ke komponen lain ini.

• Gateway dapat memperluas cakupan otorisasi dan autentikasi klien di luar ID Microsoft Entra dan autentikasi kunci API, dan berpotensi di beberapa penyedia identitas (IdP).

• Kedaulatan data harus diperhitungkan dalam implementasi Anda dalam implementasi multi-wilayah. Pastikan bahwa logika komputasi dan perutean gateway Anda mematuhi persyaratan kedaulatan yang ditempatkan pada beban kerja Anda.

Pengoptimalan Biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Semua gateway API yang diterapkan memiliki biaya runtime yang perlu dianggarkan dan diperhitungkan. Biaya tersebut biasanya meningkat dengan fitur tambahan untuk mengatasi keandalan, keamanan, dan performa gateway itu sendiri bersama dengan biaya operasional yang diperkenalkan dengan manajemen APIOps tambahan. Biaya tambahan ini perlu diukur terhadap nilai baru yang dikirimkan dari sistem dengan gateway. Anda ingin mencapai titik di mana kemampuan baru yang diperkenalkan dengan menggunakan gateway melebihi biaya untuk menerapkan dan memelihara gateway. Bergantung pada hubungan beban kerja Anda dengan penggunanya, Anda mungkin dapat menagih kembali penggunaan.

Untuk membantu mengelola biaya saat mengembangkan dan menguji gateway, pertimbangkan untuk menggunakan titik akhir yang disimulasikan untuk Azure OpenAI. Misalnya, gunakan solusi di repositori GitHub simulator Azure OpenAI API.

Keunggulan Operasional

Saat mempertimbangkan bagaimana gateway API menguntungkan arsitektur Anda, gunakan daftar periksa Ulasan desain untuk Keunggulan Operasional untuk mengevaluasi desain Anda. Anda perlu mengatasi pertimbangan keunggulan operasional seperti berikut:

• Gateway itu sendiri perlu dipantau oleh solusi pemantauan beban kerja Anda dan berpotensi oleh klien. Ini berarti bahwa komputasi dan operasi gateway perlu disertakan dalam pemodelan kesehatan beban kerja.

• Praktik penyebaran aman Anda sekarang perlu mengatasi penyebaran infrastruktur gateway API dan kode atau konfigurasi perutean gateway. Solusi automasi infrastruktur dan infrastruktur sebagai kode (IaC) Anda perlu mempertimbangkan cara memperlakukan gateway Anda sebagai sumber daya berumur panjang dalam beban kerja.

• Anda perlu membangun atau memperluas pendekatan APIOps Anda untuk mencakup API yang terekspos di gateway.

Efisiensi Performa

Saat mempertimbangkan bagaimana gateway API menguntungkan arsitektur Anda, gunakan daftar periksa Tinjauan desain untuk Efisiensi Performa untuk mengevaluasi desain Anda. Anda perlu mengatasi pertimbangan efisiensi performa seperti berikut:

• Layanan gateway dapat memperkenalkan penyempitan throughput. Pastikan gateway memiliki performa yang memadai untuk menangani beban bersamaan penuh dan dapat dengan mudah diskalakan sesuai dengan harapan pertumbuhan Anda. Pastikan elastisitas dalam solusi sehingga gateway dapat mengurangi pasokan, atau menurunkan skala, ketika permintaan rendah, seperti dengan penggunaan hari kerja.

• Layanan gateway telah memprosesnya harus melakukan per permintaan, dan memperkenalkan latensi tambahan per pemanggilan API. Anda harus mengoptimalkan logika perutean Anda agar permintaan tetap berkinerja baik.

• Dalam kebanyakan kasus, gateway harus secara geografis di dekat pengguna dan instans Azure OpenAI untuk mengurangi latensi. Meskipun latensi jaringan biasanya merupakan persentase kecil waktu dalam keseluruhan panggilan API ke model bahasa, itu mungkin merupakan faktor kompetitif untuk beban kerja Anda.

• Evaluasi dampak gateway pada fitur Azure OpenAI, seperti respons streaming atau penyematan instans untuk interaksi stateful, seperti Assistants API.

Opsi implementasi

Azure tidak menawarkan solusi turn-key yang dirancang khusus untuk memproksi API HTTP Azure OpenAI atau API inferensi model bahasa kustom lainnya. Tetapi masih ada beberapa opsi untuk diterapkan tim beban kerja Anda, seperti gateway di Azure.

Gunakan Azure API Management

Azure API Management adalah layanan yang dikelola platform yang dirancang untuk membongkar kekhawatiran lintas pemotongan untuk API berbasis HTTP. Konfigurasi ini didorong dan mendukung penyesuaian melalui sistem kebijakan pemrosesan permintaan masuk dan keluar. Ini mendukung replika multi-wilayah yang sangat tersedia, zona-redundan, dan bahkan multi-wilayah dengan menggunakan satu sarana kontrol.

Sebagian besar perutean gateway dan logika penanganan permintaan harus diterapkan dalam sistem kebijakan API Management. Anda dapat menggabungkan kebijakan bawaan, seperti Batasi penggunaan token Azure OpenAI API atau Keluarkan metrik untuk konsumsi token Azure OpenAI, dan kebijakan kustom Anda sendiri. Repositori GitHub toolkit gateway GenAI berisi sejumlah kebijakan API Management kustom bersama dengan penyiapan pengujian beban untuk menguji perilaku kebijakan.

Gunakan panduan layanan Well-Architected Framework untuk API Management saat merancang solusi yang melibatkan Azure API Management.

Menggunakan Azure API Management untuk implementasi gateway Anda umumnya merupakan pendekatan yang disukai untuk membangun dan mengoperasikan gateway Azure OpenAI. Ini lebih disukai karena layanan ini adalah penawaran platform as a service (PaaS) dengan kemampuan bawaan yang kaya, ketersediaan tinggi, dan opsi jaringan. Ini juga memiliki pendekatan APIOps yang kuat untuk mengelola API penyelesaian Anda.

Menggunakan kode kustom

Pendekatan kode kustom memerlukan tim pengembangan perangkat lunak untuk membuat solusi berkode kustom dan untuk menyebarkan solusi tersebut ke platform aplikasi Azure pilihan mereka. Membangun solusi yang dikelola sendiri untuk menangani logika gateway bisa cocok untuk tim beban kerja yang mahir dalam mengelola jaringan dan kode perutean.

Beban kerja biasanya dapat menggunakan komputasi yang mereka kenal, seperti menghosting kode gateway di Azure App Service, Azure Container Apps, atau Azure Kubernetes Service.

Penyebaran kode kustom juga dapat dihadapkan dengan API Management ketika API Management digunakan secara eksklusif untuk kemampuan gateway API HTTP inti antara klien Anda dan kode kustom Anda. Dengan cara ini antarmuka kode kustom Anda secara eksklusif dengan API HTTP Azure OpenAI Anda berdasarkan logika bisnis yang diperlukan.

Penggunaan teknologi gateway non-Microsoft, yang merupakan produk atau layanan yang tidak disediakan secara asli oleh Azure, dapat dianggap sebagai bagian dari pendekatan ini.

Contoh arsitektur

Gambar 2: Contoh arsitektur mengakses Azure OpenAI melalui gateway berbasis Azure API Management

Langkah berikutnya

Pelajari tentang skenario tertentu di mana menyebarkan gateway antara aplikasi cerdas dan penyebaran Azure OpenAI digunakan untuk memenuhi persyaratan beban kerja:

• Penyeimbangan beban atau failover antara beberapa instans backend
• Autentikasi dan otorisasi kustom untuk aplikasi klien

Pelajari cara Menerapkan pengelogan dan pemantauan untuk model Azure OpenAI.

Sumber daya terkait

• Azure OpenAI Service
• Gateway API di Azure API Management
• Repositori GitHub zona pendaratan API Management yang mencakup skenario AI generatif
• Toolkit gateway API Management
• OpenAI API Simulator