تحسين التكلفة: التخزين المؤقت الفوري

المكاسب:

• اشرح منطق مطابقة البادئة للتخزين المؤقت السريع
• يزيد من عدد ذاكرة التخزين المؤقت عن طريق وضع السياق الثابت أولاً والسياق المتغير بعد ذلك
• يمكن حساب اقتصاديات الكتابة/القراءة في ذاكرة التخزين المؤقت ونقطة التعادل

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

كيف تعمل ذاكرة التخزين المؤقت؟ القاعدة الواحدة غير القابلة للتغيير

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

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

ترتيب المعالجة عادة ما يكون: الأدوات → موجه النظام → الرسائل. قمت بوضع نقطة التخزين المؤقت (نقطة التوقف) في نهاية القسم الثابت.

اقتصاد ذاكرة التخزين المؤقت

تحتوي ذاكرة التخزين المؤقت على ثلاث مستويات للسعر:

• كتابة ذاكرة التخزين المؤقت: التخزين لأول مرة. ~1.25x سعر الإدخال العادي (لمدة 5 دقائق للتخزين).
• قراءة ذاكرة التخزين المؤقت: القراءة على الطلبات اللاحقة. ~0.1 ضعف سعر المدخلات العادي - أي عُشر.
• الإدخال العادي: الجزء الذي لا يدخل إلى ذاكرة التخزين المؤقت ويتم معالجته بالتكلفة الكاملة في كل مرة.

نقطة التعادل: الطلب الأول يدفع علاوة الكتابة (1.25×). ومن الطلب الثاني، تدخل القراءة (0.1×) حيز التنفيذ. تقريبًا، ستكون متقاربًا في طلبين؛ وبعد ذلك يكون صافي المدخرات. كلما زاد حجم السياق الثابت وزاد عدد الطلبات التي يتم إعادة استخدامها، أصبح الربح أكبر.

سيناريو

هل تعمل ذاكرة التخزين المؤقت؟

موجه نظام ثابت كبير، آلاف الطلبات

نعم – أعلى الأرباح

أسئلة كثيرة على نفس المستندات المرجعية

نعم

نص قصير مختلف تمامًا لكل طلب

لا - يتم إهدار مكافأة الكتابة

طلب لمرة واحدة

لا – لا قراءة على الإطلاق

يتغير التاريخ/المعرف مع كل طلب في موجه النظام

لا — البادئة مكسورة، النتيجة صفر

خطوة بخطوة: كيفية إعداد موجه النتائج؟

1. فصل الثابت والمتغير. ما المحتوى الذي لا يتغير أبدًا (موجه النظام، كتاب القواعد، الوثائق)؟ ما الذي يتغير مع كل طلب (سؤال المستخدم، التاريخ، المعرف)؟
2. ضع الثابت في البداية. أثناء المعالجة، يجب أن يكون الجزء الذي يأتي أولاً (الأدوات، النظام) مستقرًا.
3. ضع المتغير في النهاية. السؤال الحالي للمستخدم، الأخير.
4. ضع العلامة في نهاية الحدود. ضع نقطة التخزين المؤقت في الكتلة الأخيرة من الجزء الثابت.
5. التحقق من الضربة. تحقق مما إذا كانت ذاكرة التخزين المؤقت_قراءة_input_tokens أكبر من الصفر في حقل الاستخدام في الاستجابة. إذا كان الصفر، هناك معطل مخفي في البادئة.

{ "system": [ { "type": "text"، "text": "{{large_constant_system_promptu_and_rules}}"، "cache_control": { "type": "ephemeral" } } ]، "messages": [ { "role": "user"، "content": "{{user_current_question}}" } ]}

نصيحة: لا تخمن نتائج ذاكرة التخزين المؤقت، بل قم بقياسها. إذا كان use.cache_read_input_tokens لا يزال صفرًا في الطلبات المتتالية، فسيتم تشغيل قاطع صامت (datetime.now() في موجه النظام، JSON غير مرتبة، قائمة الأدوات التي تتغير مع كل طلب). قارن الموجه الأولي للطلبين بايت بالبايت وابحث عن الفرق.

المعطلون الصامتون

الأنماط النموذجية التي تفسد ذاكرة التخزين المؤقت دون قصد:

# فاصل: تضمين معلومات في موجه النظام الذي يتغير مع كل طلب "تاريخ اليوم: {{الآن}}. أنت مساعد..." ← تتغير البادئة مع كل طلب، النتيجة صفر# TRUE: انقل المتغير إلى نظام الرسائل: "أنت مساعد..." ← يدخل الثابت إلى الرسائل المؤقتة: [{role: user, content: "Today is {{now}}. سؤال: ..."}] ← متغير في النهاية

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

موجه ضعيف/موجه قوي (بنية صديقة لذاكرة التخزين المؤقت)

# نظام ضعيف (بناء خرق ذاكرة التخزين المؤقت): "التاريخ: 18.07.2026 14:32. المستخدم: أحمد (المعرف 8842). أنت روبوت دعم. القواعد: ...(2000 رمز مميز)..."

