تحلیل Anthropic: مدل‌های گران‌تر در مدیریت حافظه به‌صرفه‌تر هستند

تصور کنید برای کاهش هزینه‌ها، حجم کاری خود را به ارزان‌ترین مدل موجود منتقل کنید، اما دقیقاً همین تصمیم باعث غیرفعال شدن سیستم تخفیف هزینه‌ها و افزایش صورت‌حساب شما شود. در یک تحلیل دقیق که در وب‌سایت michael-kaminski.io منتشر شد، مایکل کامینسکی، توسعه‌دهنده و تحلیل‌گر، فاش کرد که «کفِ حافظه» (Cache Floor) در مدل‌های Anthropic به‌صورت معکوس با قیمت آن‌ها رابطه دارد؛ یعنی هرچه مدل ارزان‌تر باشد، برای ذخیره کردن داده‌ها در حافظه به متن طولانی‌تری نیاز دارد.

حافظه پرامپت (Prompt Caching) — شبیه به یادداشت‌برداری از دستورات تکراری است تا مدل هر بار مجبور نباشد کل کتابچه راهنما را از اول بخواند — برای کاهش هزینه‌های استنتاج (Inference) طراحی شده است. این قابلیت با ذخیره کردن بلاک‌های دستورالعمل ثابت، مانند پرامپت‌های سیستم (System Prompts) یا تعاریف ابزارها (Tool Definitions)، اجازه می‌دهد تا این بخش‌ها در هر فراخوانی مجدداً محاسبه و صورت‌حساب نشوند. برای توسعه‌دهندگانی که عامل‌های هوش مصنوعی (AI Agents) می‌سازند، این قابلیت اصلی‌ترین ابزار کاهش هزینه است. اما مشکل اینجاست که اگر طول پرامپت از یک حد نصاب یا «کف» (Floor) مدل کمتر باشد، سیستم بدون دادن هیچ خطایی، درخواست را به‌صورت «بدون حافظه» پردازش می‌کند و هزینه کامل را می‌گیرد. این موضوع در ادامه استراتژی‌های گسترده‌تری برای بهینه‌سازی قرار می‌گیرد، چرا که حذف کامل فراخوانی‌های مدل در لایه‌های بالاتر همچنان مؤثرترین راه برای کاهش هزینه‌های نهایی است.

نردبان کف‌های حافظه

طبق مستندات Anthropic که در ۱۳ سپتامبر ۲۰۲۶ بررسی شده است، حد نصاب حافظه برای مدل‌ها به‌صورت پلکانی و بر اساس مدل تعریف شده است:

• Opus 5: ۵۱۲ توکن
• Sonnet 5: ۱,۰۲۴ توکن
• Haiku 4.5: ۴,۰۹۶ توکن

این وضعیت یک پارادوکس ایجاد می‌کند: مدل گران‌ترین (Opus 5)، که هر میلیون توکن ورودی را ۵ دلار محاسبه می‌کند، تقریباً هر متنی را در حافظه نگه می‌دارد. در مقابل، ارزان‌ترین مدل (Haiku 4.5)، که قیمت آن ۱ دلار در هر میلیون توکن است، برای فعال کردن حافظه به پیشوندی نیاز دارد که ۸ برابر طولانی‌تر از مدل گران باشد. مستندات صراحتاً ذکر کرده‌اند: درخواست‌هایی که زیر این کف باشند، «بدون حافظه پردازش شده و هیچ خطایی بازگردانده نمی‌شود».

اثر واقعی بر فایل‌های مهارت (Skill Files)

برای سنجش اثر واقعی این موضوع، کامینسکی ۵۳ «فایل مهارت» (بلاک‌های دستوری ثابت) را که در Claude Code و Cowork استفاده می‌شوند، بررسی کرد. این فایل‌ها شامل ۵ فایل شخصی و ۴۸ فایل مربوط به پلاگین‌های نصب‌شده بودند. او برای شمارش کاراکترها از یک اسکریپت شل ۲۲ خطی شامل دستورات find ،wc -c و awk استفاده کرد و نرخ تبدیل را ۳.۸ کاراکتر به ازای هر توکن در نظر گرفت. این تحلیل در واقع مکمل بررسی‌های پیشین است که نشان داد کشینگ API چگونه مصرف توکن‌های Claude Code را تا ۶۰٪ کاهش داد.

این تبدیل، آستانه‌های کاراکتری را به ۱۹۴۶، ۳۸۹۱ و ۱۵,۵۶۵ کاراکتر می‌رساند. نتایج که در ۱۳ سپتامبر ۲۰۲۶ مجدداً اجرا شدند، توزیع تکان‌دهنده‌ای از موفقیت‌های حافظه (Cache Hits) را نشان می‌دهند:

• Opus 5 (کف ۵۱۲ توکن): ۱۰۰٪ (۵۳ از ۵۳ فایل) از کف عبور کردند.
• Sonnet 5 (کف ۱,۰۲۴ توکن): ۸۳٪ (۴۴ از ۵۳ فایل) از کف عبور کردند.
• Haiku 4.5 (کف ۴,۰۹۶ توکن): تنها ۲۲٪ (۱۲ از ۵۳ فایل) توانستند حافظه را فعال کنند.

جزئیات توزیع داده‌ها

بررسی دقیق‌تر اندازه فایل‌ها نشان می‌دهد که کوچک‌ترین فایل ۲,۰۰۹ کاراکتر، میانه (Median) ۸,۹۹۴ کاراکتر و بزرگ‌ترین فایل ۳۲,۰۰۲ کاراکتر بوده است. با استفاده از نرخ تبدیل توکن، این مقادیر تقریباً برابر با ۵۳۰، ۲,۳۷۰ و ۸,۴۲۰ توکن هستند.

شکاف موجود بسیار عمیق است: ۴۱ فایل از ۵۳ مورد، زیر کف مدل Haiku قرار دارند. ۹ فایل زیر کف مدل Sonnet هستند و هیچ فایلی زیر کف مدل Opus نیست. این نتیجه حاصل یک مورد استثنایی (Outlier) نیست؛ بلکه بزرگ‌ترین فایل ۱۶ برابر کوچک‌ترین فایل است. یک فایل مهارت معمولی که دقیقاً برای انجام وظیفه‌اش نوشته شده و نه بیشتر، درست در محدوده‌ای قرار می‌گیرد که ارزان‌ترین مدل از ذخیره کردن آن در حافظه امتناع می‌کند. در این راستا، رویکردهایی مانند فلسفه کدنویسی حداقلی Ponytail تلاش می‌کنند تا با جلوگیری از پیچیدگی بیش از حد عامل‌ها، مدیریت این محدودیت‌ها را ساده‌تر کنند.

ریاضیات مدل «ارزان»

وقتی پرامپت زیر حد نصاب باشد، هزینه با نرخ پایه ورودی محاسبه می‌شود. کامینسکی یک فایل میانه با ۲,۳۶۷ توکن را در ۱,۰۰۰ فراخوانی تحلیل کرد و فرض کرد در صورت فعال بودن حافظه، نرخ موفقیت بازیابی ۹۰٪ باشد. او از نرخ‌های منتشر شده استفاده کرد: نرخ پایه ورودی، هزینه نوشتن حافظه (Cache Write) برای ۵ دقیقه با ضریب ۱.۲۵ برابر، و هزینه خواندن حافظه (Cache Read) با ضریب ۰.۱ برابر.

• Haiku 4.5 (بدون حافظه): ۲.۳۷ میلیون توکن با قیمت ۱.۰۰ دلار در هر میلیون = ۲.۳۷ دلار
• Sonnet 5 (با حافظه): ۱۰٪ نوشتن با قیمت ۲.۵۰ دلار و ۹۰٪ خواندن با قیمت ۰.۲۰ دلار = ۰.۵۹ + ۰.۴۳ = ۱.۰۲ دلار
• Opus 5 (با حافظه): نوشتن با قیمت ۶.۲۵ دلار و خواندن با قیمت ۰.۵۰ دلار = ۱.۴۸ + ۱.۰۶ = ۲.۵۴ دلار

در این سناریو، مدل Sonnet 5 حدود ۵۷٪ ارزان‌تر از Haiku 4.5 تمام شد، چون حافظه‌اش فعال بود. حتی مدل گران‌قیمت Opus 5 با حافظه فعال، تنها ۷٪ گران‌تر از مدل ارزان‌قیمت (بدون حافظه) بود (اختلافی معادل ۱۷ سنت در هر هزار فراخوانی).

نقطه تلاقی (Crossover Point)

برای یافتن نقطه سربه‌سر، هزینه ترکیبی ورودی برای Sonnet به صورت 2.50(1 − h) + 0.20h یا 2.50 − 2.30h محاسبه می‌شود (که در آن h نرخ موفقیت یا Hit Rate است). در مقایسه با نرخ ثابت ۱.۰۰ دلار برای Haiku بدون حافظه، نقطه تلاقی در h = 0.65 رخ می‌دهد.

یعنی اگر نرخ موفقیت حافظه بالای ۶۵٪ باشد، Sonnet 5 با حافظه، در بخش ورودی ارزان‌تر از Haiku 4.5 بدون حافظه است. اگرچه Haiku برای خروجی ۵ دلار و Sonnet ۱۰ دلار در هر میلیون توکن می‌گیرد، اما تعاملات عامل‌های مبتنی بر مهارت (Skill-driven) با پیشوندهای طولانی و ثابت و پاسخ‌های کوتاه شناخته می‌شوند؛ یعنی دقیقاً همان ساختاری که حافظه برای آن ساخته شده است.

حالت شکست خاموش

یکی از خطرناک‌ترین جنبه‌های این سازوکار، «خاموش» بودن آن است. وقتی پرامپت برای ذخیره در حافظه بیش از حد کوتاه باشد، هیچ خطای API دریافت نمی‌کنید. تنها راه تشخیص یک عدم موفقیت (Miss)، مانیتور کردن فیلدهای cache_read_input_tokens و cache_creation_input_tokens در پاسخ است؛ اگر هر دو صفر باشند، یعنی درخواست با نرخ کامل پایه صورت‌حساب شده است.

برای توسعه‌دهندگانی که از ابزارهای واسط (Third-party harnesses) استفاده می‌کنند، این یک نقطه کور بحرانی است. کامینسکی متوجه شد که هیچ کنترلی روی پرچم cache_control ندارد، زیرا پیشوندهای او توسط ابزاری که مالک آن نبود (Claude Code و Cowork) اسمبل و ارسال می‌شدند. او هرگز درخواست واقعی را نمی‌دید، به این معنی که تنها اهرم در دست او، طول فایل و مدلی بود که توسط مسیریاب (Router) انتخاب می‌شد.

استراتژی‌های بهینه‌سازی

دو راه اصلی برای مدیریت این کف‌ها وجود دارد:

۱. پدینگ (Padding): اضافه کردن توکن‌های بی‌اثر به هر فایل مهارت تا به ۴,۰۹۶ توکن برسند و حافظه در همه مدل‌ها فعال شود. برای فایل میانه، این کار نیاز به ۱,۷۲۹ توکن اضافی (افزایش ۷۳٪) دارد. اگرچه این کار می‌تواند هزینه ۱,۰۰۰ فراخوانی در Haiku را به ۰.۸۸ دلار (ارزان‌ترین حالت ممکن) کاهش دهد، اما توکن‌های غیرضروری را در هر فراخوانی به پنجره کانتکست تحمیل می‌کند.

۲. منطق مسیریابی (Routing Logic): پذیرفتن این واقعیت که مسیریابی به مدل ارزان و حافظه پرامپت، دو بهینه‌سازی متضاد هستند. تعاملات سنگین از نظر مهارت را از Haiku 4.5 دور نگه دارید، مگر اینکه طول پیشوند از کف حافظه عبور کند.

قوانینی برای مالکان API

اگر کد شما مستقیماً API را فراخوانی می‌کند، سه قانون از این داده‌ها استخراج می‌شود:

• اندازه‌گیری بر اساس کف: پیشوند مشترک خود را بر اساس کف ارزان‌ترین مدلی که احتمال مسیریابی به آن وجود دارد (۴,۰۹۶ برای Haiku 4.5) تنظیم کنید، یا اصلاً آن را به آن مدل منتقل نکنید.
• تست از طریق فیلدهای مصرف: مقدار cache_read_input_tokens را برای هر فراخوانی ثبت کنید و هرگاه در درخواستی که انتظار داشتید حافظه فعال باشد مقدار صفر ثبت شد، هشدار (Alert) فعال کنید.
• محاسبه نقطه تلاقی: نرخ موفقیت (Hit Rate) خاص خود را اندازه بگیرید. اگر بالای ۶۵٪ است، Sonnet 5 در ورودی‌ها بر Haiku 4.5 پیروز می‌شود.

این یافته، فرض بنیادی مبنی بر اینکه «ارزان‌ترین مدل همیشه اقتصادی‌ترین انتخاب است» را تغییر می‌دهد. برای گردش‌کارهای عامل‌محور، «کف حافظه» محرک واقعی قیمت است و جدول کف‌ها باید در تنظیمات مسیریاب باشد، نه در پاورقی مستندات.

گام بعدی شما

• اگر مستقیماً از API استفاده می‌کنید، طول پیشوندهای مشترک خود را با کف حافظه ارزان‌ترین مدل (۴,۰۹۶ توکن برای Haiku) تطبیق دهید.
• سیستم مانیتورینگ خود را به‌گونه‌ای تنظیم کنید که اگر cache_read_input_tokens در درخواست‌های تکراری صفر شد، هشدار دهد.
• نرخ موفقیت حافظه (Hit Rate) خود را اندازه بگیرید؛ اگر بالای ۶۵٪ است، برای ورودی‌ها از Sonnet 5 استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.