Amazon Bedrock kini menawarkan prompt-caching untuk Claude 4.6, satu ciri yang dapat mengurangkan kependaman (latency) respons dan mengurangkan perbelanjaan inferens bagi aplikasi AI generatif. Keupayaan ini berfungsi dengan mengingati bahagian statik dalam sesuatu prompt sehingga lima minit, supaya panggilan seterusnya dapat melangkau proses semula teks tersebut yang memakan kos tinggi.

Bagaimana cache berfungsi dalam rantaian permintaan

Apabila permintaan Claude 4.6 tiba, dua lapisan akan bekerjasama.

  • Tahap model – Claude 4.6 mengekalkan cache kunci-nilai (KV) dalam memori GPU. Kali pertama model menganalisis satu blok arahan, ia menyimpan representasi dalaman yang terhasil. Pada panggilan kemudian yang menggunakan semula blok yang sama, model boleh mendapatkan semula representasi tersebut berbanding mengiranya semula.

  • Tahap Bedrock – Bedrock mengira cap jari (fingerprint) bagi segmen prompt statik tersebut. Jika permintaan baharu membawa cap jari yang sepadan, Bedrock akan menghantarnya terus ke GPU yang sudah menyimpan keadaan cache tersebut, sekali gus melangkau peringkat "pemanasan" (warm-up).

Anggaplah ia seperti memuatkan permainan yang telah disimpan berbanding memulakan permainan baharu setiap kali.

Peraturan untuk mengekalkan cache

  1. Bilangan token minimum – Claude Sonnet 4.6 memerlukan sekurang-kurangnya 1,024 token dalam segmen yang di-cache; Claude Opus 4.6 memerlukan 4,096 token. Apa-apa yang lebih kecil akan diabaikan.

  2. Jangka hayat lima minit – Cache akan tamat tempoh selepas lima minit tidak aktif. Setiap penggunaan akan menetapkan semula pemasa, jadi aliran panggilan yang stabil boleh mengekalkan cache tersebut selama-lamanya.

  3. Urutan prompt – Bedrock membaca prompt secara berturutan. Arahan statik mesti muncul terlebih dahulu, diikuti oleh penanda cachePoint, dengan semua mesej yang dijana pengguna diletakkan selepas penanda tersebut. Menukar walaupun satu aksara sebelum penanda akan merosakkan cap jari dan memaksa pembacaan sejuk (cold read).

Mengaplikasikan ciri ini dalam praktis

Bedrock Converse API adalah titik permulaan. Berikut adalah petikan kod Python ringkas yang menunjukkan 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 memberitahu Bedrock di mana segmen tidak boleh ubah (immutable) berakhir. Selepas panggilan pertama, metrik cacheReadInputTokens sepatutnya menunjukkan nilai bukan sifar, mengesahkan bahawa cache telah digunakan.

Mengapa pembangun perlu mengambil tahu

Memisahkan arahan statik daripada input pengguna yang dinamik mengalihkan beban kerja daripada kitaran GPU yang mahal kepada langkah penghalaan (routing) yang ringan. Bagi bot sembang, saluran paip penjanaan dipertingkat pengambilan (retrieval-augmented generation atau RAG), atau mana-mana perkhidmatan yang mengulang system prompt yang sama, hasilnya ialah jawapan yang lebih pantas dan bilangan token yang boleh dibilkan yang lebih rendah. Dalam senario throughput tinggi, pengurangan kecil dalam masa pengiraan pun boleh diterjemahkan kepada penjimatan kos yang ketara.

Had dan pertukaran (trade-offs)

Ciri ini hanya membantu apabila segmen prompt memenuhi had minimum token dan kekal tidak berubah. Aplikasi yang kerap mengubah suai arahan sistem, atau yang bergantung pada prompt pendek, akan melihat sedikit manfaat. Tetingkap lima minit juga bermakna trafik yang melonjak dengan jurang masa lengah yang panjang mungkin akan mengalami pembacaan sejuk (cold reads) berulang kali, sekali gus menghakis kelebihan kependaman. Akhir sekali, cache berada dalam memori GPU; jika beberapa model berkongsi perkakasan yang sama, persaingan boleh menjejaskan prestasi, walaupun Bedrock tidak mendedahkan butiran tersebut.

Apa yang perlu diperhatikan seterusnya

  • Papan pemuka metrik – Pantau cacheReadInputTokens dan kependaman keseluruhan untuk mengesahkan bahawa cache digunakan seperti yang dimaksudkan.
  • Kejuruteraan prompt – Mereka bentuk prompt yang memenuhi ambang saiz tanpa membebankan permintaan adalah satu disiplin baharu bagi pembangun.
  • Sambungan masa hadapan – Jika Bedrock memperluaskan tempoh cache atau melonggarkan had token, ekonomi perbualan jangka panjang boleh berubah dengan lebih lanjut.

Rumusan: Prompt caching memberikan pengguna Claude 4.6 satu mekanisme konkrit untuk mengurangkan masa respons dan perbelanjaan, asalkan mereka dapat menetapkan prompt yang cukup besar dan tidak boleh ubah serta mengekalkan panggilan dalam tetingkap masa yang singkat. Bagi mana-mana perkhidmatan GenAI yang mengulang arahan sistem yang sama, ciri ini berbaloi untuk diuji lebih awal.