Fase 3 · Bedrock Dasar

Prompt caching

Kalau prompt-mu punya prefiks panjang yang sama di banyak permintaan — instruksi sistem, dokumen, contoh — caching membuat bagian itu tidak diproses ulang.

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

Intisari

Kamu menandai cache checkpoint; bagian prompt sebelum tanda itu yang di-cache.
Prefiks harus identik antar permintaan. Satu karakter berubah = cache miss.
Ada minimum token per checkpoint, berbeda per model — di bawah itu, permintaan tetap sukses tapi tidak ter-cache.
TTL banyak model sekitar 5 menit, dan di-reset setiap cache hit.
Hanya untuk inferensi on-demand — tidak berlaku untuk batch inference.

Kapan ini menguntungkan

Pola khasnya: pengguna mengunggah dokumen lalu bertanya berkali-kali tentang dokumen itu. Tanpa caching, seluruh dokumen diproses ulang pada setiap pertanyaan. Dengan caching, ia diproses sekali.

Skenario	Untung?
System prompt panjang dipakai semua pengguna	Sangat
Tanya jawab berkali-kali atas satu dokumen	Sangat
Percakapan multi-giliran dengan riwayat menumpuk	Ya
Beberapa contoh few-shot yang tetap	Ya
Prompt pendek dan selalu berbeda	Tidak — malah bisa menambah biaya tulis cache

Cara menandainya

resp = runtime.converse(
    modelId=MODEL_ID,
    system=[
        {"text": INSTRUKSI_PANJANG},
        {"cachePoint": {"type": "default"}},      # semua di ATAS ini di-cache
    ],
    messages=[
        {"role": "user", "content": [
            {"text": ISI_DOKUMEN},
            {"cachePoint": {"type": "default"}},  # dokumen ikut di-cache
            {"text": pertanyaan},                 # bagian yang berubah tiap kali
        ]},
    ],
)

Urutannya menentukan segalanya: yang statis di depan, yang berubah di belakang. Kalau pertanyaan pengguna ditaruh sebelum dokumen, prefiksnya berubah setiap kali dan tidak ada yang bisa di-cache.

Minimum token itu nyata dan berbeda per model. Contoh dari dokumentasi: sebagian model mensyaratkan minimal 1.024 token per checkpoint, sebagian lain 4.096. Kalau prefiksmu lebih pendek dari itu, permintaan tetap berhasil — tapi tidak ada yang di-cache, dan kamu tidak mendapat pesan peringatan apa pun. Periksa usage untuk tahu apakah caching benar-benar bekerja.

Memverifikasi

pakai = resp["usage"]
print("tulis cache :", pakai.get("cacheWriteInputTokens", 0))
print("baca cache  :", pakai.get("cacheReadInputTokens", 0))
print("masukan biasa:", pakai["inputTokens"])

Yang kamu lihat	Artinya
Permintaan pertama: `cacheWrite` besar	Cache sedang diisi — permintaan ini memang lebih mahal
Permintaan berikutnya: `cacheRead` besar	Berhasil. Token ini ditagih dengan tarif lebih rendah.
Selalu `cacheWrite`, tidak pernah `cacheRead`	Prefiksmu berubah tiap kali, atau TTL sudah lewat
Keduanya nol	Prefiks di bawah minimum token, atau model tidak mendukung

Ekonominya

Token yang dibaca dari cache ditagih lebih murah daripada token masukan biasa. Tapi token yang ditulis ke cache bisa ditagih lebih mahal daripada token masukan biasa, tergantung modelnya. Artinya caching menguntungkan kalau prefiks yang sama dipakai beberapa kali dalam rentang TTL.

Karena TTL di-reset setiap cache hit, percakapan aktif akan terus memperpanjang umur cache-nya sendiri. Yang mati adalah prefiks yang menganggur — dan permintaan berikutnya membayar biaya tulis lagi.

Batasan	Detail
Mode inferensi	On-demand saja — bukan batch inference
API	Converse, ConverseStream, InvokeModel, InvokeModelWithResponseStream
Cross-Region inference	Bisa digabung, tapi saat trafik tinggi cache write bisa bertambah
Prompt Management	Caching bisa diaktifkan atau dimatikan per prompt

Latihan: ambil satu dokumen panjang (minimal beberapa ribu token), ajukan tiga pertanyaan berbeda tentangnya dengan cache checkpoint setelah dokumen. Cetak cacheWriteInputTokens dan cacheReadInputTokens untuk ketiganya, dan pastikan pola yang muncul: tulis besar sekali, lalu baca besar dua kali.

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