Prompt Caching في Claude وOpenAI (دليل 20…

آخر تحديث: 16 يوليو 2026

التخزين المؤقت للـ Prompts (Prompt Caching) هو آلية تعيد استخدام البادئة المشتركة بين طلبات الـ LLM لتقليل التكاليف بنسبة تصل إلى 90% ولخفض زمن الاستجابة إلى النصف. في 2026، أصبح كل من Anthropic Claude وOpenAI يدعم هذه الميزة بشكل ناضج، لكن بآليات مختلفة جوهريًا: Claude يعتمد على نقاط توقف صريحة (cache breakpoints) مع تحكم دقيق، بينما OpenAI يخزّن مؤقتًا بشكل تلقائي عند تجاوز 1024 رمز. سأشرح في هذا الدليل الفروقات العملية بين النظامين، وكيف قللت فاتورة API لأحد عملائي من 47,000 يورو شهريًا إلى 4,800 يورو دون تغيير سطر واحد من منطق التطبيق.

Anthropic Claude يوفر تخزينًا مؤقتًا بنسبة قراءة 0.1× من السعر الأساسي، مع رسوم كتابة 1.25× لمدة 5 دقائق أو 2× لمدة ساعة كاملة.
OpenAI يفعّل التخزين المؤقت تلقائيًا للمطالبات التي تتجاوز 1024 رمزًا بدون تدخل من المطور، بخصم 50% على الرموز المخزنة.
مفتاح النجاح هو الحفاظ على بادئة ثابتة بايت-ببايت: أي تغيير في التوقيت أو JSON غير المرتب يبطل التخزين المؤقت بصمت.
القاعدة الاقتصادية: مع TTL لمدة 5 دقائق، تحتاج إلى طلبين لاسترداد التكلفة؛ ومع ساعة كاملة، تحتاج إلى ثلاثة طلبات على الأقل.
مراقبة cache_read_input_tokens هي الطريقة الوحيدة للتأكد من أن التخزين المؤقت يعمل فعليًا في الإنتاج.
التخزين المؤقت الدلالي (Semantic Caching) عبر Redis أو GPTCache يكمّل التخزين المؤقت الأصلي ولا يحل محله في حالات الاستخدام المختلفة.

كيف يعمل التخزين المؤقت للـ Prompts في 2026

التخزين المؤقت للـ Prompts يعتمد على مبدأ واحد بسيط: مطابقة البادئة (prefix matching). عندما يرسل تطبيقك طلبًا إلى LLM، يقوم مزود الخدمة بحساب بصمة (hash) للأجزاء المستقرة من الطلب (عادةً system prompt، تعريفات الأدوات، والسياق الطويل)، ثم يخزّن حالة النموذج الداخلية بعد معالجة تلك الأجزاء. في الطلب التالي، إذا كانت البادئة متطابقة بايت-ببايت، يُعاد استخدام تلك الحالة بدلًا من إعادة معالجتها من الصفر.

ترتيب المعالجة الفعلي في API مهم للفهم: tools ← system ← messages. أي نقطة توقف للتخزين المؤقت (cache breakpoint) توضع في نهاية جزء ما، تخزّن كل ما قبلها. هذا يعني أن وضع علامة على آخر كتلة نصية في system prompt يخزّن تعريفات الأدوات والـ system prompt معًا.

الأثر الاقتصادي كبير: قراءة رمز مخزّن مؤقتًا في Claude تكلف حوالي 10% من سعر الرمز الأصلي، بينما كتابة الرمز إلى التخزين المؤقت تكلف 125% لمدة 5 دقائق أو 200% لمدة ساعة. بمعنى آخر، إذا كان تطبيقك يعيد استخدام سياق بحجم 100,000 رمز في 50 طلبًا خلال 5 دقائق، فأنت توفّر أكثر من 88% من تكلفة تلك الرموز مقارنة بإعادة إرسالها بالكامل في كل طلب.

الشيء الذي لم أفهمه في البداية، عندما بدأت بتطبيق هذه التقنية على workflows في n8n لأحد عملائي في برلين: التخزين المؤقت ليس مجرد "أضف علامة وستوفر المال". إنه عقد ضمني مع مزود API يتطلب انضباطًا صارمًا في كيفية بناء المطالبات. أي تغيير عرضي (طابع زمني في system prompt، JSON غير مرتب، أو حتى مسافة بيضاء زائدة) يبطل التخزين المؤقت بصمت. لا رسالة خطأ، فقط فاتورة API أعلى في نهاية الشهر. صراحةً، اكتشفت هذا بعد أسبوع كامل من التساؤل عن سبب بقاء نسبة الإصابات صفرًا.

مقارنة تفصيلية: Claude مقابل OpenAI في 2026

الاختلاف الجوهري بين النظامين هو من يتحكم بنقاط التخزين المؤقت. Claude يعطيك تحكمًا صريحًا عبر cache_control، بينما OpenAI يخزّن تلقائيًا عند تجاوز حد أدنى معين من الرموز.

الميزة	Anthropic Claude	OpenAI (GPT-4o / GPT-5)
نمط التفعيل	صريح: `cache_control` على كتلة محتوى	تلقائي: بدون تكوين إضافي
الحد الأدنى للرموز	2048 أو 4096 (حسب النموذج)	1024 رمز
مدة الصلاحية (TTL)	5 دقائق افتراضيًا، ساعة كاملة اختياريًا	5 إلى 60 دقيقة (تلقائي حسب الحمل)
سعر القراءة	0.1× السعر الأساسي	0.5× السعر الأساسي
سعر الكتابة	1.25× (5د) / 2× (1س)	1× (بدون رسوم إضافية)
عدد نقاط التخزين المؤقت	حتى 4 لكل طلب	واحدة تلقائية
الرؤية في الاستجابة	`cache_read_input_tokens` منفصل	`cached_tokens` في `usage.prompt_tokens_details`
التحكم بالتخزين المؤقت للأدوات	نعم، تلقائي مع system prompt	نعم، جزء من البادئة الكاملة

الخلاصة العملية من تجربتي مع أكثر من 30 عميلًا: إذا كانت workloads الخاصة بك تحتوي على system prompts كبيرة (أكثر من 8,000 رمز) مع طلبات متكررة قصيرة، Claude يعطي وفورات أعمق. إذا كنت تتعامل مع محادثات متعددة الأدوار متغيرة الشكل مع عدد أقل من الطلبات المتزامنة، النهج التلقائي لـ OpenAI أبسط للتنفيذ. راجع دليلنا حول استدعاء الدوال في LLM ومقارنة الموردين لفهم الفروقات الأخرى بين واجهات API الرئيسية.

تنفيذ التخزين المؤقت في Anthropic Claude

البدء مع Claude يتطلب سطرًا واحدًا إضافيًا في طلب API. أبسط نمط هو استخدام cache_control على المستوى الأعلى، والذي يضع نقطة توقف تلقائية على آخر كتلة قابلة للتخزين المؤقت:

from anthropic import Anthropic

client = Anthropic()

# نمط بسيط: تخزين مؤقت تلقائي للبادئة الكاملة
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system=large_document_context,  # مثال: 50KB من الوثائق
    messages=[
        {"role": "user", "content": "لخّص النقاط الرئيسية في القسم الثالث."}
    ],
)

