Membandingkan kebijakan pembatasan kapasitas

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

Poin Utama:

Kebijakan Kuota, SpikeArrest, PromptTokenLimit, dan LLMTokenQuota semuanya digunakan untuk pembatasan kecepatan, tetapi memiliki tujuan yang berbeda dan beroperasi pada metrik yang berbeda. Meskipun Quota dan SpikeArrest berfokus pada jumlah permintaan, kebijakan PromptTokenLimit dan LLMTokenQuota mengelola dan mengontrol penggunaan berdasarkan token, yang sangat penting untuk workload AI dan Model Bahasa Besar (LLM).

Meskipun SpikeArrest dan PromptTokenLimit mempertahankan jumlah dengan keandalan tinggi, keduanya dirancang untuk menggunakan cache upaya terbaik Redis untuk menyimpan jumlahnya. Karena cache tidak direplikasi, ada kasus saat jumlah dapat hilang, seperti saat server cache dimulai ulang, atau kasus langka lainnya.

Untuk alasan ini, kami tidak menyarankan penggunaan SpikeArrest atau PromptTokenLimit untuk kasus penggunaan yang memerlukan penghitungan akurat. Hanya kebijakan kuota sinkron atau LLMTokenQuota yang menawarkan penghitungan akurat di semua region dalam jangka waktu tertentu.

Gunakan diagram perbandingan di bawah untuk membantu Anda memutuskan kebijakan yang akan digunakan untuk kasus penggunaan pembatasan laju:

	Kuota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Gunakan ekstensi ini untuk:	Membatasi jumlah panggilan proxy API yang dapat dilakukan aplikasi developer atau developer selama jangka waktu tertentu. Metode ini paling cocok untuk membatasi laju permintaan selama interval waktu yang lebih lama seperti hari, minggu, atau bulan, terutama jika penghitungan yang akurat diperlukan.	Membatasi jumlah panggilan API yang dapat dilakukan terhadap proxy API di semua konsumen dalam jangka waktu singkat, seperti detik atau menit.	Mengelola dan membatasi total penggunaan token untuk panggilan LLM API selama jangka waktu tertentu (menit, jam, hari, minggu, atau bulan). Hal ini memungkinkan Anda mengontrol pengeluaran LLM dan menerapkan pengelolaan kuota terperinci berdasarkan produk API.	Lindungi backend target proxy API Anda dari penyalahgunaan token, perintah besar, dan potensi upaya penolakan layanan dengan membatasi kecepatan token yang dikirim dalam input dengan membatasi permintaan berdasarkan jumlah token dalam pesan perintah pengguna. Ini adalah paradigma komparatif untuk Spike Arrest untuk traffic API, tetapi untuk token.
Jangan gunakan untuk:	Lindungi backend target proxy API Anda dari lonjakan traffic. Gunakan SpikeArrest atau PromptTokenLimit untuk itu.	Menghitung dan membatasi jumlah koneksi yang dapat dilakukan aplikasi ke backend target proxy API Anda selama jangka waktu tertentu, terutama saat penghitungan yang akurat diperlukan.	Lindungi backend target proxy API Anda dari penyalahgunaan token. Gunakan PromptTokenLimit untuk itu.	Menghitung dan membatasi secara akurat jumlah total token yang digunakan untuk penagihan atau pengelolaan kuota jangka panjang. Gunakan kebijakan LLMTokenQuota untuk tindakan tersebut.
Menyimpan jumlah?	Ya	Tidak	Ya, API ini mempertahankan penghitung yang melacak jumlah token yang digunakan oleh respons LLM.	Kebijakan ini menghitung token untuk menerapkan batas kecepatan, tetapi tidak menyimpan hitungan jangka panjang yang persisten seperti kebijakan LLMTokenQuota.
Praktik terbaik untuk melampirkan kebijakan:	Lampirkan ke ProxyEndpoint Request PreFlow, biasanya setelah autentikasi pengguna. Hal ini memungkinkan kebijakan untuk memeriksa penghitung kuota di titik entri proxy API Anda.	Lampirkan ke ProxyEndpoint Request PreFlow, biasanya di awal alur. Kebijakan ini memberikan perlindungan lonjakan di titik entri proxy API Anda.	Terapkan kebijakan penegakan (EnforceOnly) dalam alur permintaan dan kebijakan penghitungan (CountOnly) dalam alur respons. Untuk respons streaming, lampirkan kebijakan penghitungan ke EventFlow.	Lampirkan ke ProxyEndpoint Request PreFlow, di awal alur, untuk melindungi backend Anda dari perintah yang terlalu besar.
Kode status HTTP saat batas telah tercapai:	429 (Layanan Tidak Tersedia)	429 (Layanan Tidak Tersedia)	429 (Layanan Tidak Tersedia)	429 (Layanan Tidak Tersedia)
Perlu diketahui:	Penghitung Kuota disimpan di Cassandra. Anda dapat mengonfigurasi kebijakan untuk menyinkronkan penghitung secara asinkron untuk menghemat resource, tetapi hal ini dapat memungkinkan panggilan sedikit melebihi batas.	Memungkinkan Anda memilih antara algoritma penghalusan atau algoritma penghitungan efektif. Yang pertama memperlancar jumlah permintaan yang dapat terjadi dalam jangka waktu tertentu, dan yang kedua membatasi total jumlah permintaan yang dapat terjadi dalam jangka waktu tertentu, tidak peduli seberapa cepat permintaan tersebut dikirim secara berurutan. Perataan tidak dikoordinasikan di seluruh Pemroses Pesan.	Dapat dikonfigurasi sebagai CountOnly untuk melacak penggunaan token atau EnforceOnly untuk menolak permintaan yang melebihi kuota. Fitur ini berfungsi dengan Produk API untuk memungkinkan konfigurasi kuota terperinci berdasarkan aplikasi, developer, model, atau set operasi LLM tertentu. Menggunakan <LLMTokenUsageSource> untuk mengekstrak jumlah token dari respons LLM dan <LLMModelSource> untuk mengidentifikasi model yang digunakan.	Penghitungan token mungkin sedikit berbeda dengan yang digunakan oleh LLM. Elemen <UserPromptSource> menentukan lokasi perintah pengguna dalam pesan permintaan.
Dapatkan detail selengkapnya:	Kebijakan kuota	Kebijakan SpikeArrest	Kebijakan LLMTokenQuota	Kebijakan PromptTokenLimit

Tips: Anda juga dapat menggunakan hal berikut untuk melindungi backend yang lambat/lemot tanpa memengaruhi performa API:

• Membuat alur bersama yang dapat digunakan kembali: Gabungkan kebijakan dan resource ke dalam alur bersama yang dapat Anda gunakan dari beberapa proxy API, dan bahkan dari alur bersama lainnya.
• Merangkai proxy API: Tentukan bahwa satu proxy adalah endpoint target proxy lain, sehingga menghubungkan kedua proxy dalam rantai proxy. Menggabungkan proxy dengan cara ini dapat membantu Anda menghindari lompatan jaringan, sehingga meningkatkan keseluruhan performa.