سود:
- منطق تطبیق پیشوند در حافظه پنهان را توضیح دهید
- با قرار دادن متن ثابت در ابتدا و پس از آن متن متغیر، ضربه حافظه پنهان را افزایش می دهد
- می تواند اقتصاد نوشتن/خواندن حافظه پنهان و نقطه سربه سر را محاسبه کند
یک محصول LLM در نمونه اولیه ارزان به نظر می رسد. وقتی به سطح ترازو می روید، صورت حساب شگفت زده می شود. در بیشتر بارهای کاری، بیشتر صورتحساب از همان زمینه ثابتی می آید که با هر درخواست بارها و بارها ارسال می شود: یک اعلان طولانی سیستم، یک دفترچه قوانین، اسناد مرجع. ذخیره سریع دقیقاً این ضایعات را از بین می برد. در این بخش، نحوه عملکرد کش، نحوه ترتیب دادن دستور ضربه زدن و نحوه محاسبه نقطه سربه سر اقتصاد کش را خواهید آموخت. هنگامی که به درستی نصب شود، به تنهایی می تواند صورتحساب شما را نصف یا حتی کمتر کند.
کش چگونه کار می کند؟ یک قانون تغییرناپذیر
ذخیره سریع یک پیشوند مطابقت دارد. ارائه دهنده به طور موقت توکن هایی را که از ابتدای درخواست شما پردازش کرده است ذخیره می کند. اگر اعلان در درخواست بعدی با همان پیشوند شروع شود، این قسمت مشترک دوباره محاسبه نمی شود. خواندن آن بسیار ارزان تر از حافظه پنهان است.
یک قانون تغییرناپذیر از این نتیجه می گیرد: اگر یک بایت در جایی از پیشوند تغییر کند، کل کش از آن نقطه به بعد نامعتبر می شود. یعنی محتوای ثابت در ابتدا و محتوای متغیر در انتها باشد. اگر خطی را در ابتدای فرمان سیستم قرار دهید که با هر درخواست تغییر می کند، مانند "تاریخ امروز: 18.07.2026"، هر چیزی که پشت آن است نمی تواند وارد حافظه پنهان شود.
ترتیب پردازش معمولاً عبارت است از: ابزارها → اعلان سیستم → پیام ها. شما نقطه کش (نقطه شکست) را در انتهای بخش ثابت قرار می دهید.
اقتصاد کش
کش دارای سه سطح قیمت است:
- نوشتن در حافظه پنهان: برای اولین بار ذخیره می شود. ~ 1.25 برابر قیمت ورودی معمولی (برای ذخیره سازی 5 دقیقه).
- Cache read: خواندن درخواست های بعدی. 0.1 برابر قیمت ورودی معمولی - یعنی یک دهم.
- ورودی عادی: بخشی که وارد کش نمی شود و هر بار با تمام هزینه پردازش می شود.
نقطه سربه سر: اولین درخواست حق بیمه پرداخت می کند (1.25×). از درخواست دوم، خواندن (0.1×) وارد عمل می شود. به طور تقریبی، شما در دو درخواست گردن و گردن خواهید بود. پس از آن، پس انداز خالص است. هرچه زمینه ثابت بزرگتر باشد و درخواستهای بیشتری از آن استفاده شود، سود بزرگتر میشود.
سناریو
آیا کش کار می کند؟
اعلان بزرگ سیستم ثابت، هزاران درخواست
بله - بالاترین درآمد
سوالات زیادی در مورد همان اسناد مرجع
بله
متن کوتاه کاملا متفاوت برای هر درخواست
خیر - جایزه نوشتن تلف می شود
درخواست یکباره
نه - اصلاً مطالعه ندارم
تغییر تاریخ/شناسه با هر درخواست در اعلان سیستم
خیر - پیشوند خراب است، ضربه صفر است
گام به گام: چگونه یک اعلان ضربه تنظیم کنیم؟
- ثابت و متغیر را جدا کنید. چه محتوایی هرگز تغییر نمی کند (اعلام سیستم، دفترچه قوانین، مستندات)؟ کدام یک با هر درخواست تغییر می کند (سوال کاربر، تاریخ، شناسه)؟
- ثابت را در ابتدا قرار دهید. در حین پردازش، قسمتی که اول می شود (ابزارها، سیستم) باید پایدار باشد.
- متغیر را در آخر قرار دهید. سوال فعلی کاربر، آخرین.
- علامت را در انتهای حاشیه قرار دهید. نقطه کش را در آخرین بلوک قسمت ثابت قرار دهید.
- تایید ضربه. بررسی کنید که آیا cache_read_input_tokens در قسمت استفاده در پاسخ، بزرگتر از صفر است. اگر صفر باشد، یک مختل کننده پنهان در پیشوند وجود دارد.
{ "system": [ { "type": "text"، "text": "{{large_constant_system_promptu_and_rules}}"، "cache_control": { "type": "Ephemeral" } } ], "messages": [ { "role": "user", "content}_rent":{{user}_content]
نکته: بازدیدهای کش را حدس نزنید، آنها را اندازه بگیرید. اگر usage.cache_read_input_tokens همچنان در درخواستهای متوالی صفر است، یک خاموش کننده خاموش (datetime.now() در فرمان سیستم، JSON نامرتب، فهرست ابزارهایی که با هر درخواست تغییر میکنند) در حال اجرا است. دستور خام دو درخواست را بایت به بایت مقایسه کنید و تفاوت را پیدا کنید.
اخلالگران خاموش
الگوهای معمولی که ناخودآگاه حافظه پنهان را خراب می کنند:
# BREAKER: جاسازی اطلاعات در سیستم که با هر درخواست تغییر میکند "تاریخ امروز: {{اکنون}}. شما دستیار هستید..." ← پیشوند با هر درخواست تغییر میکند، ضربه صفر است# TRUE: متغیر را به سیستم پیام منتقل کنید: "شما دستیار هستید..." سوال: ..."}] ← متغیر در پایان
سایر شکافها: JSON در هر درخواست به طور متفاوتی مرتب میشود (کلیدها را به ترتیب ثابت نگه میدارد)، فهرست ابزارها براساس کاربر متفاوت است (ابزارها ابتدا پردازش میشوند، در صورت تغییر چیزی به حافظه پنهان نمیرود)، تغییر مدل در اواسط مکالمه (حافظههای پنهان مختص مدل هستند).
اعلان ضعیف / اعلان قوی (ساختار سازگار با حافظه پنهان)
# سیستم ضعیف (ساخت cache busting): "تاریخ: 18.07.2026 14:32. کاربر: Ahmet (id 8842). شما یک ربات پشتیبانی هستید. قوانین: ...(2000 توکن)..."
سیستم # STRONG (ساختار مناسب حافظه پنهان): "شما یک ربات پشتیبانی هستید. قوانین: ... (2000 توکن، هرگز تغییر نمی کند)..." [نشانه حافظه پنهان] پیام ها: [ { نقش: کاربر، محتوا: "تاریخ: 18.07.2026 14:32. شناسه کاربری: 8842. سوال: چگونه پول خود را بازپرداخت کنم؟" }]
در نسخه ضعیف، بلوک قانون 2000 توکن با هزینه کامل در هر درخواست پردازش می شود. در نسخه قوی، همان بلوک یک بار نوشته می شود و در تمام درخواست های بعدی با یک دهم قیمت خوانده می شود.
سه کیف کوچک
مورد 1 - ذخیره کتاب قوانین. یک اتوماسیون حسابداری کتاب قوانین 12000 رمزی را به هر فاکتور اضافه می کرد. 5000 درخواست در روز هزینه ورودی بدون حافظه پنهان حدود 180 دلار در روز است. آنها دفترچه قوانین را ثابت نگه داشتند و آن را در حافظه پنهان نگه داشتند: درخواست های اول حق بیمه نوشتن پرداخت می کردند، سپس 0.1× را می خواند. هزینه ورودی 90٪ کاهش یافت و به 18 دلار در روز رسید.
مورد 2 - هزینه خط تاریخ پنهان. یک تیم یک کش راه اندازی کرد اما هیچ ضربه ای دریافت نکرد. cache_read_input_tokens همیشه صفر بود. دلیل: datetime.now() در خط اول اعلان سیستم وجود داشت، پیشوند با هر درخواست تغییر می کرد. وقتی تاریخ را به پیام کاربر منتقل کردیم، نرخ ضربه ناگهان از 0٪ به 94٪ افزایش یافت.
مورد 3 - حافظه پنهان نابجا. یک برنامه جستجو با هر درخواست، پرس و جوهای کوتاه کاملاً متفاوتی را ارسال می کرد. آنها مشتاقانه یک علامت کش اضافه کردند. بدون پیشوند مشترک، هر درخواست فقط یک حق بیمه پرداخت می کرد، بدون خواندن - افزایش هزینه. تابلو را برداشتند. درس: کش فقط در صورتی پرداخت میشود که یک پیشوند بزرگ و ثابت وجود داشته باشد که دوباره استفاده شود.
اشتباهات رایج
- مخلوط کردن ثابت و متغیر: زمانی که محتوای متغیر در پیشوند باشد، ضربه مجددا تنظیم می شود.
- جاسازی تاریخ/شناسه در اعلان سیستم: رایج ترین مختل کننده خاموش.
- عدم اندازه گیری ضربه: اگر cache_read_input_tokens بررسی نشود، ضایعات متوجه نمی شوند.
- افزودن حافظه پنهان زمانی که پیشوند عمومی وجود ندارد: شما فقط حق بیمه نوشتن را پرداخت می کنید، هزینه افزایش می یابد.
- تغییر لیست یا مدل خودرو: پیشوند از ابتدا شکسته است. همه چیز بازنویسی شده است
- فراموش کردن حداقل اندازه حافظه پنهان: کش های بسیار کوتاه (با توجه به مدل کمتر از 1 تا 4 هزار توکن) بی صدا وارد حافظه پنهان نمی شوند.
عمیق تر: طراحی کش بر اساس نوع بار کاری
بازده واقعی ذخیره سازی بسته به ماهیت حجم کاری شما متفاوت است. بنابراین ابتدا با ترافیک خود آشنا شوید. سه الگوی معمولی و نصب صحیح:
اعلان مشترک سیستم، سوالات مختلف. متداول ترین الگوی سازمانی: یک سیستم بزرگ (نقش، قوانین، شاید سند مرجع) با صدها سؤال مختلف کاربر. در اینجا قسمت ثابت (سیستم) در ابتدا کش می شود. هر سوال جدید فقط برای بخش کوچک خود بهای کامل را پرداخت می کند. سود بسیار زیاد است، زیرا بخش بزرگ به طور مکرر با یک دهم قیمت تلاوت می شود.
مونولوگ چند دور. همانطور که مکالمه به طول می انجامد، هر دور جدید بر روی تمام تاریخ قبلی ساخته می شود. اگر پرچم کش را در پایان دور آخر قرار دهید، هر درخواست از پیشوند مکالمه قبلی مجددا استفاده می کند. بازدیدها با رشد مکالمه جمع می شوند. این به طور چشمگیری هزینه جلسات طولانی دستیار را کاهش می دهد.
پیشوند مشترک آخرین بیتی است که باید تغییر کند. درخواستهای چندگانه مجموعه بزرگی از اولویتهای ثابت (مجموعه نمونه، دستورالعملها) را به اشتراک میگذارند، اما در پایان با یک سؤال از هم جدا میشوند. شما نشانگر کش را در انتهای قسمت مشترک قرار می دهید. در غیر این صورت، هر درخواست کش جداگانه خود را می نویسد و هیچ کدام خوانده نمی شود.
یک نکته: حافظه پنهان به مدل و حداقل اندازه معین بستگی دارد. پیشوندهای بسیار کوچک (زیر چند هزار توکن، بسته به مدل) حتی اگر آنها را پرچم گذاری کنید بی سر و صدا وارد حافظه پنهان نمی شوند - cache_creation_input_tokens صفر می ماند. همچنین، تغییر مدل در اواسط مکالمه، کل کش را باطل می کند. اگر کار متفاوتی نیاز به یک مدل ارزان دارد، جریان اصلی را در یک مدل نگه دارید و کار جانبی را در یک تماس جداگانه قرار دهید.
به طور خلاصه
حافظه پنهان سریع یک تطبیق پیشوند است: محتوای ثابت باید در ابتدا باشد، محتوای متغیر باید در پایان باشد. برای یک زمینه بزرگ و استفاده مجدد، هزینه خواندن یک دهم قیمت کامل است که تقریباً حتی در دو درخواست کاهش می یابد. رایج ترین اشتباه، خراب کردن پیشوند با جاسازی داده های متغیر در اعلان سیستم است. با اندازهگیری آن در قسمت استفاده، ضربه را تأیید میکنید.
وظیفه کاربردی
حجم کاری را انتخاب کنید. (1) محتوا را به دو ستون تقسیم کنید: "هرگز تغییر نمی کند" و "با هر درخواست تغییر می کند". (2) ساختار prompt را دوباره ترسیم کنید، قسمت ثابت را در ابتدا و قسمت متغیر را در پایان قرار دهید. (3) اندازه توکن قسمت ثابت را تخمین بزنید و هزینه ماهانه را با/بدون کش مقایسه کنید. (4) توجه داشته باشید که از کدام فیلد (cache_read_input_tokens) ضربه را تأیید خواهید کرد.
چک لیست
- [ ] می توانم توضیح دهم که کش تطبیق پیشوند و تنها قانون تغییرناپذیر است.
- [ ] می توانم با قرار دادن محتوای ثابت در ابتدا و متغیر در پایان، دقت را افزایش دهم.
- [ ] من اقتصاد نوشتن/خواندن و نقطه سربه سر دو درخواست را می دانم.
- [ ] می توانم اخلالگرهای بی صدا (تاریخ، JSON نامرتب، تغییر لیست خودرو) را تشخیص دهم.
- [ ] من می توانم با usage.cache_read_input_tokens ضربه را تأیید کنم.