Amazon Bedrock ഇപ്പോൾ Claude 4.6-ന് വേണ്ടി prompt-caching വാഗ്ദാനം ചെയ്യുന്നു. ഇത് ജനറേറ്റീവ്-AI ആപ്ലിക്കേഷനുകളുടെ റെസ്‌പോൺസ് ലേറ്റൻസി (response latency) കുറയ്ക്കാനും ഇൻഫറൻസ് ചിലവ് (inference spend) ലാഭിക്കാനും സഹായിക്കുന്ന ഒരു ഫീച്ചറാണ്. ഒരു പ്രോംപ്റ്റിലെ മാറ്റമില്ലാത്ത ഭാഗം അഞ്ച് മിനിറ്റ് വരെ ഓർമ്മിച്ചുവെക്കുന്നതിലൂടെ, തുടർന്നുള്ള കോളുകളിൽ ആ ടെക്സ്റ്റ് വീണ്ടും പ്രോസസ്സ് ചെയ്യേണ്ടി വരുന്ന ചിലവേറിയ ഘട്ടം ഒഴിവാക്കാൻ ഈ സാങ്കേതികവിദ്യ സഹായിക്കുന്നു.

കാഷെ (cache) എങ്ങനെയാണ് റിക്വസ്റ്റ് ചെയിനിൽ പ്രവർത്തിക്കുന്നത്

ഒരു Claude 4.6 റിക്വസ്റ്റ് വരുമ്പോൾ, രണ്ട് തലങ്ങൾ ഒത്തുചേർന്ന് പ്രവർത്തിക്കുന്നു.

  • Model level – Claude 4.6 അതിന്റെ GPU മെമ്മറിയിൽ ഒരു key-value (KV) cache സൂക്ഷിക്കുന്നു. ആദ്യമായി ഒരു നിർദ്ദേശാസമൂഹം (block of instructions) മോഡൽ വിശകലനം ചെയ്യുമ്പോൾ, അതിന്റെ ആന്തരിക രൂപം (internal representation) അത് സംഭരിക്കുന്നു. ഒരേ ഭാഗം തന്നെ വീണ്ടും ഉപയോഗിക്കുന്ന പിൽക്കാല കോളുകളിൽ, അത് വീണ്ടും കണക്കുകൂട്ടുന്നതിന് പകരം നിലവിലുള്ള രൂപം മോഡലിന് വീണ്ടെടുക്കാൻ സാധിക്കും.

  • Bedrock level – Bedrock സ്റ്റാറ്റിക് പ്രോംപ്റ്റ് ഭാഗത്തിന്റെ ഒരു ഫിംഗർപ്രിന്റ് (fingerprint) കണക്കാക്കുന്നു. പുതിയൊരു റിക്വസ്റ്റിൽ ഒരേ ഫിംഗർപ്രിന്റ് ഉണ്ടെങ്കിൽ, “warm-up” ഘട്ടം ഒഴിവാക്കി, കാഷെ ചെയ്ത സ്റ്റേറ്റ് നിലവിലുള്ള GPU-ലേക്ക് തന്നെ Bedrock അതിനെ റൂട്ട് ചെയ്യുന്നു.

ഓരോ തവണയും പുതിയൊരു ഗെയിം തുടങ്ങുന്നതിന് പകരം, സേവ് ചെയ്ത ഒരു ഗെയിം ലോഡ് ചെയ്യുന്നത് പോലെ ഇതിനെ കരുതാം.