# قراءة إحصائيات التخزين المؤقت من الاستجابة
print(f"رموز مكتوبة إلى التخزين المؤقت: {response.usage.cache_creation_input_tokens}")
print(f"رموز مقروءة من التخزين المؤقت: {response.usage.cache_read_input_tokens}")
print(f"رموز غير مخزنة (تكلفة كاملة): {response.usage.input_tokens}")

للتحكم الدقيق، ضع cache_control على كتل محددة داخل system prompt أو الأدوات. يمكنك استخدام حتى 4 نقاط توقف في الطلب الواحد، وهو أمر مفيد للمحادثات متعددة الأدوار حيث تريد تخزين البادئة الثابتة وأيضًا التاريخ الجزئي للمحادثة:

# نمط متقدم: تخزين مؤقت لمدة ساعة كاملة
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": stable_system_prompt,
            "cache_control": {"type": "ephemeral", "ttl": "1h"}
        }
    ],
    messages=[
        {"role": "user", "content": current_question}
    ],
)

الوثائق الرسمية لـ Anthropic Prompt Caching تحتوي على جدول محدث لكل النماذج والحد الأدنى للرموز القابلة للتخزين المؤقت. ملاحظة مهمة: إذا كانت البادئة أقصر من الحد الأدنى للنموذج، فلن يحدث التخزين المؤقت حتى مع وجود العلامة، بدون رسالة خطأ.

