عنوان: تغییر نام یک ابزار، از دست رفتن کل حافظه پنهان (Cache)
قیمتگذاری جدید حافظه پنهان (cache) آنتروپیک (Anthropic) به این معناست که یک تغییر کوچک در سطح یک کاراکتر — مانند تغییر نام یک ابزار یا افزودن برچسب زمانی (timestamp) به یک دستور سیستم (system prompt) — میتواند یک برخورد موفق با حافظه پنهان (cache hit) ارزانقیمت را به یک عدم برخورد (cache miss) با قیمت کامل تبدیل کند و هزینهها را دهها برابر افزایش دهد.
این تغییر ناشی از سیستم تخفیف دو مرحلهای حافظه پنهان آنتروپیک است. برای برخی مدلها، خواندن از حافظه پنهان تنها 0.025 × قیمت ورودی معمولی هزینه دارد؛ برای برخی دیگر، این تخفیف 0.1 × است. این تخفیف تنها زمانی اعمال میشود که درخواست دقیقاً با یک ورودی ذخیرهشده در حافظه پنهان مطابقت داشته باشد. در صورت عدم مطابقت، هزینه بر اساس نرخ پایه محاسبه میشود، بنابراین شکاف بین برخورد موفق (hit) و عدم برخورد (miss) به شدت افزایش مییابد. در عمل، یک تغییر کوچک در دستور (prompt) میتواند هزینه را تا چهل برابر مقدار مورد انتظار بالا ببرد.
چرا این تغییر اهمیت دارد
آنتروپیک لایه حافظه پنهان را برای تشویق به استفاده مجدد از دستورات یکسان اضافه کرد؛ الگویی رایج در عاملها (agents) که مکرراً از یک مجموعه ابزار یکسان استفاده میکنند. ایده ساده است: نتیجه ترکیب یک دستور و یک ابزار را یک بار ذخیره کنید، سپس در فراخوانیهای بعدی آن را با هزینه کم بازیابی کنید. ضرایب جدید بخش «بازیابی» را بسیار ارزانتر میکنند، اما جریمه برای «عدم برخورد» (miss) را نیز بسیار سنگینتر میکنند.
توسعهدهندگانی که عاملها را بر پایه دستورات سیستم پایدار ساختهاند، اکنون میبینند که هرگونه تغییر — عمدی یا تصادفی — زنجیره حافظه پنهان را میشکند. نتیجه این امر، یک مالیات پنهان بر سرویس است: کاهش نسبت برخورد موفق با حافظه پنهان (cache-hit ratio) مستقیماً به افزایش هزینههای عملیاتی منجر میشود.
چه چیزی حافظه پنهان را از کار میاندازد
مستندات آنتروپیک سلسلهمراتبی را توصیف میکند که در آن تغییرات در سطوح بالاتر، تمام موارد زیرین را باطل میکند. نتیجه عملی این است که ویرایشهای ظاهراً بیضرر میتوانند باعث ایجاد هزینههای سنگین با قیمت کامل شوند.
- تعاریف ابزار (Tool definitions) – افزودن، حذف، تغییر نام یک ابزار یا تغییر توضیحات آن، حافظه پنهان مربوط به ابزارها، دستور سیستم و تمام تاریخچه پیامها را پاک میکند.
- کلید جستجوی وب (Web-search toggle) – تغییر مقدار بولین (boolean) که ابزار جستجوی وب را فعال میکند، دستور سیستم و حافظه پنهان پیامها را پاک میکند.
- پارامتر انتخاب ابزار (Tool-choice parameter) – تغییر پارامتری که انتخاب میکند کدام ابزار اجرا شود، تنها حافظه پنهان پیامها را باطل میکند.
- محمولههای تصویری (Image payloads) – افزودن یا حذف تصاویر تنها بر حافظه پنهان پیامها تأثیر میگذارد.
الگوهای رایجی که توسعهدهندگان ناخواسته فعال میکنند:
- تغییر ترتیب ابزارها – برخی از پایگاههای کد، دیکشنریهای ابزار را در هر بار استقرار (deployment) مرتب میکنند. ترتیب جدید یک کلید حافظه پنهان متفاوت ایجاد میکند و باعث میشود هر بار با عدم برخورد (miss) مواجه شوید.
- دستورات دارای برچسب زمانی – گنجاندن رشتهای مانند “generated at HH:MM:SS” در دستور سیستم، هر درخواست را منحصربهفرد میکند و عدم برخورد با حافظه پنهان را تضمین میکند.
- چرخش بخشهای مختلف دستور – تعویض یک عبارت خوشآمدگویی یا بنر نسخه، هش (hash) دستور را تغییر داده و حافظه پنهان را از کار میاندازد.
شناسایی هزینه پنهان
گزارشهای استفاده آنتروپیک، پویایی حافظه پنهان را از طریق سه فیلد نشان میدهند:
cache_read_input_tokens– توکنهایی که از یک ورودی در حافظه پنهان خوانده شدهاند.cache_creation_input_tokens– توکنهایی که باعث ذخیره شدن یک ورودی جدید در حافظه پنهان شدهاند.input_tokens– توکنهایی که با نرخ معمولی محاسبه میشوند (باقیمانده پس از خواندن از حافظه پنهان).
افزایش ناگهانی در input_tokens همراه با کاهش در cache_read_input_tokens نشان میدهد که چیزی در پشته دستور (prompt stack) تغییر کرده است. نظارت بر این معیارها به تیمها اجازه میدهد تا قبل از باد شدن هزینهها، واکنش نشان دهند.
پاسخ توسعهدهنده
با مواجهه با واقعیت جدید قیمتگذاری، بسیاری از تیمها اکنون پایداری دستور (prompt stability) را به عنوان یک معیار عملکردی درجهیک در نظر میگیرند. استراتژیهای رایج عبارتند از:
- دستورات سیستم ایستا (Static system prompts) – ذخیره دستور در یک فایل تحت کنترل نسخه (version-controlled) و تزریق آن بدون تغییرات در زمان اجرا.
- ترتیب ابزار تعیینپذیر (Deterministic tool ordering) – تعریف مستقیم لیست ابزارها در کد، به جای تکیه بر ترتیب دیکشنری یا مولدهای خارجی.
- حذف برچسب زمانی – انتقال اطلاعات ثبت وقایع (logging) یا زمانبندی به یک کانال متادیتای مجزا که بر رشته دستور تأثیر نمیگذارد.
- تستهای آگاه از حافظه پنهان (Cache-aware testing) – افزودن تستهای واحد (unit tests) که تأیید میکنند هشِ کل دستور (سیستم + ابزارها + پیامها) در طول نسخههای مختلف ثابت میماند.
این اقدامات بار مهندسی کمی را اضافه میکنند، اما در برابر «مالیات پنهانی» که اکنون یک عدم برخورد با حافظه پنهان (cache miss) به همراه دارد، محافظت میکنند.
دیدگاه آنتروپیک
آنتروپیک استدلال میکند که تخفیف بیشتر، مشوق استفاده مجدد است که میتواند بار محاسباتی کلی روی سرورهایش را کاهش دهد. آنها امیدوارند با ارزانتر کردن چشمگیر خواندن از حافظه پنهان، توسعهدهندگان عاملهایی طراحی کنند که به جای تغییر مداوم دستورات، مکرراً از یک مجموعه ابزار یکسان استفاده کنند. این معامله، جریمه بالاتری برای فراخوانیهای غیرقابل استفاده مجدد است که به گفته شرکت، توسعهدهندگان را به سمت رعایت اصول بهداشتی بهتر در نوشتن دستورات (prompt hygiene) سوق میدهد.
منتقدان خاطرنشان میکنند که بسیاری از عاملهای دنیای واقعی نیاز دارند پرامپتها را در لحظه تغییر دهند؛ افزودن کانتکست، برچسبهای زمانی یا انتخابهای پویای ابزارها اغلب ضروری است. برای این نوع بار کاری، قیمتگذاری جدید میتواند Anthropic را در مقایسه با ارائهدهندگانی که بدون توجه به میزان برخورد با کش (cache hits)، نرخ ثابتی دریافت میکنند، کمجذابیتتر کند.
آنچه باید در ادامه زیر نظر داشت
- بازنگری در قیمتگذاری – اگر بازخوردهای جامعه کاربری نشان دهد که شکاف بین برخورد و عدم برخورد با کش (hit-miss gap) بسیار زیاد است، Anthropic ممکن است ضرایب را بازتنظیم کند.
- قابلیتهای کنترل کش (Cache-control) – بهروزرسانیهای آتی API ممکن است به توسعهدهندگان اجازه دهد مشخص کنند کدام بخش از یک پرامپت باید از کلید کش مستثنی شود، که این امر راه حلی میانه را ارائه میدهد.
- واکنشهای رقبا – سایر ارائهدهندگان LLM ممکن است برای حفظ توان رقابتی، مدلهای کش خود را تغییر دهند؛ این کار میتواند از طریق ارائه قیمتگذاریهای ثابتتر یا در دسترس قرار دادن کنترلهای دقیقتر روی کش انجام شود.
نکته کلیدی
با قیمتگذاری جدید کش توسط Anthropic، هزینه عدم برخورد پرامپت با کش (prompt miss) دیگر یک ناراحتی جزئی نیست؛ بلکه یک اهرم مالی است که میتواند بودجه یک پروژه را به شدت تغییر دهد. تغییرناپذیر نگه داشتن پرامپتهای سیستم، تعاریف ابزار و متادیتای مرتبط، اکنون به اندازه نوشتن کد کارآمد اهمیت دارد. تیمهایی که قطعیت پرامپت (prompt determinism) را به عنوان یک معیار قابل اندازهگیری در نظر میگیرند، از صورتحسابهای غافلگیرکننده جلوگیری کرده و کنترل هزینههای عاملهای هوش مصنوعی خود را حفظ خواهند کرد.