View a markdown version of this page

Praktik terbaik penskalaan dan throughput - Amazon Bedrock
Titik akhir Amazon Bedrocktitik akhir mantel batuan dasar: throughput dan kuotatitik akhir runtime bedrock-: throughput dan kuotaMemahami respons kesalahan HTTPPenanganan kesalahan yang disarankanMeningkatkan throughputPraktik terbaik tambahanKetersediaan regional dan inferensi lintas wilayahMendapatkan bantuanRingkasan rekomendasi

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 API Pen OpenAI-compatible yelesaian dan Tanggapan Obrolan, dan API Pesan Antropik.

  • bedrock-runtime.{region}.amazonaws.com— Mendukung API Bedrock-native InvokeModel dan Converse, API Penyeles OpenAI-compatible aian dan Tanggapan Obrolan, dan API Pesan Anthropic.

Untuk sebagian besar aplikasi baru, mulailah denganbedrock-runtime. Gunakan bedrock-mantle saat Anda membutuhkan kemampuan yang hanya tersedia di titik akhir tersebut, seperti alat sisi server, inferensi latar belakang, Proyek, Ruang Kerja, atau model yang hanya tersedia di. bedrock-mantle Anda dapat menggunakan kedua titik akhir dalam aplikasi yang sama. Untuk perbandingan lengkap, lihatTitik akhir didukung oleh Amazon Bedrock.

Mengapa kedua titik akhir berperilaku berbeda

Kedua permukaan titik akhir menggunakan mesin inferensi dasar yang sama, tetapi penghitungan kuota dan opsi kapasitasnya berbeda. bedrock-runtimemenggunakan kuota token per model dan, untuk beberapa model, kuota permintaan per menit (RPM). bedrock-mantletidak memberlakukan kuota RPM dan menggunakan kuota input-token dan output-token terpisah untuk model yang telah menerbitkan kuota. Model lain bedrock-mantle mungkin tidak memiliki kuota per akun yang terekspos di Kuota Layanan, tetapi throughput mereka masih diatur oleh kapasitas layanan internal.

Kuota adalah batas atas, bukan jaminan bahwa setiap permintaan sesuai permintaan akan segera dilayani. Selama periode permintaan tinggi, permintaan dapat diantri atau menerima kesalahan kapasitas sementara. Rancang aplikasi Anda untuk mengikat konkurensi, pekerjaan antrian, dan mencoba lagi kesalahan sementara tanpa membuat lonjakan coba lagi.

titik akhir mantel batuan dasar: throughput dan kuota

T bedrock-mantle itik akhir memiliki perilaku kuota berikut:

  • Model dengan kuota yang diterbitkan memiliki kuota per-model, input-token-per-menit per wilayah, dan output-token-per-menit yang terpisah.

  • Titik akhir tidak menerapkan kuota RPM. Dua beban kerja dengan RPM yang sama dapat menghabiskan jumlah kapasitas yang sangat berbeda, jadi rencanakan dan batasi tarif dengan token dan konkurensi, bukan RPM saja.

  • Ketika permintaan diterima, pemeriksaan input-token menyertakan token input ditambah nilai yang dimintamax_tokens. Setelah tanggapan selesai, bagian yang tidak digunakan dari reservasi itu diisi ulang. Tetapkan max_tokens tidak lebih tinggi dari kebutuhan aplikasi Anda.

  • Model tanpa kuota TPM yang dipublikasikan saat ini tidak memiliki kuota TPM per akun yang ditampilkan di Kuota Layanan. Ini tidak berarti bahwa throughput tidak terbatas; kapasitas layanan internal dan pembatasan tarif transien masih berlaku.

  • Inferensi batch dan Throughput Provisioned hanya tersedia melalui. bedrock-runtime Service-tier dan dukungan model bervariasi menurut model.

Nilai default dan alokasi akun Anda dapat bervariasi menurut model, Wilayah, dan riwayat penggunaan. Untuk nilai saat ini, detail evaluasi kuota, dan proses AWS Dukungan untuk meminta kenaikan, lihatKuota untuk titik akhir mantel dasar. Lihat yang berlaku Sekilas tentang model untuk titik akhir khusus model, tingkat layanan, dan dukungan fitur.

titik akhir runtime bedrock-: throughput dan kuota

T bedrock-runtime itik akhir memiliki perilaku kuota berikut:

  • Per-model, Kuota token per wilayah menghitung token input dan output bersama-sama. Token keluaran mengkonsumsi kuota sesuai dengan tingkat pembakaran khusus model.

  • Beberapa model juga memiliki kuota RPM, sementara model lain hanya diatur oleh kuota token. Periksa kuota yang berlaku untuk model dan profil inferensi yang tepat yang Anda gunakan.

  • Per-minute dan kuota token per hari dibagikan di seluruh API inferensi yang memanggil model yang sama pada titik akhir ini. Alokasi untuk bedrock-runtime dan bedrock-mantle independen.

  • Profil inferensi kustom, inferensi batch, dan Throughput Provisioned memiliki kuota terpisah dan hanya tersedia melalui. bedrock-runtime

Untuk nilai kuota saat ini, detail pembakaran token, dan proses peningkatan kuota, lihat. Kuota untuk titik akhir runtime dasar Lihat yang berlaku Sekilas tentang model untuk titik akhir khusus model, tingkat layanan, dan dukungan fitur.

Memahami respons kesalahan HTTP

HTTP 429

Jawaban 429 berarti permintaan itu tidak diterima. Periksa jenis API-specific kesalahan daripada mengandalkan status HTTP saja. Kes ThrottlingException alahan A atau batas tarif umumnya berarti bahwa permintaan melebihi kuota akun atau batas tarif layanan. Beberapa operasi runtime juga menggunakan HTTP 429 untukModelNotReadyException. Aktifbedrock-mantle, periksa penggunaan TPM input dan output serta max_tokens nilai permintaan; titik akhir tidak memiliki kuota RPM. Aktifbedrock-runtime, periksa kuota token gabungan dan RPM, jika model memiliki kuota RPM.

HTTP 503

Tanggapan 503 berarti bahwa layanan untuk sementara tidak dapat menangani permintaan karena permintaan tinggi atau kendala kapasitas. Itu tidak menunjukkan bahwa Anda melebihi kuota akun. Coba kembali respons transien dengan mundur eksponensial dan jitter. Jika respons berlanjut, hentikan peningkatan lalu lintas, kurangi konkurensi, dan pertimbangkan inferensi Wilayah atau Lintas wilayah yang berbeda saat didukung.

HTTP 529 () overloaded_error

Beberapa API model mengembalikan 529 ketika model sementara tidak dapat memproses permintaan karena permintaan tinggi atau kapasitas penyajian yang tidak mencukupi. Perlakukan itu sebagai kesalahan kapasitas sementara. Jika respons menyertakan Retry-After header, tunggu setidaknya durasi itu sebelum mencoba lagi, dan tambahkan jitter sehingga klien tidak mencoba lagi secara bersamaan.

Untuk API-specific penyebab dan langkah penyelesaian, lihatMemecahkan Masalah Kode Kesalahan API Amazon Bedrock.

Penanganan kesalahan yang disarankan

Kesalahan sementara

Coba kembali hanya kesalahan yang aman untuk dicoba lagi, seperti pelambatan sementara dan kesalahan kapasitas. Jika layanan mengembalikan Retry-After header, hormati itu. Jika tidak, terapkan backoff eksponensial dengan jitter acak:

  • Mulailah dengan penundaan singkat (misalnya, 1 detik).

  • Tingkatkan penundaan setelah setiap percobaan ulang dan batasi penundaan maksimum agar sesuai dengan anggaran latensi aplikasi Anda.

  • Tambahkan jitter acak dan hindari percobaan ulang yang disinkronkan di seluruh pekerja.

  • Gunakan anggaran percobaan ulang terbatas yang sesuai dengan tujuan latensi aplikasi Anda. Misalnya, batasi operasi hingga enam upaya total: permintaan awal dan hingga lima percobaan ulang.

