Knaph

درست به کار بردنِ عامل‌ها32 از 376 دقیقه مطالعه

هر بار همان شروع

جلسه‌ی کارِ لیلا با عاملش ۴۰ نوبت طول کشید. از درس «پرداخت برای هر توکن» یادش هست که هر نوبت کل گفت‌وگو را دوباره می‌فرستد. پس حساب می‌کند: حدود ۲٫۸ میلیون توکن ورودی، که با قیمت ۴ دلار برای هر یک میلیون توکن باید حدود ۱۱ دلار شود. اما صفحه‌ی مصرفش حدود یک دلار و نیم نشان می‌دهد. یعنی حسابش اشتباه بوده؟


لیلا حسابم را دو بار چک کردم. هر نوبت واقعاً همه‌چیز را دوباره می‌فرستد.

امید درست است. دو درخواست را کنار هم بگذار: نوبت ۳۹ و نوبت ۴۰. چه فرقی دارند؟

لیلا نوبت ۴۰ همان نوبت ۳۹ است با کمی اضافه در آخرش: آخرین پاسخِ مدل و نتیجه‌ی آخرین ابزاری که خواسته. همه‌ی قبلش عیناً یکی است.

امید و در نوبت ۴۰ بر سر آن همه توکنِ یکسان چه می‌آید؟

لیلا مدل دوباره از اول می‌خواندشان. بیش از صد هزار توکن که همین چند ثانیه پیش خوانده بود.

امید مجبور است؟

لیلا گفتیم مدل بی‌حافظه است. نمی‌تواند درخواستِ قبلی را به یاد بیاورد.

امید درست، مدل هیچ‌چیز نگه نمی‌دارد. اما خواندنِ یک پرامپت یعنی حسابِ زیادی روی هر توکن، و نتیجه‌ی این حساب‌ها را می‌شود برای مدت کوتاهی جایی بیرون از مدل نگه داشت.

لیلا پس کامپیوترهای ارائه‌دهنده کاری را که روی شروعِ درخواستم کرده‌اند نگه می‌دارند، و اگر درخواستِ بعدی همان‌طور شروع شود، دوباره انجامش نمی‌دهند؟

امید این همان کش کردن پرامپت است. و چون نکردنِ آن کار برای آن‌ها ارزان‌تر است، برای تو هم ارزان‌تر است.


کش چطور کار می‌کند

وقتی مدل یک درخواست را می‌خواند، برای هر توکن، از اولی تا آخری، حسابِ زیادی انجام می‌دهد. کش کردن پرامپت (prompt caching) یعنی ارائه‌دهنده نتیجه‌ی این حساب‌ها را برای شروعِ یک درخواست، که به آن پیشوند (prefix) می‌گویند، چند دقیقه نگه می‌دارد. اگر درخواستِ بعدی دقیقاً با همان توکن‌ها شروع شود، آن بخش لازم نیست دوباره حساب شود. به این برخورد با کش (cache hit) می‌گویند. (کش انباری از کارهای انجام‌شده است که دمِ دست نگه داشته می‌شود تا لازم نباشد کاری دو بار انجام شود.)

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

از این دو نتیجه می‌گیریم:

  • ارزان‌تر است. توکن‌های ورودیِ کش‌شده حدود یک‌دهمِ قیمت معمول هزینه دارند، و در بعضی مدل‌ها حتی کمتر. در اواخر ۲۰۲۶، بزرگ‌ترین مدلِ روزمره‌ی Claude برای هر یک میلیون توکن ورودی حدود ۴ دلار می‌گیرد و برای هر یک میلیون توکنی که از کش خوانده شود ۰٫۲۰ دلار، یعنی یک‌بیستم. حساب‌های این درس برای ساده ماندن با یک‌دهم انجام شده‌اند. گذاشتنِ یک پیشوند در کش، بار اول، کمی بیشتر از ورودیِ معمولی هزینه دارد.
  • سریع‌تر است. کاری که انجام نشود یعنی وقتی که صرفه‌جویی شده، پس یک درخواستِ طولانی که با کش برخورد کند زودتر شروع به پاسخ دادن می‌کند.

پول لیلا همین‌جا صرفه‌جویی شد. در نوبت ۴۰، حدود ۱۰۶٬۰۰۰ توکن از کش آمد و فقط ۲٬۰۰۰ توکنِ آخر با قیمت کامل حساب شد. در کل جلسه، هزینه از حدود ۱۱ دلار به حدود ۱٫۵۰ دلار رسید.

هزینه‌ی ورودیِ هر نوبت در یک جلسه‌ی ۴۰ نوبتی. بدون کش، هر ستون با بزرگ شدنِ تاریخچه بلندتر می‌شود؛ با کش، تقریباً همه‌ی هر ستون از کش خوانده می‌شود و یک‌دهم هزینه دارد.

فقط وقتی دقیقاً یکی باشد

کش روی یک پیشوندِ دقیقاً یکسان کار می‌کند. ارائه‌دهنده درخواستِ تازه را از اولین توکن با درخواستِ ذخیره‌شده مقایسه می‌کند. در اولین تفاوت، تطبیق متوقف می‌شود و همه‌ی بعد از آن دوباره با قیمت کامل پردازش می‌شود، هر قدر هم که بقیه‌اش یکسان باشد.

