ما هو التخزين المؤقت للمطالبات؟ كيف يُعاد استخدام مطالبة متكررة

يعني التخزين المؤقت للمطالبات (prompt caching) أن الـ API يتذكّر بداية طلبك ويعيد استخدامها في المرة التالية التي ترسل فيها البداية نفسها. ما زلت ترسل النص الكامل في كل استدعاء، لكن المزوّد يستطيع تخطّي عمل قراءة الجزء المتكرر مرة أخرى، وبعض المزوّدين يفوترون ذلك الجزء بسعر أقل. وهو يعمل فقط على بداية الطلب، وفقط إذا كانت تلك البداية مطابقة تمامًا.

روبوت الدعم الذي يعيد قراءة الصفحة نفسها#

لنفترض أنك تدير روبوت دعم يتعامل مع 2,000 تذكرة يوميًا. كل طلب يبدأ بالـ 3,000 توكن نفسها: نبرة الصوت، وقواعد الاسترداد، وسياسة الشحن. بعد ذلك تأتي رسالة العميل المكوّنة من سطر واحد، شيء مثل "أين طلبي؟" (إذا كانت التوكنات ما زالت غامضة، فابدأ بـ ما هو التوكن.)

بدون التخزين المؤقت، يقرأ المزوّد كل الـ 3,000 توكن من القواعد مرة أخرى للتذكرة رقم 1، والتذكرة رقم 2، والتذكرة رقم 2,000. الصفحة نفسها، مقروءة 2,000 مرة. مع التخزين المؤقت، يدفع الطلب الأول السعر الكامل لقراءتها، ويمكن للطلبات اللاحقة التي تبدأ بالنص نفسه إعادة استخدام العمل.

يصف دليل الـ API الخاص بـ DeepSeek (تم التحقق منه في 24 أكتوبر 2026) هذا بالضبط: التخزين المؤقت للسياق مفعّل افتراضيًا، ولا يحتاج إلى تغييرات في الكود، والطلب اللاحق ذو البادئة المتداخلة يُحتسب "إصابة في الذاكرة المؤقتة" (cache hit). يُخزَّن الإدخال فقط. أما الإجابة فتُولَّد من جديد في كل مرة.

ما الذي يُحتسب "الشيء نفسه": قاعدة البادئة#

تطابق الذاكرة المؤقتة من الحرف الأول فصاعدًا. في اللحظة التي يختلف فيها طلبك عن الطلب المخزَّن، يصبح كل ما بعد تلك النقطة جديدًا. لهذا السبب يهم ترتيب طلبك أكثر من طوله.

إليك الخطأ الذي يقتل التخزين المؤقت بهدوء. يريد المطوّر أن يعرف الروبوت الوقت فيضع الوقت في الأعلى:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

يتغيّر الوقت كل ثانية، لذا يختلف السطر الأول نفسه في كل طلب، ولا يمكن لأي شيء بعده أن يتطابق. الحل هو نقل كل ما يتغيّر إلى النهاية:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

الآن تأتي الـ 3,000 توكن من القواعد أولًا وتبقى مطابقة. المنطق نفسه يغطي الحالتين الشائعتين الأخريين: المحادثة الطويلة تعيد إرسال تاريخها كاملًا في كل دور، لذا تكون الرسائل القديمة بداية متكررة جاهزة (المزيد عن ذلك في لماذا تكلف المحادثة الطويلة أكثر)، والوكيل (agent) يكرر تعريفات أدواته وتعليماته في كل خطوة.

التخزين المؤقت أيضًا بذل أفضل جهد (best-effort). تقول DeepSeek إن بناء الذاكرة المؤقتة يستغرق بضع ثوانٍ، والإصابة تحتاج إلى تطابق كامل مع وحدة بادئة مخزَّنة موجودة، ولا يوجد معدل إصابة مضمون، والذواكر المؤقتة غير المستخدمة تُمسح، عادةً خلال ساعات إلى أيام. لذا قد لا يصيب طلب ثانٍ أُطلق بعد نصف ثانية من الأول بعد، وقد تغطي الإصابة أقل من بادئتك كاملة.

كيف تراه: حقول الذاكرة المؤقتة في usage#

لا يلزمك التخمين فيما إذا كان قد نجح. كل مزوّد يبلّغ عنه في جزء usage من الاستجابة، تحت أسماء حقوله الخاصة.

تستخدم DeepSeek حقلين:

• prompt_cache_hit_tokens — توكنات الإدخال التي وُجدت في الذاكرة المؤقتة
• prompt_cache_miss_tokens — توكنات الإدخال التي لم توجد

لنفترض أن تذكرة الدعم الأولى تعود بـ prompt_cache_hit_tokens: 0 وprompt_cache_miss_tokens: 3200، وأن تذكرة بعد دقيقة تُظهر prompt_cache_hit_tokens: 3000 وprompt_cache_miss_tokens: 200. لقد أُعيد استخدام الـ 3,000 توكن من القواعد؛ ولم يُقرأ من الصفر سوى رسالة العميل الجديدة وبضعة توكنات. إذا بقي رقم الإصابة صفرًا في كل استدعاء، فانظر إلى بداية طلبك: هناك شيء ما يتغيّر فيها.

تعمل Anthropic بشكل مختلف، لأنك تحدد ما يجب تخزينه مؤقتًا. تضيف cache_control من النوع ephemeral إلى الطلب أو إلى كتلة محتوى:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

