Amazon Bedrock kini menawarkan prompt-caching untuk Claude 4.6, sebuah fitur yang dapat memangkas latensi respons dan mengurangi biaya inferensi untuk aplikasi AI generatif. Kemampuan ini bekerja dengan mengingat bagian statis dari sebuah prompt hingga lima menit, sehingga panggilan berikutnya dapat melewati proses ulang teks tersebut yang memakan biaya.

Bagaimana cache bekerja dalam rantai permintaan

Saat permintaan Claude 4.6 tiba, dua lapisan bekerja sama.

  • Level model – Claude 4.6 mempertahankan cache key-value (KV) di memori GPU. Saat pertama kali model mengurai sebuah blok instruksi, ia menyimpan representasi internal yang dihasilkan. Pada panggilan berikutnya yang menggunakan blok yang sama, model dapat mengambil representasi tersebut alih-alih menghitungnya kembali.

  • Level Bedrock – Bedrock menghitung fingerprint dari segmen prompt statis. Jika permintaan baru membawa fingerprint yang cocok, Bedrock akan langsung mengarahkannya ke GPU yang sudah menyimpan status cache tersebut, melewati tahap "pemanasan" (warm-up).

Anggap saja seperti memuat permainan yang sudah disimpan (saved game) daripada memulai permainan baru setiap saat.

Aturan agar cache tetap aktif

  1. Jumlah token minimum – Claude Sonnet 4.6 memerlukan setidaknya 1.024 token dalam segmen yang di-cache; Claude Opus 4.6 membutuhkan 4.096 token. Segala sesuatu yang lebih kecil akan diabaikan.

  2. Masa berlaku lima menit – Cache kedaluwarsa setelah lima menit tidak ada aktivitas. Setiap pemanggilan akan menyetel ulang pengatur waktu, sehingga aliran panggilan yang stabil dapat menjaga cache tetap aktif tanpa batas waktu.

  3. Urutan prompt – Bedrock membaca prompt secara berurutan. Instruksi statis harus muncul pertama kali, diikuti oleh penanda cachePoint, dengan semua pesan yang dibuat pengguna setelah penanda tersebut. Mengubah satu karakter saja sebelum penanda akan merusak fingerprint dan memaksa pembacaan ulang dari awal (cold read).

Menerapkan fitur ini dalam praktik

Bedrock Converse API adalah titik masuknya. Berikut adalah cuplikan Python minimal yang mendemonstrasikan struktur yang diperlukan.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

cachePoint memberi tahu Bedrock di mana segmen yang tidak dapat diubah (immutable) berakhir. Setelah panggilan pertama, metrik cacheReadInputTokens harus menunjukkan nilai non-nol, yang mengonfirmasi bahwa cache telah digunakan.

Mengapa pengembang perlu peduli

Memisahkan instruksi statis dari input pengguna yang dinamis mengalihkan beban kerja dari siklus GPU yang mahal ke langkah perutean (routing) yang ringan. Untuk chatbot, alur kerja retrieval-augmented generation (RAG), atau layanan apa pun yang mengulang system prompt yang sama, hasilnya adalah respons yang lebih cepat dan jumlah token yang ditagih lebih rendah. Dalam skenario throughput tinggi, pengurangan waktu komputasi yang moderat sekalipun dapat menghasilkan penghematan biaya yang nyata.

Batasan dan pertukaran (trade-offs)

Fitur ini hanya membantu jika segmen prompt memenuhi jumlah token minimum dan tetap tidak berubah. Aplikasi yang sering mengubah instruksi sistem, atau yang mengandalkan prompt pendek, akan melihat sedikit manfaat. Jendela lima menit juga berarti bahwa lalu lintas yang melonjak dengan jeda waktu diam yang lama dapat berulang kali mengalami cold read, yang mengikis keuntungan latensi. Terakhir, cache berada di memori GPU; jika beberapa model berbagi perangkat keras yang sama, persaingan (contention) dapat memengaruhi performa, meskipun Bedrock tidak memaparkan detail tersebut.

Apa yang perlu diperhatikan selanjutnya

  • Dasbor metrik – Pantau cacheReadInputTokens dan latensi secara keseluruhan untuk memverifikasi bahwa cache digunakan sebagaimana mestinya.
  • Prompt engineering – Merancang prompt yang memenuhi ambang batas ukuran tanpa membuat permintaan menjadi terlalu besar adalah disiplin baru bagi pengembang.
  • Ekstensi masa depan – Jika Bedrock memperluas durasi cache atau melonggarkan batas token, ekonomi percakapan berdurasi panjang dapat bergeser lebih jauh.

Kesimpulan: Prompt caching memberikan pengguna Claude 4.6 tuas konkret untuk memangkas waktu respons sekaligus biaya, asalkan mereka dapat mengunci prompt yang cukup besar dan tidak berubah, serta menjaga panggilan tetap dalam jendela waktu yang singkat. Untuk layanan GenAI apa pun yang mengulang instruksi sistem yang sama, fitur ini layak untuk diuji lebih awal.