Amazon Bedrock sasa inatoa huduma ya prompt-caching kwa Claude 4.6, kipengele ambacho kinaweza kupunguza muda wa kusubiri majibu (latency) na kupunguza gharama za utendaji (inference spend) kwa programu za AI-generative. Uwezo huu hufanya kazi kwa kukumbuka sehemu isiyobadilika ya prompt kwa hadi dakika tano, hivyo maombi yanayofuata huacha mchakato wa gharama wa kusoma tena maandishi hayo.

Jinsi cache inavyoingia katika mnyororo wa maombi

Maombi ya Claude 4.6 yanapofika, tabaka mbili hufanya kazi kwa pamoja.

  • Ngazi ya modeli – Claude 4.6 inadumisha cache ya key-value (KV) kwenye kumbukumbu ya GPU. Mara ya kwanza modeli inapochanganua kizuizi cha maelekezo, huhifadhi uwakilishi wa ndani unaotokana na mchakato huo. Katika maombi ya baadaye yanayotumia tena kizuizi hicho hicho, modeli inaweza kupata uwakilishi huo badala ya kuufanyia hesabu upya.

  • Ngazi ya Bedrock – Bedrock hupiga alama ya kidole (fingerprint) ya sehemu ya prompt isiyobadilika. Ikiwa ombi jipya lina alama inayolingana, Bedrock hulielekeza moja kwa moja kwenye GPU ambayo tayari ina hali iliyohifadhiwa (cached state), hivyo kuruka hatua ya “warm-up”.

Ifikirie kama vile unapakia mchezo uliohifadhiwa badala ya kuanza mchezo mpya kila wakati.

Kanuni zinazodumisha cache

  1. Idadi ya chini ya tokeni – Claude Sonnet 4.6 inahitaji angalau tokeni 1,024 katika sehemu iliyohifadhiwa; Claude Opus 4.6 inahitaji tokeni 4,096. Chochote kidogo zaidi kinapuuzwa.

  2. Muda wa dakika tano – Cache huisha baada ya dakika tano za kutotumika. Kila ombi linalofanikiwa huwezesha upya saa, hivyo mtiririko thabiti wa maombi unaweza kuifanya cache idumu bila kikomo.

  3. Mpangilio wa prompt – Bedrock husoma prompt kwa mfuatano. Maelekezo yasiyobadilika lazima yaonekane kwanza, yakifuatiwa na alama ya cachePoint, kisha ujumbe wote uliotengenezwa na mtumiaji baada ya alama hiyo. Kubadilisha hata herufi moja kabla ya alama hiyo kunaharibu alama ya kidole (fingerprint) na kulazimisha kusoma upya kuanzia mwanzo (cold read).

Kuweka kipengele hiki katika vitendo

Bedrock Converse API ndio lango la kuingilia. Hapa chini kuna kipande kidogo cha Python kinachoonyesha muundo unaohitajika.

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 inaambia Bedrock sehemu isiyobadilika inapoishia. Baada ya ombi la kwanza, kipimo cha cacheReadInputTokens kinapaswa kuonyesha thamani isiyo sifuri, kikithibitisha kuwa cache imetumika.

Kwa nini watengenezaji wanapaswa kujali

Kutenganisha maelekezo yasiyobadilika kutoka kwa ingizo la mtumiaji linalobadilika kunahamisha kazi kutoka kwenye mizunguko ya gharama kubwa ya GPU kwenda kwenye hatua nyepesi ya uelekezaji (routing). Kwa roboti za mazungumzo (chatbots), mifumo ya retrieval-augmented generation (RAG), au huduma yoyote inayorudia prompt ile ile ya mfumo, matokeo yake ni majibu ya haraka na idadi ndogo ya tokeni zinazolipwa. Katika mazingira ya uzalishaji mkubwa, hata upungufu mdogo wa muda wa kompyuta unaweza kuleta akiba kubwa ya gharama.

Mipaka na mabadiliko ya kulinganisha

Kipengele hiki husaidia tu wakati sehemu ya prompt inakidhi idadi ya chini ya tokeni na inabaki bila kubadilika. Programu zinazobadilisha mara kwa mara maelekezo ya mfumo, au zinazotegemea prompt fupi, hazitaona faida kubwa. Dirisha la dakika tano pia linamaanisha kuwa trafiki inayokuja kwa mfululizo lakini yenye mapengo marefu ya kutotumika inaweza kusababisha kusoma upya (cold reads) mara kwa mara, jambo linalopunguza faida ya kasi. Hatimaye, cache inaishi kwenye kumbukumbu ya GPU; ikiwa modeli nyingi zinatumia vifaa vile vile, ushindani unaweza kuathiri utendaji, ingawa Bedrock haitoi maelezo hayo.

Nini cha kufuatilia baadaye

  • Dashibodi za vipimo – Fuatilia cacheReadInputTokens na kasi ya jumla (latency) ili kuhakikisha kuwa cache inatumika kama ilivyokusudiwa.
  • Uhandisi wa prompt (Prompt engineering) – Kubuni prompt zinazokidhi vigezo vya ukubwa bila kuongeza uzito wa ombi ni taaluma mpya kwa watengenezaji.
  • Mageuzi ya baadaye – Ikiwa Bedrock itaongeza muda wa cache au kupunguza mipaka ya tokeni, uchumi wa mazungumzo marefu unaweza kubadilika zaidi.

Muhtasari: Prompt caching inawapa watumiaji wa Claude 4.6 njia madhubuti ya kupunguza muda wa majibu na gharama, mradi tu waweze kuweka prompt kubwa ya kutosha isiyobadilika na kuweka maombi ndani ya muda mfupi. Kwa huduma yoyote ya GenAI inayorudia maelekezo ile ile ya mfumo, kipengele hiki kinafaa kufanyiwa majaribio mapema.