کش ۱۲ساعتهٔ OpenAI آمد؛ نوشتن گران‌تر است و از بار سوم می‌صرفد

OpenAI در ۲۰ اکتبر ۲۰۲۶ گزینهٔ کش ۱۲ساعته را به Responses API افزود؛ ثبت تغییرات API می‌گوید نوشتن در این کش با ۲٫۵ برابر نرخ ورودی عادی محاسبه می‌شود. این عمر طولانی‌تر برای پیشوند مشترکی مانند دستورالعمل‌ها، تعریف ابزارها یا متن مرجع اهمیت دارد که درخواست‌های بعدی با فاصلهٔ چند ساعت دوباره از آن استفاده می‌کنند.

طبق راهنمای کش پرامپت OpenAI، این تنظیم در Responses API برای GPT-5.6 و مدل‌های بعدی است؛ نوشتن در کش پیش‌فرض ۳۰دقیقه‌ای ۱٫۲۵ برابر و نوشتن در کش ۱۲ساعته ۲٫۵ برابر ورودی عادی هزینه دارد. اگر پیشوند ثابت بماند، درخواست‌ها در عمر کش بلندتر جا بگیرند و کش کوتاه‌تر پیش از هر درخواست منقضی شده باشد، سومین درخواست نخستین نقطه‌ای است که عمر ۱۲ساعته ارزان‌تر می‌شود. منظور، درخواست اولیه به‌علاوهٔ دو بار استفادهٔ دوباره است، نه سومین استفادهٔ دوباره.

سومین درخواست چگونه نقطهٔ صرفه می‌شود؟

برای جداکردن اثر کش از قیمت خود مدل، هزینهٔ ورودی عادیِ یک پیشوند ثابت را یک واحد فرض کنیم. فرض دیگر این است که هر درخواست دقیقاً همان پیشوند را دارد، کش ۳۰دقیقه‌ای پیش از درخواست بعدی دیگر قابل خواندن نیست و کش ۱۲ساعته تا آخر رشته معتبر می‌ماند. در بیشتر مدل‌های مشمول این قابلیت، هر خواندن موفق از هر دو کش ۰٫۱ واحد هزینه دارد؛ برای GPT-6.1 Sol این نرخ ۰٫۰۵ واحد است. محاسبهٔ زیر با نرخ رایج ۰٫۱ انجام شده و هزینهٔ متن متغیر و خروجی را کنار می‌گذارد.

• در سناریوی فرضیِ دو درخواست، کش کوتاه‌تر دو بار پیشوند را با جمع ۲٫۵ واحد می‌نویسد. کش بلندتر یک بار ۲٫۵ واحد می‌نویسد و یک بار ۰٫۱ واحد می‌خواند؛ جمع ۲٫۶ واحد است. یک استفادهٔ دوباره هنوز نوشتن گران‌تر را جبران نمی‌کند.
• در سناریوی سه درخواست، هزینهٔ سه نوشتن ۳۰دقیقه‌ای ۳٫۷۵ واحد است. مسیر ۱۲ساعته یک نوشتن و دو خواندن دارد و ۲٫۷ واحد هزینه می‌برد. صرفه از اینجا آغاز می‌شود، چون دو نوشتن دوباره با دو خواندن ارزان جایگزین شده‌اند.
• در سناریوی چهار درخواست، چهار نوشتن کوتاه‌مدت ۵ واحد و یک نوشتن بلندمدت همراه با سه خواندن ۲٫۸ واحد هزینه دارد. هر خواندن موفق بعدی در همین بازه فقط ۰٫۱ واحد به هزینهٔ پیشوند در مسیر بلندمدت اضافه می‌کند.

این اعداد محاسبهٔ مستند از نرخ‌ها و فرض‌های مشخص هستند، نه نتیجهٔ صورت‌حساب واقعی. عمرهای اعلام‌شده حداقل‌اند و ممکن است کش کوتاه‌تر بیش از ۳۰ دقیقه باقی بماند؛ در آن صورت درخواست بعدی می‌تواند از همان کش خوانده شود و نقطهٔ صرفه جابه‌جا شود. برعکس، درخواست‌هایی که بعد از پایان پوشش ۱۲ساعته می‌رسند ممکن است به نوشتن تازه نیاز پیدا کنند.

TTL پیشوند ثابت را از تاریخچهٔ گفت‌وگو جدا می‌کند

مقدار prompt_cache_options.ttl عمر پیش‌فرض کش را برای درخواست تعیین می‌کند: "30m" حالت معمول است و "12h" حداقل عمر بلندتر را انتخاب می‌کند. برای بخش ثابتی که قرار است در طول روز تکرار شود، می‌توان prompt_cache_breakpoint را در پایان همان بخش گذاشت و ttl آن نقطه را "12h" تعیین کرد. پیشوندِ واجد شرایط در GPT-5.6 و مدل‌های بعدی باید دست‌کم ۱۰۲۴ توکن ورودیِ قابل مشاهده داشته باشد؛ محتوای پنهان سیستم در این حد حساب نمی‌شود.

