يوفر Amazon Bedrock الآن ميزة التخزين المؤقت للمطالبات (prompt-caching) لنموذج Claude 4.6، وهي ميزة يمكنها تقليل زمن استجابة (latency) التفاعلات وخفض تكاليف الاستدلال (inference spend) لتطبيقات الذكاء الاصطناعي التوليدي. تعمل هذه القدرة من خلال تذكر جزء ثابت من المطالبة لمدة تصل إلى خمس دقائق، بحيث تتخطى الاستدعاءات اللاحقة عملية إعادة المعالجة المكلفة لهذا النص.

كيف يتناسب التخزين المؤقت مع سلسلة الطلبات

عند وصول طلب إلى Claude 4.6، يتعاون مستويان:

  • على مستوى النموذج (Model level) – يحافظ Claude 4.6 على ذاكرة تخزين مؤقت للمفاتيح والقيم (KV cache) في ذاكرة وحدة معالجة الرسومات (GPU). في المرة الأولى التي يقوم فيها النموذج بتحليل كتلة من التعليمات، فإنه يخزن التمثيل الداخلي الناتج. وفي الاستدعاءات اللاحقة التي تعيد استخدام نفس الكتلة، يمكن للنموذج استرداد التمثيل بدلاً من إعادة حسابه.

  • على مستوى Bedrock (Bedrock level) – يقوم Bedrock بحساب بصمة (fingerprint) لجزئية المطالبة الثابتة. إذا حمل طلب جديد بصمة مطابقة، يقوم Bedrock بتوجيهه مباشرة إلى وحدة معالجة الرسومات (GPU) التي تحتوي بالفعل على الحالة المخزنة مؤقتًا، متجاوزًا مرحلة "الإحماء" (warm-up stage).

تخيل الأمر كأنك تقوم بتحميل لعبة محفوظة بدلاً من بدء لعبة جديدة في كل مرة.

القواعد التي تحافظ على استمرارية التخزين المؤقت

  1. الحد الأدنى لعدد الرموز (tokens) – يتطلب Claude Sonnet 4.6 ما لا يقل عن 1,024 رمزًا في الجزء المخزن مؤقتًا؛ بينما يحتاج Claude Opus 4.6 إلى 4,096 رمزًا. أي عدد أقل من ذلك سيتم تجاهله.

  2. عمر مدته خمس دقائق – تنتهي صلاحية التخزين المؤقت بعد خمس دقائق من عدم النشاط. كل عملية استدعال ناجحة تعيد ضبط المؤقت، لذا فإن التدفق المستمر للاستدعاءات يمكن أن يحافظ على التخزين المؤقت نشطًا إلى أجل غير مسمى.

  3. ترتيب المطالبة – يقرأ 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) المكلفة إلى خطوة توجيه خفيفة الوزن. بالنسبة لروبوتات الدردشة (chatbots)، أو مسارات التوليد المعزز بالاسترجاع (RAG)، أو أي خدمة تكرر نفس مطالبة النظام، فإن النتيجة هي ردود أسرع وعدد أقل من الرموز (tokens) القابلة للفوترة. في سيناريوهات الإنتاجية العالية، يمكن حتى للتقليل المتواضع في وقت الحوسبة أن يترجم إلى توفير ملحوظ في التكاليف.

القيود والمقايضات

تساعد هذه الميزة فقط عندما يستوفي جزء المطالبة الحد الأدنى من الرموز ويبقى دون تغيير. التطبيقات التي تقوم بتعديل تعليمات النظام بشكل متكرر، أو التي تعتمد على مطالبات قصيرة، لن تجد فائدة تذكر. كما أن نافذة الخمس دقائق تعني أن حركة المرور المتقطعة والمكثفة التي تتخللها فترات خمول طويلة قد تؤدي إلى تكرار عمليات القراءة الباردة، مما يقلل من ميزة تقليل زمن الاستجابة. أخيرًا، يعيش التخزين المؤقت في ذاكرة وحدة معالجة الرسومات (GPU)؛ فإذا تشاركت نماذج متعددة في نفس الأجهزة، فقد يؤثر التنافس على الأداء، رغم أن Bedrock لا يكشف عن هذه التفاصيل.

ما يجب مراقبته لاحقًا

  • لوحات معلومات المقاييس – راقب cacheReadInputTokens وزمن الاستجابة الإجمالي للتحقق من استخدام التخزين المؤقت كما هو مخطط له.
  • هندسة المطالبات – يعد تصميم مطالبات تلبي عتبات الحجم دون تضخيم الطلب تخصصًا جديدًا للمطورين.
  • التوسعات المستقبلية – إذا قام Bedrock بتوسيع مدة التخزين المؤقت أو تخفيف حدود الرموز، فقد تتغير اقتصاديات المحادثات طويلة الأمد بشكل أكبر.

الخلاصة: تمنح ميزة التخزين المؤقت للمطالبات مستخدمي Claude 4.6 أداة ملموسة لتقليل كل من وقت الاستجابة والتكاليف، بشرط أن يتمكنوا من تثبيت مطالبة كبيرة بما يكفي وغير قابلة للتغيير، والحفاظ على الاستدعاءات ضمن نافذة زمنية قصيرة. لأي خدمة ذكاء اصطناعي توليدي تكرر نفس تعليمات النظام، تستحق هذه الميزة التجربة في وقت مبكر.