لو فاتورة Claude Sonnet 4.6 طلعت $1,247 الشهر اللي فات على شات بوت خدمة عملاء بـ 18,000 محادثة، انت بتدفع تمن نفس الـ 6,500 token من الـ system prompt 18,000 مرة. Prompt Caching من Anthropic بيخفّض الرقم لـ $127 بدون أي تغيير في الجودة، وبيقلّل p95 latency من 4.1 ثانية لـ 1.3 ثانية. السطر الوحيد اللي بيتضاف هو cache_control.
ليه بتدفع تمن نفس الكلام آلاف المرات في API Claude
المشكلة باختصار
أي شات بوت إنتاجي عنده 3 طبقات input ثابتة في كل request:
- System prompt — تعليمات الـ persona، الـ guardrails، أمثلة few-shot. عادة 3,000 إلى 8,000 token. ثابت تماماً.
- Knowledge base أو RAG context — وثائق retrieved chunks. عادة 4,000 إلى 20,000 token. متغيّر جزئياً.
- User message — السؤال الحالي. عادة 50 إلى 300 token. متغيّر كلياً.
في كل request، الـ API بيحاسبك على الـ 3 طبقات بالكامل. لكن الـ 90%+ من الـ tokens بتتكرر بحرفها. لو شات بوتك بيخدم 100,000 سؤال شهرياً ومتوسط input 12,000 token، انت بتعالج 1.2 مليار token — منهم 1.05 مليار token مكررة. بسعر Claude Sonnet 4.6 (3 دولار لكل مليون input token)، انت بتدفع $3,150 شهرياً، منهم $2,835 على tokens بعتها قبل كده.
ايه هو Prompt Caching بالظبط
مثال موظف الاستقبال (للمبتدئ)
تخيّل موظف استقبال في فندق فيه دليل من 300 صفحة عن السياسات والخدمات. كل لما عميل بيسأله سؤال — حتى لو "في wifi مجاني؟" — الموظف بيقرأ الدليل من أوله لحد ما يلاقي الإجابة في صفحة 47. السؤال اللي كان المفروض ياخد 3 ثواني بياخد 30 ثانية، والعميل بينتظر، وموظف الاستقبال بيتكلّف ساعات شغل زيادة على فيه فايدة.
دلوقتي تخيّل إن الموظف قرأ الدليل مرة واحدة الصبح، وحفظ خريطته في دماغه. أي عميل بيسأل في الساعة اللي بعدها، الموظف بيجاوب في 3 ثواني، لأنه عارف بالظبط فين الإجابة بدون ما يقرأ من الأول. ده اللي Prompt Caching بيعمله مع Claude — بيحفظ "حفظة" الـ system prompt مرة واحدة، وأي request بعديها خلال نافذة زمنية بيستفيد من الحفظة دي.
التعريف العلمي
الـ Transformer architecture اللي Claude مبني عليها (Vaswani et al., 2017) بتشتغل بمبدأ self-attention. لكل token في الـ input، النموذج بيحسب 3 مصفوفات: Query (Q)، Key (K)، Value (V). الـ K و V بيتخزّنوا داخلياً وبيُستخدموا في حساب الـ attention للـ tokens اللي بعدها. ده اسمه KV Cache، وهو موجود في كل LLM بشكل افتراضي داخل الـ request الواحد.
اللي Anthropic أضافته هو إن الـ KV Cache ده ممكن يتخزّن عبر الـ requests على disk سريع، مش يتمسح بعد كل request. لما يجي request جديد بنفس الـ prefix (نفس الـ tokens في نفس الترتيب من أول الـ input)، النموذج بيستورد الـ KV من الـ cache بدل ما يحسبها من الصفر. النتيجة:
]]>