دليل شامل لـ Prompt Caching: المبادئ ونموذج التكلفة وطريقة التطبيق

ما المشكلة التي يحلها Prompt caching

في مدخلات معظم استدعاءات LLM، هناك جزء كبير متطابق في كل مرة: المطالبة النظامية، أمثلة few-shot، المستندات الثابتة المسترجعة، تعريفات الأدوات (tool schema). ووفق الفوترة العادية، يُدفع ثمن هذه المحتويات المتكررة من رموز الإدخال في كل مرة، ويُعاد حساب attention لها في كل مرة.

فكرة Prompt caching مباشرة: يخزّن الخادم نتيجة حساب هذه البادئة، وإذا كانت البادئة في الطلب التالي متطابقة تماماً يعيد استخدامها مباشرة، ويعيد حساب الجزء الجديد فقط. تصفها Anthropic في [توثيق prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) كوسيلة لتقليل زمن الاستجابة والتكلفة، ويقابلها في OpenAI آليات مثل التخزين المؤقت التلقائي للمطالبات وخصومات batch.

أي السيناريوهات توفر المال فعلاً

Prompt caching ليس مفتاحاً يُشغَّل فتوفر التكلفة تلقائياً. له حد ربحية واضح: عدد مرات إعادة استخدام نفس البادئة × طول البادئة > التكلفة الإضافية لكتابة التخزين المؤقت.

• مطالبة نظامية طويلة + محادثة متعددة الأدوار: مطالبة نظامية بآلاف الرموز وجلسات متعددة الأدوار، مربحة تقريباً دائماً.
• RAG + مجموعة مستندات ثابتة: ضع مستندات السياسات/قاعدة المعرفة غير المتغيرة في البادئة، ودع سؤال المستخدم فقط يتغير.
• وكيل برمجي / استدعاء أدوات: غالباً ما يتكرر tool schema ووصف بنية المستودع في كل استدعاء.
• استدعاءات فردية ببادئة قصيرة: قد تكون تكلفة كتابة التخزين المؤقت أعلى من التوفير، لا تفرض التخزين المؤقت.

خمسة أخطاء شائعة تؤدي إلى إبطال التخزين المؤقت

• إدراج طابع زمني أو معرّف عشوائي في البادئة: حتى وضع Date.now() في موضع ثابت واحد يغيّر البادئة بأكملها.
• تجميع المطالبة النظامية ديناميكياً: يحصل مستخدمون مختلفون على بادئات مختلفة، فيُخفَّض معدل الإصابة إلى ما يقارب 0.
• ضغط سجل الرسائل بالتلخيص: إعادة الكتابة في كل دور تجعل البادئة غير مستقرة.
• وضع إدخال المستخدم في المقدمة: هذا هو الخطأ الهيكلي الأكثر شيوعاً، يجب إبقاء المتغيرات في أقصى النهاية.
• النظر إلى الفاتورة فقط دون معدل الإصابة: بدون مؤشر معدل الإصابة، لا يمكن نسب عائد التخزين المؤقت إطلاقاً.

إعادة استخدام نفس استراتيجية التخزين المؤقت بين عدة نماذج

إذا كان منتجك يستخدم Claude وGPT معاً، فإن دلالات التخزين المؤقت ليست متطابقة تماماً بين المورّدين (من يعلن نقاط توقف التخزين المؤقت، وطول TTL، وطريقة الفوترة). إبقاء هذه الطبقة التكيفية خلف بوابة موحدة يعني أن كود الأعمال يحتفظ ببنية مطالبة واحدة فقط، دون إعادة كتابة عند تبديل النموذج.

تحافظ بوابة Admesh على بروتوكول متوافق مع OpenAI في الطبقة السفلية، لذا يمكن تبديل المورّدين بتغيير حقل model فقط مع نفس بنية المطالبة؛ وتظهر فوترة إصابات التخزين المؤقت موحدة في تفاصيل usage بالفاتورة، دون الحاجة للتكامل مع طريقة فوترة كل مورّد على حدة.

عرض وحدات الفوترة وشرح رموز التخزين المؤقت →

قائمة التطبيق

1. قسّم المطالبة إلى ثلاثة أجزاء: «بادئة مستقرة / جزء شبه مستقر / إدخال المستخدم»، وضع الجزء المستقر في المقدمة.
2. تأكد من عدم وجود طوابع زمنية أو أرقام عشوائية أو معرّفات مستخدم في البادئة المستقرة.
3. احسب رموز قراءة وكتابة التخزين المؤقت بشكل منفصل في الفاتورة، وحوّلها إلى معدل إصابة حقيقي.
4. استخدم مجموعة طلبات تقييم ثابتة للاختبار الدوري، للتأكد من أن تعديلات المطالبة لم تُنهِ معدل الإصابة.
5. ضع حداً أدنى لعائد التخزين المؤقت (مثلاً أقل من 5% فارجع عن بنية المطالبة)، لتجنب التحسين من أجل التحسين.