Bagikan melalui

Apa itu throughput yang telah dialokasikan?

Nota

Untuk informasi selengkapnya tentang perubahan terbaru pada penawaran throughput yang disediakan, lihat artikel pembaruan untuk informasi selengkapnya.

Penawaran throughput yang disediakan Azure AI Foundry adalah jenis penyebaran model yang memungkinkan Anda menentukan jumlah throughput yang Anda butuhkan dalam penyebaran model. Azure AI Foundry kemudian mengalokasikan kapasitas pemrosesan model yang diperlukan dan memastikannya siap untuk Anda. Anda dapat menggunakan throughput yang disediakan yang Anda minta di berbagai portofolio model yang dijual langsung oleh Azure. Model ini termasuk model Azure OpenAI dan keluarga model unggulan yang baru diperkenalkan seperti Azure DeepSeek, Azure Grok, Azure Llama, dan banyak lagi dalam Azure AI Foundry Models.

Throughput yang telah disediakan menawarkan:

  • Pilihan model boarder pada model unggulan terbaru
  • Fleksibilitas untuk mengganti model dan mengatur penyebaran dengan kuota throughput yang telah ditentukan
  • Diskon signifikan dan kemampuan untuk meningkatkan pemanfaatan reservasi Anda dengan pilihan reservasi yang lebih fleksibel
  • Performa yang dapat diprediksi, dengan memberikan latensi dan throughput maks yang stabil untuk beban kerja yang seragam.
  • Kapasitas pemrosesan yang dialokasikan: Konfigurasi penyebaran menentukan jumlah kapasitas throughput. Setelah disebarkan, throughput tersedia apakah digunakan atau tidak.
  • Penghematan biaya: Beban kerja throughput tinggi dapat memberikan penghematan biaya dibandingkan dengan konsumsi berbasis token.

Petunjuk / Saran

Kapan menggunakan throughput yang disediakan

Anda harus mempertimbangkan untuk beralih dari penyebaran standar ke penyebaran throughput yang disediakan ketika Anda memiliki persyaratan throughput dan latensi yang terdefinisi dengan baik dan dapat diprediksi. Biasanya, ini terjadi ketika aplikasi siap untuk produksi atau sudah disebarkan dalam produksi dan ada pemahaman tentang lalu lintas yang diharapkan. Ini memungkinkan pengguna untuk secara akurat memperkirakan kapasitas yang diperlukan dan menghindari penagihan yang tidak terduga. Penyebaran Throughput yang Ditentukan juga berguna untuk aplikasi yang memiliki persyaratan sensitif terhadap waktu nyata/latensi.

Konsep utama

Bagian yang mengikuti menjelaskan konsep utama yang harus Anda ketahui saat menggunakan penawaran throughput yang disediakan.

Unit Throughput yang Disediakan (PTU)

Unit throughput yang disediakan (PTU) adalah unit generik dari kapasitas pemrosesan model yang dapat Anda gunakan untuk menentukan besar kapasitas penyebaran agar mencapai throughput yang diperlukan untuk memproses masukan dan menghasilkan keluaran. Unit throughput yang disediakan diberikan ke langganan sebagai kuota, dan digunakan untuk menentukan biaya. Setiap kuota khusus untuk suatu wilayah dan menentukan jumlah maksimum PTU yang dapat ditetapkan untuk penyebaran di langganan dan wilayah tersebut.

Manajemen biaya di bawah reservasi PTU bersama

Anda dapat menggunakan kemampuan PTU untuk mengelola biaya dengan lancar untuk model-model Foundry melalui reservasi PTU yang dibagi. Namun, unit PTU yang diperlukan untuk penyebaran dan performa throughput disesuaikan secara dinamis dengan model yang dipilih. Untuk mempelajari selengkapnya tentang biaya PTU dan titik latensi model, lihat Memahami biaya yang terkait dengan PTU.

Reservasi PTU yang ada secara otomatis ditingkatkan untuk memberdayakan pelanggan dengan peningkatan efisiensi dan penghematan biaya saat mereka mengimplementasikan Model-Model Foundry. Misalnya, Anda memiliki reservasi PTU yang sudah ada, dengan sebanyak 500 PTU yang dibeli. Anda menggunakan 300 unit untuk model Azure OpenAI, dan Anda memilih untuk juga menggunakan PTU untuk menyebarkan Azure DeepSeek, Azure Llama, atau model lain dengan kemampuan PTU pada Model Foundry.

  • Jika Anda menggunakan sisa 200 PTU untuk DeepSeek-R1, 200 PTU berbagi diskon reservasi secara otomatis, dan total penggunaan Anda untuk reservasi adalah 500 PTU.

  • Jika Anda menggunakan 300 PTU untuk DeepSeek-R1, maka 200 PTU mendapatkan diskon reservasi secara otomatis sementara 100 PTU melebihi reservasi dan dikenakan tarif per jam DeepSeek-R1.

