API جدید prompt-caching مدل Claude Opus 5، با اجازه دادن به مدل برای نادیده گرفتن متنهای تغییرناپذیر، هزینههای توکن را در اپلیکیشنهای سبک چت به شدت کاهش میدهد. اولین درخواست با مبلغی اندک بیشتر (premium) همراه است؛ اما هر درخواست بعدی تقریباً با یکدهم نرخ پایه هزینه خواهد داشت که باعث میشود یک هزینه تکرارشونده، به یک هزینه یکباره تبدیل شود.
چرا توسعهدهندگان دو بار برای کلمات یکسان هزینه میپردازند
بیشتر رابطهای کاربری گفتگومحور، در هر مرحله کل پرامپت را دوباره میسازند: یک پرامپت سیستم ۸۰۰۰ توکنی، فایلهای PDF پیوستشده و تاریخچه کامل گفتگو، هر بار که کاربر سوال بعدی را میپرسد، همراه با هم به مدل ارسال میشوند. مدل تمام توکنها را دوباره پردازش میکند، حتی اگر بخش عمده آن متن هرگز تغییر نکرده باشد. با قیمتگذاری فعلی، این افزونگی (redundancy) میتواند بخش اعظم هزینه یک بات پرکار را به خود اختصاص دهد.
کش (Cache) چگونه محاسبات را تغییر میدهد
این API برای هر «بلوک» از توکنها تا یک نقطه مرزی (breakpoint) مشخص، یک ورودی در کش ایجاد میکند. وقتی درخواست بعدی شامل همان بلوک در ابتدای متن باشد، سرویس به جای توکنایز کردن مجدد، آن را از کش میخواند. تفکیک قیمتگذاری نشاندهنده کار ذخیره شده است:
- نوشتن در کش – مدت ماندگاری (TTL) ۵ دقیقهای: ۱.۲۵ × قیمت پایه
- نوشتن در کش – مدت ماندگاری (TTL) ۱ ساعته: ۲ × قیمت پایه
- خواندن از کش (hit): ۰.۱ × قیمت پایه
در عمل، اولین فراخوانی برای یک بلوک جدید، کمی بیشتر از یک درخواست معمولی هزینه دارد. اما هر فراخوانی بعدی که به کش برخورد کند (hit)، ۹۰٪ ارزانتر است؛ بنابراین با عمیقتر شدن گفتگو، هزینه خالص به شدت کاهش مییابد.
«قانون طلایی» برای ساختاردهی به پرامپتها
اثربخشی کش به این بستگی دارد که محتوای ایستا (static) و پویا (dynamic) را کجا قرار میدهید. هر چیزی که ثابت میماند را در ابتدا قرار دهید و بخشهای همیشه در حال تغییر را به انتها منتقل کنید. یک ترتیب قابل اعتماد به این صورت است:
۱. Tools – تعاریف هرگونه تابع خارجی که مدل ممکن است فراخوانی کند.
۲. System instructions – رفتار سطح بالایی که میخواهید مدل دنبال کند.
۳. Documents – بافتهای طولانی مانند PDFها، پایگاههای دانش یا گزیدههای سیاستنامهها.
۴. User questions – پرسش زنده کاربر که در هر مرحله تغییر میکند.
اگر هر توکنی را قبل از یک نقطه مرزی تغییر دهید، ورودی کش باطل شده و مدل باید تمام آنچه را که پس از آن میآید، دوباره پردازش کند.
محدودیتهای پنهانی که باید رعایت کنید
- حداقل اندازه بلوک – مدل Opus 5 فقط بلوکهایی را کش میکند که حداقل شامل ۵۱۲ توکن باشند. هر چیزی کوچکتر، کاملاً از چرخه کش خارج میشود.
- باگ برچسب زمانی (Timestamp) – وارد کردن یک برچسب زمانی متغیر در داخل یک بلوکِ کششده، باعث عدم تطابق (miss) میشود، زیرا متن بلوک هرگز دقیقاً با متن جدید مطابقت نخواهد داشت.
- بازگشت ۲۰ بلوکی (20-block look-back) – سرویس برای یافتن تطابق، تنها ۲۰ بلوک آخر را اسکن میکند. جلسات طولانیمدتی که به سرعت جلو میروند، ممکن است از پنجره کش فراتر بروند.
- درخواستهای موازی – ارسال چندین درخواست یکسان در یک لحظه، همگی با شکست (miss) مواجه میشوند، زیرا کش تنها پس از اتمام اولین درخواست پر میشود. ابتدا کش را با یک فراخوانی گرم کنید، سپس بقیه درخواستها را ارسال کنید.
مشاهده میزان صرفهجویی در پاسخ API
هر پاسخ، سه شمارنده توکن را گزارش میدهد:
cache_read_input_tokens– توکنهایی که از طریق برخورد با کش (cache hit) تامین شدهاند.cache_creation_input_tokens– توکنهایی که در این درخواست در کش نوشته شدهاند.input_tokens– توکنهای جدیدی که در کش نبودند.
این سه عدد را با هم جمع کنید تا مجموع توکنهایی که مدل در آن مرحله در نظر گرفته است را به دست آورید. اگر هر دو فیلد مربوط به کش صفر باشند، یعنی درخواست با کش مطابقت نداشته است؛ در این صورت اندازه بلوک و محل قرارگیری نقطه مرزی خود را بررسی کنید.
نکته کلیدی: با قرار دادن محتوای تغییرناپذیر در ابتدای پرامپت و سپردن کارهای سنگین به prompt-caching API مدل Claude Opus 5، شما یک هزینه تکرارشونده برای توکنها را به یک هزینه یکباره تبدیل میکنید. نتیجه این کار، کاهش چشمگیر هزینه برای هر چتباتی است که مکرراً به یک پرامپت سیستم یا مجموعهای از اسناد ارجاع میدهد—به شرطی که حداقل تعداد توکن را رعایت کنید، از قرار دادن نشانگرهای تغییرپذیر در بلوکهای کششده خودداری کنید و محتوای واجد شرایط برای کش را در محدوده ۲۰ بلوک نگه دارید.