نصف کردن هزینهٔ توکن با چند تغییر ساده

بیشتر صورت‌حساب‌های بزرگ به این دلیل بزرگ نیستند که کار زیادی انجام شده؛ به این دلیل بزرگ‌اند که همان کار با توکن‌های بیشتری از لازم انجام شده. خبر خوب این است که چند تغییر کوچک — که هیچ‌کدام کیفیت خروجی را پایین نمی‌آورند — معمولاً بیشترین اثر را دارند.

این چهار مورد را به ترتیب اثرگذاری آورده‌ام. اگر فقط وقت یکی را دارید، اولی را انجام دهید.

۱. کش پرامپت — بزرگ‌ترین برد، اگر پرامپت ثابتی دارید

اگر برنامهٔ شما هر بار یک پرامپت سیستمی طولانی می‌فرستد — دستورالعمل، مثال، بخشی از یک سند مرجع — دارید بابت همان متن ثابت، هر بار پول کامل می‌دهید.

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

• نوشتن در کش کمی گران‌تر از ورودی عادی است (حدود ۲۵٪ بیشتر در حالت متداول).
• خواندن از کش خیلی ارزان‌تر است — معمولاً حدود یک‌دهم ورودی عادی.

یعنی از تماس دوم به بعد، بخش ثابت پرامپت شما تقریباً رایگان می‌شود. برای برنامه‌ای که یک پرامپت سیستمی هزار توکنی دارد و روزی چند هزار درخواست می‌زند، این تفاوت به‌تنهایی می‌تواند بیشتر از هر بهینه‌سازی دیگری صرفه‌جویی کند.

شرط استفاده: ترتیب پیام‌ها را ثابت نگه دارید

کش وقتی کار می‌کند که ابتدای پرامپت بایت‌به‌بایت تکرار شود. یعنی:

• بخش ثابت را همیشه اول بگذارید و بخش متغیر را بعد از آن.
• چیزی مثل زمان فعلی، شناسهٔ تصادفی یا نام کاربر را داخل بخش ثابت نبرید. یک تفاوت کوچک در ابتدای متن، کل کش را بی‌اثر می‌کند.

messages = [
    # ثابت — همیشه یکسان، همیشه اول
    {"role": "system", "content": LONG_INSTRUCTIONS},
    # متغیر — بعد از بخش ثابت
    {"role": "user", "content": user_question},
]

اگر تاریخ یا نام کاربر واقعاً لازم است، آن را در پیام کاربر بگذارید، نه در پرامپت سیستمی.

در صفحهٔ «مصرف»، ستون توکن به شما نشان می‌دهد کش واقعاً فعال شده یا نه. اگر بعد از این تغییر عددها فرقی نکردند، یعنی ابتدای پرامپت هنوز در هر تماس متفاوت است.

۲. مدل را متناسب با کار انتخاب کنید، نه با عادت

خیلی از برنامه‌ها همه‌چیز را به گران‌ترین مدل می‌دهند، چون روز اول با آن شروع کرده‌اند و بعد کسی برنگشته سراغش.

اما کارها یکسان نیستند:

• طبقه‌بندی یک پیام کوتاه، استخراج یک تاریخ، تشخیص زبان — این‌ها کار مدل کوچک‌اند.
• استدلال چندمرحله‌ای، نوشتن بلند، تحلیل سند پیچیده — این‌ها کار مدل بزرگ‌اند.

تفاوت قیمت بین این دو دسته اغلب یک مرتبهٔ بزرگی است. اگر ۸۰٪ درخواست‌های شما از نوع اول باشند و همه به مدل بزرگ بروند، بیشترِ صورت‌حساب‌تان بابت کاری است که مدل ارزان هم درست انجام می‌داد.

الگوی دومرحله‌ای ساده و مؤثر است: اول مدل ارزان را بزنید؛ اگر نتیجه به معیار شما نرسید، همان درخواست را به مدل گران بدهید. حتی اگر یک‌سوم موارد به مرحلهٔ دوم برسند، باز هم از فرستادن همه‌چیز به مدل گران ارزان‌تر است.

۳. تاریخچهٔ گفتگو را بی‌نهایت رشد ندهید

این رایج‌ترین اشتباه در برنامه‌های چت است و بی‌سروصدا گران می‌شود.

در هر تماس، کل تاریخچه دوباره فرستاده می‌شود. یعنی پیام دهم شما هزینهٔ نه پیام قبلی را هم دارد. مکالمه‌ای که پنجاه پیام ادامه پیدا کند، اواخرش هر تماس چند برابر اولش خرج برمی‌دارد — بدون اینکه کیفیت جواب لزوماً بهتر شده باشد.

دو راه‌حل رایج:

1. پنجرهٔ لغزان — فقط N پیام آخر را نگه دارید. برای بیشتر کاربردهای پشتیبانی، ده پیام آخر کافی است.
2. خلاصه‌سازی تدریجی — وقتی تاریخچه از حدی بلندتر شد، بخش قدیمی را با یک خلاصهٔ کوتاه جایگزین کنید.

روش دوم کیفیت را بهتر حفظ می‌کند ولی خودش یک تماس اضافی دارد؛ برای مکالمه‌های طولانی هنوز به‌صرفه است.

۴. max_tokens را واقع‌بینانه ببندید

این تنظیم دو کار می‌کند و هر دو به نفع شماست.

اگر جواب مورد انتظار شما دو پاراگراف است، max_tokens را روی عددی متناسب با دو پاراگراف بگذارید، نه روی سقف مدل. مدل‌ها وقتی فضای زیاد ببینند، تمایل دارند پرحرف شوند — و خروجی معمولاً چند برابر ورودی قیمت دارد.

نکتهٔ دوم مربوط به کیف پول است: پیش از هر تماس، مبلغی معادل تخمین درخواست از موجودی شما رزرو می‌شود، و آن تخمین به max_tokens نگاه می‌کند. اگر آن را روی سقف مدل رها کنید، برای هر درخواست مبلغ بزرگی رزرو می‌شود — حتی اگر جواب کوتاه باشد و در نهایت رقم واقعی خیلی کمتر شود. با یک عدد واقع‌بینانه، هم رزروها کوچک‌تر می‌شوند و هم درخواست‌هایتان کمتر به سقف موجودی می‌خورند.

---

چیزی که مخصوص فارسی است

متن فارسی معمولاً به توکن‌های بیشتری شکسته می‌شود تا همان متن به انگلیسی. این یعنی همهٔ نکات بالا برای شما اثر بزرگ‌تری دارند تا برای یک تیم انگلیسی‌زبان با همان حجم کار.

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

ترتیب پیشنهادی

اگر می‌خواهید امروز شروع کنید:

1. پرامپت سیستمی را ثابت و اول قرار دهید تا کش فعال شود.
2. max_tokens را روی عددی واقع‌بینانه ببندید.
3. برای درخواست‌های ساده یک مدل ارزان‌تر امتحان کنید.
4. تاریخچهٔ چت را محدود کنید.

بعد از هر تغییر، یک روز صبر کنید و در صفحهٔ «مصرف» تفکیک روزانه را ببینید. اثر هر تغییر جداگانه معلوم می‌شود و می‌فهمید کدام برای کار شما بیشترین صرفه را داشته است.

و یک شبکهٔ ایمنی

برای هر کلید سقف روزانه بگذارید — سقف توکن یا سقف ریالی. بهینه‌سازی هزینه را پایین می‌آورد؛ سقف تضمین می‌کند یک اشتباه در کد، شبانه صورت‌حساب غیرمنتظره نسازد. این دو جای هم را نمی‌گیرند.