Untuk mempelajari tentang menghemat biaya dengan reservasi PTU, lihat Menghemat biaya dengan Reservasi Throughput yang Disediakan Microsoft Azure AI Foundry.

Jenis Penyebaran

Saat Anda membuat penyebaran yang disediakan di Azure AI Foundry, jenis penyebaran pada dialog "Buat Penyebaran" dapat diatur ke Throughput Yang Disediakan Global, Throughput yang Disediakan Zona Data, atau jenis penyebaran Throughput yang Disediakan Regional tergantung pada kebutuhan pemrosesan data untuk beban kerja yang diberikan.

Saat Anda membuat penyebaran yang disediakan di Azure AI Foundry melalui CLI atau API, sku-name dapat diatur ke GlobalProvisionedManaged, DataZoneProvisionedManaged, atau ProvisionedManaged tergantung pada kebutuhan pemrosesan data untuk beban kerja yang diberikan.

Jenis Penyebaran nama SKU di CLI
Throughput Global yang Disediakan GlobalProvisionedManaged
Throughput yang Disediakan Zona Data Zona Data Dikelola yang Diatur
Throughput Regional yang Disediakan ProvisionedManaged dapat diterjemahkan sebagai "Dikelola yang Disediakan" jika merujuk pada konsep IT di mana sesuatu dikelola setelah secara khusus disediakan atau dikonfigurasi.

Untuk menyesuaikan perintah contoh Azure CLI berikut ke jenis penyebaran yang berbeda, perbarui sku-name parameter agar sesuai dengan jenis penyebaran yang ingin Anda sebarkan.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

Transparansi kapasitas

Model yang dijual langsung oleh Azure adalah layanan yang sangat dicari di mana permintaan pelanggan mungkin melebihi kapasitas GPU layanan. Microsoft berusaha untuk menyediakan kapasitas untuk semua wilayah dan model yang diminati, tetapi menjual wilayah selalu merupakan kemungkinan. Batasan ini dapat membatasi kemampuan beberapa pelanggan untuk membuat penyebaran model, versi, atau jumlah PTU yang diinginkan di wilayah yang diinginkan - bahkan jika mereka memiliki kuota yang tersedia di wilayah tersebut. Secara umum:

  • Kuota menempatkan batas jumlah maksimum PTU yang dapat disebarkan di langganan dan wilayah, dan tidak menjamin ketersediaan kapasitas.
  • Kapasitas dialokasikan pada waktu penyebaran dan ditahan selama penyebaran ada. Jika kapasitas layanan tidak tersedia, penyebaran gagal.
  • Pelanggan menggunakan informasi real time tentang ketersediaan kuota/kapasitas untuk memilih wilayah yang sesuai untuk skenario mereka dengan kapasitas model yang diperlukan.
  • Mengurangi skala atau menghapus penggelaran akan mengembalikan kapasitas ke wilayah tersebut. Tidak ada jaminan bahwa kapasitas akan tersedia jika penyebaran ditingkatkan atau dibuat ulang nanti.

Panduan kapasitas regional

Untuk menemukan kapasitas yang diperlukan untuk penyebarannya, gunakan API kapasitas atau pengalaman penyebaran Azure AI Foundry untuk memberikan informasi real time tentang ketersediaan kapasitas.

Di Azure AI Foundry, pengalaman penyebaran mengidentifikasi kapan suatu wilayah tidak memiliki kapasitas yang diperlukan untuk menyebarkan model. Ini melihat model, versi, dan jumlah PTU yang diinginkan. Jika kapasitas tidak tersedia, pengalaman mengarahkan pengguna untuk memilih wilayah alternatif.

Rincian tentang pengalaman penyebaran dapat ditemukan dalam panduan memulai yang di-sediakan Azure AI Foundry.

API kapasitas model dapat digunakan untuk mengidentifikasi penyebaran ukuran maksimum model yang ditentukan secara terprogram. API mempertimbangkan kuota dan kapasitas layanan Anda di wilayah tersebut.

Jika wilayah yang dapat diterima tidak tersedia untuk mendukung model, versi, dan/atau PTU yang diinginkan, pelanggan juga dapat mencoba langkah-langkah berikut:

  • Lakukan penyebaran dengan jumlah PTU yang lebih kecil.
  • Coba lakukan penyebaran pada waktu yang berbeda. Ketersediaan kapasitas berubah secara dinamis berdasarkan permintaan pelanggan dan lebih banyak kapasitas mungkin tersedia nanti.
  • Pastikan kuota tersedia di semua wilayah yang dapat diterima. API kapasitas model dan pengalaman Azure AI Foundry mempertimbangkan ketersediaan kuota dalam mengembalikan wilayah alternatif untuk membuat penyebaran.

