لو الـ agent بتاعك بيرسل نفس system prompt حجمه 35 KB ومعاه 5 ملفات سياق ثابتة في كل طلب، الموديل بيعيد قراءة كل ده من الصفر وبتدفع كامل سعر التوكنز. Prompt Caching في Claude API بيخلّي الـ infrastructure تحتفظ بالجزء الثابت في ذاكرة مؤقتة على السيرفر، ويعيد استخدامه في الطلبات اللاحقة بسعر 10% فقط من السعر الأصلي. النتيجة على workload إنتاج حقيقي: انخفاض فاتورة الـ input 88%، وانخفاض زمن الاستجابة الأول (TTFT) من 4.2 ثانية لـ 1.1 ثانية على نفس الموديل بنفس الجودة.
Prompt Caching في Claude: شرح تقني عميق ومقياس إنتاج
المشكلة باختصار
أي تطبيق LLM شغّال في إنتاج بيكرّر جزء كبير من الـ context في كل طلب. الـ system prompt بيوصل لـ 50 KB لو فيه تعليمات دقيقة وأمثلة few-shot. تطبيقات الـ RAG بتلصق 4-8 chunks ثابتة من قاعدة المعرفة. الـ agent بيرفع كامل الـ tool definitions في كل خطوة من خطواته. كل ده بيتعامل معاه الموديل كتوكنز جديدة في كل مرة، فبتدفع عليه ثمنه كامل وبيستهلك compute في الـ forward pass من جديد.
قبل ما نخش في الـ KV cache والـ attention، خلّينا نفهم الفكرة بمثال بسيط للمبتدئين.
المثال البسيط: الكاشير اللي بيحفظ الزبون
تخيّل كاشير في كافيتيريا الشركة. أول مرة تيجي، بتقوله "أنا أحمد، صنف B، حساسية لاكتوز، الفاتورة على قسم الـ engineering". الكاشير بيكتب التفاصيل دي ويحفظها على ورقة جنبه. تاني مرة تيجي بعد ساعة، بتقوله "نفس طلب أمس + كرواسون"، فهو بيرجع للورقة المحفوظة بدل ما يسمع كل التفاصيل من الأول. ده بيوفّر وقتك ووقته.
الـ Prompt Caching في Claude بيشتغل بنفس المنطق بالظبط: الموديل بيشوف الجزء الثابت من الـ prompt مرة واحدة، يحفظ تمثيله الداخلي على السيرفر، وفي الطلبات اللي بعدها بيرجع للنسخة المحفوظة بدل ما يعالج التوكنز من جديد. الفرق إن المثال الواقعي بيقطع التكلفة لـ 10% فعلياً، مش مجرد توفير وقت.
التعريف العلمي الدقيق
Prompt Caching ميكانيزم على مستوى الـ inference بيحفظ الـ key-value tensors اللي طلعت من الـ self-attention layers أثناء معالجة قطاع معيّن من الـ prompt. لمّا يجي طلب لاحق بنفس البيانات في نفس الترتيب البايت-bayt، الـ inference engine بيستعيد الـ KV cache من ذاكرة الـ accelerator بدل ما يعيد الـ forward pass على التوكنز دي. ده بيوفّر الـ compute بالكامل على الجزء المحفوظ، فالسعر بينخفض لـ 10% وزمن الـ time-to-first-token بينخفض بنسبة 70 إلى 85% حسب حجم الجزء المحفوظ (Anthropic Engineering, 2024).
الافتراض المهم هنا: الـ cache lifetime الافتراضي 5 دقائق، وبيتجدّد كل ما يتم استخدامه (sliding TTL). في 2025 Anthropic أضافت خيار extended_cache بـ ساعة واحدة بسعر write مختلف، ودول الخيارين الوحيدين المتاحين رسميًا.
متى يستحق التكلفة الإضافية للكتابة
الـ cache write بيتكلف 1.25x من السعر العادي للتوكن. ده معناه إن الميزة مش مجانية: لو الـ cached content هيتقرا مرة واحدة بس، أنت خسران فلوس. الرياضيات اللي وراها بسيطة:
]]>