Amazon Bedrock હવે Claude 4.6 માટે prompt-caching ઓફર કરે છે, જે એક એવી સુવિધા છે જે generative-AI એપ્લિકેશન્સ માટે પ્રતિસાદ લેટન્સી (response latency) ઘટાડી શકે છે અને ઇન્ફરન્સ ખર્ચ (inference spend) પણ ઓછો કરી શકે છે. આ ક્ષમતા પ્રોમ્પ્ટના સ્થિર (static) ભાગને પાંચ મિનિટ સુધી યાદ રાખીને કામ કરે છે, જેથી પછીના કોલ્સમાં તે ટેક્સ્ટનું ખર્ચાળ પુનઃ-પ્રોસેસિંગ કરવાનું ટાળી શકાય છે.

રિક્વેસ્ટ ચેઇનમાં કેશ (cache) કેવી રીતે ફિટ થાય છે

જ્યારે Claude 4.6 રિક્વેસ્ટ આવે છે, ત્યારે બે લેયર્સ સહકાર આપે છે.

  • Model level – Claude 4.6 GPU મેમરીમાં key-value (KV) કેશ જાળવી રાખે છે. જ્યારે મોડેલ પહેલીવાર સૂચનાઓના બ્લોકને પાર્સ કરે છે, ત્યારે તે પરિણામી આંતરિક પ્રતિનિધિત્વ (internal representation) સ્ટોર કરે છે. પછીના કોલ્સમાં જ્યારે તે જ બ્લોકનો ફરીથી ઉપયોગ કરવામાં આવે છે, ત્યારે મોડેલ તેને ફરીથી ગણતરી કરવાને બદલે તે પ્રતિનિધિત્વ મેળવી શકે છે.

  • Bedrock level – Bedrock સ્થિર પ્રોમ્પ્ટ સેગમેન્ટનું ફિંગરપ્રિન્ટ (fingerprint) ગણતરી કરે છે. જો નવી રિક્વેસ્ટમાં મેચિંગ ફિંગરપ્રિન્ટ હોય, તો Bedrock તેને સીધું જ તે GPU પર રૂટ કરે છે જેની પાસે પહેલેથી જ કેશ કરેલ સ્ટેટ હોય છે, જેનાથી “warm-up” સ્ટેજ બાયપાસ થઈ જાય છે.

તેને દર વખતે નવો ગેમ શરૂ કરવાને બદલે સેવ કરેલી ગેમ લોડ કરવા જેવું સમજો.

કેશને જીવંત રાખવાના નિયમો

  1. Minimum token count – Claude Sonnet 4.6 ને કેશ કરેલા સેગમેન્ટમાં ઓછામાં ઓછા 1,024 ટોકન્સની જરૂર છે; Claude Opus 4.6 ને 4,096 ટોકન્સની જરૂર છે. તેનાથી નાની કોઈપણ વસ્તુને અવગણવામાં આવે છે.

  2. Five-minute lifetime – બિન-સક્રિયતાના પાંચ મિનિટ પછી કેશ એક્સપાયર (expire) થઈ જાય છે. દરેક હિટ ટાઈમરને રીસેટ કરે છે, તેથી કોલ્સનો સતત પ્રવાહ કેશને અનિશ્ચિત સમય માટે જીવંત રાખી શકે છે.

  3. Prompt ordering – Bedrock પ્રોમ્પ્ટને ક્રમિક રીતે વાંચે છે. સ્થિર સૂચનાઓ પહેલા દેખાવી જોઈએ, ત્યારબાદ a 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 ને જણાવે છે કે અપરિવર્તનીય (immutable) સેગમેન્ટ ક્યાં સમાપ્ત થાય છે. પ્રથમ કોલ પછી, cacheReadInputTokens મેટ્રિક શૂન્યથી વધુ મૂલ્ય બતાવવી જોઈએ, જે પુષ્ટિ કરે છે કે કેશનો ઉપયોગ થયો છે.

ડેવલપર્સે શા માટે આ બાબત પર ધ્યાન આપવું જોઈએ

ડાયનેમિક યુઝર ઇનપુટથી સ્થિર સૂચનાઓને અલગ કરવાથી કામ મોંઘા GPU સાયકલથી હળવા રૂટિંગ સ્ટેપ તરફ ખસે છે. ચેટબોટ્સ, રિટ્રીવલ-ઓગમેન્ટેડ જનરેશન (RAG) પાઇપલાઇન્સ, અથવા કોઈપણ સર્વિસ જે સમાન સિસ્ટમ પ્રોમ્પ્ટનું પુનરાવર્તન કરે છે, તેના માટે પરિણામ ઝડપી જવાબો અને ઓછા બિલ કરી શકાય તેવા ટોકન કાઉન્ટ્સ છે. હાઇ-થ્રુપુટ સિનારિયોમાં, કમ્પ્યુટ સમયમાં સામાન્ય ઘટાડો પણ નોંધપાત્ર ખર્ચ બચત માં પરિણમી શકે છે.

મર્યાદાઓ અને ટ્રેડ-ઓફ્સ

આ સુવિધા ત્યારે જ મદદ કરે છે જ્યારે પ્રોમ્પ્ટ સેગમેન્ટ ટોકન મિનિમમ્સને પૂર્ણ કરે અને અપરિવર્તિત રહે. જે એપ્લિકેશન્સ વારંવાર સિસ્ટમ સૂચનાઓમાં ફેરફાર કરે છે, અથવા જે ટૂંકા પ્રોમ્પ્ટ્સ પર આધાર રાખે છે, તેમને બહુ ઓછો ફાયદો થશે. પાંચ મિનિટની વિન્ડોનો અર્થ એ પણ છે કે લાંબા આઈડલ ગેપ્સ સાથેના બર્સ્ટી ટ્રાફિકમાં વારંવાર કોલ્ડ રીડ્સ થઈ શકે છે, જે લેટન્સીના ફાયદાને ઘટાડે છે. છેલ્લે, કેશ GPU મેમરીમાં રહે છે; જો મલ્ટિપલ મોડેલ્સ સમાન હાર્ડવેર શેર કરે છે, તો સ્પર્ધા (contention) પર્ફોર્મન્સને અસર કરી શકે છે, જોકે Bedrock તે વિગતો જાહેર કરતું નથી.

આગળ શું જોવું

  • Metric dashboards – કેશનો ઉપયોગ ઈરાદા મુજબ થઈ રહ્યો છે કે નહીં તે ચકાસવા માટે cacheReadInputTokens અને એકંદર લેટન્સી પર નજર રાખો.
  • Prompt engineering – રિક્વેસ્ટને વધાર્યા વિના સાઈઝ થ્રેશોલ્ડને સંતોષતા પ્રોમ્પ્ટ્સ ડિઝાઇન કરવા એ ડેવલપર્સ માટે એક નવું શિસ્ત (discipline) છે.
  • Future extensions – જો Bedrock કેશ ડ્યુરેશન વધારે અથવા ટોકન મર્યાદાઓમાં છૂટછાટ આપે, તો લાંબા સમય સુધી ચાલતા સંવાદોનું અર્થશાસ્ત્ર વધુ બદલાઈ શકે છે.

Takeaway: પ્રોમ્પ્ટ કેશિંગ Claude 4.6 વપરાશકર્તાઓને પ્રતિસાદ સમય અને ખર્ચ બંને ઘટાડવા માટે એક નક્કર સાધન આપે છે, જો તેઓ પૂરતા પ્રમાણમાં મોટા, અપરિવર્તનીય પ્રોમ્પ્ટને લોક કરી શકે અને કોલ્સને ટૂંકા સમયગાળામાં રાખી શકે. કોઈપણ GenAI સર્વિસ જે સમાન સિસ્ટમ સૂચનાઓનું પુનરાવર્તન કરે છે, તેના માટે આ સુવિધા વહેલી ટેસ્ટ કરવા જેવી છે.