Bagaimana cara memantau kapasitas?

Pemanfaatan Terkelola yang Disediakan - Metrik V2 di Azure Monitor mengukur pemanfaatan penyebaran tertentu dalam interval 1 menit. Semua jenis penyebaran yang diaktifkan dioptimalkan untuk memastikan bahwa panggilan yang diterima diproses dengan waktu pemrosesan model yang konsisten (latensi end-to-end aktual tergantung pada karakteristik panggilan).

Cara kerja performa pemanfaatan

Penyebaran yang sudah terprovisi memberi Anda sejumlah kapasitas pemrosesan model yang dialokasikan untuk mengoperasikan model yang ditentukan.

Di semua jenis penyebaran yang disediakan, ketika kapasitas terlampaui, API mengembalikan Kesalahan Status HTTP 429. Respons cepat memungkinkan pengguna untuk membuat keputusan tentang cara mengelola lalu lintas mereka. Pengguna dapat mengalihkan permintaan ke penyebaran terpisah, ke instans penyebaran standar, atau menggunakan strategi coba lagi untuk mengelola permintaan tertentu. Layanan terus mengembalikan kode status HTTP 429 sampai pemanfaatan turun di bawah 100%.

Apa yang harus saya lakukan saat menerima respons 429?

Respons 429 bukan kesalahan, tetapi sebaliknya, ini adalah bagian dari desain untuk memberi tahu pengguna bahwa penyebaran tertentu sepenuhnya digunakan pada titik waktu tertentu. Dengan memberikan respon gagal cepat, Anda memiliki kontrol atas metode menangani situasi ini dengan cara yang paling sesuai dengan kebutuhan aplikasi Anda.

Header retry-after-ms dan retry-after dalam respons memberi tahu Anda waktu untuk menunggu sebelum panggilan berikutnya akan diterima. Cara Anda memilih untuk menangani respons ini tergantung pada persyaratan aplikasi Anda. Berikut adalah beberapa pertimbangan:

  • Anda dapat mempertimbangkan untuk mengalihkan lalu lintas ke model lain, penyebaran baru, atau pengalaman yang berbeda. Opsi ini adalah solusi latensi terendah karena tindakan dapat diambil segera setelah Anda menerima sinyal 429. Untuk ide tentang cara menerapkan pola ini secara efektif, lihat posting komunitas ini.
  • Jika Anda baik-baik saja dengan latensi per panggilan yang lebih lama, terapkan logika coba lagi sisi klien. Opsi ini memberi Anda jumlah throughput tertinggi per PTU. Pustaka klien Azure AI Foundry menyertakan kemampuan bawaan untuk menangani percobaan ulang.

Bagaimana layanan memutuskan kapan harus mengirim 429?

Dalam semua jenis penyebaran yang disediakan, setiap permintaan dievaluasi secara individual sesuai dengan ukuran permintaannya, ukuran pembuatan yang diharapkan, dan model, untuk menentukan pemanfaatan yang diharapkan. Perilaku ini berbeda dengan penyebaran standar, yang memiliki perilaku pembatasan tarif kustom berdasarkan perkiraan beban lalu lintas. Untuk penyebaran standar, perilaku pembatasan tarif kustom ini dapat menyebabkan kesalahan HTTP 429 dihasilkan sebelum nilai kuota yang ditentukan terlampaui jika lalu lintas tidak didistribusikan secara merata.

Untuk penyebaran yang disediakan, kami menggunakan variasi algoritma wadah bocor untuk menjaga pemanfaatan kurang dari 100% sambil memungkinkan beberapa lonjakan dalam aliran traffic. Logika tingkat tinggi adalah sebagai berikut:

  1. Setiap pelanggan memiliki jumlah kapasitas yang ditetapkan yang dapat mereka gunakan pada penyebaran

  2. Saat permintaan dibuat:

    sebuah. Ketika pemanfaatan saat ini di atas 100%, layanan mengembalikan kode 429 dengan retry-after-ms header yang diatur ke waktu hingga pemanfaatan di bawah 100%

    b. Selain itu, layanan memperkirakan perubahan bertahap pada pemanfaatan yang diperlukan untuk melayani permintaan dengan menggabungkan token prompt, mengurangi token yang di-cache, dan yang ditentukan max_tokens dalam panggilan. Pelanggan dapat menerima diskon hingga 100% pada token prompt mereka tergantung pada ukuran token cache mereka. max_tokens Jika parameter tidak ditentukan, layanan memperkirakan nilai. Estimasi ini dapat menyebabkan konkurensi yang lebih rendah dari yang diharapkan ketika jumlah token yang dihasilkan aktual kecil. Untuk konkurensi tertinggi, pastikan bahwa max_tokens nilainya sedekat mungkin dengan ukuran generasi yang sebenarnya.

  3. Ketika permintaan selesai, kita sekarang tahu biaya komputasi aktual untuk panggilan. Untuk memastikan akuntansi yang akurat, kami memperbaiki pemanfaatan menggunakan logika berikut:

    a. Jika > aktual lebih besar dari perkiraan, maka perbedaannya ditambahkan ke penggunaan penyebaran.

    b. Jika perkiraan aktual < , maka perbedaannya dikurangi.

  4. Penggunaan keseluruhan dikurangi secara kontinu berdasarkan jumlah PTU yang dikerahkan.

