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) کیش برقرار رکھتا ہے۔ جب ماڈل پہلی بار ہدایات کے ایک بلاک کو پرس (parse) کرتا ہے، تو یہ اس کے نتیجے میں بننے والی اندرونی نمائندگی (internal representation) کو محفوظ کر لیتا ہے۔ بعد میں ایسی کالز میں جو اسی بلاک کو دوبارہ استعمال کرتی ہیں، ماڈل اسے دوبارہ کیلکولیٹ کرنے کے بجائے اس نمائندگی کو حاصل کر سکتا ہے۔

  • Bedrock level – Bedrock ساکن پرومپٹ سیگمنٹ کا ایک فنگر پرنٹ (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 – پانچ منٹ تک غیر فعالیت (inactivity) رہنے کے بعد کیش ختم ہو جاتا ہے۔ ہر ہٹ (hit) ٹائمر کو ری سیٹ کر دیتی ہے، اس لیے کالز کا ایک مسلسل سلسلہ کیش کو غیر محدود مدت تک فعال رکھ سکتا ہے۔

  3. Prompt ordering – Bedrock پرومپٹ کو ترتیب وار پڑھتا ہے۔ ساکن ہدایات پہلے ہونی چاہئیں، جس کے بعد ایک cachePoint مارکر ہو، اور اس مارکر کے بعد تمام صارف کے تیار کردہ پیغامات ہوں۔ مارکر سے پہلے ایک حرف کی تبدیلی بھی فنگر پرنٹ کو توڑ دیتی ہے اور "cold read" پر مجبور کرتی ہے۔

اس فیچر کا عملی استعمال

Bedrock Converse API اس کا داخلی نقطہ (entry point) ہے۔ نیچے ایک مختصر 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 میٹرک کو غیر صفر (non-zero) ویلیو دکھانی چاہیے، جو اس بات کی تصدیق کرتی ہے کہ کیش استعمال ہوا ہے۔

ڈویلپرز کو اس کی اہمیت کیوں سمجھنی چاہیے

ساکن ہدایات کو متحرک صارف ان پٹ سے الگ کرنے سے کام مہنگے GPU سائیکلز سے ہٹ کر ایک ہلکے پھلکے راؤٹنگ مرحلے پر منتقل ہو جاتا ہے۔ چیٹ بوٹس، retrieval-augmented generation (RAG) پائپ لائنز، یا کسی بھی ایسی سروس کے لیے جو ایک ہی سسٹم پرومپٹ کو بار بار استعمال کرتی ہے، اس کا نتیجہ تیز تر جوابات اور کم قابلِ بل (billable) ٹوکنز کی صورت میں نکلتا ہے۔ زیادہ تھرو پٹ (high-throughput) والے منظرناموں میں، کمپیوٹ ٹائم میں معمولی سی کمی بھی نمایاں لاگت کی بچت میں بدل سکتی ہے۔

حدود اور توازن (Limits and trade-offs)

یہ فیچر صرف اس وقت مدد کرتا ہے جب پرومپٹ سیگمنٹ ٹوکن کی کم از کم حد کو پورا کرے اور تبدیل نہ ہو۔ وہ ایپلی کیشنز جو سسٹم کی ہدایات میں بار بار تبدیلی کرتی ہیں، یا جو مختصر پرومپٹس پر انحصار کرتی ہیں، انہیں اس کا بہت کم فائدہ ہوگا۔ پانچ منٹ کی مدت کا مطلب یہ بھی ہے کہ طویل وقفوں والے غیر مستقل ٹریفک (bursty traffic) کے دوران بار بار "cold reads" ہو سکتے ہیں، جس سے لیٹنسی کا فائدہ ختم ہو سکتا ہے۔ آخر میں، کیش GPU میموری میں رہتا ہے؛ اگر متعدد ماڈلز ایک ہی ہارڈ ویئر شیئر کرتے ہیں، تو مقابلہ (contention) کارکردگی کو متاثر کر سکتا ہے، اگرچہ Bedrock ان تفصیلات کو ظاہر نہیں کرتا۔

آگے کن چیزوں پر نظر رکھنی چاہیے

  • Metric dashboards – یہ تصدیق کرنے کے لیے کہ کیش کا مطلوبہ طریقے سے استعمال ہو رہا ہے، cacheReadInputTokens اور مجموعی لیٹنسی پر نظر رکھیں۔
  • Prompt engineering – ایسے پرومپٹس ڈیزائن کرنا جو ریکویسٹ کو بوجھل کیے بغیر سائز کی حدوں کو پورا کریں، ڈویلپرز کے لیے ایک نیا شعبہ ہے۔
  • Future extensions – اگر Bedrock کیش کے دورانیے کو بڑھاتا ہے یا ٹوکن کی حدود میں نرمی کرتا ہے، تو طویل گفتگو کے معاشی پہلو مزید بدل سکتے ہیں۔

خلاصہ (Takeaway): پرومپٹ کیشنگ Claude 4.6 صارفین کو رسپانس ٹائم اور اخراجات دونوں کو کم کرنے کے لیے ایک ٹھوس ذریعہ فراہم کرتی ہے، بشرطیکہ وہ ایک کافی بڑی، ناقابل تبدیلی پرومپٹ کو برقرار رکھ سکیں اور کالز کو ایک مختصر دورانیے کے اندر رکھ سکیں۔ کسی بھی ایسی GenAI سروس کے لیے جو ایک ہی سسٹم ہدایات کو بار بار دہراتی ہے، اس فیچر کا جلد تجربہ کرنا فائدہ مند ہے۔