കാഷെ നിലനിർത്തുന്നതിനുള്ള നിയമങ്ങൾ

  1. Minimum token count – Claude Sonnet 4.6-ന് കാഷെഡ് സെഗ്മെന്റിൽ കുറഞ്ഞത് 1,024 ടോക്കണുകൾ ആവശ്യമാണ്; Claude Opus 4.6-ന് 4,096 ടോക്കണുകൾ ആവശ്യമാണ്. ഇതിൽ കുറഞ്ഞ അളവിലുള്ളവ അവഗണിക്കപ്പെടും.

  2. Five-minute lifetime – അഞ്ച് മിനിറ്റ് നേരത്തേക്ക് പ്രവർത്തനം ഇല്ലാതായാൽ കാഷെ കാലാവധി അവസാനിക്കും. ഓരോ തവണ കാഷെ ഉപയോഗിക്കുമ്പോഴും ടൈമർ റീസെറ്റ് ചെയ്യപ്പെടുന്നതിനാൽ, തുടർച്ചയായ കോളുകളിലൂടെ കാഷെ എത്രകാലം വേണമെങ്കിലും നിലനിർത്താൻ സാധിക്കും.

  3. Prompt ordering – Bedrock പ്രോംപ്റ്റ് ക്രമമായി വായിക്കുന്നു. സ്റ്റാറ്റിക് നിർദ്ദേശങ്ങൾ ആദ്യം വരണം, അതിനുശേഷം ഒരു cachePoint മാർക്കർ ഉണ്ടായിരിക്കണം, അതിനുശേഷം മാത്രമേ യൂസർ നൽകുന്ന സന്ദേശങ്ങൾ വരാവൂ. മാർക്കറിന് മുമ്പുള്ള ഒരു അക്ഷരം പോലും മാറ്റം വരുത്തിയാൽ ഫിംഗർപ്രിന്റ് മാറുകയും അത് പുതിയൊരു കോൾഡ് റീഡ് (cold read) ആവശ്യപ്പെടുകയും ചെയ്യും.

ഈ ഫീച്ചർ പ്രായോഗികമായി ഉപയോഗിക്കുന്നത് എങ്ങനെ

Bedrock Converse API ആണ് ഇതിന്റെ പ്രവേശന കവാടം. ആവശ്യമായ ഘടന കാണിക്കുന്ന ഒരു ചെറിയ Python സ്നിപ്പറ്റ് താഴെ നൽകുന്നു.

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 Bedrock-ന് പറഞ്ഞുതരുന്നു. ആദ്യത്തെ കോളിന് ശേഷം, cacheReadInputTokens എന്ന മെട്രിക് പൂജ്യമല്ലാത്ത ഒരു മൂല്യം കാണിക്കണം, ഇത് കാഷെ ഉപയോഗിക്കപ്പെട്ടുവെന്ന് സ്ഥിരീകരിക്കുന്നു.

ഡെവലപ്പർമാർ ഇത് ശ്രദ്ധിക്കേണ്ടത് എന്തുകൊണ്ട്

സ്റ്റാറ്റിക് നിർദ്ദേശങ്ങളെ ഡൈനാമിക് ആയ യൂസർ ഇൻപുട്ടിൽ നിന്ന് വേർതിരിക്കുന്നത്, ജോലിഭാരം ചിലവേറിയ GPU സൈക്കിളുകളിൽ നിന്ന് ലഘുവായ റൂട്ടിംഗ് ഘട്ടത്തിലേക്ക് മാറ്റുന്നു. ചാറ്റ്‌ബോട്ടുകൾ, റിട്രീവൽ-ഓഗ്മെന്റഡ് ജനറേഷൻ (RAG) പൈപ്പ്‌ലൈനുകൾ, അല്ലെങ്കിൽ ഒരേ സിസ്റ്റം പ്രോംപ്റ്റ് ആവർത്തിക്കുന്ന ഏതൊരു സേവനം എന്നിവയ്ക്ക്, ഇതിന്റെ ഫലം വേഗത്തിലുള്ള മറുപടികളും കുറഞ്ഞ ടോക്കൺ ചിലവുമാണ്. ഉയർന്ന അളവിൽ ഡാറ്റ കൈകാര്യം ചെയ്യുന്ന സാഹചര്യങ്ങളിൽ, കമ്പ്യൂട്ട് സമയത്തിലെ ചെറിയ കുറവ് പോലും വലിയ രീതിയിലുള്ള ചിലവ് ലാഭത്തിലേക്ക് നയിച്ചേക്കാം.

