AI SDK v5: افزایش سرعت پاسخ‌دهی عامل‌ها با سیستم نقاط کش

اگر یک عامل هوش مصنوعی با ده‌ها ابزار پیچیده مدیریت می‌کنید، احتمالاً هر بار برای ارسال داده‌های تکراری به API پول پرداخت می‌کنید. BrainGrid، پلتفرم تخصصی مستندات فنی، دریافت که ارسال مداوم طرح‌های ابزار (Tool Schemas)، درست مثل این است که برای قهوه‌ای که هرگز نمی‌نوشید، هر روز پول بدهید.

طبق گزارش این تیم در ۱۷ ژوئن ۲۰۲۶، آن‌ها توانستند با یک تغییر ساده در پیکربندی، هزینه‌های توکن را به‌شدت کاهش دهند. این موفقیت از طریق پیاده‌سازی کشینگ موقت (Ephemeral Caching) — سیستمی که داده‌های تکراری را در سرور ذخیره می‌کند تا هر بار ارسال نشوند — حاصل شد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی توکن‌ها اشاره کردیم، مدیریت پنجره متنی کلید سودآوری در مقیاس است.

زمینه: پلتفرم BrainGrid

BrainGrid ابزاری است که ایده‌های پراکنده برنامه‌نویسان را به مستندات دقیق تبدیل می‌کند تا دستیارهای کدنویسی بتوانند آن‌ها را اجرا کنند. این پلتفرم کدبیس‌ها را تحلیل می‌کند، سوالات شفاف‌کننده می‌پرسد و نیازمندی‌ها را به وظایف اتمیک، قابل تایید و آماده برای هوش مصنوعی تبدیل می‌کند. این وظایف در نهایت به پرامپت‌های دقیقی با کانتکست کامل برای IDEهای هوش مصنوعی مانند Cursor یا Claude Code تبدیل می‌شوند.

برای دستیابی به این هدف، BrainGrid چندین عامل تخصصی را با استفاده از ده‌ها ابزار مختلف مدیریت می‌کند. چون این ابزارها هسته منطق عامل هستند، باید در هر درخواست API ارسال شوند و این یعنی مصرف توکن بسیار بالا.

مشکل: سوختن توکن‌ها

در گردش‌کارهای عامل‌محور، این ناکارآمدی ضربدر می‌شود؛ یعنی یک نوبت گفتگو شامل ارسال سوال کاربر، مجموعه کامل تعاریف ابزارها، فراخوانی ابزار توسط AI و سپس ارسال نتایج است که در آن تعاریف ابزارها دوباره ارسال می‌شوند.

به نقل از تیم فنی BrainGrid، این اتلاف منابع بسیار قابل توجه است:

• یک ابزار ساده، مانند read_web_page دارای طرحی است که به تنهایی صدها توکن مصرف می‌کند.
• وقتی این مقدار در ده‌ها ابزار و چندین نوبت گفتگو ضرب شود، توکن‌ها به‌سرعت می‌سوزند.
• از آنجایی که تعاریف ابزارها به‌ندرت تغییر می‌کنند، سیستم در واقع برای ارسال داده‌های استاتیک تکراری هزینه می‌پردازد که علاوه بر هزینه، سرعت عملکرد را نیز کاهش می‌دهد.

این تیم هنگام مهاجرت به AI SDK v5 متوجه این موضوع شد. دلیل اولیه این مهاجرت، نیاز به تایپ‌های صحیح TypeScript و استریم کردن ابزارها بود، اما در نهایت آن‌ها را به قابلیتی رساند که در یادداشت‌های انتشار (Release Notes) پنهان شده بود: پشتیبانی از کشینگ موقت توسط Anthropic از طریق پارامتر providerOptions.

جزئیات: سازوکار کشینگ

کشینگ موقت Anthropic به توسعه‌دهندگان اجازه می‌دهد تعاریف ابزارها را به عنوان «کش‌شدنی» علامت‌گذاری کنند تا در سرور برای استفاده مجدد ذخیره شوند. اگرچه مستندات این ویژگی پراکنده بود، اما مبادلات مالی و فنی آن کاملاً شفاف است:

• هزینه اولیه (Premium): کاربران برای اولین بار ۲۵٪ مبلغ بیشتری برای توکن‌های ورودی کش‌شده می‌پردازند.
• تخفیف در دفعات بعد (Cache Hit): دسترسی‌های بعدی به کش تنها ۱۰٪ قیمت استاندارد توکن ورودی هزینه دارد.
• نقطه سر‌به‌سر (Break-even Point): اگر ابزارها بیش از چهار بار در یک گفتگو استفاده شوند، هزینه اولیه جبران شده و سیستم وارد مرحله صرفه‌جویی خالص می‌شود.

پیاده‌سازی این مورد به عنوان یک «میوه کم‌ارتفاع» (راهکاری ساده و سریع) توصیف شده است که تنها به سه خط پیکربندی در تعریف ابزار نیاز دارد:

1. پارامتر providerOptions باید تعریف شود.
2. شیء anthropic باید مشخص گردد.
3. مقدار cacheControl باید روی type: 'ephemeral' تنظیم شود.

نکته فنی: ترفند «نقطه کش»

یک نکته فنی حیاتی در این مسیر وجود دارد: ترتیب ابزارها اهمیت دارد. Anthropic از سیستمی به نام «نقطه کش» (Cache Point) استفاده می‌کند؛ به این معنا که هر چیزی که در درخواست قبل از یک ابزار کش‌شدنی قرار بگیرد، خودش هم به‌طور خودکار کش می‌شود.

به همین دلیل BrainGrid تمام ابزارها را علامت‌گذاری نکرد. آن‌ها فقط آخرین ابزار لیست خود را پیکربندی کردند. برای مثال، در آرایه‌ای شامل generateRequirements ،generateSubtasks ،clarifyingQuestions ،thinking و webSearch ، تنها ابزار نهایی یعنی readWebPage نیاز به پیکربندی کشینگ دارد تا اطمینان حاصل شود تمام ابزارهای قبلی نیز در کش قرار می‌گیرند.

نتایج

پس از استقرار این تغییر، تیم سه مزیت اصلی را مشاهده کرد:

1. کاهش هزینه‌ها: علی‌رغم پرداخت ۲۵٪ مبلغ بیشتر برای توکن‌های اولیه، هزینه‌های کلی توکن کاهش یافت.
2. افزایش سرعت: پرس‌وجوها «تیزتر» و سریع‌تر به نظر می‌رسند زیرا داده‌های کمتری در هر درخواست منتقل می‌شود.
3. پایداری: هیچ تغییری در رفتار هوش مصنوعی مشاهده نشد؛ سیستم صرفاً بهینه‌تر عمل کرد.

برای توسعه‌دهندگان، این تجربه نشان می‌دهد که اثرگذارترین بهینه‌سازی‌ها اغلب مبتنی بر پیکربندی هستند، نه تغییرات گسترده معماری. در حالی که BrainGrid هفته‌ها وقت صرف بازنویسی پرامپت‌ها و کانتکست کرده بود، پیشرفت واقعی از طریق چند خط تنظیمات در SDK حاصل شد.

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

گام بعدی شما

• لیست ابزارهای (Tool Array) عامل‌های خود را بررسی کنید و ابزارهای سنگین و ثابت را به انتهای لیست ببرید.
• اگر از مدل‌های Anthropic استفاده می‌کنید، پارامتر cacheControl را روی ephemeral تنظیم کنید.
• تعداد دفعات تکرار ابزارها در هر گفتگو را اندازه بگیرید تا نقطه سر‌به‌سر هزینه را پیدا کنید.

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