# متى يقلل تخزين الـ prompt مؤقتًا تكلفة وكيل البرمجة فعلًا؟ > يقلل prompt caching التكلفة عندما تعيد طلبات كثيرة استخدام بادئة كبيرة مستقرة بايتًا ببايت، وتتجاوز وفورات cache read تكلفة الكتابة وحالات miss والتعقيد الإضافي. يكون prompt caching ذا قيمة عندما يرسل الوكيل البداية الكبيرة نفسها تمامًا مرات كثيرة، لا عندما تبدو prompts متشابهة للإنسان فقط. قد يفسد timestamp أو ترتيب أدوات مختلف أو ملخص workspace متغير أو request ID في البداية إعادة استخدام كل ما بعده. قبل إعادة تصميم prompts، افحص usage metadata لطلبات حقيقية. حدد عدد input tokens المؤهلة، وعدد cache reads المبلغ عنها، ومعدل تغير البادئة، وما إذا كان النموذج والبروتوكول يقدمان فائدة فعلية. ## نمذج خط الأساس من دون cache ابدأ بتكلفة الإدخال لأن caching لا يقلل output tokens أو تنفيذ الأدوات. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` استخدم وحدات متسقة، عادة تكلفة كل مليون token. لا تدخل خصمًا من الذاكرة؛ استخدم السعر الحالي وحقول الاستخدام للنموذج المحدد. | المكوّن | ثابت بين الطلبات؟ | الموضع المتوقع | |---|---|---| | سياسة النظام | عادة | أولًا | | مخططات الأدوات | عادة | مبكرًا | | قواعد repository | غالبًا | مبكرًا | | نقطة تحقق المهمة | أحيانًا | الوسط | | طلب المستخدم | نادرًا | متأخرًا | | مخرجات الأداة الحية | لا | أخيرًا | ## احسب نقطة التعادل بالرموز ليكن `P` عدد tokens البادئة الثابتة، و`R` عدد الطلبات، و`W` سعر cache write، و`H` سعر cache read، و`U` سعر الإدخال العادي. ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` تفترض هذه الحالة المثالية hit بعد الطلب الأول. لنسبة hit مقاسة `h`، استبدل حد الطلبات اللاحقة بمزيج موزون من `H` و`U`. أضف tokens خارج البادئة بالسعر العادي للطرفين. لا يكون caching مفيدًا ماليًا إلا إذا ظلت الوفورات موجبة بعد miss والتكلفة الهندسية. ## ضع المحتوى الثابت أولًا ابنِ prompt من الأكثر ثباتًا إلى الأكثر تغيرًا: * تعليمات النظام والأمان. * تعريفات الأدوات بترتيب حتمي. * قواعد repository والنص المرجعي الدائم. * نقطة تحقق موجزة للمهمة. * طلب المستخدم الحالي. * أحدث مخرجات أداة. سلسل المخططات بطريقة حتمية. تجنب الترتيب العشوائي وتغييرات whitespace وtimestamps والتعليقات الخاصة بالطلب في البادئة. أصدر نسخًا من الحزم الثابتة عن قصد. ## اجعل البادئة مفيدة لا كبيرة فقط قد تسجل بادئة متضخمة cache reads كثيرة مع زيادة إجمالي tokens وتشتيت النموذج. أزل الأدوات القديمة والسياسات المكررة والملفات المرجعية غير المرتبطة. قس التكلفة لكل تغيير مقبول، لا نسبة cache hit وحدها. قد يتفوق prompt أقصر غير مخزن إذا حل المهمة في دورات أقل. ## راقب الطلبات والنتائج سجّل النموذج والبروتوكول وإصدار البادئة وإجمالي input tokens وcached input tokens عند توفرها وoutput tokens والزمن وعدد tool calls وretry ونتيجة المهمة. علّم الحقول المفقودة unavailable بدل صفر. | المقياس | سبب أهميته | |---|---| | نسبة tokens المخزنة | تؤكد حدوث إعادة الاستخدام | | سبب miss | يكشف تغير البادئة غير المقصود | | الطلبات لكل مهمة | يظهر الحلقات التي تلغي الوفورات | | تكلفة التغيير المقبول | تربط tokens بالنتيجة المفيدة | | نسبة retry | تكشف تكلفة الموثوقية خارج cache | أسبوع من المهام الممثلة أنفع من prompt اصطناعي مكرر مئة مرة. ## راقب routing وحدود الجلسة قد يعتمد سلوك cache على النموذج والمزود والمنطقة وretention window وrouting. يمكن لـ gateway أو fallback نقل الطلب إلى مسار لا يملك البادئة الدافئة نفسها. يوفر Atlas Cloud عدة صيغ LLM عبر API واحد لكنه لا يعد بخصم عام لـ prompt cache. تحقق من النموذج ووحدة التحكم الحاليين. استخدم [بروتوكولات LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) للصيغة المتوافقة و[كتالوج النماذج](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) للتفاصيل الحالية. ## تجنب الوفورات الوهمية قد يخفي بند إدخال أقل دورات إضافية أو tool calls فاشلة أو إعادة بناء السياق. ميّز cache read عن تخزين التطبيق وretrieval؛ فهي تحل مشكلات مختلفة. لا تضع أسرارًا لمجرد أن المحتوى قابل للتخزين. لا تحل بنية caching محل التحكم بالوصول أو متطلبات الاحتفاظ. ## استخدم بوابة تبنٍ عملية طبّق prompt caching عندما: * تكون البادئة الثابتة مفيدة ومتكررة كثيرًا. * يبلغ الاستخدام الحقيقي عن cache read. * تبقى الوفورات بعد نسبة miss المرصودة. * يكون إصدار البادئة بسيطًا وحتميًا. * لا تسوء جودة المهمة ولا عدد الدورات. وإلا فقلل حجم prompt، واجلب الملفات ذات الصلة فقط، واختصر حلقة الوكيل أولًا. ## الخلاصة يقلل prompt caching تكلفة وكيل البرمجة عندما يعاد استخدام بادئة كبيرة مفيدة ومستقرة بايتًا ببايت مرات كافية على مسار يبلغ عن إدخال مخزن أرخص. ضع المادة الثابتة أولًا، واحسب التعادل بالأسعار الحالية، وقس تكلفة التغيير المقبول. لا تعد نسبة hit العالية مكسبًا إذا كان prompt متضخمًا أو يحتاج الوكيل دورات أكثر. ## FAQ ### ما المحتوى الأنسب لـ prompt caching؟ تعليمات النظام الثابتة ومخططات الأدوات وقواعد repository والمواد المرجعية قليلة التغيير أنسب من السجلات الحية أو أحدث رسالة للمستخدم. ### لماذا يوضع المحتوى المتغير بعد البادئة الثابتة؟ تعتمد prefix cache غالبًا على بداية متطابقة. يمكن أن يجعل timestamp أو request ID أو سياق متغير مبكرًا كل المحتوى الثابت اللاحق حالة miss. ### هل يقلل prompt caching زمن الاستجابة دائمًا؟ لا. تعتمد النتيجة على تطبيق المزود وحالة cache وrouting والنموذج وحجم الطلب والحمل. قس زمن الاستجابة منفصلًا عن التكلفة. ### كيف أحسب نقطة التعادل؟ قارن تكلفة الإدخال غير المخزن بتكلفة cache write وcache read عبر مرات الاستخدام المتوقعة، ثم أضف تكلفة الهندسة ونسبة miss. ### هل يمكن تخزين تعريفات الأدوات مؤقتًا؟ قد تكون جزءًا من بادئة متكررة إذا شملها المزود والبروتوكول في caching. تحقق من usage metadata بدل الافتراض. ### هل يجب تخزين نص جلسة البرمجة كاملًا؟ غالبًا لا. يتغير النص كل دورة. ضع التعليمات والمخططات الثابتة أولًا، ثم نقطة تحقق موجزة والطلب الحالي.