کاشهٔ پرامپت در کلود هزینهٔ API یک عامل هوش مصنوعی را ۸۵٪ کاهش داد

اگر امروز برای اجرای یک عامل هوش مصنوعی در مقیاس تولیدی هزینه می‌پردازید، احتمالاً متوجه شده‌اید که بخش بزرگی از صورت‌حساب شما صرف ارسال تکراری دستورالعمل‌های طولانی می‌شود. یک تغییر ساده در پیکربندی پرامپت‌های سیستمی توانست هزینهٔ روزانهٔ یک عامل با ۴۰۰۰ درخواست را از ۴۷ دلار به ۶.۸۰ دلار کاهش دهد. این کاهش ۸۵ درصدی هزینه در ۹ اوت ۲۰۲۶ و روی مدل Claude 3.5 Sonnet ثبت شد. نکتهٔ کلیدی این است که هیچ تغییری در منطق یا رفتار عامل ایجاد نشد و تنها نحوهٔ پردازش توکن‌ها توسط API بهینه شد.

همان‌طور که در تحلیل قبلی ما درباره‌ی اتوماسیون گردش‌های کاری با Claude اشاره کردیم، چالش اصلی توسعه‌دهندگان اکنون از «هوش مدل» به «اقتصاد مقیاس‌پذیری» تغییر کرده است. برای اکثر برنامه‌نویسان، گلوگاه اصلی ارسال مداوم پرامپت سیستمی (System Prompt) — که شبیه به دفترچهٔ راهنمای دائمی است که مدل باید در هر بار پاسخگویی دوباره بخواند — است. این پرامپت‌ها که شامل قوانین، شخصیت و تعاریف ابزارها هستند، در هر درخواست هزینهٔ توکن‌های ورودی را بالا می‌برند.

سازوکار کشینگ پیشوندی

Anthropic مکانیزم کشینگ را در سطح پیشوند (Prefix) پیاده کرده است. طبق مستندات این شرکت، وقتی درخواستی ارسال می‌شود، API بررسی می‌کند که آیا ابتدای پیام با یک توالی ذخیره‌شده در حافظه مطابقت دارد یا خیر. اگر تطابق پیدا شود، مدل توکن‌ها را از یک KV Store (حافظه کلید-مقدار) می‌خواند و دیگر نیازی به پردازش مجدد آن‌ها نیست، که این امر منجر به اعمال نرخ هزینه بسیار پایین‌تری می‌شود.

به گزارش dev.to، ساختار قیمت‌گذاری Claude 3.5 Sonnet در اواسط ۲۰۲۶ به این صورت است:

• توکن‌های ورودی عادی: ۳.۰۰ دلار به ازای هر میلیون توکن.
• نوشتن در کش (اولین استفاده یا Miss): ۳.۷۵ دلار به ازای هر میلیون توکن (یک هزینه اضافی ۲۵ درصدی).
• خواندن از کش (Hit): ۰.۳۰ دلار به ازای هر میلیون توکن (تخفیف ۹۰ درصدی).

این حافظه ۵ دقیقه باقی می‌ماند و با هر بار خواندن (Hit)، زمان انقضا (TTL) بازنشانی می‌شود. این ویژگی باعث می‌شود کشینگ برای هر عامل تولیدی که بیش از یک بار در هر پنج دقیقه فراخوانی می‌شود، یک گزینه ایده‌آل باشد.

استراتژی نقاط شکست در پیاده‌سازی

توسعه‌دهندگان برای فعال‌سازی این قابلیت از بلوک cache_control به عنوان یک «نقطه شکست» (Breakpoint) استفاده می‌کنند. API تمام محتوای قبل از این نشانگر و خودِ نشانگر را ذخیره می‌کند. در این مورد خاص، پرامپت سیستمی با حدود ۲۸۰۰ توکن به عنوان ephemeral علامت‌گذاری شد تا کش فعال شود.

import anthropic
client = anthropic.Anthropic()