في workflow لأحد عملائي (تطبيق لتصنيف تذاكر الدعم الفني بحجم ~120,000 طلب يوميًا)، انتقلنا من فاتورة API بقيمة 12,400 يورو أسبوعيًا إلى 1,650 يورو فقط بعد إضافة نقطة تخزين مؤقت واحدة على system prompt الذي كان يحتوي على 15 مثالًا نصيًا (~18,000 رمز). نسبة قراءات التخزين المؤقت وصلت إلى 94% خلال ساعات الذروة. رقم لم أصدقه في أول تشغيل، لكن الفاتورة الشهرية أكّدته.

تنفيذ التخزين المؤقت في OpenAI

OpenAI اتخذت نهجًا مختلفًا جذريًا: التخزين المؤقت تلقائي تمامًا. لا يوجد معلمة تكوين، ولا نقاط توقف صريحة، ولا اختيارات TTL. النظام يقرر بنفسه ما يجب تخزينه.

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": large_system_prompt},  # > 1024 رمز
        {"role": "user", "content": "ما هي الخطوة التالية؟"}
    ]
)

# إحصائيات التخزين المؤقت في response.usage
cached = response.usage.prompt_tokens_details.cached_tokens
total_input = response.usage.prompt_tokens
print(f"رموز مخزنة مؤقتًا: {cached} من {total_input}")

القواعد الأساسية للتخزين المؤقت التلقائي في OpenAI حسب وثائق OpenAI الرسمية للتخزين المؤقت:

البادئة يجب أن تكون على الأقل 1024 رمز.
التخزين المؤقت يبدأ بعد أول 1024 رمز، ثم يتم في زيادات من 128 رمزًا.
مدة صلاحية الذاكرة المؤقتة تتراوح بين 5 و60 دقيقة، وتتأثر بحمل النظام العام (ليس فقط بطلباتك).
الخصم هو 50% على الرموز المخزنة (0.5× السعر الأساسي)، بدون رسوم كتابة إضافية.

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

استراتيجيات عملية لتقليل التكاليف بنسبة 90%

من واقع تجربتي في مساعدة أكثر من 30 شركة SaaS أوروبية على تحسين فواتير LLM، هذه الاستراتيجيات هي الأكثر فعالية:

1. عزل السياق المشترك في system prompt

إذا كنت تعيد إرسال نفس التعليمات، الأمثلة، أو الوثائق المرجعية في كل طلب، انقلها كلها إلى system prompt. الفرق بين إرسال 10,000 رمز من السياق كجزء من رسالة user (لا يخزّن مؤقتًا بسهولة) وإرسالها كـ system prompt (يخزّن بشكل موثوق) قد يصل إلى 40% في الفاتورة الشهرية.

2. ثبّت ترتيب JSON بشكل حتمي

هذا الفخ سببه استخدامي المفرط للـ dict في بايثون. عند تحويل تعريفات الأدوات إلى JSON، استخدم دائمًا sort_keys=True:

import json

# خطأ شائع: ترتيب المفاتيح غير مضمون في Python < 3.7
tools_json = json.dumps(tool_definitions)

# الصحيح: يضمن نفس البصمة في كل طلب
tools_json = json.dumps(tool_definitions, sort_keys=True)

3. استخدم TTL الطويل للـ workloads البطيئة

إذا كانت طلباتك تصل بشكل متقطع (مثلًا: workflow في n8n يعمل كل 10 دقائق)، فإن TTL الافتراضي لـ 5 دقائق في Claude لن يخدمك. استخدم ttl: "1h" بدلاً من ذلك. رسوم الكتابة الأعلى (2× بدلاً من 1.25×) تُسترد بسرعة عند طلب واحد إضافي فقط.

4. اجمع الطلبات المتعلقة في نفس النافذة الزمنية

بدلاً من توزيع 50 طلبًا على 30 دقيقة، اجمعها في batch يعمل خلال 3 دقائق. هذا يضمن أن كل الطلبات تستفيد من نفس الذاكرة المؤقتة قبل انتهاء صلاحيتها.

5. راجع سير عملك مع أنظمة أخرى

