التخزين المؤقت للموجّهات مقابل التخزين المؤقت الدلالي: ما الذي يوفّره كل منهما

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

باختصار. يمنح التخزين المؤقت للموجّهات خصمًا على بداية الموجّه المتكررة، مثل موجّه نظام طويل، لكن النموذج يعمل رغم ذلك وتدفع ثمن كل رمز إخراج. أما التخزين المؤقت بالتطابق التام والتخزين الدلالي فيلغيان الاستدعاء كليًا حين يكون السؤال قد أُجيب عنه من قبل. في اختبارنا على 3,000 طلب، مع تفعيل التخزين المؤقت للموجّهات لدى المزوّد أصلًا، خفّضت إضافة HotKV أمام النموذج استدعاءاته ورموزه وتكلفته بنحو 70%، لأن رموز الإخراج ظلت تمثل ما بين 73% و92% من تكلفة خط الأساس.

كيف يعمل التخزين المؤقت للموجّهات

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

ما الذي يُخزَّن

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

لا تُخزَّن الموجّهات الأقصر من حد أدنى معين، ولا يُعاد أي خطأ. وفي نماذج Claude الحالية التي استخدمناها، وهي Fable 5.1 وOpus 5.5 وSonnet 5.5 وHaiku 5.5، الحد الأدنى الموثَّق هو 512 رمزًا. وتُعزل المدخلات المخزنة لكل مؤسسة، ولكل مساحة عمل في Claude API.

كم يكلّف

مدة الصلاحية الافتراضية خمس دقائق، وكل استخدام للمدخل يجددها دون رسوم إضافية. وتتوفر مدة ساعة واحدة. تبلغ كلفة كتابة المدخل 1.25 ضعف سعر الإدخال الأساسي لمدة الخمس دقائق، و2 ضعف لمدة الساعة. وتبلغ كلفة قراءته 0.1 من سعر الإدخال الأساسي في معظم النماذج، و0.05 في Opus 5.5 وSonnet 5.5، و0.025 في Fable 5.1، بحسب صفحة الأسعار. وهذه المعاملات تتغير، فاقرأ الصفحة الحالية قبل أن تجري أي حساب.

ما لا يستطيع التخزين المؤقت للموجّهات إلغاءه

يخفّض التخزين المؤقت للموجّهات سعر قراءة البادئة. لكنه لا يتجاوز النموذج. فكل طلب ما زال يولّد إجابة جديدة، وما زلت تنتظرها، ويُحاسَب كل رمز إخراج بسعر الإخراج الكامل.

يوضح اختبارنا مدى أهمية ذلك. أرسلنا 3,000 سؤال دعم عملاء إلى كل نموذج من أربعة نماذج Claude، مع سياسة من 2,200 رمز بوصفها موجّه النظام، والتخزين المؤقت لدى المزوّد مفعّلًا. كانت قراءات الذاكرة المؤقتة لتلك السياسة تمثل ما بين 90% و93% من الرموز المحتسبة. أما الإخراج فلم يتجاوز 6% إلى 9% من الرموز، ومع ذلك مثّل 73% إلى 92% من تكلفة خط الأساس. كانت البادئة رخيصة أصلًا، فبقي الإنفاق في الإجابات.

وهذه هي الفجوة التي تملؤها الطبقات الأخرى. تجد المنهجية الكاملة والنتائج في اختبار توفير الرموز.

التخزين المؤقت للاستجابات بالتطابق التام والدلالي

تجيب طبقتان عن الطلب من الذاكرة. وتختلفان في كيفية الحكم بأن طلبًا جديدًا يطابق طلبًا قديمًا.

التخزين المؤقت للاستجابات بالتطابق التام

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

في تشغيلنا، أجابت الذاكرة المؤقتة بالتطابق التام عن نحو 39% من الطلبات. وعاد السؤال المكرر بوسيط يبلغ نحو 0.05 ms. وقد قيس ذلك بعميل Python عبر الحلقة المحلية (loopback) على الجهاز نفسه، فاقرأه بوصفه رقمًا محليًا لا رقم شبكة. استخدم الاختبار GET وSET العاديين لهذه الطبقة. ولدى HotKV Enterprise أيضًا ذاكرة موجّهات مخصصة بالتطابق التام هي PCACHE.*، مع حدود لكل مساحة أسماء وتتبّع للتكلفة.

لا ترى هذه الطريقة اختلاف الصياغة. فـ "How do I reset my password?" و"I forgot my password" مفتاحان مختلفان.

التخزين المؤقت الدلالي

تبحث الذاكرة المؤقتة الدلالية عن معنى السؤال. تحوّل السؤال إلى تضمين، وتجد أقرب سؤال مخزن، وتعيد إجابته إذا تجاوز تشابه جيب التمام عتبة معينة. وهي في HotKV SCACHE.*، المبنية على فهرس المتجهات نفسه الذي يقوم عليه البحث المتجهي.

