প্রম্পট ক্যাশিং কী? একটি পুনরাবৃত্ত প্রম্পট কীভাবে পুনরায় ব্যবহৃত হয়

প্রম্পট ক্যাশিং মানে হলো API আপনার অনুরোধের শুরুটা মনে রাখে এবং পরের বার একই শুরু পাঠালে সেটা পুনরায় ব্যবহার করে। আপনি প্রতিবার পুরো টেক্সটই পাঠান, কিন্তু প্রোভাইডার পুনরাবৃত্ত অংশটা আবার পড়ার কাজ এড়িয়ে যেতে পারে, এবং কিছু প্রোভাইডার সেই অংশের জন্য কম দাম নেয়। এটি শুধু অনুরোধের শুরুতে কাজ করে, এবং শুধু তখনই যখন সেই শুরুটা হুবহু একই থাকে।

সাপোর্ট বট যে একই পৃষ্ঠা বারবার পড়ে#

ধরুন আপনি একটি সাপোর্ট বট চালান যেটি দিনে ২,০০০ টিকিট হ্যান্ডেল করে। প্রতিটি অনুরোধ একই ৩,০০০ টোকেন দিয়ে শুরু হয়: কথার ধরন, রিফান্ডের নিয়ম, শিপিং নীতি। এর পরে আসে এক লাইনের গ্রাহক বার্তা, যেমন "আমার অর্ডার কোথায়?" (টোকেন সম্পর্কে এখনও ধোঁয়াশা থাকলে, টোকেন কী দিয়ে শুরু করুন।)

ক্যাশিং ছাড়া, প্রোভাইডার টিকিট নম্বর ১, টিকিট নম্বর ২, এবং টিকিট নম্বর ২,০০০-এর জন্য আবার সব ৩,০০০ টোকেন নিয়ম পড়ে। একই পৃষ্ঠা, ২,০০০ বার পড়া। ক্যাশিংয়ের সাথে, প্রথম অনুরোধটি এটি পড়ার পুরো দাম দেয়, এবং পরবর্তী অনুরোধগুলি যেগুলি একই টেক্সট দিয়ে শুরু হয় সেগুলি কাজটি পুনরায় ব্যবহার করতে পারে।

DeepSeek-এর API গাইড (২৪ অক্টোবর ২০২৬-এ যাচাই করা) ঠিক এটাই বর্ণনা করে: কনটেক্সট ক্যাশিং ডিফল্টভাবে চালু, কোনো কোড পরিবর্তনের প্রয়োজন নেই, এবং ওভারল্যাপিং প্রিফিক্স সহ পরবর্তী অনুরোধকে "ক্যাশ হিট" হিসেবে গণনা করা হয়। শুধু ইনপুট ক্যাশ হয়। উত্তর প্রতিবার নতুন করে তৈরি হয়।

কী "একই" হিসেবে গণ্য হয়: প্রিফিক্স নিয়ম#

ক্যাশ প্রথম অক্ষর থেকে মিলিয়ে দেখে। যে মুহূর্তে আপনার অনুরোধ ক্যাশ করা অনুরোধ থেকে আলাদা হয়, তার পরের সবকিছু নতুন। এজন্যই আপনার অনুরোধের ক্রম তার দৈর্ঘ্যের চেয়ে বেশি গুরুত্বপূর্ণ।

এখানে সেই ভুল যা নীরবে ক্যাশিং নষ্ট করে। একজন ডেভেলপার চান বট সময় জানুক এবং সেটি উপরে রাখেন:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

সময় প্রতি সেকেন্ডে বদলায়, তাই একদম প্রথম লাইনটি প্রতিটি অনুরোধে আলাদা হয়, এবং তার পরের কিছুই মিলতে পারে না। সমাধান হলো যা বদলায় তা শেষে সরিয়ে নেওয়া:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

এখন ৩,০০০ টোকেন নিয়ম প্রথমে আসে এবং একই থাকে। একই যুক্তি অন্য দুটি সাধারণ ক্ষেত্রেও প্রযোজ্য: একটি দীর্ঘ চ্যাট প্রতিটি পালায় তার পুরো ইতিহাস পুনরায় পাঠায়, তাই পুরনো বার্তাগুলি একটি তৈরি-তৈরি পুনরাবৃত্ত শুরু (দীর্ঘ চ্যাট কেন বেশি খরচ করে সম্পর্কে আরও), এবং একটি এজেন্ট প্রতিটি ধাপে তার টুল সংজ্ঞা এবং নির্দেশাবলী পুনরাবৃত্তি করে।

ক্যাশিং সর্বোত্তম-প্রচেষ্টা ভিত্তিকও। DeepSeek বলে ক্যাশ তৈরি হতে কয়েক সেকেন্ড লাগে, একটি হিটের জন্য বিদ্যমান ক্যাশ প্রিফিক্স ইউনিটের সম্পূর্ণ মিল প্রয়োজন, কোনো নিশ্চিত হিট রেট নেই, এবং অব্যবহৃত ক্যাশ মুছে ফেলা হয়, সাধারণত কয়েক ঘণ্টা থেকে কয়েক দিনের মধ্যে। তাই প্রথমটির আধা সেকেন্ড পরে পাঠানো দ্বিতীয় অনুরোধটি এখনও হিট নাও করতে পারে, এবং হিটটি আপনার পুরো প্রিফিক্সের চেয়ে কম কভার করতে পারে।