وفقًا لوثائق التخزين المؤقت للمطالبات الخاصة بـ Anthropic (تم التحقق منها في 24 أكتوبر 2026)، تُبلّغ الإجابة عن ثلاثة أرقام: cache_creation_input_tokens (كُتب في الذاكرة المؤقتة الآن)، وcache_read_input_tokens (قُرئ منها)، وinput_tokens (ما جاء بعد آخر نقطة توقف للتخزين المؤقت). لنفترض أن الاستدعاء الأول يُظهر cache_creation_input_tokens: 10000، cache_read_input_tokens: 0؛ والثاني يُظهر 0 و10000. هذا كتابة في الذاكرة المؤقتة تتبعها قراءة منها.

هناك فخ واحد على الشاشة. المطالبات الأقصر من الحد الأدنى للنموذج (512 أو 1,024 أو 4,096 توكن، حسب النموذج) تُعالَج دون تخزين مؤقت ودون خطأ. سترى أصفارًا في حقلَي الذاكرة المؤقتة دون أي تحذير. العمر الافتراضي 5 دقائق، ويُجدَّد مجانًا عند كل استخدام؛ وttl اختياري بقيمة 1h يبقيه مدة أطول.

ما الذي يفعله بفاتورتك#

يغيّر التخزين المؤقت سعر الجزء المتكرر، لذا يستحق الحساب مرة واحدة. تسرد Anthropic معاملات ضرب على سعر الإدخال الأساسي: كتابة في الذاكرة المؤقتة بعمر 5 دقائق تكلف 1.25×، والقراءة تكلف 0.1× (0.05× لـ Opus 5.5 وSonnet 5.5). خذ بادئة من 10,000 توكن يُعاد استخدامها في 20 طلبًا خلال نافذة الـ 5 دقائق، باستخدام قراءة 0.1× القياسية:

10,000 × 20 = 200,000 توكن بالسعر الأساسي دون تخزين مؤقت

10,000 × 1.25 = 12,500 للطلب الأول الذي يكتب الذاكرة المؤقتة

19 × 10,000 × 0.1 = 19,000 للطلبات الـ 19 التي تقرأ منها

12,500 + 19,000 = 31,500 مكافئ توكن مع التخزين المؤقت

إذن يكلّف الجزء المتكرر أقل بكثير من خُمس المبلغ غير المخزَّن. المفارقة: إذا انقضت الـ 5 دقائق بين الطلبات، يكتب الطلب التالي الذاكرة المؤقتة من جديد بمعامل 1.25×، وقد تنتهي بادئة نادرة الاستخدام إلى تكلفة أعلى من عدم التخزين المؤقت إطلاقًا.

الآن الروبوت من البداية، كخط أساس بسيط بالسعر الكامل. 2,000 طلب يوميًا، و3,000 توكن إدخال وحوالي 300 توكن إخراج لكل طلب:

2,000 × 3,000 = 6,000,000 توكن إدخال يوميًا

2,000 × 300 = 600,000 توكن إخراج يوميًا

يسعّر الجدول عبء عمل ذلك اليوم على كل نموذج متاح في CheapTokens إلى جانب OpenRouter:

DeepSeek-V4-Flash أرخص من OpenRouter إجمالًا، مع احتساب الإدخال والإخراج معًا، وعبء العمل يتسع بسهولة: سياق 380K وما يصل إلى 32,768 توكن إخراج لكل إجابة. هذه تكلفة عبء العمل بالسعر الكامل: توكنات الإدخال × السعر لكل توكن. البادئة الطويلة الثابتة هي حيث تكون حصة الإدخال هذه أكبر.

جرّبه بنفسك في خمس دقائق#

الخطة: أرسل مطالبة النظام الطويلة نفسها مرتين بأسئلة مختلفة وانظر إلى usage. ضع نص قواعدك الخاص في support_rules.txt (صفحة أو صفحتان من النص تكفي). نقطة النهاية هي CheapTokens API المتوافقة مع OpenAI، ويمكنك أخذ المفتاح من حسابك.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

ما يجب فحصه في المخرجات: prompt_tokens يخبرك بحجم طلبك. يحمل الطلبان نص SYSTEM نفسه، لذا يتكرر معظم ذلك الرقم من طلب إلى آخر — تقريبًا بحجم ملف قواعدك. تلك البداية المتكررة هي الجزء الذي يستطيع مزوّد يدعم التخزين المؤقت، مثل DeepSeek API أو Anthropic أعلاه، إعادة استخدامه. الآن تمرين على الترتيب: أضف سطرًا بالوقت الحالي (datetime.now()) في أعلى SYSTEM وشغّل مرة أخرى. لم يعد الطلبان يتشاركان بداية، لأنهما يختلفان من السطر الأول نفسه. ضع السطر نفسه في نهاية المطالبة وتعود البداية المشتركة.

قائمة تحقق قصيرة لمطالباتك الخاصة:

1. النص الثابت أولًا: التعليمات، والقواعد، وتعريفات الأدوات، والأمثلة.
2. النص المتغيّر أخيرًا: التاريخ، واسم المستخدم، وأحدث رسالة.
3. أبقِ البادئة مطابقة بايتًا ببايت — حتى مسافة إضافية تُحتسب.
4. تحقق من الحد الأدنى لحجم المزوّد قبل أن تتساءل لماذا لم يُخزَّن شيء مؤقتًا.
5. انظر إلى حقول usage بعد التغيير، لا قبله.

لتسعير عبء عملك الخاص، افتح صفحة التسعير وأدخل أحجام الإدخال والإخراج لديك، أو ابدأ من صفحة DeepSeek. بمجرد أن يعمل الطلب الأول، يستغرق التقدير نفسه دقيقة لأي مطالبة تكتبها. لمعرفة تكلفة جانبي الطلب، راجع توكنات الإدخال مقابل الإخراج.