Nota

Panggilan diterima hingga pemanfaatan mencapai 100%. Lonjakan sedikit di atas 100% mungkin diizinkan dalam waktu singkat, tetapi pada akhirnya, lalu lintas Anda dibatasi pada pemanfaatan 100%.

Diagram memperlihatkan bagaimana panggilan berikutnya ditambahkan ke pemanfaatan.

Berapa banyak panggilan bersamaan yang dapat saya lakukan pada implementasi saya?

Jumlah panggilan bersamaan yang dapat Anda capai tergantung pada setiap bentuk panggilan (ukuran prompt, max_tokens parameter, dll.). Layanan terus menerima panggilan hingga pemanfaatan mencapai 100%. Untuk menentukan perkiraan jumlah panggilan bersamaan, Anda dapat memodelkan permintaan maksimum per menit untuk bentuk panggilan tertentu dalam kalkulator kapasitas. Jika sistem menghasilkan kurang dari jumlah token output yang ditetapkan untuk parameter max_tokens, maka penyebaran yang disediakan akan menerima lebih banyak permintaan.

Kemampuan throughput yang disediakan untuk Model yang Dijual Langsung oleh Azure

Bagian ini mencantumkan Model Foundry yang mendukung kemampuan throughput yang disediakan. Anda dapat menggunakan kuota PTU dan reservasi PTU di seluruh model yang ditunjukkan dalam tabel.

Poin-poin berikut adalah beberapa takeaway penting dari tabel:

  • Versi model tidak disertakan dalam tabel ini. Periksa versi yang didukung untuk setiap model saat Anda memilih opsi penyebaran di portal Azure AI Foundry.

  • Opsi penyebaran throughput yang dialokasikan per wilayah bervariasi tergantung pada wilayah.

  • Model baru yang dijual langsung oleh Azure didaftarkan dengan opsi penyebaran throughput yang telah disediakan secara Global terlebih dahulu. Opsi Zona data yang disediakan akan hadir nanti.

  • PTU dikelola secara regional dan berdasarkan jenis penawaran. Kuota PTU dan reservasi apa pun harus berada di wilayah dan bentuk (Global, Zona data, Regional) yang ingin Anda gunakan.

  • Spillover adalah fitur opsional yang mengelola fluktuasi lalu lintas pada deployment yang sudah diatur. Untuk informasi selengkapnya tentang spillover, lihat Mengelola lalu lintas dengan spillover untuk penyebaran yang sudah diatur (Pratinjau).

Keluarga Model Nama model Disediakan secara global Zona data yang disediakan Diprovisikan regional Fitur limpahan
Azure OpenAI Gpt4.1 ✅ ✅ ✅ ✅
Gpt 4.1 mini ✅ ✅ ✅ ✅
GPT 4.1 Nano ✅ ✅ ✅ ✅
Gpt 4o ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3.5 Turbo ✅ ✅ ✅ ✅
o1 ✅ ✅ ✅ ✅
O3 mini ✅ ✅ ✅ ✅
O4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅
DeepSeek-R1-0528 ✅

Ketersediaan wilayah untuk kemampuan throughput yang disediakan

Ketersediaan model Throughput yang disediakan secara global

Wilayah o3
2025-04-16		 o4-mini
2025-04-16		 gpt-4.1
2025-04-14		 gpt-4.1-nano
2025-04-14		 gpt-4.1-mini
2025-04-14		 o3-mini
31-01-2025		 o1
17-12-2024		 gpt-4o
13 Mei 2024		 gpt-4o
2024-08-06		 gpt-4o
20 November 2024		 gpt-4o-mini
18 Juli 2024		 DeepSeek-R1 DeepSeek-V3-0324 DeepSeek-R1-0528
Australia bagian timur ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brasil Selatan ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
kanada timur ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
FranceCentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Jerman Barat Tengah ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Italia Utara ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Jepang Timur ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norwegia Timur ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
polandcentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southafricanorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southeastasia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
India Selatan ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
swedencentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Swiss bagian Utara ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Swiss bagian barat ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ ✅ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Nota

Versi yang disediakan dari gpt-4Version:turbo-2024-04-09 saat ini hanya terbatas pada teks.

Konten terkait