Amazon Bedrock இப்போது Claude 4.6 க்கான prompt-caching வசதியை வழங்குகிறது. இந்த வசதி பதிலளிக்கும் தாமதத்தைக் (latency) குறைக்கவும், generative-AI பயன்பாடுகளுக்கான இன்ஃபரன்ஸ் செலவைக் (inference spend) குறைக்கவும் உதவும். ஒரு ப்ராம்ப்ட்டின் நிலையான பகுதியை ஐந்து நிமிடங்கள் வரை நினைவில் வைத்துக்கொள்வதன் மூலம் இந்தத் திறன் செயல்படுகிறது, இதனால் அடுத்தடுத்த அழைப்புகளில் அந்த உரையை மீண்டும் செயலாக்கும் (re-processing) செலவு தவிர்க்கப்படுகிறது.

கேச் (cache) எவ்வாறு கோரிக்கை சங்கிலியில் பொருந்துகிறது

ஒரு Claude 4.6 கோரிக்கை வரும்போது, இரண்டு அடுக்குகள் இணைந்து செயல்படுகின்றன.

  • Model level – Claude 4.6, GPU நினைவகத்தில் (memory) ஒரு key-value (KV) கேச்சை பராமரிக்கிறது. முதல் முறை மாடல் ஒரு அறிவுறுத்தல் தொகுப்பை (block of instructions) பகுப்பாய்வு செய்யும்போது, அதன் விளைவாகக் கிடைக்கும் உள்நிலைத் தரவை (internal representation) சேமிக்கிறது. அதே தொகுப்பை மீண்டும் பயன்படுத்தும் அடுத்தடுத்த அழைப்புகளில், மாடல் அதை மீண்டும் கணக்கிடுவதற்குப் பதிலாக, சேமிக்கப்பட்ட தரவை மீட்டெடுக்க முடியும்.

  • Bedrock level – Bedrock நிலையான ப்ராம்ப்ட் பகுதியின் ஒரு fingerprint-ஐ கணக்கிடுகிறது. புதிய கோரிக்கை அதே போன்ற fingerprint-ஐக் கொண்டிருந்தால், Bedrock அதை ஏற்கனவே கேச் செய்யப்பட்ட நிலையில் உள்ள GPU-விற்கு நேரடியாக வழிநடத்தும், இதனால் "warm-up" நிலை தவிர்க்கப்படுகிறது.

ஒவ்வொரு முறையும் புதிய விளையாட்டைத் தொடங்குவதற்குப் பதிலாக, சேமிக்கப்பட்ட ஒரு விளையாட்டை (saved game) ஏற்றுவது போல இதை நினைவில் கொள்ளுங்கள்.

கேச்சை உயிர்ப்புடன் வைத்திருக்கும் விதிகள்

  1. குறைந்தபட்ச டோக்கன் எண்ணிக்கை (Minimum token count) – Claude Sonnet 4.6 கேச் செய்யப்பட்ட பகுதியில் குறைந்தது 1,024 டோக்கன்களைக் கொண்டிருக்க வேண்டும்; Claude Opus 4.6-க்கு 4,096 டோக்கன்கள் தேவை. இதற்குக் குறைவாக இருந்தால் அது புறக்கணிக்கப்படும்.

  2. ஐந்து நிமிட ஆயுட்காலம் (Five-minute lifetime) – செயல்பாடற்ற ஐந்து நிமிடங்களுக்குப் பிறகு கேச் காலாவதியாகிவிடும். ஒவ்வொரு முறையும் கேச் பயன்படுத்தப்படும்போது (hit) டைமர் மீண்டும் தொடங்கும், எனவே தொடர்ச்சியான அழைப்புகள் கேச்சை எவ்வளவு காலமும் உயிர்ப்புடன் வைத்திருக்க முடியும்.

  3. ப்ராம்ப்ட் வரிசைமுறை (Prompt ordering) – Bedrock ப்ராம்ப்ட்டை வரிசையாகப் படிக்கிறது. நிலையான அறிவுறுத்தல்கள் முதலில் வர வேண்டும், அதைத் தொடர்ந்து ஒரு cachePoint மார்க்கர் இருக்க வேண்டும், அதன் பிறகு பயனர் உருவாக்கிய செய்திகள் வர வேண்டும். மார்க்கருக்கு முன் ஒரு எழுத்தை மாற்றினாலும், அது fingerprint-ஐ மாற்றிவிடும் மற்றும் மீண்டும் முழுமையாகப் படிக்க வேண்டிய கட்டாயத்தை (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)}")

மாற்ற முடியாத பகுதி (immutable segment) எங்கு முடிகிறது என்பதை cachePoint Bedrock-க்குக் கூறுகிறது. முதல் அழைப்பிற்குப் பிறகு, cacheReadInputTokens அளவீடு (metric) பூஜ்ஜியமற்ற மதிப்பைத் காட்ட வேண்டும், இது கேச் பயன்படுத்தப்பட்டதை உறுதிப்படுத்தும்.

