اگر امروز برای هر درخواست کاربر، یک فراخوانی کامل به مدل‌های زبانی هزینه می‌پردازید، احتمالاً بخش بزرگی از بودجه‌تان را صرف پردازش درخواست‌های تکراری می‌کنید. طبق گزارشی که در ۱۹ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، استقرار یک استراتژی حافظه موقت چندلایه توانسته است نرخ برخورد (Hit Rate) را در نقاط دسترسی پرترافیک به ۳۵٪ برساند.
بسیاری از تیم‌های فنی برای کاهش هزینه‌ها بر مسیریابی ترافیک بین ارائه‌دهندگان مختلف تمرکز می‌کنند، اما این کار حجم درخواست‌های تکراری را نادیده می‌گیرد. این مسئله به‌ویژه در ابزارهای تخصصی مشهود است، همان‌طور که در بررسی نسبت ورودی‌های تکراری در عامل‌های کدنویسی مشاهده کردیم، این تکرارها عامل پنهان اتلاف بودجه هستند. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی حافظه در shoehorn اشاره کردیم، اکنون باید تمرکز را از بهره‌وری سخت‌افزاری به بهره‌وری درخواست‌ها تغییر دهیم. در واقع باید با فراخوانی‌های مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — مانند پرس‌وجوهای پایگاه‌داده برخورد کرد؛ به‌طوری که ورودی‌های تکراری نباید منجر به محاسبات گران‌قیمت مجدد شوند.
زمینه تکرار در ترافیک عملیاتی
بهینه‌سازی هزینه معمولاً روی قیمت هر توکن متمرکز است، اما اهرم واقعی، شناسایی «تکرارهای تغییرپوش» است. بر اساس بررسی‌های فنی، ترافیک عملیاتی اغلب شامل هم‌پوشانی‌های شدیدی است؛ مثلاً زمانی که یک پرامپت سیستمی یکسان با ورودی‌های تقریباً مشابه کاربر در هر بار فراخوانی دوباره به بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — تبدیل می‌شود.
همچنین پرسش‌هایی که در سیستم‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — توسط کاربران مختلف در بازه‌های زمانی کوتاه پرسیده می‌شوند، یا مراحل پیش‌پردازش قطعی که برای هر درخواست دوباره محاسبه می‌شوند، باعث اتلاف منابع می‌گردند.
جزئیات پیاده‌سازی
این استراتژی از سه لایه مجزا برای شکار انواع تکرارها استفاده می‌کند:
۱. حافظه موقت دقیق (Exact Cache)
این لایه کل درخواست، شامل پرامپت‌های سیستمی، پیام‌ها و پارامترها را هش (Hash) می‌کند. اگر هش تولید شده با یک ورودی ذخیره‌شده مطابقت داشته باشد، سیستم بلافاصله پاسخ را برمی‌گرداند.
- سازوکار: استفاده از هش SHA-256 برای درخواست‌های JSON (با کلیدهای مرتب‌شده) جهت ایجاد یک کلید منحصربه‌فرد.
- تأثیر: با وجود اینکه برخی این روش را برای پرامپت‌های پویا بیش از حد ساده می‌دانند، اما در عمل بخش بزرگی از هزینه‌های نقاط دسترسی پرترافیک را حذف کرد.
۲. حافظه موقت معنایی (Semantic Cache)
برای وظایفی مانند طبقه‌بندی یا پرسش‌وپاسخ‌های پایدار، تیم از بردارهای معنایی برای یافتن پرامپت‌های «تقریباً یکسان» استفاده کرد. این رویکرد یادآور تغییر موتور حافظه محلی به بردار معنایی در Arka Sentinel است که برای بهینه‌سازی پردازش داده‌ها طراحی شده بود.
سازوکار: سیستم ورودی کاربر را به بردار تبدیل کرده و در یک شاخص برداری به دنبال همسایه‌هایی با آستانه شباهت حدود ۰.۹۲ می‌گردد.
محدودیت: این لایه فقط برای وظایف قطعی (Deterministic) استفاده می‌شود تا از ارائه محتوای قدیمی یا تکراری در تولیدات خلاقانه جلوگیری شود؛ چرا که حافظه موقت در تولیدات خلاق منجر به «صداهای تکراری» می‌شود.
۳. حافظه موقت گام‌های قطعی (Deterministic-Step Cache)
بسیاری از فراخوانی‌های مدل در واقع کارهای ساده‌ای مثل تجزیه (Parsing)، نرمال‌سازی یا تبدیل فرمت هستند. تیم این موارد را به توابع خالص (Pure Functions) منتقل کرد که یک‌بار محاسبه و سپس بازاستفاده می‌شوند و مدل را کاملاً از چرخه خارج کردند.
برای حفظ عملکرد، سیستم از TTL (زمان ماندگاری) بر اساس نوسان داده‌ها استفاده می‌کند. پاسخ‌های مرجع پایدار، TTL طولانی می‌گیرند و داده‌های سریع، یا کوتاه حافظه می‌گیرند یا اصلاً ذخیره نمی‌شوند. طبق اعلام تیم توسعه، هزینه یک جست‌وجوی برداری باید کمتر از هزینه یک خطای حافظه (Model Miss) باشد تا سیستم توجیه‌پذیر بماند.
این تغییر، فرض بنیادین مبنی بر اینکه هر تعامل کاربر نیاز به یک استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — تازه دارد را تغییر می‌دهد. با اولویت دادن به «فراخوانی‌هایی که انجام نمی‌شوند»، توسعه‌دهندگان می‌توانند به تأخیر p95 زیر ۵۰ میلی‌ثانیه برسند که در مقایسه با صدها میلی‌ثانیه در فراخوانی‌های خام، پیشرفتی عظیم است.
برای جیب توسعه‌دهندگان، این یعنی با مقیاس‌پذیری برنامه، هزینه به‌ازای هر کاربر به‌شدت کاهش می‌یابد. اثر ترکیبی مسیریابی و حافظه موقت، مجموع صرفه‌جویی‌ها را در نقاط بهینه به بیش از ۴۰٪ رساند. این لایه در واقع زیرمجموعه مسیریابی و حفاظ‌ها قرار می‌گیرد؛ مشابه ساختار لایه‌ای در معماری نظارت بر محتوا که برای فیلتر کردن درخواست‌ها پیش از رسیدن به مدل استفاده می‌شود، فراخوانی‌ای که حذف شود، دیگر نیازی به مسیریابی یا محافظت ندارد.
گام بعدی شما
- لاگ‌های عملیاتی خود را برای اندازه‌گیری میزان هم‌پوشانی درخواست‌های تقریباً یکسان بررسی کنید.
- نرخ برخورد (Cache Hit Rate) را رصد کنید تا متوجه شوید چه زمانی «تغییر پرامپت» (Prompt Drift) رخ داده و زمان بازنگری در منطق حافظه موقت است.
- وظایف ساده تبدیل فرمت را از مدل زبانی خارج کرده و به توابع کدنویسی شده منتقل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو