Fase 3 · Bedrock Dasar

Provisioned Throughput

Provisioned Throughput menukar bayar-per-token dengan bayar-per-jam. Ia menjamin kapasitas, tapi menagih walaupun tidak dipakai.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~5 menit baca

Intisari

Ditagih per jam per model unit (MU), bukan per token.
Satu MU menentukan berapa token masuk dan keluar yang bisa diproses per menit.
Komitmen: tanpa komitmen (bisa dihapus kapan saja), 1 bulan, atau 6 bulan — makin panjang makin murah per jam.
Wajib kalau kamu memakai model yang sudah dikustomisasi.
Penagihan berlanjut sampai kamu menghapusnya — bukan sampai kamu berhenti memakainya.

Kapan ini masuk akal

Situasi	Pilihan
Trafik naik-turun, prototipe, aplikasi internal	On-demand
Beban stabil dan besar sepanjang hari	Provisioned Throughput mungkin lebih murah — hitung dulu
Butuh jaminan kapasitas (SLA internal)	Provisioned Throughput
Memakai model kustom hasil fine-tuning	Provisioned Throughput — tidak ada pilihan lain
Butuh perutean lintas region	On-demand + inference profile — PT tidak mendukungnya

Yang menentukan harga

Model yang dipilih. Untuk model kustom, harganya mengikuti model dasarnya.
Jumlah model unit. Satu MU menetapkan berapa token masukan yang bisa diproses dan berapa token keluaran yang bisa dihasilkan per menit.
Durasi komitmen. Tanpa komitmen paling mahal per jam tapi paling luwes; 1 bulan dan 6 bulan makin murah, tapi tidak bisa dihapus sebelum masanya habis.

Jebakan biaya yang paling mahal di seluruh roadmap ini. Provisioned Throughput ditagih per jam sejak dibuat sampai dihapus, terlepas dari ada tidaknya permintaan. Membuatnya untuk "mencoba sebentar" lalu lupa menghapusnya berarti tagihan berjalan 24 jam sehari. Kalau kamu belum benar-benar butuh, jangan buat.

Alurnya

kelola = boto3.client("bedrock", region_name="us-east-1")

pt = kelola.create_provisioned_model_throughput(
    modelId="anthropic.claude-3-5-haiku-20241022-v1:0",
    provisionedModelName="chat-produksi",
    modelUnits=1,
    commitmentDuration="OneMonth",   # atau hilangkan untuk tanpa komitmen
)

# Setelah aktif, ARN-nya dipakai sebagai modelId saat memanggil
resp = runtime.converse(
    modelId=pt["provisionedModelArn"],
    messages=[{"role": "user", "content": [{"text": "halo"}]}],
)

Perhatikan: yang berubah cuma modelId — ia berisi ARN provisioned model, bukan ID model biasa. Sisa kodenya identik, jadi berpindah antara on-demand dan PT tetap cuma soal konfigurasi.

Cara memutuskan

Hitung titik impasnya sebelum berkomitmen, bukan sesudah:

Jalankan on-demand dulu selama beberapa minggu.
Kumpulkan usage.inputTokens dan usage.outputTokens dari log — data ini kamu punya kalau sejak awal mencatatnya seperti di materi Converse API.
Hitung biaya on-demand bulanan nyata.
Bandingkan dengan biaya per jam PT × 730 jam.
Perhitungkan juga puncak trafikmu: PT dengan MU terlalu sedikit tetap akan throttle.

Cara menurunkan biaya, urut dari yang paling murah dicoba
1. Pilih model yang lebih kecil untuk tugas yang sederhana (Fase 7)
2. Prompt caching untuk prefiks yang berulang
3. Batch inference untuk pekerjaan yang tidak buru-buru
4. Turunkan `maxTokens` dan rapikan prompt
5. Baru pertimbangkan Provisioned Throughput

Latihan: jangan membuat Provisioned Throughput. Sebagai gantinya, ambil log usage dari latihan-latihan sebelumnya, hitung proyeksi biaya on-demand bulanan kalau aplikasimu melayani 10.000 percakapan, dan tuliskan pada tingkat trafik berapa PT baru masuk akal. Kemampuan menghitung ini yang diuji di Domain 4.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.