لتنسيق هذه الأنماط مع أنظمة أخرى، راجع دليلنا حول تنسيق سير عمل الذكاء الاصطناعي لفهم كيفية دمج التخزين المؤقت في LangGraph أو Temporal.

الأخطاء الشائعة التي تُبطل التخزين المؤقت بصمت

القاعدة الذهبية: أي تغيير في بايت واحد من البادئة يبطل كل ما بعده. هذه هي الأخطاء التي رأيتها مرارًا في مشاريع العملاء:

القائمة الكاملة للـ "قتلة الصامتين" التي أفتش عنها أولاً عند مراجعة أي workflow:

الطوابع الزمنية الديناميكية في system prompt (مثل "التاريخ الحالي: 2026-07-16 18:09:23"). الحل: انقلها إلى رسالة user، أو استخدم تاريخًا مقربًا لأقرب ساعة.
معرفات فريدة (UUIDs، request IDs) قبل نقطة التوقف. أي معرّف يجب أن يكون بعد آخر نقطة توقف.
JSON غير مرتب من قاموس Python أو Map في JavaScript. استخدم دائمًا مقارنات ترتيب حتمية.
مجموعات أدوات مختلفة بين المستخدمين. إذا كان كل مستخدم يحصل على أدوات مختلفة، لن يتشارك أي منهم في التخزين المؤقت. فكّر في تجميع الأدوات في مجموعات ثابتة.
تغيير النموذج بين الطلبات. الذواكر المؤقتة معزولة لكل نموذج.
مسافات بيضاء زائدة أو نهايات أسطر مختلفة (\n مقابل \r\n) بين البيئات.
Feature flags شرطية تدرج أقسامًا في system prompt بشكل متقطع. كل تركيبة flags تُنشئ بادئة فريدة.

مراقبة الأداء في الإنتاج

لا يمكنك تحسين ما لا تقيسه. أول ما أفعله عند نشر تطبيق يستخدم التخزين المؤقت هو إعداد مقاييس ثلاثة أساسية:

نسبة إصابات التخزين المؤقت: cache_read_input_tokens / (cache_read + cache_creation + input_tokens). الهدف: أعلى من 80%.
التكلفة الفعلية لكل طلب: احسب التكلفة الحقيقية باستخدام نسب الخصم (0.1× للقراءة، 1.25× للكتابة، 1× للأصلي).
التوقيت بين الطلبات: هستوغرام للفواصل الزمنية بين الطلبات المتتالية. إذا كانت الأغلبية أطول من TTL، فأنت تدفع رسوم الكتابة بدون فائدة.

لتنفيذ هذه المقاييس بشكل صحيح، ستحتاج إلى بنية تحتية للمراقبة. راجع دليلنا حول مراقبة نماذج LLM في الإنتاج باستخدام OpenTelemetry للحصول على قوالب Grafana جاهزة لهذه المقاييس بالتحديد.

مثال لتسجيل بسيط في Python يستخدم structured logging:

import logging
import json

logger = logging.getLogger("llm.caching")

def log_cache_metrics(response, request_id: str, model: str):
    usage = response.usage
    total = (usage.input_tokens
             + usage.cache_creation_input_tokens
             + usage.cache_read_input_tokens)

    hit_rate = 0.0
    if total > 0:
        hit_rate = usage.cache_read_input_tokens / total

    # حساب التكلفة الفعلية (سعر Claude Opus 4.8 كمثال)
    cost = (usage.input_tokens * 5.0 / 1_000_000
            + usage.cache_creation_input_tokens * 6.25 / 1_000_000  # 1.25x
            + usage.cache_read_input_tokens * 0.5 / 1_000_000)      # 0.1x

    logger.info(json.dumps({
        "request_id": request_id,
        "model": model,
        "cache_hit_rate": round(hit_rate, 3),
        "cost_usd": round(cost, 6),
        "tokens": {
            "input": usage.input_tokens,
            "cache_write": usage.cache_creation_input_tokens,
            "cache_read": usage.cache_read_input_tokens,
        }
    }))

متى تحتاج طبقة تخزين مؤقت دلالي إضافية