SYSTEM_PROMPT = """ You are a support agent for Acme Corp... [2,800 tokens of rules, tool definitions, persona, examples] """

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"} # <-- کل تنظیمات در این خط است
        }
    ],
    messages=[{"role": "user", "content": user_message}]
)

سناریوهایی که بیشترین بازگشت سرمایه (ROI) را دارند عبارتند از:

• پرامپت‌های سیستمی حجیم: هر پرامپتی بالای ۱۰۰۰ توکن که مکرراً استفاده می‌شود. اگر API را بیش از یک بار در هر ۵ دقیقه فراخوانی کنید، این روش تقریباً همیشه سودآور است.
• تعاریف ابزارها: طرح‌های ابزار (Tool Schemas) به عنوان توکن‌های ورودی محاسبه می‌شوند. مجموعه‌ای از ۱۰ ابزار با توضیحات مناسب ممکن است ۸۰۰ تا ۱۲۰۰ توکن اشغال کند؛ بنابراین بلوک ابزارها را کش کنید.
• نمونه‌های Few-Shot: افزودن ۵ تا ۱۰ مثال موفق برای ارتقای کیفیت پاسخ‌ها معمولاً ۲۰۰۰ تا ۴۰۰۰ توکن اضافه می‌کند. این بخش اغلب بزرگ‌ترین فرصت برای صرفه‌جویی در هزینه‌هاست.
• تحلیل اسناد: کش کردن یک قرارداد یا سند حجیم در حالی که ۲۰ سؤال مختلف درباره آن پرسیده می‌شود. در این حالت، متن سند را به عنوان یک پیام کاربر کش کرده و تمام پرس‌وجوها را روی همان کش ارسال کنید.

کشینگ پیشرفته با نقاط شکست متعدد

توسعه‌دهندگان می‌توانند تا ۴ نقطه شکست در هر درخواست تعریف کنند. این قابلیت اجازه می‌دهد بخش‌های مختلف پرامپت بر اساس نرخ تغییراتشان، به صورت مستقل کش شوند.

به عنوان مثال، یک درخواست می‌تواند شامل یک بلوک BASE_RULES (که همیشه ثابت است)، یک بلوک TOOL_DEFINITIONS (که به ندرت تغییر می‌کند) و یک بلوک dynamic_context (که در هر درخواست تغییر می‌کند) باشد. با علامت‌گذاری دو بلوک اول به عنوان ephemeral ، API آن‌ها را به صورت جداگانه کش می‌کند.

قانون کشینگ پیشوندی بسیار سخت‌گیرانه است: API همه چیز را تا آخرین نقطه شکست علامت‌گذاری شده در توالی کش می‌کند. اگر محتوای پویا بین دو بلوک کش‌شده قرار بگیرد، کش دوم شکست می‌خورد زیرا پیشوند دیگر یکسان نیست. بنابراین همیشه محتوای متغیر را در انتهای درخواست قرار دهید.

تلهٔ «خطای کش» (Cache Miss)

یک جزئیات حیاتی این است که حتی یک فاصله (Whitespace) یا تغییر در سطح کاراکترها اهمیت دارد. چون کلید کش دقیقاً همان توالی توکن‌هاست، هرگونه جایگذاری پویا (Interpolation) — مانند درج نام کاربر یا سطح حساب کاربری در بلوک کش‌شده — باعث شکست کش شده و جریمهٔ نوشتن کامل (Write Premium) را فعال می‌کند.

تفاوت این دو رویکرد را در نظر بگیرید:

• روش غلط: جایگذاری {company_name} داخل بلوک کش‌شده باعث می‌شود هر درخواست منحصربه‌فرد شود و در نتیجه نرخ Hit صفر گردد.
• روش درست: قرار دادن ۲۸۰۰ توکن قوانین ثابت در یک STATIC_BLOCK کش‌شده و افزودن زمینه پویا (مثلاً: "Current context: working for {company_name}") در خارج از محدوده کش.

محاسبه نقطهٔ سربه‌سر

