اگر امروز برای پردازش متون طولانی در GPT-4 هزینه پرداخت می‌کنید، احتمالاً بخش بزرگی از بودجه شما صرف پردازش تکراری دستورالعمل‌های ثابت می‌شود. این اتلاف منابع در برنامه‌های تولیدی، جایی که یک بات پشتیبانی باید در هر پیام، کل دفترچه راهنمای محصول را دوباره بخواند، به یک گلوگاه مالی تبدیل شده است. برای مثال، یک خط لوله RAG ممکن است در هر پرسش تکمیلی، مجموعه‌ای از اسناد بازیابی‌شده یکسان را دوباره در پرامپت بگنجاند. این چالش‌ها در واقع بخشی از تصمیم‌گیری‌های استراتژیک در معماری سیستم‌هاست که در راهنمای انتخاب میان پرامپت، RAG و تنظیم دقیق برای استقرار AI در سال ۲۰۲۶ به تفصیل بررسی کردیم.
طبق گزارش ۱۲ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، تکنیکی به نام کشینگ پرامپت (Prompt Caching) این مشکل را حل کرده و می‌تواند هزینه توکن‌های ورودی ذخیره‌شده را تقریباً ۹۰ درصد کاهش دهد. این روش با ذخیره وضعیت محاسباتی پیشوندهای ثابت، تضمین می‌کند که شما تنها برای بخش‌های جدید و متغیر پرس‌وجوی کاربر هزینه کامل بپردازید.
همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش تأخیر در شخصی‌سازی‌های مقیاس‌پذیر اشاره کردیم، این رویکرد با وضعیت توجه مدل برخورد می‌کند، درست مانند اینکه یک مرورگر وب، تصویر یک سایت را کش می‌کند تا هر بار آن را دانلود نکند. در این حالت، مدل به‌جای بازخوانی مداوم یک سند طولانی یا مجموعه‌ای از تعاریف ابزارها هر بار که کاربر سؤالی می‌پرسد، صرفاً وضعیت محاسباتی قبلی را بارگذاری می‌کند. این کار باعث حذف تأخیر پیش‌پُرکردن برای پیشوند می‌شود و در نتیجه زمان تا نخستین توکن (Time to First Token) به‌شدت افت می‌کند.
زمینه: درک سازوکار فنی
برای درک دلیل اثرگذاری این روش، باید به دو مرحله تولید توجه کرد: پیش‌پُرکردن (Prefill) و رمزگشایی (Decoding). در مرحله پیش‌پُرکردن، مدل تمام پرامپت را در یک گذر reading می‌خواند و هزینه و زمان آن با طول پرامپت رابطه مستقیم دارد. سپس در مرحله رمزگشایی، پاسخ توکن به توکن تولید می‌شود. در سناریوهایی با پرامپت‌های طولانی و پاسخ‌های کوتاه، مرحله پیش‌پُرکردن عامل اصلی هزینه و تأخیر است.
مدل‌ها در هر بار تولید، از کارهای قبلی خود استفاده می‌کنند. وقتی مدل در حال تولید توکن ۵۰۰ام است، توکن‌های ۱ تا ۴۹۹ را دوباره نمی‌خواند؛ بلکه تنسورهای توجه کلید/مقدار (KV attention tensors) را در یک KV Cache نگه می‌دارد و از آن‌ها استفاده مجدد می‌کند. کشینگ پرامپت دقیقاً همین ترفند است، اما به‌جای یک درخواست، در چندین درخواست API مختلف اعمال می‌شود. ارائه‌دهنده به‌جای حذف وضعیت پیش‌پُرکردن در پایان هر تماس، آن را بر اساس بایت‌های دقیق پیشوند ذخیره می‌کند.
برای پیاده‌سازی این سازوکار، توسعه‌دهندگان باید پرامپت‌ها را به دو بخش متمایز تقسیم کنند:
- پیشوند ثابت: دستورالعمل‌های سیستمی، تعاریف ابزار، اسناد طولانی و نمونه‌های چند-شات (few-shot) که در تمام تماس‌ها یکسان هستند. این بخش از مدیریت ابزارها در واقع تکاملی از رویکرد جدید مدیریت ابزارهای خارجی AI است تا مدل‌های سبک‌تر بتوانند با بهره‌وری بیشتری عمل کنند.
- پسوند متغیر: پرسش خاص کاربر یا داده‌های پویا که در هر بار تغییر می‌کنند.
جزئیات: پیاده‌سازی و محدودیت‌های فنی
تطبیق در کشینگ به‌صورت «تطبیق دقیق پیشوند» انجام می‌شود. کلید کش شامل بایت‌های دقیق از ابتدای پرامپت تا یک نقطه شکست (breakpoint) است. این قانون «یا تطابق کامل یا شکست» (byte-identical or bust)، پیامدهای حیاتی دارد:
- ترتیب قطعی: محتوای ثابت باید حتماً در ابتدا و محتوای متغیر در انتها باشد. ترتیب رندر، به اندازه خودِ محتوا اهمیت دارد.
- نابودکنندگان خاموش کش: هر عنصری که باعث تغییر بایت‌ها شود، کلید را تغییر می‌دهد. مواردی مانند استفاده از
datetime.now()در پرامپت سیستمی، درج شناسه‌های درخواست (request ID)، قرار دادن نام‌های کاربری در بخش‌های بالایی متن یا فراخوانی‌های نامرتبjson.dumps()، باعث شکست کش می‌شوند. - لیست‌های پویا: جابه‌جا کردن ترتیب یک لیست از ابزارها در میان گفتگو، باعث بروز Cache Miss شده و مدل را مجبور می‌کند تمام محتوای بعد از نقطه تغییر را دوباره پیش‌پُر کند.
موازنه هزینه و عملکرد
کشینگ رایگان نیست، اما به‌سرعت به نقطه سربه-سرب می‌رسد. نوشتن در کش هزینه بیشتری دارد — حدود ۱.۲۵ برابر قیمت پایه برای زمان بقای (TTL) ۵ دقیقه‌ای و ۲ برابر برای TTL یک‌ساعته. با این حال، هر خوانش بعدی از کش تنها در حدود ۰.۱ برابر قیمت ورودی پایه هزینه دارد.
با TTL ۵ دقیقه‌ای، دومین تماس به‌تنهایی هزینه اضافی نوشتن را جبران می‌کند (زیرا ۱.۲۵ + ۰.۱ کمتر از پرداخت ۲ برابر برای حالت بدون کش است). اما برای TTL یک‌ساعته، معمولاً سه تماس لازم است تا عملیات سودآور شود. نکته مهم این است که کشینگ معمولاً فقط برای پیشوندهایی با طول حداقلی فعال می‌شود؛ این آستانه بسته به مدل، معمولاً بین ۱۰۲۴ تا ۴۰۹۶ توکن است. پایین‌تر از این حد، کشینگ به‌طور مخفیانه هیچ کاری انجام نمی‌دهد.
تفاوت ارائه‌دهندگان و روش تأیید
شرکت‌ها این قابلیت را متفاوت پیاده کرده‌اند. آنتروپیک (Anthropic) صریح است؛ کاربران باید یک نقطه شکست cache_control در آخرین بلوک ثابت قرار دهند. آنتروپیک به‌صورت پیش‌فرض TTL ۵ دقیقه‌ای را در نظر می‌گیرد، اما گزینه یک‌ساعته نیز دارد که در آن هر Hit باعث بازنشانی تایمر می‌شود. برای مدیریت ترافیک‌های شدید و ناگهانی (bursty traffic)، توسعه‌دهندگان می‌توانند با یک تماس ارزان در زمان شروع، کش را «پیش‌گرم» (pre-warm) کنند. در مقابل، OpenAI و سایر ارائه‌دهندگان معمولاً پیشوندهای طولانی را پس از عبور از یک آستانه مشخص، به‌صورت خودکار کش می‌کنند. این استراتژی‌های بهینه‌سازی هزینه در محیط‌های واقعی را می‌توان در تجربه کاهش هزینه‌های API آنتروپیک با سیستم نقاط کش مشاهده کرد.
توسعه‌دهندگان برای تأیید موفقیت نباید به نبود خطا تکیه کنند، بلکه باید فیلدهای مصرف را تحلیل کنند:
cache_creation_input_tokens: نشان‌دهنده آنچه نوشته شده (شکست کش یا Miss).cache_read_input_tokens: نشان‌دهنده آنچه بازاستفاده شده (موفقیت کش یا Hit).
اگر مقدار Reads در تماس‌هایی که یکسان به نظر می‌رسند صفر باقی بماند، توسعه‌دهندگان باید بایت‌های رندر شده‌ی واقعی بین دو درخواست را مقایسه (diff) کنند تا عاملی که باعث ابطال کش می‌شود را پیدا کنند.
این تغییر، اقتصاد برنامه‌های مبتنی بر تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، ابتدا کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را به‌طور بنیادی تغییر می‌دهد. وقتی هزینه بارگذاری زمینه به ۱۰ درصد می‌رسد، توسعه‌دهندگان می‌توانند بدون انفجار صورت‌حساب، اسناد بسیار بیشتری را به پرامپت اضافه کنند. اگر در حال بهینه‌سازی یک عامل (Agent) تولیدی هستید، گام بعدی شما باید حسابرسی پرامپت سیستمی برای شناسایی هرگونه رشته غیرقطعی باشد که به‌طور مخفیانه Hitهای کش شما را نابود می‌کند.
گام بعدی شما
- پرامپت‌های سیستمی خود را برای شناسایی رشته‌های غیرقطعی (مثل تاریخ و ساعت جاری) که باعث حذف کش می‌شوند، بازبینی کنید.
- در مدل‌های آنتروپیک، نقاط شکست
cache_controlرا دقیقاً در انتهای بخش‌های ثابت تعریف کنید. - مقدار
cache_read_input_tokensرا در لاگ‌های خود پایش کنید تا نرخ موفقیت کش (Cache Hit Rate) را بسنجید.
اما تأثیر این بهینه‌سازی بر سرعت پاسخ‌دهی عامل‌های پیچیده حتی خیره‌کننده‌تر است؛ به بررسی ما درباره معماری‌های استدلالی جدید مراجعه کنید.
گفتگو