Amazon Bedrock आता Claude 4.6 साठी prompt-caching ऑफर करत आहे, हे एक असे वैशिष्ट्य आहे जे generative-AI ॲप्लिकेशन्ससाठी प्रतिसादाचा विलंब (latency) कमी करू शकते आणि inference खर्च कमी करू शकते. ही क्षमता प्रॉम्प्टचा एक स्थिर भाग पाच मिनिटांपर्यंत लक्षात ठेवते, ज्यामुळे पुढील कॉल्समध्ये त्या मजकुराची खर्चिक पुनरावृत्ती (re-processing) टाळता येते.
कॅश (cache) विनंती साखळीमध्ये (request chain) कशी बसते
जेव्हा Claude 4.6 विनंती येते, तेव्हा दोन स्तर (layers) एकमेकांशी समन्वय साधतात.
Model level – Claude 4.6 GPU मेमरीमध्ये key-value (KV) कॅश राखते. जेव्हा मॉडेल पहिल्यांदा सूचनांचा संच (block of instructions) वाचते, तेव्हा ते resulting internal representation साठवते. नंतरच्या कॉल्समध्ये जेव्हा तोच संच पुन्हा वापरला जातो, तेव्हा मॉडेल ते पुन्हा मोजण्याऐवजी (recomputing) ते representation मिळवू शकते.
Bedrock level – Bedrock स्थिर प्रॉम्प्ट सेगमेंटचा एक fingerprint मोजते. जर नवीन विनंतीमध्ये जुळणारा fingerprint असेल, तर Bedrock ती विनंती थेट त्या GPU कडे पाठवते ज्यामध्ये आधीच कॅश केलेली स्थिती (cached state) आहे, ज्यामुळे “warm-up” टप्पा वगळला जातो.
हे प्रत्येक वेळी नवीन गेम सुरू करण्याऐवजी, सेव्ह केलेला गेम लोड करण्यासारखे आहे असे समजा.
कॅश जिवंत ठेवण्याचे नियम
Minimum token count – Claude Sonnet 4.6 साठी कॅश केलेल्या सेगमेंटमध्ये किमान १,०२४ tokens असणे आवश्यक आहे; Claude Opus 4.6 साठी ४,०९६ tokens आवश्यक आहेत. त्यापेक्षा कमी असल्यास ते दुर्लक्षित केले जाते.
Five-minute lifetime – पाच मिनिटांच्या निष्क्रियतेनंतर कॅश संपते (expires). प्रत्येक हिटमुळे टाइमर रिसेट होतो, त्यामुळे कॉल्सचा सतत प्रवाह कॅश कायम ठेवू शकतो.
Prompt ordering – Bedrock प्रॉम्प्ट क्रमाने वाचते. स्थिर सूचना प्रथम येणे आवश्यक आहे, त्यानंतर
cachePointमार्कर असावा आणि त्यानंतर सर्व युजर-जनरेटेड मेसेजेस असावेत. मार्करपूर्वीचा एकही कॅरेक्टर बदलल्यास fingerprint बदलतो आणि 'cold read' अनिवार्य होतो.
या वैशिष्ट्याचा प्रत्यक्ष वापर करणे
Bedrock Converse API हा प्रवेश बिंदू (entry point) आहे. खाली एक किमान Python snippet आहे जे आवश्यक संरचना दर्शवते.
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 सायकलकडून हलक्या वजनाच्या राउटिंग स्टेपकडे वळते. चॅटबॉट्स, retrieval-augmented generation (RAG) पाइपलाइन्स किंवा कोणताही सेवा जो तोच सिस्टम प्रॉम्प्ट वारंवार वापरतो, त्यांच्यासाठी याचा परिणाम म्हणजे जलद प्रतिसाद आणि कमी बिलिंग टोकन काउंट. उच्च-थ्रूपुट (high-throughput) परिस्थितीमध्ये, कम्प्युट वेळेतील थोडीशी घट देखील लक्षणीय खर्च बचतीमध्ये रूपांतरित होऊ शकते.
मर्यादा आणि तडजोड (Limits and trade-offs)
हे वैशिष्ट्य तेव्हाच मदत करते जेव्हा प्रॉम्प्ट सेगमेंट टोकन किमान मर्यादेत बसतो आणि अपरिवर्तित राहतो. जे ॲप्लिकेशन्स वारंवार सिस्टम सूचनांमध्ये बदल करतात किंवा जे लहान प्रॉम्प्ट्सवर अवलंबून असतात, त्यांना फारसा फायदा होणार नाही. पाच मिनिटांच्या विंडोचा अर्थ असा देखील आहे की, दीर्घ विश्रांतीसह येणाऱ्या अचानक ट्रॅफिकमुळे वारंवार 'cold reads' होऊ शकतात, ज्यामुळे लेटन्सीचा फायदा कमी होऊ शकतो. शेवटी, कॅश GPU मेमरीमध्ये असते; जर अनेक मॉडेल्स एकच हार्डवेअर शेअर करत असतील, तर स्पर्धा (contention) कामगिरीवर परिणाम करू शकते, जरी Bedrock त्या तपशीलांची माहिती देत नाही.
पुढे काय पाहावे
- Metric dashboards – कॅश नियोजित केल्याप्रमाणे वापरली जात आहे की नाही हे तपासण्यासाठी
cacheReadInputTokensआणि एकूण लेटन्सीवर लक्ष ठेवा. - Prompt engineering – विनंतीचा आकार न वाढवता आकार मर्यादेचे पालन करणारे प्रॉम्प्ट्स डिझाइन करणे हे डेव्हलपर्ससाठी एक नवीन कौशल्य आहे.
- Future extensions – जर Bedrock ने कॅशचा कालावधी वाढवला किंवा टोकन मर्यादा शिथिल केली, तर दीर्घकाळ चालणाऱ्या संभाषणांचे अर्थशास्त्र अधिक बदलू शकते.
Takeaway: प्रॉम्प्ट कॅशिंग Claude 4.6 वापरकर्त्यांना प्रतिसाद वेळ आणि खर्च दोन्ही कमी करण्यासाठी एक ठोस साधन देते, जर ते पुरेसा मोठा, अपरिवर्तनीय प्रॉम्प्ट लॉक करू शकले आणि कॉल्स एका लहान विंडोमध्ये ठेवू शकले तर. कोणत्याही GenAI सेवेसाठी जो तोच सिस्टम प्रॉम्प्ट वारंवार वापरतो, हे वैशिष्ट्य लवकर तपासून पाहण्यासारखे आहे.