Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Praktik terbaik penskalaan dan throughput
Topik ini menjelaskan cara kerja batas throughput dan penjadwalan di seluruh titik akhir Amazon Bedrock dan memberikan praktik terbaik untuk menskalakan aplikasi AI generatif Anda.
Titik akhir Amazon Bedrock
Amazon Bedrock mendukung dua titik akhir untuk inferensi:
-
bedrock-mantle.{region}.api.aws— Mendukung Penyelesaian dan Tanggapan Obrolan (dari OpenAI), dan Pesan (dari Antropik). -
bedrock-runtime.{region}.amazonaws.com— Mendukung Bedrock-native API (Invoke dan Converse), Penyelesaian Obrolan, dan API Pesan.
Untuk informasi selengkapnya tentang titik akhir ini dan cara memilih di antara mereka, lihatTitik akhir yang didukung oleh Amazon Bedrock.
Mengapa kedua titik akhir berperilaku berbeda
Dalam banyak layanan multi-tenant tradisional, arsitektur dirancang di sekitar kuota per akun untuk mengelola akses berbagi adil ke sumber daya bersama. Ini adalah pendekatan yang digunakan dengan bedrock-runtime.
Dengan bedrock-mantle, pendekatan yang berbeda digunakan. Titik akhir ini dirancang dengan penjadwalan lanjutan dan mekanisme antrian kerja yang memberikan distribusi pembagian yang adil sambil mendukung batas throughput awal yang lebih tinggi. Desain ini juga memungkinkan bedrock-mantle untuk menampung serangkaian model yang luas dan memberikan kemampuan lengkap yang tersedia di seluruh katalog model. Dalam kebanyakan kasus, permintaan dilayani segera. Dalam beberapa kasus, permintaan dapat diantrian sebentar sementara beban kerja dalam penerbangan selesai dan throughput tersedia. Bagian di bawah ini menjelaskan cara menangani skenario ini.
titik akhir batuan dasar mantel: throughput dan kuota
Semua model bedrock-mantle berbagi batas keras tunggal 10.000 RPM per akun per Wilayah. Ada beberapa perbedaan dalam bagaimana throughput dan kuota berperilaku untuk Claude vs. model lain seperti yang ditunjukkan di bawah ini.
| Claude 4.7+ | Semua model lainnya | |
|---|---|---|
| Masukan TPM | 10M * | Tidak ada batas TPM per pelanggan atau per model |
| Keluaran TPM | 2M | Tidak ada batas TPM per pelanggan atau per model |
| RPM | 10.000 (dibagikan di semua model di titik akhir ini) | 10.000 (dibagikan di semua model di titik akhir ini) |
| On-demand tingkatan | Standar | Standar, Prioritas, Flex (beberapa pengecualian) - lihat halaman detail model untuk ketersediaan |
| Batch | Tidak | Ya untuk model yang didukung - lihat halaman detail model untuk ketersediaan |
| Kapasitas terpesan | Tidak ada | Tidak ada |
* Batas TPM masukan Anda tergantung pada riwayat penggunaan Anda dengan Amazon Bedrock. Periksa halaman Kuota
titik akhir bedrock-runtime: throughput dan kuota
Tabel berikut merangkum throughput dan kuota untuk. bedrock-runtime
| Claude 4.7+ | Semua model lainnya | |
|---|---|---|
| Masukan TPM | 15M * | Bervariasi* |
| Keluaran TPM | Dikombinasikan dengan Input TPM. Burndown berlaku. | Tidak ada. Burndown berlaku. |
| RPM | 10.000 (dibagikan di semua model) | Bervariasi* |
| On-demand tingkatan | Standar | Standar, Prioritas, Flex (beberapa pengecualian) - lihat halaman detail model untuk ketersediaan |
| Batch | Tidak | Ya untuk model yang didukung - lihat halaman detail model untuk ketersediaan |
| Kapasitas terpesan | Tidak ada | Tier/Provisioned Kapasitas Cadangan |
* Kuota untuk model ini bervariasi berdasarkan penggunaan. Periksa halaman Kuota
Memahami tanggapan kesalahan HTTP
- HTTP 429
-
Respons 429 berarti Anda telah melampaui batas RPM untuk akun Anda. Kurangi tingkat pengiriman permintaan Anda. Jika Anda memerlukan alokasi RPM yang lebih tinggi, mintalah peningkatan melalui konsol Service Quotas
atau hubungi Akun AWS tim Anda. - HTTP 503
-
Respons 503 berarti bahwa ada peningkatan permintaan untuk Amazon Bedrock di Wilayah ini. Anda harus mengurangi tingkat permintaan Anda dan kemudian mencoba lagi dengan backoff eksponensial atau menyebarkan lalu lintas di seluruh Wilayah.
Penanganan kesalahan yang disarankan
Kesalahan sementara (sesekali 503 tanggapan)
Terapkan backoff eksponensial dengan jitter acak:
Mulailah dengan penundaan singkat (misalnya, 1 detik).
Gandakan penundaan setelah setiap upaya yang gagal.
Batasi percobaan ulang hingga 6 upaya.
Sebagian besar AWS SDK dan pustaka HTTP populer menyediakan dukungan bawaan untuk pola ini.
contoh Coba lagi konfigurasi untuk bedrock-runtime (AWS SDK/ boto3)
import boto3 from botocore.config import Config config = Config(retries={"total_max_attempts": 6, "mode": "standard"}) client = boto3.client("bedrock-runtime", config=config)
contoh Coba lagi konfigurasi untuk mantel dasar (OpenAI SDK)
from openai import OpenAI client = OpenAI( api_key=api_key, base_url=f"https://bedrock-mantle.{region}.api.aws/v1", max_retries=6, timeout=60.0, )
contoh Coba lagi konfigurasi untuk mantel dasar (Anthropic SDK)
import anthropic client = anthropic.Anthropic( api_key=api_key, base_url=f"https://bedrock-mantle.{region}.api.aws", max_retries=6, timeout=60.0, )
Kesalahan berkelanjutan (respons 503 persisten)
Jika Anda menerima kesalahan 503 berkelanjutan, mencoba lagi saja tidak akan menyelesaikan masalah. Tingkat permintaan Anda melebihi throughput yang tersedia. Lakukan langkah berikut:
Kurangi tingkat di mana aplikasi Anda mengirimkan permintaan baru.
Menerapkan pembatasan tarif sisi klien atau antrian permintaan.
Lepaskan permintaan dengan prioritas lebih rendah hingga throughput pulih.
Meningkatkan throughput
Saat mengkonsumsi throughput sesuai permintaan pada bedrock-mantletitik akhir, skala throughput yang tersedia dari waktu ke waktu. Tidak semua permintaan dalam kuota Anda dijamin berhasil selama periode permintaan tinggi, jadi ramping secara bertahap adalah penting.
Prosedur ramp-up yang direkomendasikan
Mulai dari volume permintaan target Anda, misalnya 500 RPM.
Jika Anda menerima 503 tanggapan, kurangi tarif Anda, misalnya sebesar 50%.
Terus kurangi dengan tarif itu sampai Anda mencapai kondisi mapan di mana permintaan berhasil secara konsisten.
Tahan pada kondisi mapan itu untuk durasi singkat, katakanlah 15 menit.
Tingkatkan throughput lagi, misalnya 50%, dan tahan selama 15 menit lagi.
Ulangi sampai Anda mencapai volume target Anda.
Misalnya, jika target Anda 2.000 RPM tetapi Anda menerima 503 kesalahan, kurangi menjadi 1.000 RPM. Jika kesalahan tetap ada, kurangi hingga 500 RPM. Setelah permintaan berhasil secara konsisten pada 500 RPM, tahan selama 15 menit, kemudian skala ke 750, lalu 1.125, dan seterusnya.
Tarif ramp tidak dapat disesuaikan. Untuk meminta alokasi RPM yang lebih tinggi, gunakan konsol Service Quotas
Praktik terbaik tambahan
Gunakan bendera fitur untuk secara bertahap mentransisikan lalu lintas antar model daripada mengalihkan semua lalu lintas sekaligus.
Sebarkan beban kerja yang besar di beberapa menit dan pertimbangkan pola waktu hari untuk menghindari periode penggunaan puncak.
Mulai pengujian dengan batch kecil dan skala secara bertahap. Hindari mengirim ribuan permintaan pengujian secara bersamaan.
Untuk pemrosesan data offline yang besar, gunakan Batch API atau Flex Tier jika aplikasi Anda dapat memproses respons secara asinkron.
Ketersediaan regional dan inferensi lintas wilayah
On-demand throughput dialokasikan di tingkat Regional dan bervariasi antar Wilayah. Jika beban kerja Anda menargetkan satu Wilayah, Anda mungkin menemukan 503 respons selama periode permintaan tinggi. Untuk memaksimalkan ketersediaan dan jika Anda menggunakan bedrock-runtime, gunakanInferensi lintas wilayah global.
Mendapatkan bantuan
-
Perencanaan throughput — Hubungi Akun AWS tim Anda untuk peramalan throughput. Rencanakan throughput puncak 2x hingga 3x selama acara penskalaan.
-
Optimalisasi kinerja — Pantau efisiensi penggunaan token, optimalkan permintaan untuk mengurangi konsumsi token, dan memilih model berdasarkan persyaratan kasus penggunaan Anda.
-
Eskalasi Support — Saat membuka kasus AWS Support untuk masalah throughput, sertakan yang berikut ini: kode kesalahan tertentu, ID permintaan, pola lalu lintas (RPM/TPM), dan timeline penskalaan Anda.
Ringkasan rekomendasi
| Skenario | Rekomendasi |
|---|---|
| Beban kerja umum | Gunakan bedrock-mantletitik akhir bila memungkinkan. |
| Sesekali 503 kesalahan | Coba lagi dengan backoff eksponensial dan jitter. |
| Berkelanjutan 503 kesalahan | Kurangi tingkat pengiriman permintaan. Menerapkan pembatasan tingkat sisi klien. |
| 429 kesalahan | Kurangi tingkat permintaan. Minta alokasi RPM yang lebih tinggi melalui Service Quotas |
| Pemrosesan offline besar | Gunakan Batch API atau Flex Tier. |