أُجيب عن نحو 31% من طلباتنا بهذه الطريقة. واستغرقت إعادة الصياغة وسيطًا يبلغ نحو 130 ms، وأغلبه استدعاء خدمة التضمين، فالإصابة الدلالية أسرع بكثير من استدعاء النموذج لكنها ليست فورية. ولو لم توجد الطبقة الدلالية، لاحتاجت الذاكرة بالتطابق التام وحدها إلى 1,264 استدعاءً للنموذج على الأكثر من أصل 3,000، أي أقل بنحو 58%. وقد رفعت الطبقة الدلالية التوفير إلى نحو 70%.

وفيها أيضًا يكمن الخطر. فالسؤال المشابه ليس دائمًا السؤال نفسه. جعلنا نموذج Claude ثانيًا يقيّم كل إصابة دلالية مقابل إجابة جديدة. وعند عتبتنا الافتراضية 0.81، كانت الإجابات المخزنة تلائم السؤال الفعلي بمعدل أقل من الجديدة بفارق يتراوح بين 5.8 و10.7 نقطة مئوية. وفي Sonnet 5.5، لم تُظهر العتبات 0.88 وما فوقها عجزًا من هذا النوع، بأدلة ضعيفة. أما الأسئلة التي كُتبت لتختلف بتفصيل حاسم واحد فقد طابقت بنسبة 62% عند 0.81 وبنسبة 10% عند 0.95.

التخزين المؤقت للموجّهات مقابل التخزين المؤقت الدلالي جنبًا إلى جنب

التخزين المؤقت للموجّهات لدى المزوّد والتخزين المؤقت للاستجابات ليسا بديلين. أحدهما يخفض سعر الاستدعاءات التي ما زلت تجريها، والآخر يخفض عددها.

ما يفعله التخزين المؤقت بزمن الاستجابة

تجاوز النموذج يغيّر سرعة وصول الإجابات كما يغيّر كلفتها. في تشغيلنا انخفض الوسيط لزمن الوصول إلى إجابة كاملة من 2.7 ثانية إلى 127 ms على Fable 5.1، ومن 2.9 ثانية إلى 126 ms على Opus 5.5، ومن 1.8 ثانية إلى 128 ms على Sonnet 5.5، ومن 1.4 ثانية إلى 125 ms على Haiku 5.5. أي أسرع بما بين 11 و23 مرة عند الوسيط.

أما الطرف البطيء فلم يتحرك إلا قليلًا. فنحو 30% من الطلبات ما زالت تصل إلى النموذج، وكان المئين 99 على Fable 5.1 نحو 6.4 ثانية مع HotKV مقابل 6.6 ثانية بدونه. تزيل الذاكرة المؤقتة الانتظار عن الطلبات التي تجيب عنها ولا تفعل شيئًا لتلك التي تخفق فيها. فإذا كانت شكواك من أسوأ حالة بطيئة لا من الحالة المعتادة، فلن يحلها التخزين المؤقت وحده.

هذه أزمنة الوصول إلى الإجابة الكاملة، لأن الاستدعاءات لم تُبث. والإجابة المبثوثة تُظهر كلماتها الأولى أبكر. فالفجوة في نافذة الدردشة أصغر من الفجوة في هذه الأرقام.

اختيار الطبقة لحركة طلباتك

تعتمد الطبقة المناسبة على كيفية تكرار طلباتك، ويمكنك قياس ذلك قبل أن تبني أي شيء.

طابق الطبقة مع حركة الطلبات

طابق الطبقة مع كيفية تكرار طلباتك.

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

يتبع التوفير التكرار. فحين جعلنا كل نية متساوية الاحتمال بدلًا من انحراف Zipf، انخفضت التكلفة بنسبة 56% على النموذجين اللذين أعدنا تشغيلهما، ومع 3,000 سؤال مختلف كليًا انخفضت بنسبة 38%. وعبء العمل الذي لا يتضمن أسئلة مكررة أو متشابهة لا يوفّر شيئًا.

قِس تكرار طلباتك أولًا

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

from collections import Counter

def normalise(question: str) -> str:
    return " ".join(question.lower().split())

counts = Counter(normalise(q) for q in logged_questions)
repeat_share = 1 - len(counts) / sum(counts.values())

repeat_share هي نسبة الطلبات التي كانت ستجيب عنها ذاكرة بالتطابق التام بعد أن ترى كل سؤال مرة أولى. وكانت مجموعة الاختبار لدينا تضم 1,264 سؤالًا مختلفًا بين 3,000 طلب، فكانت النسبة نحو 58%. وإذا خرجت نسبتك قرب 5%، فلن تفيد الذاكرة بالتطابق التام كثيرًا، ولن تساعد إلا الطبقة الدلالية.

وهناك تحفظان. الذاكرة المؤقتة تبدأ فارغة، فتصل الطلبات الأولى إلى النموذج دائمًا. وفي تشغيلنا، قُدّم نحو 52% من أول ألف طلب من الذاكرة المؤقتة ونحو 81% من آخر ألف. كما أن سجل حركة الشهر الماضي يحدثك عن الشهر الماضي. وإذا كنت على وشك إطلاق ميزة تغيّر ما يسأل عنه الناس، فاعتبر الرقم دليلًا تقريبيًا.