جای نقطهٔ توقف بخشی از تصمیم اقتصادی است، زیرا هر نقطه تمام پیشوند پیش از خود را پوشش می‌دهد. در درخواستِ دارای چند نقطه، اگر نقطهٔ ۱۲ساعته پس از نقطهٔ ۳۰دقیقه‌ای و در انتهای پیشوندی بلندتر قرار گیرد، توکن‌های مشترک نیز با عمر بلندتر نوشته و با نرخ آن محاسبه می‌شوند. نوشتن ۱۲ساعته روی پیشوندی که پوشش ۳۰دقیقه‌ای معتبر دارد، نوشتن تازه به شمار می‌رود و هزینهٔ نوشتن قبلی از آن کسر نمی‌شود.

در چیدمان مناسب برای پیشوند پایدار، نقطهٔ ۱۲ساعته پس از دستورالعمل‌ها و محتوای مرجع ثابت می‌آید و بخش‌های متغیرِ نشست عمر کوتاه‌تر خود را دارند. حالت "explicit" اجازه می‌دهد پرسش جاری پس از آخرین نقطهٔ توقف قرار گیرد و برای آن نوشتن کش ثبت نشود. حفظ ترتیب و متن پیشوند نیز مهم است: اگر محتوای پیش از نقطه تغییر کند، درخواست بعدی دیگر لزوماً با ورودی ذخیره‌شده تطابق ندارد.

چرا تنظیم ۱۲ساعته برای کل درخواست ممکن است گران شود؟

در حالت ضمنی، نقطهٔ توقف با آخرین پیام واجد شرایط گفت‌وگو جلو می‌رود. TTL تعیین‌شده در سطح درخواست هم به این نقطهٔ ضمنی و هم به نقطه‌های صریحِ بدون TTL اختصاصی اعمال می‌شود. بنابراین گذاشتن "12h" روی کل درخواست می‌تواند بخش تازهٔ تاریخچه را در هر نوبت با نرخ نوشتن بلندمدت ثبت کند، حتی وقتی آن بخش پس از پایان نشست دوباره خوانده نمی‌شود.

در محاسبهٔ ImportStatic، گفت‌وگویی فرضی با ۲۰ مرحله، پیشوند مشترک ۸۰۰۰توکنی و ۱۵۰۰ توکن تازه در هر مرحله با نرخ‌های GPT-6.1 Sol قیمت‌گذاری شده است: هزینهٔ ورودی با کش ضمنی ۳۰دقیقه‌ای ۰٫۱۳۸۷ دلار و با TTL سراسری ۱۲ساعته ۰٫۲۳۳۷ دلار، حدود ۶۸٪ بیشتر، به دست آمد. محاسبه‌گران کد را با سرور آزمایشی محلی اجرا کردند و درخواستی به OpenAI نفرستادند؛ این مبلغ‌ها برآورد بر پایهٔ قواعد قیمت‌گذاری‌اند، نه هزینهٔ ثبت‌شده در قبض.

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

هزینهٔ واقعی از کدام شمارنده‌ها به دست می‌آید؟

در پاسخ‌های Responses API، مقدار input_tokens_details.cached_tokens توکن‌های خوانده‌شده از کش را نشان می‌دهد. جزئیات cache_write_tokens_details نیز نوشتن‌ها را میان ttl_30m_tokens و ttl_12h_tokens جدا می‌کند. برای به‌دست‌آوردن هزینهٔ ورودی، توکن‌های عادی با نرخ عادی، خواندن‌ها با نرخ ورودی کش‌شده و هر گروه نوشتن با نرخ عمر خودش محاسبه و جمع می‌شوند.

شمار کل cache_write_tokens را نباید بار دیگری به جمع افزود، چون دو جزء نوشتن پیش‌تر در آن حساب شده‌اند. شمار درخواست‌ها به‌تنهایی هم صرفه را نشان نمی‌دهد: مقدار پیشوندِ واقعاً ثابت، خواندن‌های موفق و توکن‌های تازه‌ای که با هر عمر نوشته شده‌اند، تعیین می‌کنند هزینهٔ بالاتر نوشتن اولیه جبران شده است یا خیر. برای GPT-6.1 Sol نیز باید نرخ خواندن مخصوص همان مدل را در حساب گذاشت، نه نرخ رایج بیشتر مدل‌ها.

عمر ۱۲ساعته حداقل زمان واجد شرایط بودن برای خواندن از کش است، نه موعد قطعی حذف آن. در نتیجه، هزینهٔ نهایی یک کاربرد واقعی به تطابق پیشوند و خواندن‌های ثبت‌شده در مصرف همان درخواست‌ها وابسته می‌ماند؛ صرف انتخاب TTL بلندتر، صرفه‌جویی وعده‌داده‌شده در سناریوی پیشوند ثابت را تضمین نمی‌کند.

بیشتر بخوانید:

• گواهی AI یا نمونه‌کار؛ مدرک سیگنال است، پروژه توانایی را نشان می‌دهد
• Carta یا Pulley؛ ۲۵ سهام‌دار نقطهٔ شروع است، نه قیمت نهایی
• pgvector یا Pinecone؛ سه‌برابر توان عملیاتی می‌تواند ۴٫۸ برابر گران‌تر شود