# نظام قوي (بنية صديقة لذاكرة التخزين المؤقت): "أنت روبوت دعم. القواعد: ...(2000 رمز مميز، لا تتغير أبدًا)..." [علامة ذاكرة التخزين المؤقت]الرسائل: [ { role: user, content: "Date: 18.07.2026 14:32. معرف المستخدم: 8842. سؤال: كيف يمكنني بدء استرداد أموالي؟" }]

في الإصدار الضعيف، تتم معالجة كتلة القاعدة المكونة من 2000 رمزًا بالتكلفة الكاملة لكل طلب. في النسخة القوية يتم كتابة نفس الكتلة مرة واحدة وقراءتها على جميع الطلبات اللاحقة بعشر السعر.

ثلاث حالات صغيرة

الحالة 1 - تخزين كتاب القواعد مؤقتًا. كانت أتمتة المحاسبة تضيف دليل القواعد المكون من 12000 رمزًا مميزًا إلى كل فاتورة؛ 5000 طلب يوميا. تكاليف الإدخال بدون ذاكرة تخزين مؤقت ~ 180 دولارًا في اليوم. لقد أبقوا كتاب القواعد ثابتًا وقاموا بتخزينه مؤقتًا: دفعت الطلبات الأولى علاوة كتابة، والقراءات اللاحقة 0.1×. انخفضت تكلفة الإدخال بنسبة 90% إلى 18 دولارًا تقريبًا في اليوم.

الحالة 2 - تكلفة سطر التاريخ المخفي. قام أحد الفرق بإعداد مخبأ لكنه لم يتلق أي إصابات. كانت ذاكرة التخزين المؤقت (cache_read_input_tokens) دائمًا صفرًا. السبب: كان هناك datetime.now() في السطر الأول من موجه النظام، وكانت البادئة تتغير مع كل طلب. عندما قمنا بنقل التاريخ إلى رسالة المستخدم، ارتفع معدل الدخول فجأة من 0% إلى 94%.

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

الأخطاء الشائعة

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

أعمق: تصميم ذاكرة التخزين المؤقت حسب نوع عبء العمل

يختلف المردود الفعلي للتخزين المؤقت وفقًا لطبيعة عبء العمل لديك؛ لذا تعرف على حركة المرور الخاصة بك أولاً. ثلاثة أنماط نموذجية والتثبيت الصحيح:

موجه النظام المشترك، أسئلة مختلفة. نمط المؤسسة الأكثر شيوعًا: موجه نظام كبير (الدور، القواعد، ربما مستند مرجعي) مع مئات من أسئلة المستخدم المختلفة. هنا يتم تخزين الجزء الثابت (النظام) مؤقتًا في البداية؛ كل سؤال جديد يدفع الثمن الكامل فقط لجزء صغير خاص به. الربح مرتفع جدًا لأن الجزء الكبير يتلى مراراً وتكراراً بعشر الثمن.

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

البادئة المشتركة هي آخر جزء يجب تغييره. تشترك الطلبات المتعددة في مجموعة كبيرة من المقدمات الثابتة (مجموعة العينات والتعليمات) ولكن يتم فصلها بسؤال واحد في النهاية. قمت بوضع مؤشر ذاكرة التخزين المؤقت في نهاية الجزء المشترك؛ وإلا فإن كل طلب سيكتب ذاكرة تخزين مؤقت منفصلة خاصة به ولن تتم قراءة أي منها.

تحذير واحد: تعتمد ذاكرة التخزين المؤقت على النموذج وحد أدنى معين للحجم. لن تدخل البادئات الصغيرة جدًا (أقل من بضعة آلاف من الرموز المميزة، اعتمادًا على الطراز) إلى ذاكرة التخزين المؤقت بصمت حتى إذا قمت بوضع علامة عليها - تظل ذاكرة التخزين المؤقت_creation_input_tokens صفرًا. كما أن تغيير النموذج في منتصف المحادثة يؤدي إلى إبطال ذاكرة التخزين المؤقت بأكملها؛ إذا كانت مهمة مختلفة تتطلب نموذجًا رخيصًا، فاحتفظ بالتدفق الرئيسي في نموذج واحد وقم بوضع الوظيفة الجانبية في مكالمة منفصلة.

باختصار

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

مهمة التطبيق

اختر عبء العمل. (1) قسم المحتوى إلى عمودين: "لا يتغير أبدًا" و"يتغير مع كل طلب". (2) إعادة رسم هيكل الموجه، بوضع الجزء الثابت في البداية والجزء المتغير في النهاية. (3) قم بتقدير حجم الرمز المميز للجزء الثابت ومقارنة التكلفة الشهرية مع/بدون ذاكرة التخزين المؤقت. (4) لاحظ الحقل (cache_read_input_tokens) الذي ستتحقق من النتيجة منه.

قائمة مرجعية

• [ ] يمكنني أن أشرح أن ذاكرة التخزين المؤقت هي مطابقة البادئة والقاعدة الوحيدة غير القابلة للتغيير.
• [ ] يمكنني زيادة الدقة عن طريق وضع المحتوى الثابت في البداية والمتغير في النهاية.
• [ ] أعرف اقتصاديات الكتابة/القراءة ونقطة التعادل للطلبين.
• [ ] يمكنني التعرف على المعطلات الصامتة (التاريخ، JSON غير المرتب، تغيير قائمة المركبات).
• [ ] يمكنني التحقق من النتيجة باستخدام use.cache_read_input_tokens.