الجمع بين الطبقات

ينبغي أن يمر الطلب عبر الطبقات من الأرخص والأكثر أمانًا إلى الأعلى كلفة، وأن تستطيع رؤية ما وفّرته كل طبقة.

ترتيب البحث

الترتيب مهم. افحص الطبقة الأرخص والأكثر أمانًا أولًا، ولا تستدعِ النموذج إلا حين تخفق كل الطبقات. يفترض هذا المثال عميلًا على نمط redis-py مع decode_responses=True، ومساحتي أسماء أُنشئتا مسبقًا، ودالتي embed وllm الخاصتين بك.

def answer(question: str) -> str:
    if hit := r.execute_command("PCACHE.GET", "answers_exact", question):
        return hit                                   # same words

    vector = embed(question)
    hit = r.execute_command("SCACHE.GET", "answers_semantic", *vector, "THRESHOLD", 0.90)
    if hit:
        return hit[0]                                # same meaning

    reply = llm.complete(question)                   # provider prompt caching applies here
    r.execute_command("PCACHE.SET", "answers_exact", question, reply, "TTL", 3600)
    r.execute_command("SCACHE.SET", "answers_semantic", question, reply, *vector, "TTL", 3600)
    return reply

أنشئ مساحتي الأسماء مرة واحدة بالأمرين PCACHE.CREATE answers_exact وSCACHE.CREATE answers_semantic 1536 THRESHOLD 0.90، مع استخدام بُعد نموذج التضمين الذي تعتمده. وتأتي مجموعة أوامر الذكاء الاصطناعي مع مثيلات HotKV Cloud من خطتي Performance وScale، وتسرد صفحة الذكاء الاصطناعي ما يفعله كل محرك. وتبيّن صفحة الأسعار ما تتضمنه كل خطة.

متابعة النتائج في الإنتاج

الذاكرة المؤقتة التي لا تراها لا يمكنك الوثوق بها. يحتفظ HotKV بعدّاد إصابات وإخفاقات لكل مساحة أسماء. وإذا خزّنت استهلاك الرموز في الاستدعاء الأصلي مع كل مدخل، فيستطيع أيضًا أن ينسب الرموز والتكلفة التي تجنّبتها كل إصابة لاحقة. وتحمل ردود PCACHE.STATS وSCACHE.STATS حينئذٍ حقولًا مثل usage_saved_requests وusage_saved_input_tokens وusage_saved_cost_usd.

PCACHE.SET answers_exact "How do I reset my password?" "Open Settings ..." MODEL <model> INPUT 100 OUTPUT 180 CACHEREAD 2200

استبدل <model> بمعرّف نموذجك. يحتسب INPUT رموز الموجّه غير المخزنة مؤقتًا، ويحتسب CACHEREAD الرموز التي قدّمها المزوّد من ذاكرته المؤقتة، فلا يتداخلان. ويجب أن يكون النموذج في جدول أسعار HotKV كي يكون لحقل التكلفة معنى. يعرض LLMSTATS.PRICE LIST النماذج المعروفة، ويضيف LLMSTATS.PRICE SET نموذجك الخاص. أما النموذج الذي لا سعر له فتُحتسب رموزه مع ذلك، لكن تكلفته تُسجَّل صفرًا، ويبيّن عدّاد منفصل أن طلبات بقيت بلا تسعير.

تخفّض الذاكرة المؤقتة الإنفاق، وتضع الميزانية سقفًا لما تبقّى. يحدد LLMBUDGET.SET حدًّا من الرموز والدولارات على نافذة زمنية. ويُفحص LLMBUDGET.CONSUME قبل استدعاء النموذج، فيُوقَف الوكيل الخارج عن السيطرة قبل أن ينفق المال لا بعده. ويحتفظ LLMSTATS.RECORD بإجماليات لكل مستأجر تفهم رموز قراءة الذاكرة المؤقتة وكتابتها لدى المزوّد. وتستخدم الثلاثة جدول أسعار واحدًا عند تمرير اسم النموذج، فلا يمكن أن يختلف رقم التوفير والميزانية ولوحة المتابعة.

أخطاء تجعل الذاكرة المؤقتة تعيد إجابات خاطئة

تأتي معظم الإصابات السيئة من مفتاح ينقصه شيء. ضع النموذج وإصدار الموجّه وإصدار أي أداة أو سياسة في مفتاح التطابق التام، كي لا يستطيع تغيير في الموجّه تقديم إجابات كُتبت للإصدار القديم.

امنح المدخلات مدة صلاحية تناسب سرعة تغيّر حقائقك. وافصل المستأجرين بمساحات أسماء منفصلة حتى لا تُعرض إجابة عميل على عميل آخر. ولا تخزّن أبدًا إجابة تحتوي على بيانات شخصية ما لم يتضمن المفتاح صاحب تلك البيانات.

وأخيرًا، قِس على حركة طلباتك أنت. فأرقامنا من مجموعة بيانات عامة واحدة من الأسئلة المصرفية القصيرة، وسياسة خيالية، وتشغيل واحد لكل حالة، وهي ليست وعدًا بعبء عملك.

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