شرح التخزين المؤقت للموجهات (Prompt Caching): كيف يعمل، وكم يكلّف، ومتى يوفّر المال فعلًا
AI & ML
By Syed Sartaj Ahmed · 7/2/2026 · 7 min read
التخزين المؤقت للموجهات (Prompt Caching) هو تحسين في استدلال النماذج اللغوية الكبيرة يحفظ الحالة المحسوبة (KV cache) للجزء الثابت من الموجّه — موجّه النظام وتعريفات الأدوات والمستندات — بحيث تتخطى الطلبات المتكررة إعادة حسابه. النتيجة: انخفاض يصل إلى ~85% في زمن أول رمز (token) وحتى ~90% في تكلفة الإدخال المخزَّن، دون تغيير النموذج أو مخرجاته. أستخدمه في الإنتاج ضمن مساعد RAG؛ وإليك كيف يعمل، وما الذي تفعله OpenAI وAnthropic وvLLM بشكل مختلف، والأخطاء التي تقتل نسبة إصابة الكاش لديك بصمت.

ما هو التخزين المؤقت للموجهات؟
يمرّ كل طلب LLM بمرحلتين. التعبئة المسبقة (Prefill) تعالج الموجّه كاملًا بالتوازي — تقطيعه إلى رموز، وتشغيل الانتباه (attention)، وبناء KV cache (متجهات المفاتيح/القيم التي تحسبها كل طبقة لكل رمز). ثم يولّد فك الترميز (Decode) الإجابة رمزًا رمزًا. مرحلة Prefill مقيّدة بالحوسبة وتهيمن على زمن أول رمز؛ أما Decode فيعمل دائمًا.
في الوكلاء ومساعدي RAG، أكثر من 90% من كل طلب هو بادئة متطابقة: موجّه النظام نفسه، وتعريفات الأدوات نفسها، وقاعدة المعرفة نفسها — ولا يتغير سوى سؤال المستخدم. بدون التخزين المؤقت يعيد النموذج حساب كل ذلك في كل استدعاء. أما معه فيُحفظ KV cache الخاص بالبادئة ويُعاد استخدامه، فلا يعالج النموذج إلا الرموز الجديدة. وهو يسرّع Prefill فقط — فالتوليد يحدث دائمًا، ولهذا لا تتغير المخرجات.
مقارنة المزوّدين (2026)
OpenAI: تلقائي، بدءًا من 1,024 رمزًا
التخزين المؤقت لدى OpenAI تلقائي — دون تغييرات برمجية ودون رسوم إضافية. يعمل للموجهات من 1,024 رمزًا فأكثر، ويُخصم الإدخال المخزَّن حتى 90% على النماذج الحالية (رقم الـ50% المتداول هو رقم إطلاق 2024 القديم). تبقى البادئات دافئة نحو 5–10 دقائق من الخمول، ويمكن تحسين التوجيه عبر prompt_cache_key. راقب usage.prompt_tokens_details.cached_tokens للتأكد من عمله.
Anthropic (Claude): نقاط صريحة وأكبر الخصومات
التخزين لدى Claude صريح: تضع حتى 4 نقاط cache_control على الأدوات والنظام والرسائل. القراءات تُحاسب بـ 0.1× من سعر الإدخال (خصم 90%). أما الكتابة فعليها رسم إضافي — وهنا التفصيل الذي تغفله أغلب المنشورات: 1.25× لمدة البقاء الافتراضية (5 دقائق)، لكن 2× لمدة الساعة. أي أن كاش الخمس دقائق يتعادل من الطلب الثاني، بينما يحتاج كاش الساعة إلى ثلاث قراءات فأكثر ليجدي. الحد الأدنى القابل للتخزين يعتمد على النموذج (نحو 1,024–4,096 رمزًا) — والبادئات الأقصر لا تُخزَّن بصمت دون أي خطأ. راقب cache_creation_input_tokens وcache_read_input_tokens.
vLLM (الاستضافة الذاتية): تخزين تلقائي للبادئات
إذا كنت تشغّل نماذجك بنفسك، فإن التخزين التلقائي للبادئات في vLLM مفعَّل افتراضيًا في محرك V1. يجزّئ كتل KV (كل كتلة مفتاحها تجزئة الكتلة الأم + رموزها بالضبط) فوق PagedAttention، ويُخلي بأسلوب LRU، ويسرّع — ككل تخزين للموجهات — مرحلة Prefill فقط. لا خصم لكل رمز هنا لأنك تملك اقتصاديات وحدة المعالجة: المكسب هو الإنتاجية وزمن الاستجابة.
التخزين المؤقت للموجهات مقابل التخزين الدلالي
يُخلط بينهما كثيرًا وهما يحلان مشكلتين مختلفتين. تخزين الموجهات يعمل داخل الاستدلال: يطابق بادئة الرموز حرفيًا وما يزال يشغّل النموذج — إنما يتخطى إعادة حساب البادئة. أما التخزين الدلالي (Redis LangCache وGPTCache) فيعمل في طبقة التطبيق: يضمّن الأسئلة الواردة ويطابقها مع السابقة بتشابه الاتجاه (cosine)، ويعيد الإجابة المخزنة — متخطيًا استدعاء النموذج كليًا حتى مع إعادة الصياغة. وهذا أرخص كثيرًا عند الإصابة، مع خطر تقديم إجابة قديمة أو خاطئة إذا كانت عتبة التشابه فضفاضة. عمليًا يتكاملان: تخزين دلالي في الأمام، وتخزين موجهات خلفه.
كيف تحصل على إصابات كاش فعلًا (من الإنتاج)
تخزين الموجهات مطابقة حرفية للبادئة — بايت واحد متغيّر يكسر كل ما بعده. الممارسات المهمة:
- المحتوى الثابت أولًا، ومدخل المستخدم أخيرًا. موجّه النظام وتعريفات الأدوات والمستندات في الأعلى؛ وسؤال المستخدم في النهاية. إن حقنت طابعًا زمنيًا أو معرّفًا عشوائيًا في موجّه النظام فقد عطّلت الكاش للتو.
- حافظ على ثبات الموجّه بايتًا ببايت. سلسِل تعريفات الأدوات بشكل حتمي. في مساعد RAG الخاص بي تشكّل تعليمات النظام ومخططات الأدوات وهيكل المستندات البادئة المخزَّنة؛ ولا يتغير سوى نتائج الاسترجاع والسؤال.
- أصدر نسخ موجّه النظام بقرار مقصود. كل تعديل إبطال كامل للكاش — اجمع تغييراتك بدل الترقيع المستمر.
- خزّن الأشياء الكبيرة المملة. المستندات الطويلة وفهارس الأدوات الضخمة هي بالضبط حيث يتضاعف خصم الـ90%.
- قِس نسبة إصابة الكاش كمقياس منتج. يعرض OpenAI وAnthropic الرموز المخزنة لكل طلب — فعّل تنبيهات على التراجع، لأن انخفاضًا صامتًا في الإصابات هو ارتفاع صامت في التكلفة.
هل يوفّر التخزين المؤقت للموجهات المال فعلًا؟
احسبها لكل بادئة لا من صفحات التسويق. على Claude بمدة 5 دقائق: تكلف البادئة 1.25× مرة واحدة ثم 0.1× لكل قراءة — تعادل من الطلب الثاني وتوفير ~87% على إدخال البادئة بحلول الطلب العاشر. روبوت محادثة بحركة مستمرة يبقي نافذة الخمس دقائق حية إلى ما لا نهاية (كل قراءة تعيد ضبط المؤقت). أما الأحمال المتقطعة فقد تحتاج مدة الساعة — لكن بتكلفة كتابة 2× فتأكد أنك ستحصل على 3 قراءات فأكثر. وعلى OpenAI الأمر أبسط: التخزين تلقائي ومجاني، فرتّب موجهاتك له وسيظهر الخصم وحده.
أسئلة شائعة
هل يغيّر التخزين المؤقت إجابات النموذج؟
لا. متجهات KV المخزنة هي بالضبط ما كان النموذج سيحسبه — ويجري التوليد كما هو تمامًا. إنه تحسين أداء لا تغيير سلوك.
هل هو مجاني؟
على OpenAI نعم — تلقائي والخصم مشمول. على Anthropic القراءات مخفضة 90% لكن الكتابة عليها رسم 25% (5 دقائق) أو 100% (ساعة)، فيؤتي ثماره من الطلب الثاني. وعلى vLLM لا تدفع شيئًا إضافيًا — فهي أجهزتك.
لماذا نسبة إصابة الكاش لديّ منخفضة؟
غالبًا: شيء ديناميكي (طابع زمني، معرّف مستخدم، ترتيب أدوات متقلب) يقع مبكرًا في موجهك فيكسر البادئة، أو أن بادئتك أقصر من الحد الأدنى القابل للتخزين لدى المزوّد.
أبني أنظمة ذكاء اصطناعي وكيلي وRAG في الإنتاج — حيث تفصل تحسينات كهذه بين العرض التجريبي والمنتج الحقيقي. إن كنت تعمل على بنية LLM التحتية أو توظّف مهندسين مهووسين بهذه التفاصيل، لنتحدث.
Tags: Prompt caching, LLM, KV cache, OpenAI, Anthropic, vLLM, AI engineering, Semantic caching