توسعه‌دهندگان می‌توانند با محاسبه نرخ خواندن سربه‌سر، متوجه شوند که آیا کشینگ برای آن‌ها توجیه‌پذیر است یا خیر. فرض کنید T تعداد توکن‌های بلوک کش‌شده و R تعداد درخواست‌ها در ساعت باشد:

• هزینه نوشتن در کش (W): T * $3.75/M
• سود به ازای هر خواندن (S): T * ($3.00 - $0.30) / M = T * $2.70/M
• تعداد خواندن برای سربه‌سر: W / S = $3.75 / $2.70 ≈ ۱.۴ بار در هر پنجرهٔ زمانی.

به زبان ساده، اگر یک عامل در هر ۵ دقیقه بیش از ۱.۴ درخواست (حدود ۱۷ درخواست در ساعت) ارسال کند، کشینگ سودآور می‌شود. در مقیاس ۴۰۰۰ درخواست در روز، یک عامل صدها بار در هر پنجرهٔ زمانی به کش دسترسی پیدا می‌کند. این رویکرد بهینه‌سازی هزینه‌ها در کنار استفاده از قراردادهای اندازه‌گیری برای جلوگیری از محاسبهٔ دوبرابره هزینه‌ها، می‌تواند بودجهٔ عملیاتی پروژه‌های هوش مصنوعی را به شدت کاهش دهد.

تأیید عملکرد

برای اطمینان از صحت اجرا، توسعه‌دهندگان باید شیء usage در پاسخ API را مانیتور کنند. یک نسبت کشینگ سالم باید مقدار cache_read_input_tokens بالا و cache_creation_input_tokens پایینی داشته باشد.

usage = response.usage
total_input = usage.input_tokens
cache_writes = getattr(usage, 'cache_creation_input_tokens', 0)
cache_reads = getattr(usage, 'cache_read_input_tokens', 0)

print(f"Cache write: {cache_writes} tokens (paid at $3.75/M)")
print(f"Cache read: {cache_reads} tokens (paid at $0.30/M)")
print(f"Regular: {total_input} tokens (paid at $3.00/M)")

اگر هزینهٔ نوشتن (Writes) غالب است، این موضوع نشان می‌دهد که یا فاصلهٔ درخواست‌های شما بیش از ۵ دقیقه است یا محتوای غیرثابت را داخل بلوک کش قرار داده‌اید. در این موارد، به جای تغییر تنظیمات کشینگ، محتوای پرامپت را اصلاح کنید.

این تغییر در ساختار هزینه‌ها به این معناست که «مالیات توکن» برای استفاده از پرامپت‌های باکیفیت و چندنمونه‌ای (Few-shot) برای کاربران حجیم عملاً حذف شده است. این قابلیت به توسعه‌دهندگان اجازه می‌دهد بدون ترس از افزایش خطی هزینه‌ها، در ارائه زمینه (Context) و مثال‌های بیشتر به مدل سخاوتمندتر باشند.

برای کسانی که در مقیاس بالا می‌سازند، مرز بعدی بهینه‌سازی تعادل بین TTL کش و فرکانس درخواست‌ها برای به حداقل رساندن هزینه نوشتن است. شما می‌توانید الگوهای هزینه و قابلیت اطمینان بیشتر را در راهنمای Reliable Agent در penloomstudio.com/field-guide.html بررسی کنید.

گام بعدی شما

• اگر پرامپت سیستمی شما بیش از ۱۰۰۰ توکن است، بلافاصله از cache_control استفاده کنید.
• تمام متغیرهای پویا (نام کاربر، تاریخ، وضعیت حساب) را به انتهای پیام منتقل کنید تا کش شکسته نشود.
• نرخ cache_read را در لاگ‌های خود مانیتور کنید تا از عدم وقوع Cache Miss مطمئن شوید.

اما بهینه‌سازی هزینه تنها نیمی از مسیر است؛ برای درک نحوهٔ مدیریت حافظه در مقیاس‌های میلیونی، به تحلیل ما درباره‌ی معماری KV Cache مراجعه کنید.