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

اوپنایآی قابلیت نگهداری ۱۲ ساعته (TTL) را به راهنمای کش پرامپت خود اضافه کرده است؛ گزینه‌ای که جایگزین زمان پیش‌فرض ۳۰ دقیقه‌ای گذشته می‌شود. با این تغییر، ایجنت‌های سازگار می‌توانند دستورالعمل‌های سیستمی پایدار، تعاریف ابزارها و کانتکست‌های مرجع را در درخواست‌هایی با فاصله چند ساعت مجدداً به کار بگیرند و تنها هزینه تخفیف‌خورده توکن‌های کش‌شده را بپردازند.

این تغییر به‌طور ویژه برای ایجنت‌هایی طراحی شده است که در سراسر روز کاری فعال باقی می‌مانند، اما رویدادهای کاربری، وظایف زمان‌بندی‌شده یا فراخوانی ابزارها را به‌صورت پراکنده دریافت می‌کنند. توسعه‌دهندگان اکنون می‌توانند پارامتر prompt_cache_options.ttl را روی "12h" تنظیم کنند، مقدار پیش‌فرض "30m" را نگه دارند یا با استفاده از نقاط شکست کش صریح (Explicit Breakpoints)، هر دو بازه زمانی را در قالب یک درخواست ترکیب نمایند.

پنجره ذخیره‌سازی اختصاصی برای ایجنت‌های کم‌کار

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

گزینه ۱۲ ساعته دسترسی به این پیشوندها را در وقفه‌های زمانی طولانی‌تر حفظ می‌کند. اوپنایآی پروژه Dots را به‌عنوان نمونه‌ای از این کاربرد معرفی کرده است؛ محصولی در حوزه ایجنت‌های مداوم که دستورالعمل‌ها، ابزارها و کانتکست مشترک خود را در تمام طول روز کاری حفظ می‌کند و به درخواست‌های دوره‌ای پاسخ می‌دهد.

حساب‌وکتاب اقتصادی استفاده مجدد از کش

برای مدل GPT-5.6 و نسخه‌های پس از آن، هزینه نوشتن در کش ۱٫۲۵ برابر نرخ استاندارد توکن ورودی است. در مقابل، خواندن از کش در بیشتر مدل‌های پشتیبانی‌شده فقط ۰٫۱ برابر (۹۰ درصد تخفیف) و در مدل GPT-6.1 Sol معادل ۰٫۰۵ برابر (۹۵ درصد تخفیف) هزینه دارد. در مستندات رسمی اوپنایآی، ضریب قیمت اضافی برای سطح ۱۲ ساعته در نظر گرفته نشده است.

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

هر چه تعداد دفعات استفاده مجدد از کش بالاتر برود، صرفه‌جویی مالی نیز بیشتر خواهد بود؛ مشروط بر اینکه پیشوند کش‌شده کاملاً دست‌نخورده باقی بماند و درخواست‌ها پیش از پایان مهلت ماندگاری (TTL) به سرور ارسال شوند.

یک درخواست با چند بازه زمانی مختلف برای کش

قابلیت کش‌گذاری صریح از چندین نقطه شکست (Breakpoint) درون یک درخواست پشتیبانی می‌کند؛ قابلیتی که اجازه می‌دهد بخش‌های مختلف پرامپت با نرخ‌های متفاوتی منقضی شوند. هر نقطه شکست نشان‌دهنده پایان یک پیشوند قابل استفاده مجدد است و هر درخواست می‌تواند تا حداکثر چهار عملیات نوشتن کش را هم‌زمان تعریف کند.

کدام سناریوها بیشترین بهره را می‌برند؟

بارهای کاری با پیشوندهای حجیم و پایدار که دوره‌های بی‌کاری آن‌ها بیش از ۳۰ دقیقه طول می‌کشد، بیشترین مزیت مالی را از این ویژگی به دست می‌آورند. برجسته‌ترین نمونه‌های آن عبارت‌اند از:

• ایجنت‌های زمان‌بندی‌شده‌ای که هر یک ساعت یک‌بار فعال می‌شوند
• دستیاران پشتیبانی با وقفه‌های طولانی میان پیام‌های کاربران
• سیستم‌های ارزیابی خودکار که از معیارهای سنجش ثابت بهره می‌برند
• فرآیندهای پس‌زمینه با مجموعه‌ای بزرگ از تعاریف ابزارها
• ایجنت‌های ماندگاری که اسناد مرجع یکسانی را در چندین تسک مختلف به اشتراک می‌گذارند

مکالمات پیوسته و متراکمی که در حالت عادی کش ۳۰ دقیقه‌ای را گرم نگه می‌دارند، منفعت چندانی از تمدید این زمان به دست نخواهند آورد. علاوه بر این، پرامپت‌ها در مدل‌های GPT-5.6 و پس از آن به پیشوندی با حداقل ۱٬۰۲۴ توکن ورودی قابل رویت نیاز دارند تا کش شوند؛ پیشوندهای کوتاه‌تر صرف‌نظر از مدت ماندگاری انتخاب‌شده، فرآیند کش را دور می‌زنند و مستقیم پردازش می‌شوند.

نحوه فعال‌سازی و بررسی نرخ موفقیت کش

فعال‌سازی این بازه زمانی طولانی‌تر تنها به اضافه کردن یک فیلد ساده در درخواست نیاز دارد. نمونه کد زیر در حالت صریح (Explicit)، زمان ماندگاری را روی ۱۲ ساعت تنظیم کرده و نقطه شکست را پس از محتوای پایدار بخش برنامه‌نویس (Developer) قرار می‌دهد:

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {
    "mode": "explicit",
    "ttl": "12h"
  },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": {
            "mode": "explicit"
          }
        }
      ]
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

پاسخ دریافتی از سرور، وضعیت فعالیت کش را از طریق پارامترهای usage.input_tokens_details.cached_tokens و cache_write_tokens گزارش می‌دهد. علاوه بر این، تیم‌های فنی می‌توانند با مراجعه به داشبورد اختصاصی کش پرامپت (Prompt Caching Dashboard)، نرخ موفقیت بازخوانی‌ها را رصد کرده و هزینه‌های جاری را با حالت بدون کش مقایسه کنند.

استفاده مجدد از کش همچنان نیازمند تطابق مو‌به‌موی کل پیشوند رندرشده است. هرگونه تغییر در متن سیستم، تعاریف ابزارها، سطح استدلال مدل (Reasoning Effort)، ساختارهای خروجی کنترل‌شده (Structured Outputs) یا حتی چیدمان محتوا، پیشوند متفاوتی می‌سازد و مانع از موفقیت کش (Hit) می‌شود. از این رو، محتوای ثابت باید همواره در ابتدا قرار گیرد و بخش‌های متغیر مکالمه پس از آخرین نقطه شکست طولانی‌مدت اضافه شوند.

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