এটি কীভাবে দেখবেন: usage-এ ক্যাশ ফিল্ড#

এটি কাজ করেছে কিনা তা অনুমান করতে হবে না। প্রতিটি প্রোভাইডার এটি প্রতিক্রিয়ার usage অংশে নিজস্ব ফিল্ড নামে রিপোর্ট করে।

DeepSeek দুটি ফিল্ড ব্যবহার করে:

• prompt_cache_hit_tokens — ক্যাশে পাওয়া গেছে এমন ইনপুট টোকেন
• prompt_cache_miss_tokens — যে ইনপুট টোকেন পাওয়া যায়নি

ধরুন আপনার প্রথম সাপোর্ট টিকিট prompt_cache_hit_tokens: 0 এবং prompt_cache_miss_tokens: 3200 নিয়ে ফিরে আসে, এবং এক মিনিট পরে একটি টিকিট prompt_cache_hit_tokens: 3000 এবং prompt_cache_miss_tokens: 200 দেখায়। ৩,০০০ টোকেন নিয়ম পুনরায় ব্যবহার করা হয়েছে; শুধু নতুন গ্রাহক বার্তা এবং কয়েকটি টোকেন নতুন করে পড়া হয়েছে। যদি প্রতিটি কলে হিট সংখ্যা শূন্যেই থাকে, আপনার অনুরোধের শুরুটা দেখুন: সেখানে কিছু একটা বদলাচ্ছে।

Anthropic ভিন্নভাবে কাজ করে, কারণ আপনি কী ক্যাশ করতে হবে তা চিহ্নিত করেন। আপনি অনুরোধে বা একটি কনটেন্ট ব্লকে ephemeral টাইপ সহ cache_control যোগ করেন:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Anthropic-এর প্রম্পট ক্যাশিং ডকুমেন্টেশন (২৪ অক্টোবর ২০২৬-এ যাচাই করা) অনুসারে, উত্তরটি তিনটি সংখ্যা রিপোর্ট করে: cache_creation_input_tokens (এখন ক্যাশে লেখা), cache_read_input_tokens (এটি থেকে পড়া), এবং input_tokens (শেষ ক্যাশ ব্রেকপয়েন্টের পরে যা এসেছে)। ধরুন প্রথম কল cache_creation_input_tokens: 10000, cache_read_input_tokens: 0 দেখায়; দ্বিতীয়টি 0 এবং 10000 দেখায়। এটি একটি ক্যাশ লেখা তারপর একটি ক্যাশ পড়া।

পর্দায় একটি ফাঁদ আছে। মডেলের ন্যূনতম (মডেলের উপর নির্ভর করে ৫১২, ১,০২৪ বা ৪,০৯৬ টোকেন) থেকে ছোট প্রম্পট ক্যাশিং ছাড়াই এবং কোনো ত্রুটি ছাড়াই প্রক্রিয়া করা হয়। আপনি উভয় ক্যাশ ফিল্ডে শূন্য দেখবেন এবং কোনো সতর্কতা পাবেন না। ডিফল্ট আয়ু ৫ মিনিট, প্রতিটি ব্যবহারে বিনামূল্যে রিফ্রেশ হয়; ঐচ্ছিক 1h-এর ttl এটি দীর্ঘস্থায়ী করে।

এটি আপনার বিলে কী করে#

ক্যাশিং পুনরাবৃত্ত অংশের দাম পরিবর্তন করে, তাই একবার গণনা করা মূল্যবান। Anthropic বেস ইনপুট দামের উপর গুণক তালিকাভুক্ত করে: ৫-মিনিট আয়ুর একটি ক্যাশ লেখার খরচ ১.২৫×, একটি পড়ার খরচ ০.১× (Opus 5.5 এবং Sonnet 5.5-এর জন্য ০.০৫×)। ৫-মিনিটের উইন্ডোর মধ্যে ২০টি অনুরোধে পুনরায় ব্যবহৃত একটি ১০,০০০-টোকেন প্রিফিক্স নিন, স্ট্যান্ডার্ড ০.১× পড়া ব্যবহার করে:

ক্যাশিং ছাড়া বেস দামে ১০,০০০ × ২০ = ২০০,০০০ টোকেন

ক্যাশ লেখা প্রথম অনুরোধের জন্য ১০,০০০ × ১.২৫ = ১২,৫০০

এটি পড়া ১৯টি অনুরোধের জন্য ১৯ × ১০,০০০ × ০.১ = ১৯,০০০

ক্যাশিং সহ ১২,৫০০ + ১৯,০০০ = ৩১,৫০০ টোকেন-সমতুল্য

তাই পুনরাবৃত্ত অংশের খরচ ক্যাশবিহীন পরিমাণের এক-পঞ্চমাংশের অনেক নিচে। সমস্যা: যদি অনুরোধের মধ্যে ৫ মিনিট পার হয়ে যায়, পরেরটি আবার ১.২৫×-এ ক্যাশ লেখে, এবং একটি বিরলভাবে ব্যবহৃত প্রিফিক্স ক্যাশিং না করার চেয়ে বেশি খরচ করতে পারে।

এখন শুরু থেকে বটটি, একটি সাধারণ পূর্ণ-দাম বেসলাইন হিসেবে। দিনে ২,০০০ অনুরোধ, প্রতিটিতে ৩,০০০ ইনপুট টোকেন এবং প্রায় ৩০০ আউটপুট টোকেন:

দিনে ২,০০০ × ৩,০০০ = ৬,০০০,০০০ ইনপুট টোকেন

দিনে ২,০০০ × ৩০০ = ৬০০,০০০ আউটপুট টোকেন

টেবিলটি OpenRouter-এর পাশে প্রতিটি উপলব্ধ CheapTokens মডেলে সেই দিনের কাজের চাপের দাম দেখায়:

DeepSeek-V4-Flash ইনপুট এবং আউটপুট একসাথে গণনা করে মোটের দিক থেকে OpenRouter-এর চেয়ে সস্তা, এবং কাজের চাপ সহজেই ফিট করে: ৩৮০K কনটেক্সট এবং প্রতি উত্তরে সর্বোচ্চ ৩২,৭৬৮ আউটপুট টোকেন। এটি কাজের চাপের পূর্ণ-দাম খরচ: ইনপুট টোকেন × প্রতি টোকেনের দাম। একটি দীর্ঘ স্থিতিশীল প্রিফিক্স যেখানে সেই ইনপুট অংশ সবচেয়ে বড়।

পাঁচ মিনিটে নিজে চেষ্টা করুন#

পরিকল্পনা: একই দীর্ঘ সিস্টেম প্রম্পট দুবার ভিন্ন প্রশ্ন সহ পাঠান এবং usage দেখুন। আপনার নিজের নিয়মের টেক্সট support_rules.txt-এ রাখুন (এক বা দুই পৃষ্ঠা টেক্সট যথেষ্ট)। এন্ডপয়েন্টটি OpenAI-সামঞ্জস্যপূর্ণ CheapTokens API, এবং আপনি আপনার অ্যাকাউন্ট থেকে কী নিতে পারেন।

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

প্রিন্টআউটে কী পরীক্ষা করবেন: prompt_tokens আপনাকে বলে আপনার অনুরোধ কত বড়। উভয় অনুরোধে একই SYSTEM টেক্সট থাকে, তাই সেই সংখ্যার বেশিরভাগই এক অনুরোধ থেকে পরেরটিতে পুনরাবৃত্তি হয় — মোটামুটি আপনার নিয়ম ফাইলের আকার। সেই পুনরাবৃত্ত শুরুটাই হলো সেই অংশ যা ক্যাশিং সহ একটি প্রোভাইডার, যেমন উপরের DeepSeek API বা Anthropic, পুনরায় ব্যবহার করতে পারে। এখন ক্রম নিয়ে একটি অনুশীলন: SYSTEM-এর উপরে বর্তমান সময় (datetime.now()) সহ একটি লাইন যোগ করুন এবং আবার চালান। দুটি অনুরোধ আর শুরু ভাগ করে না, কারণ তারা একদম প্রথম লাইন থেকেই আলাদা। প্রম্পটের শেষে একই লাইন রাখুন এবং ভাগ করা শুরু ফিরে আসে।

আপনার নিজের প্রম্পটের জন্য একটি সংক্ষিপ্ত চেকলিস্ট:

1. স্থিতিশীল টেক্সট প্রথমে: নির্দেশাবলী, নিয়ম, টুল সংজ্ঞা, উদাহরণ।
2. পরিবর্তনশীল টেক্সট শেষে: তারিখ, ব্যবহারকারীর নাম, সর্বশেষ বার্তা।
3. প্রিফিক্স বাইট-ফর-বাইট অভিন্ন রাখুন — এমনকি একটি অতিরিক্ত স্পেসও গণনা হয়।
4. কেন কিছু ক্যাশ হয়নি ভাবার আগে প্রোভাইডারের ন্যূনতম আকার পরীক্ষা করুন।
5. পরিবর্তনের পরে usage ফিল্ড দেখুন, আগে নয়।

আপনার নিজের কাজের চাপের দাম নির্ধারণ করতে, প্রাইসিং পেজ খুলুন এবং আপনার ইনপুট ও আউটপুট আকার দিন, অথবা DeepSeek পেজ থেকে শুরু করুন। প্রথম অনুরোধ কাজ করলে, আপনি যে কোনো প্রম্পটের জন্য একই অনুমান এক মিনিটে করতে পারেন। একটি অনুরোধের দুই দিকের খরচ কী, তা জানতে ইনপুট বনাম আউটপুট টোকেন দেখুন।