Sebagian besar AWS SDK dan pustaka HTTP populer menyediakan dukungan bawaan untuk pola ini. Retry-setting nama berbeda: botocore menyer total_max_attempts takan permintaan awal, sedangkan OpenAI dan Anthropic SDK max_retries hanya menghitung percobaan ulang. Oleh karena itu, contoh berikut menggunakan nilai numerik yang berbeda untuk memberikan contoh anggaran enam upaya yang sama.

contoh Coba lagi konfigurasi untuk bed rock-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 land rock-mantle (OpenAI SDK)
from openai import OpenAI

client = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
    max_retries=5,
)
contoh Coba lagi konfigurasi untuk land rock-mantle (Anthropic SDK)
import anthropic

client = anthropic.Anthropic(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic",
    max_retries=5,
)

Konfigurasikan batas waktu koneksi dan baca secara terpisah dari percobaan ulang, berdasarkan model dan durasi inferensi maksimum operasi yang didokumentasikan. Waktu tunggu yang lebih pendek dari permintaan inferensi jangka panjang yang valid dapat menyebabkan percobaan ulang yang dapat dihindari dan pekerjaan duplikat.

Kesalahan kapasitas berkelanjutan

Jika Anda menerima kesalahan 503 atau 529 persisten, percobaan ulang saja dapat memperkuat beban. Layanan mungkin mengalami kendala kapasitas sementara, atau beban kerja mungkin melebihi kapasitas yang saat ini tersedia untuk model dan Wilayah. Lakukan langkah berikut:

  • Hentikan ramp dan kembali ke tingkat permintaan stabil terakhir dan tingkat konkurensi.

  • Gunakan konkurensi sisi klien terbatas, pembatasan tarif, dan antrian permintaan.

  • Menunda atau menghilangkan permintaan prioritas rendah sampai kapasitas pulih.

  • Untukbedrock-runtime, gunakan inferensi lintas wilayah saat model mendukungnya. Untuk beban kerja berkelanjutan yang dapat diprediksi, evaluasi Provisioned Throughput.

  • Jika masalah berlanjut, periksa Dasbor AWS Kesehatan dan hubungi AWS Dukungan dengan ID permintaan dan stempel waktu UTC.

Meningkatkan throughput

On-demand kapasitas dapat bervariasi menurut model, Wilayah, dan waktu. Tidak semua permintaan dalam kuota dijamin berhasil selama periode permintaan tinggi, jadi tingkatkan secara bertahap saat meluncurkan beban kerja, mengubah model atau Wilayah, atau membuat peningkatan lalu lintas yang besar. Ini sangat penting untuk bedrock-mantle model yang tidak memiliki kuota per akun yang dipublikasikan.

Prosedur ramp-up yang disarankan

  1. Perkirakan tingkat token target dan konkurensi untuk setiap titik akhir, model, dan Wilayah. Untukbedrock-mantle, lacak token input dan output secara terpisah dan sertakan max_tokens nilai yang diminta dalam perkiraan penerimaan input-token.

  2. Mulailah pada garis dasar stabil yang diketahui di bawah target. Jika Anda tidak memiliki baseline, mulailah dengan beban representatif kecil alih-alih mengirim volume target penuh.

  3. Tahan setiap level cukup lama untuk mengamati keberhasilan permintaan, kesalahan 429/503 /529, persentil latensi, konsumsi token, konkurensi, dan kedalaman antrian.

  4. Tingkatkan satu langkah terkontrol pada satu waktu. Ubah hanya satu dimensi beban utama pada satu waktu sehingga Anda dapat mengidentifikasi penyebab regresi.

  5. Jika pelambatan, kesalahan kapasitas, atau latensi naik melampaui ambang batas Anda, jeda ramp, hormati Retry-After header apa pun, dan kembali ke level stabil terakhir.

  6. Lanjutkan sampai Anda mencapai target, dan ulangi validasi untuk setiap model dan Wilayah yang akan menerima lalu lintas produksi.

Pilih ukuran langkah dan periode pengamatan dari pola latensi dan lalu lintas beban kerja Anda. Jangan gunakan RPM sebagai satu-satunya sinyal kontrol: ukuran token permintaan dan panjang respons dapat mengubah konsumsi kapasitas secara substansif bahkan ketika RPM tetap konstan.