برای همین برنامه‌ی دور مدل هر درخواست را با یک ترتیبِ ثابت می‌سازد، و آنچه کمتر عوض می‌شود را اول می‌گذارد: پرامپت سیستمی و توضیح ابزارها، بعد فایل‌های پروژه مثل CLAUDE.md و حافظه، بعد گفت‌وگو، و نوبت‌های تازه در آخر. اضافه کردن به آخر هیچ‌وقت کش را خراب نمی‌کند. تغییر چیزی نزدیکِ شروع، خراب می‌کند.

در Claude Code (تا سال ۲۰۲۶)، این کارها کش را از کار می‌اندازند و نوبتِ بعدی را کُندتر و گران‌تر می‌کنند، و بعد از آن شروعِ تازه دوباره کش می‌شود:

  • عوض کردنِ مدل، یا تغییر دادنِ میزانِ تلاش، در میانه‌ی یک جلسه؛
  • وصل کردن یا برداشتن یک سرور MCP، در تنظیم‌هایی که توضیح همه‌ی ابزارها را از اول بار می‌کنند؛
  • فشرده‌سازیِ گفت‌وگو، که آن را از نو می‌نویسد.

این‌ها خرابش نمی‌کنند: ویرایش فایل‌های پروژه (نتیجه‌ی ابزارهایی‌اند که به آخر اضافه می‌شوند)، استفاده از یک مهارت (آن هم به آخر اضافه می‌شود)، و راه انداختنِ زیرعامل‌ها (درخواست‌های خودشان را دارند). حتی ویرایش CLAUDE.md در میانه‌ی جلسه هم کش را خراب نمی‌کند، چون تغییرش فقط وقتی اثر می‌کند که گفت‌وگو را پاک یا فشرده کنید.

ماندگار نیست

اگر مدتی کسی از یک پیشوندِ ذخیره‌شده استفاده نکند، از بین می‌رود: به‌طور پیش‌فرض بعد از ۵ دقیقه در API، و برای گفت‌وگوی اصلی در اشتراک‌های Claude بعد از یک ساعت. هر برخورد با کش ساعت را از نو شروع می‌کند، پس عاملی که پیوسته کار می‌کند در تمام جلسه کش‌شده می‌ماند.

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

امتحان کنید

در Claude Code، بعد از چند نوبت، دستور /usage را اجرا کنید: نشان می‌دهد چه مقدار از ورودی‌تان از کش آمده. بعد با /model مدل را عوض کنید و یک پیام دیگر بفرستید: آن نوبت باید از نو شروع کند. اگر برنامه‌نویسی می‌کنید، API در بخشِ مصرفِ هر پاسخ توکن‌های کش‌شده را گزارش می‌دهد (برای Claude، cache_read_input_tokens). یا تمرینِ بعد از این درس را حل کنید، که حساب می‌کند کش چقدر صرفه‌جویی می‌کند.

درست به کار بردن

  1. مدل و میزانِ تلاش را در شروع انتخاب کنید. عوض کردنشان در میانه‌ی یک جلسه‌ی طولانی کش را دور می‌ریزد. اگر کاری مدل دیگری لازم دارد، جلسه‌ی تازه‌ای برایش شروع کنید.
  2. تنظیم‌هایتان را بین جلسه‌ها مرتب کنید. سرورهای MCP را اضافه کنید و CLAUDE.md را بازنویسی کنید پیش از شروع، نه وسط کار.
  3. جلسه‌های کار را پیوسته نگه دارید و آگاهانه تمامشان کنید. جلسه‌ای که بعد از یک وقفه‌ی طولانی به آن برمی‌گردید یک بار دیگر هزینه‌ی کل تاریخچه‌اش را می‌دهد. برای کار تازه، گفت‌وگو را پاک کنید.
  4. اگر عامل خودتان را می‌سازید، شروع را ثابت نگه دارید. آنچه هیچ‌وقت عوض نمی‌شود را اول بگذارید و آنچه عوض می‌شود (تاریخ امروز، پیام کاربر) را آخر. یک کلمه‌ی متغیر در بالای درخواست باعث می‌شود هر درخواست قیمت کامل بدهد.

واژه‌های این درس

  • کش کردن پرامپت - نگه داشتنِ کاری که ارائه‌دهنده روی شروعِ یک درخواست انجام داده، تا درخواستِ بعدی که همان‌طور شروع می‌شود ارزان‌تر و سریع‌تر باشد
  • پیشوند - شروعِ یک درخواست، از اولین توکن تا جایی؛ بخشی که کش می‌تواند با آن تطبیق دهد
  • برخورد با کش - درخواستی که شروعش دقیقاً با یک پیشوندِ ذخیره‌شده یکی است، پس آن بخش به جای پردازشِ دوباره از کش خوانده می‌شود

ایده‌ی اصلی

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

دانش خود را بسنجید

ورود برای سنجش دانش خود از این درس و پیگیری پیشرفتتان.