Amazon Bedrock اکنون به توسعه‌دهندگان اجازه می‌دهد بخش‌هایی از یک پرامپت را کش (cache) کنند، که باعث کاهش هزینه‌های مصرف توکن تا ۹۰٪ و کاهش تأخیر پاسخ تا ۸۵٪ برای برنامه‌هایی می‌شود که از یک پیشوند ثابت در پرامپت استفاده می‌کنند.
چرا این تغییر اهمیت دارد
اجرای مدل‌های زبانی بزرگ به صورت درخواستی، با هر بار ارسال توکن‌ها به مدل، هزینه ایجاد می‌کند. چت‌بات‌ها، دستیارهای کدنویسی و ابزارهای جستجوی اسناد، اغلب دستورالعمل‌های سیستمی یا مطالب مرجع یکسانی را دوباره ارسال می‌کنند که باعث افزایش هزینه‌ها و کند شدن پاسخ‌ها می‌شود.
مکانیزم عملکرد کش کردن پرامپت
Bedrock یک پرچم (flag) با عنوان “cacheable” اضافه کرده است که توسعه‌دهندگان می‌توانند آن را به هر بخشی از پرامپت متصل کنند—این بخش‌ها معمولاً شامل دستورالعمل‌های سطح سیستم، اسناد پس‌زمینه طولانی یا تعاریف ابزارهایی هستند که در طول یک نشست (session) هرگز تغییر نمی‌کنند. هنگامی که درخواستی دریافت می‌شود، Bedrock بررسی می‌کند که آیا بخش علامت‌گذاری شده با یک ورودی ذخیره‌شده مطابقت دارد یا خیر. اگر مطابقت داشته باشد، سرویس از بازکدگذاری (re-encoding) و اجرای مجدد آن بخش از طریق مدل صرف‌نظر کرده و در عوض، نمایش پیش‌محاسبه‌شده را از کش فراخوانی می‌کند.
آمار و ارقام
- هزینه توکن ورودی: تا ۹۰٪ کاهش، زیرا پیشوند کش‌شده دیگر در هر فراخوانی توکن مصرف نمی‌کند.
- تأخیر (Latency): تا ۸۵٪ سریع‌تر، زیرا از انجام پردازش‌های سنگین مدل برای بخش ثابت جلوگیری می‌شود.
بهترین سناریوها برای استفاده
این قابلیت زمانی بیشترین کارایی را دارد که پرامپت شامل یک بلوک بزرگ و تغییرناپذیر باشد که پس از آن یک پرس‌وجوی کوتاه و متغیر از سوی کاربر می‌آید. الگوهای رایج عبارتند از:
- خط لوله‌های Retrieval-augmented generation (RAG) که یک سند بازیابی‌شده را به ابتدای هر پرس‌وجو اضافه می‌کنند.
- ربات‌های پشتیبانی مشتری که همیشه با یک بیانیه خط‌مشی یا متن تعیین‌کننده لحن یکسان شروع می‌شوند.
- دستیارهای کدنویسی که پیش از قطعه کد توسعه‌دهنده، یک تعریف ثابت از ابزار زبان را بارگذاری می‌کنند.
تغییراتی که توسعه‌دهندگان باید اعمال کنند
توسعه‌دهندگان باید ترتیب پرامپت را به‌گونه‌ای تغییر دهند که محتوای ثابت دقیقاً در ابتدا قرار گیرد و در تمامی فراخوانی‌ها، بیت‌به‌بیت (byte-for-byte) یکسان باقی بماند. ورودی متغیر کاربر پس از پیشوند کش‌شده می‌آید. نیازی به تغییر مدل نیست؛ همان endpoints Bedrock درخواست را مدیریت می‌کنند.
چه کسانی سود می‌برند و چه کسانی باید مراقب باشند
مزیت این قابلیت تنها برای حجم‌های کاری (workloads) اعمال می‌شود که در آن‌ها پیشوند واقعاً ثابت می‌ماند. برنامه‌هایی که دستورالعمل‌های سیستمی را برای هر کاربر شخصی‌سازی می‌کنند یا بافت (context) را مکرراً تغییر می‌دهند، سود چندانی نخواهند برد و باید پیچیدگی اضافه شده به پرامپت‌نویسی را در مقابل سود ناچیز آن بسنجند.
خلاصه کلام: کش کردن پرامپت، ابزاری ساده در اختیار کاربران Bedrock قرار می‌دهد تا هزینه‌های عملیاتی هوش مصنوعی را کاهش داده و زمان پاسخ‌دهی را بهبود بخشند، مشروط بر اینکه برنامه‌های آن‌ها بتواند یک پیشوند پرامپت قابل استفاده مجدد را مجزا کند.