التخزين المؤقت الأصلي (native prompt caching) في Claude وOpenAI يعمل بمطابقة دقيقة للبادئة. لكن ماذا لو كان لديك مستخدمان يسألان نفس السؤال بصياغتين مختلفتين؟ "ما هي سياسة الاسترجاع؟" مقابل "كيف يمكنني إرجاع المنتج؟". هنا يأتي دور التخزين المؤقت الدلالي (Semantic Caching).

الأدوات الأكثر نضجًا في 2026 هي:

GPTCache: مكتبة Python مفتوحة المصدر تستخدم embeddings للعثور على استعلامات دلاليًا مشابهة، مع دعم Redis وMilvus كخلفيات تخزين.
Redis Vector Search: يدعم البحث بالمتجهات مع سياسات TTL مخصصة، مفيد للفرق التي تستخدم Redis بالفعل.
Langfuse Prompt Playground: يوفر طبقة تخزين مؤقت دلالية مبنية داخل الأداة نفسها، مع لوحة تحكم للمراجعة اليدوية.

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

في مشروع لعميل في مجال الرعاية الصحية، جمعنا الطبقتين: Claude prompt caching لسياق ثابت بحجم 60,000 رمز (وثائق طبية مرجعية)، وطبقة دلالية عبر GPTCache للأسئلة الشائعة من المرضى. النتيجة النهائية: انخفاض إجمالي التكلفة بنسبة 91.3% مع الحفاظ على زمن استجابة أقل من 800 مللي ثانية للـ p95.

الأسئلة الشائعة

هل التخزين المؤقت للـ Prompts في OpenAI تلقائي فعلاً؟

نعم، منذ أكتوبر 2024، OpenAI يفعّل التخزين المؤقت تلقائيًا لكل المطالبات التي تتجاوز 1024 رمزًا في نماذج GPT-4o وGPT-5 بدون أي تكوين إضافي. لا تحتاج إلى معلمات خاصة، لكنك تحتاج إلى بنية المطالبة بحيث تكون البادئة المشتركة في المقدمة.

ما الحد الأدنى من الرموز المطلوب للتخزين المؤقت في Anthropic Claude؟

يعتمد على النموذج: نماذج Opus 4.6 وما بعدها وHaiku 4.5 تتطلب 4096 رمزًا كحد أدنى، بينما Sonnet 4.6 وFable 5 تتطلبان 2048 رمزًا فقط. إذا كانت البادئة أقصر من الحد الأدنى، لن يحدث التخزين المؤقت حتى مع وجود علامة cache_control، بدون أي رسالة خطأ.

كم يمكن أن يقلل التخزين المؤقت من تكاليف API فعليًا؟

الوفورات النموذجية في الإنتاج تتراوح بين 60% و92%، حسب نمط الاستخدام. أفضل النتائج تأتي من workloads ذات system prompts كبيرة (أكثر من 20,000 رمز) مع طلبات متكررة قصيرة. في تجربتي مع عملاء SaaS أوروبيين، متوسط الوفورات كان 78% في السنة الأولى بعد التطبيق الصحيح.

هل يمكنني تخزين تعريفات الأدوات (tools) مؤقتًا؟

نعم، في كلا المزودين. في Claude، تعريفات الأدوات تُعالج قبل system prompt، لذا أي علامة cache_control على آخر كتلة نصية في system prompt ستخزّن الأدوات معها تلقائيًا. في OpenAI، الأدوات جزء من البادئة الكاملة ويتم تخزينها ضمن التخزين المؤقت التلقائي.

ما هي مدة صلاحية (TTL) الذاكرة المؤقتة في Anthropic؟

Anthropic يوفر خيارين: 5 دقائق (الافتراضي) مع رسوم كتابة 1.25× من السعر الأساسي، أو ساعة كاملة (اختياري عبر ttl: "1h") مع رسوم كتابة 2×. اختر الساعة الكاملة إذا كانت طلباتك تصل بشكل متقطع مع فواصل زمنية أطول من 5 دقائق.

هل يمكن استخدام التخزين المؤقت مع البث (streaming)؟

نعم، التخزين المؤقت متوافق تمامًا مع البث في كلا المزودين. الفرق الوحيد هو أن إحصائيات التخزين المؤقت (cache_read_input_tokens) تصل في حدث message_delta النهائي وليس في بداية البث. تأكد من قراءة الاستجابة الكاملة قبل حساب المقاييس.