Prompt caching در Claude — کاهش هزینه

اگه از Claude API استفاده می‌کنی و هزینه‌ات بیشتر از چیزیه که انتظار داشتی، احتمالاً با Prompt Caching می‌تونی اونو به شدت کاهش بدی. این یه feature واقعی با اعداد واقعی‌ه — نه تبلیغ.

مشکلی که Prompt Caching حلش می‌کنه

فرض کن یه اپلیکیشن ساختی که Claude رو می‌خونه. داری یه سیستم پرامپت ۱۰ هزار توکنی داری — مستندات محصول، دستورالعمل‌ها، مثال‌ها. هر بار که یه کاربر سؤال می‌کنه، تمام این ۱۰ هزار توکن دوباره پردازش می‌شه.

بدون caching: ۱۰۰۰ کاربر × ۱۰K توکن = ۱۰ میلیون توکن ورودی — هر روز.

با Prompt Caching: اون ۱۰K توکن یه بار پردازش می‌شه، نتیجه cache می‌شه، و هر درخواست بعدی فقط هزینهٔ بازیابی cache رو داره که ۹۰٪ ارزون‌تره.

مکانیزم کار

Anthropic توی API اجازه می‌ده که بخشی از prompt رو با cache_control علامت‌گذاری کنی. اون بخش برای ۵ دقیقه (و در برخی پلن‌ها تا ۱ ساعت) cache می‌مونه.

ساختار کلی در Python:

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "<دستورالعمل‌های اصلی سیستم اینجا>",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": سوال_کاربر}]
)

هر بار که همین request با همین cache block بیاد، Claude بخش cache شده رو دوباره پردازش نمی‌کنه.

اعداد واقعی — چقدر صرفه‌جویی می‌کنی؟

(بر اساس pricing Anthropic در ۲۰۲۵ — برای مقادیر دقیق صفحهٔ رسمی رو چک کن)

یعنی از دفعهٔ دوم به بعد، ۹۰٪ ارزون‌تر. اگه سیستم پرامپتت بزرگه و ترافیک داری، break-even از اولین cache hit اتفاق می‌افته.

چه چیزایی رو cache کنیم؟

ارزش داره:

• سیستم پرامپت‌های طولانی (مستندات، دستورالعمل‌ها)
• مثال‌های few-shot که همیشه تکرار می‌شن
• اسناد مرجعی که به همهٔ کاربران مربوطه
• کدبیس یا متنی که هر query بهش رجوع می‌کنه

ارزش نداره:

• پیام‌های کوتاه کاربر (این بخش هر بار فرق داره، نمی‌شه cache کرد)
• محتوایی که هر request دیفرنت هست
• بخش‌های کمتر از ~۱۰۲۴ توکن (minimum token برای cache)

محدودیت‌های مهم

۱. حداقل توکن: نمی‌شه هر چیزی رو cache کرد. Claude 3.5 Sonnet حداقل ۱۰۲۴ توکن می‌خواد تا cache فعال بشه. مدل‌های سبک‌تر این سقف رو ندارن.

۲. مدت انقضا: cache به صورت پیش‌فرض ۵ دقیقه عمر داره. اگه ترافیکت کمه و بین request‌ها فاصلهٔ زیادی هست، cache مدام expire می‌شه و سود چندانی نداری.

۳. ترتیب اهمیت داره: cache block باید دقیقاً همون ترتیب و محتوا داشته باشه. یه تغییر کوچیک در system prompt = cache miss = دوباره از اول.

۴. فقط توی API: این feature برای کاربران Claude.ai (وب/اپ) نیست — فقط توسعه‌دهنده‌هایی که مستقیم با API کار می‌کنن ازش بهره می‌برن.

یه مثال کاربردی

فرض کن داری یه chatbot پشتیبانی می‌سازی. مستندات محصولت ۸۰۰۰ توکنه. هر روز ۵۰۰ تا سؤال دریافت می‌کنی.

بدون cache: 500 × 8000 = 4M توکن ورودی/روز → ~$12/روز فقط برای system prompt با cache: ۱ cache write + 499 cache read → ~$1.5/روز

صرفه‌جویی ماهانه: حدود $315 فقط برای همین یه بخش.

ترکیب با RAG و long context

اگه از RAG استفاده می‌کنی، می‌تونی document chunks پرتکرار رو cache کنی. اگه context window طولانی می‌خوای، cache می‌تونه هزینهٔ اون context ثابت رو به شدت کاهش بده — بخش ثابت رو cache کن، بخش متغیر رو هر بار بفرست.

جمع‌بندی

Prompt Caching یه feature فنیه که برای توسعه‌دهنده‌هایی که با Claude API می‌سازن، اهمیت عملی بالایی داره. اگه اپلیکیشنت system prompt ثابت و بزرگ داره، فعال‌سازیش تقریباً همیشه منطقیه. پیاده‌سازیش هم ساده‌ست — فقط اضافه کردن cache_control به بخش‌های مناسب.

---

همچنین بخوان

• Claude API — راهنمای شروع
• RAG چیست؟ — ترکیب caching با retrieval-augmented generation
• Context window های طولانی در Claude — چطور از ۲۰۰K توکن بهینه استفاده کنی
• Claude چیست؟ راهنمای کامل