പരിമിതികളും വിട്ടുവീഴ്ചകളും

പ്രോംപ്റ്റ് ഭാഗം നിശ്ചിത ടോക്കൺ പരിധിയിൽ എത്തിയാൽ മാത്രമേ ഈ ഫീച്ചർ ഗുണകരമാകൂ. സിസ്റ്റം നിർദ്ദേശങ്ങളിൽ ഇടയ്ക്കിടെ മാറ്റം വരുത്തുന്നതോ അല്ലെങ്കിൽ ചെറിയ പ്രോംപ്റ്റുകൾ ഉപയോഗിക്കുന്നതോ ആയ ആപ്ലിക്കേഷനുകൾക്ക് ഇതിന്റെ ഗുണം വളരെ കുറവായിരിക്കും. അഞ്ച് മിനിറ്റ് എന്ന സമയപരിധി ഉള്ളതിനാൽ, ഇടവേളകൾ കൂടുതലുള്ള ട്രാഫിക് വന്നാൽ വീണ്ടും കോൾഡ് റീഡ് (cold read) ആവശ്യമായി വരികയും ലേറ്റൻസി ഗുണം നഷ്ടപ്പെടുകയും ചെയ്തേക്കാം. കൂടാതെ, കാഷെ GPU മെമ്മറിയിലാണ് ഇരിക്കുന്നത്; ഒന്നിലധികം മോഡലുകൾ ഒരേ ഹാർഡ്‌വെയർ പങ്കിടുന്നുണ്ടെങ്കിൽ പെർഫോമൻസിനെ അത് ബാധിച്ചേക്കാം, എങ്കിലും Bedrock ഇതിന്റെ വിശദാംശങ്ങൾ പുറത്തുവിടുന്നില്ല.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • Metric dashboards – കാഷെ ഉദ്ദേശിച്ച രീതിയിൽ ഉപയോഗിക്കപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കാൻ cacheReadInputTokens-ഉം മൊത്തത്തിലുള്ള ലേറ്റൻസിയും ശ്രദ്ധിക്കുക.
  • Prompt engineering – റിക്വസ്റ്റ് വലുതാക്കാതെ തന്നെ നിശ്ചിത ടോക്കൺ പരിധി പാലിക്കുന്ന രീതിയിൽ പ്രോംപ്റ്റുകൾ രൂപകൽപ്പന ചെയ്യുക എന്നത് ഡെവലപ്പർമാർക്ക് പുതിയൊരു വെല്ലുവിളിയാണ്.
  • Future extensions – Bedrock കാഷെ കാലാവധി വർദ്ധിപ്പിക്കുകയോ ടോക്കൺ പരിധികൾ കുറയ്ക്കുകയോ ചെയ്താൽ, ദീർഘനേരം നീണ്ടുനിൽക്കുന്ന സംഭാഷണങ്ങളുടെ സാമ്പത്തിക ലാഭം വർദ്ധിച്ചേക്കാം.

ചുരുക്കത്തിൽ: മതിയായ അളവിലുള്ളതും മാറ്റമില്ലാത്തതുമായ ഒരു പ്രോംപ്റ്റ് ഉറപ്പാക്കാനും കോളുകൾ ചെറിയ സമയപരിധിക്കുള്ളിൽ നിലനിർത്താനും സാധിക്കുമെങ്കിൽ, Claude 4.6 ഉപയോക്താക്കൾക്ക് മറുപടി സമയവും ചിലവും കുറയ്ക്കാൻ prompt caching ഒരു മികച്ച മാർഗ്ഗമാണ്. ഒരേ സിസ്റ്റം നിർദ്ദേശങ്ങൾ ആവർത്തിക്കുന്ന ഏതൊരു GenAI സേവനത്തിനും ഈ ഫീച്ചർ നേരത്തെ തന്നെ പരീക്ഷിച്ചു നോക്കുന്നത് നന്നായിരിക്കും.