டெவலப்பர்கள் ஏன் இதைக் கவனிக்க வேண்டும்

நிலையான அறிவுறுத்தல்களைப் பயனரின் மாறும் உள்ளீட்டிலிருந்து (dynamic user input) பிரிப்பதன் மூலம், அதிக செலவு பிடிக்கும் GPU சுழற்சிகளைக் குறைத்து, இலகுவான ரூட்டிங் (routing) நிலைக்கு மாற்ற முடியும். சாட்பாட்கள் (chatbots), retrieval-augmented generation (RAG) குழாய்கள் (pipelines) அல்லது ஒரே சிஸ்டம் ப்ராம்ப்ட்டைத் திரும்பத் திரும்பப் பயன்படுத்தும் எந்தவொரு சேவைக்கும், இதன் விளைவாக வேகமான பதில்களும் குறைந்த டோக்கன் செலவும் கிடைக்கும். அதிகப்படியான பயன்பாடு (high-throughput) உள்ள சூழல்களில், கணக்கீட்டு நேரத்தைக் குறைப்பது குறிப்பிடத்தக்க செலவு சேமிப்பிற்கு வழிவகுக்கும்.

வரம்புகள் மற்றும் சவால்கள் (Limits and trade-offs)

ப்ராம்ப்ட் பகுதி குறைந்தபட்ச டோக்கன் அளவை எட்டும்போது மற்றும் மாற்றமில்லாமல் இருக்கும்போது மட்டுமே இந்த வசதி உதவும். சிஸ்டம் அறிவுறுத்தல்களை அடிக்கடி மாற்றும் பயன்பாடுகள் அல்லது குறுகிய ப்ராம்ப்ட்களைப் பயன்படுத்தும் பயன்பாடுகள் இதிலிருந்து பெரிய பலனைப் பெறாது. ஐந்து நிமிட கால அவகாசம் என்பதால், நீண்ட இடைவெளிகளுடன் கூடிய திடீர் போக்குவரத்து (bursty traffic) மீண்டும் மீண்டும் 'cold reads'-ஐ ஏற்படுத்தி, தாமதத்தைக் குறைக்க உதவும் நன்மையைக் குறைத்துவிடும். இறுதியாக, கேச் GPU நினைவகத்தில் உள்ளது; பல மாடல்கள் ஒரே வன்பொருளைப் பகிர்ந்து கொண்டால், செயல்திறன் பாதிக்கப்படலாம், இருப்பினும் Bedrock அந்த விவரங்களை வெளிப்படையாகக் காட்டுவதில்லை.

அடுத்து கவனிக்க வேண்டியவை

  • அளவீட்டு டாஷ்போர்டுகள் (Metric dashboards) – கேச் திட்டமிட்டபடி பயன்படுத்தப்படுவதை உறுதி செய்ய cacheReadInputTokens மற்றும் ஒட்டுமொத்த தாமதத்தைக் (latency) கவனித்துக் கொண்டே இருங்கள்.
  • ப்ராம்ப்ட் இன்ஜினியரிங் (Prompt engineering) – கோரிக்கையை அதிகப்படியாக அதிகரிக்காமல், அளவு வரம்புகளைப் பூர்த்தி செய்யும் வகையில் ப்ராம்ப்ட்களை வடிவமைப்பது டெவலப்பர்களுக்கு ஒரு புதிய பயிற்சியாகும்.
  • எதிர்கால விரிவாக்கங்கள் (Future extensions) – Bedrock கேச் கால அளவை அதிகரித்தாலோ அல்லது டோக்கன் வரம்புகளைத் தளர்த்தினாலோ, நீண்ட கால உரையாடல்களின் பொருளாதாரத் தாக்கம் மேலும் மாறக்கூடும்.

சுருக்கம் (Takeaway): போதுமான அளவு பெரிய மற்றும் மாற்ற முடியாத ப்ராம்ப்ட்டை நிலைநிறுத்தி, அழைப்புகளை குறுகிய காலத்திற்குள் வைத்திருந்தால், prompt caching வசதி Claude 4.6 பயனர்களுக்குப் பதிலளிக்கும் நேரம் மற்றும் செலவு இரண்டையும் குறைக்க ஒரு உறுதியான வாய்ப்பை வழங்குகிறது. ஒரே சிஸ்டம் அறிவுறுத்தல்களைத் திரும்பத் திரும்பப் பயன்படுத்தும் எந்தவொரு GenAI சேவைக்கும், இந்த வசதியை முன்கூட்டியே சோதித்துப் பார்ப்பது பயனுள்ளதாக இருக்கும்.