Untuk bedrock-mantle kenaikan kuota, ikutiMeminta peningkatan kuota. Untukbedrock-runtime, ikutiMeminta peningkatan kuota.

Praktik terbaik tambahan

  • Gunakan bendera fitur untuk secara bertahap mengalihkan lalu lintas antar model daripada mengalihkan semua lalu lintas sekaligus.

  • Sebarkan beban kerja yang besar di beberapa menit dan pertimbangkan pola waktu dalam sehari untuk menghindari periode penggunaan puncak.

  • Uji dengan distribusi representatif ukuran input, ukuran output, latensi, dan konkurensi. Hindari mengirim permintaan pengujian secara tiba-tiba.

  • Gunakan pembatasan tarif sisi klien yang sadar token, konkurensi terbatas, dan antrian terbatas. Pem RPM-only batas tidak melindungi terhadap perubahan ukuran permintaan.

  • Untuk pekerjaan offline asinkron dan volume tinggi, gunakan inferensi batch aktif. bedrock-runtime

  • Untuk model yang didukung dan permintaan yang tidak peka waktu yang dapat mentolerir latensi variabel, pertimbangkan tingkat layanan Flex.

Ketersediaan regional dan inferensi lintas wilayah

On-demand Kapasitasnya bersifat Regional dan dapat bervariasi antar Wilayah. Jika beban kerja Anda menargetkan satu Wilayah, itu dapat mengalami kesalahan kapasitas selama periode permintaan tinggi. Dengan bedrock-runtime, gunakan Inferensi Lintas wilayah global saat model dan persyaratan tempat tinggal data Anda mendukungnya. Jika Anda menerapkan failover Regional Anda sendiri, verifikasi ketersediaan model di setiap Wilayah target dan terapkan percobaan ulang terbatas sehingga failover tidak membuat lonjakan lalu lintas.

Mendapatkan bantuan

  • Perencanaan throughput — Perkirakan token input dan output puncak, latensi respons, konkurensi, dan toleransi antrian untuk setiap model dan Wilayah. Sertakan ruang kepala khusus beban kerja, dan hubungi Akun AWS tim Anda untuk peluncuran besar atau penting bisnis.

  • Pengoptimalan kinerja — Pantau ukuran prompt, token yang dihasilkanmax_tokens, persentil latensi, dan penggunaan cache saat didukung. Optimalkan perintah dan batas keluaran untuk menghindari pemesanan atau konsumsi token yang tidak perlu.

  • Eskalasi dukungan — Saat membuka kasus AWS Dukungan, sertakan titik akhir, Wilayah, model atau ID profil inferensi, status HTTP dan jenis kesalahan API, ID permintaan, cap waktu UTC, tarif token, tingkat permintaan, konkurensi, dan garis waktu penskalaan Anda.

Ringkasan rekomendasi

Skenario Rekomendasi
Beban kerja umum Mulailah denganbedrock-runtime. Gunakan bedrock-mantle untuk kemampuan atau model yang membutuhkannya. Lihat Titik akhir didukung oleh Amazon Bedrock.
Kesalahan sementara 429, 503, atau 529 Periksa jenis kesalahan API. Untuk kesalahan yang dapat dicoba ulang, hormati Retry-After dan coba lagi dengan backoff dan jitter eksponensial dalam anggaran percobaan ulang yang dibatasi.
Kesalahan kapasitas berkelanjutan Hentikan ramping, kembali ke level stabil terakhir, ikat konkurensi dan antrian, tunda pekerjaan dengan prioritas rendah, dan gunakan inferensi lintas wilayah jika didukung.
Perencanaan kuota Gunakan input dan output TPM terpisah untukbedrock-mantle. Gunakan kuota token gabungan, pembakaran token, dan RPM jika berlaku untukbedrock-runtime.
Pemrosesan offline besar Gunakan inferensi batch untuk pekerjaan asinkron. Gunakan tingkat layanan Flex untuk permintaan yang didukung dan tidak peka waktu yang dapat mentolerir latensi variabel.