Gemini context caching: Interactions API explicit cache নিতে পারে না

Gemini API-তে একই বড় কনটেক্সট বারবার ব্যবহার করতে হলে আগে API বেছে নিতে হবে। Google-এর ক্যাশিং নির্দেশনা অনুযায়ী, Interactions API শুধু implicit caching সমর্থন করে; নিজে explicit cache তৈরি ও ব্যবহার করতে হলে generateContent API প্রয়োজন।

কাছাকাছি সময়ে একই বড় ইনপুট দিয়ে অনুরোধ পাঠালে implicit caching দিয়ে শুরু করা যায়, যদিও ক্যাশে হিটের নিশ্চয়তা নেই। নির্দিষ্ট কনটেন্ট ধরে রেখে তার মেয়াদ নিয়ন্ত্রণ করতে চাইলে explicit cache কাজে আসে। সে ক্ষেত্রে প্রতিবার কম দামে cached token ব্যবহারের সুবিধার পাশাপাশি ক্যাশ কতক্ষণ সংরক্ষিত থাকবে, তার খরচও হিসাব করতে হবে।

API বেছে নেওয়ার সিদ্ধান্তপ্রবাহ

• বড় স্থির অংশ নেই → প্রতিটি অনুরোধে নথি বা নির্দেশনা বদলে গেলে পুরোনো কনটেক্সট পুনর্ব্যবহারের সুযোগ সীমিত। আগে সাধারণ ইনপুট টোকেনের খরচ হিসাব করুন।
• স্থির অংশ আছে, কিন্তু মেয়াদ নিয়ন্ত্রণের দরকার নেই → Interactions API দিয়ে implicit caching ব্যবহার করুন। অভিন্ন বড় অংশ অনুরোধের শুরুতে রাখুন এবং অনুরূপ অনুরোধ কাছাকাছি সময়ে পাঠান।
• স্থির অংশ বহুবার লাগবে, মেয়াদও ঠিক করতে হবে → generateContent API দিয়ে explicit cache তৈরি করুন। পরে নতুন প্রশ্নের সঙ্গে ক্যাশের নাম পাঠান এবং প্রত্যাশিত ব্যবহার শেষ হলে মেয়াদ বাড়ানোর প্রয়োজন আছে কি না বিবেচনা করুন।

এই প্রবাহে মূল পার্থক্য হলো ক্যাশের ওপর নিয়ন্ত্রণ। Interactions API কথোপকথনের আগের অবস্থা ধরে রাখা এবং প্রতিটি অনুরোধ স্বতন্ত্রভাবে পাঠানো—উভয় ক্ষেত্রেই implicit caching সমর্থন করে। কিন্তু সেখানে explicit cache অবজেক্ট তৈরি করে তার নাম পরবর্তী অনুরোধে দেওয়ার ব্যবস্থা নেই। একই বড় অংশ বারবার লাগলেই তাই API বদলানো জরুরি নয়; নির্দিষ্ট ক্যাশ তৈরি ও তার মেয়াদ পরিচালনার প্রয়োজনই সিদ্ধান্তটি বদলায়।

Implicit caching কখন যথেষ্ট

Gemini 2.5 ও পরবর্তী মডেলগুলোতে implicit caching স্বয়ংক্রিয়ভাবে চালু থাকে। অনুরোধের শুরুতে থাকা কনটেন্ট আগের অনুরোধের সঙ্গে মিললে সেই অংশ ক্যাশে পাওয়া যেতে পারে এবং হিট হওয়া টোকেনের জন্য কম দাম প্রযোজ্য হয়। ক্যাশ তৈরি করার আলাদা ধাপ নেই; একই লেখা পাঠালেই প্রতিবার হিট হবে, এমন নিশ্চয়তাও নেই।

ধরা যাক, অনেক প্রশ্নের আগে একই দীর্ঘ নির্দেশনা বা নথি থাকে, আর শেষে শুধু প্রশ্নটি বদলায়। স্থির অংশটি আগে রাখলে অভিন্ন প্রারম্ভিক অংশ শনাক্ত হওয়ার সুযোগ বাড়ে। নতুন তথ্য শুরুতেই ঢুকিয়ে দিলে বা অনুরোধগুলোর মধ্যে দীর্ঘ বিরতি থাকলে সেই সুযোগ কমতে পারে। তাই সম্ভাব্য সাশ্রয় আর বাস্তবে পাওয়া সাশ্রয়কে এক ধরে বাজেট করা ঠিক হবে না।

Gemini 2.5 Flash মডেলে ক্যাশিংয়ের জন্য ন্যূনতম ইনপুট ২,০৪৮ টোকেন। এই সীমা পূরণ করাও হিটের নিশ্চয়তা দেয় না। Interactions API-র প্রতিক্রিয়ায় usage.total_cached_tokens মানটি দেখায় কত টোকেন ক্যাশে পাওয়া গেছে; শুধু মোট ইনপুট টোকেন দেখে তা বোঝা যায় না। অনিয়মিত অনুরোধে তাই implicit caching সহজ পথ, তবে খরচের পূর্বাভাসে হিট না হওয়া অনুরোধও ধরতে হবে।

Explicit cache তৈরি ও পুনর্ব্যবহার

generateContent ক্যাশিং নির্দেশনায় দেখানো পদ্ধতিতে প্রথমে নির্দিষ্ট মডেলের জন্য স্থির কনটেন্ট দিয়ে ক্যাশ তৈরি করা হয়। পরবর্তী generateContent অনুরোধে সেই ক্যাশের নামের সঙ্গে নতুন প্রশ্ন পাঠানো যায়। Explicit caching বর্তমানে বিটা পর্যায়ে আছে; সংশ্লিষ্ট এন্ডপয়েন্ট ও সফটওয়্যার কিটের পদ্ধতি v1beta-তে পাওয়া যায়।

বড় স্থির নির্দেশনা, বারবার বিশ্লেষণ করা ভিডিও বা একই নথিসমষ্টি নিয়ে ধারাবাহিক প্রশ্ন explicit cache-এর উপযুক্ত উদাহরণ। প্রশ্ন ও পরিবর্তনশীল তথ্য আলাদা ইনপুটে রাখতে হয়। ক্যাশটি যে মডেলের জন্য তৈরি, ব্যবহারের অনুরোধেও সেই মডেল বেছে নিতে হয়। মডেলের ইনপুট সীমা হিসাব করার সময় ক্যাশে থাকা টোকেনও অন্তর্ভুক্ত থাকে; ক্যাশ বড় হলেই পরবর্তী প্রশ্নের জন্য অসীম জায়গা পাওয়া যায় না।

ক্যাশ তৈরির সময় তার মেয়াদ নির্ধারণ করা যায়; মেয়াদ না দিলে ডিফল্ট সময় এক ঘণ্টা। পরে মেয়াদ বা মেয়াদ শেষ হওয়ার সময় বদলানো এবং প্রয়োজন ফুরোলে ক্যাশ মুছে ফেলা যায়। ক্যাশের কনটেন্ট বদলানোর ব্যবস্থা নেই, তাই স্থির অংশ সংশোধিত হলে নতুন ক্যাশ তৈরি করতে হবে। এই কারণে নথির সংস্করণ বদলায় এমন কাজে ক্যাশের নাম ও সংশ্লিষ্ট কনটেন্টের রেকর্ড অ্যাপ্লিকেশনেই রাখা সুবিধাজনক।

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

Gemini 2.5 Flash দিয়ে টোকেন ও সংরক্ষণ খরচ

নিচের হিসাব Gemini 2.5 Flash মডেলের পেইড Standard স্তরে টেক্সট ইনপুটের জন্য। Google-এর মূল্যতালিকায় প্রতি ১০ লাখ সাধারণ ইনপুট টোকেনের দাম ০.৩০ মার্কিন ডলার, একই পরিমাণ cached token ব্যবহারের দাম ০.০৩ ডলার এবং ১০ লাখ টোকেন এক ঘণ্টা সংরক্ষণের দাম ১.০০ ডলার। আউটপুট টোকেনের দাম আলাদা; এই উদাহরণে সেটি ধরা হচ্ছে না।

ধরা যাক, ১ লাখ টোকেনের একটি স্থির নথি আধা ঘণ্টার মধ্যে ১০টি প্রশ্নে ব্যবহার করা হবে। কোনো ক্যাশে হিট ছাড়া প্রতিবার পুরো নথি সাধারণ ইনপুট হিসেবে পাঠালে শুধু ওই স্থির অংশের খরচ হবে ১০ × ১ লাখ × ০.৩০ ÷ ১০ লাখ = ০.৩০ ডলার। একই অংশ explicit cache থেকে ১০ বার ব্যবহার করলে cached token ব্যবহারে ০.০৩ ডলার এবং আধা ঘণ্টা সংরক্ষণে ০.০৫ ডলার, অর্থাৎ এই দুই খাতে মোট ০.০৮ ডলার।

এটি সম্পূর্ণ বিলের তুলনা নয়। নতুন প্রশ্নের ইনপুট, আউটপুট এবং অন্য প্রযোজ্য খরচ এখানে বাদ দেওয়া হয়েছে। সাধারণ ইনপুটের তুলনাটিও ধরে নিয়েছে যে সেখানে কোনো implicit ক্যাশে হিট হয়নি। যদি সেই অনুরোধগুলোর বড় অংশ আগেই কম দামে implicit ক্যাশ থেকে আসে, explicit cache বেছে নেওয়ার বাড়তি আর্থিক সুবিধা কমে যাবে।

কতক্ষণ রাখলে সংরক্ষণ খরচ সাশ্রয় খেয়ে ফেলে

ওই শর্তসাপেক্ষ উদাহরণে সাধারণ ইনপুটের ০.৩০ ডলার থেকে cached token ব্যবহারের ০.০৩ ডলার বাদ দিলে সংরক্ষণ খরচের জন্য সর্বোচ্চ ০.২৭ ডলার জায়গা থাকে। ১ লাখ টোকেন সংরক্ষণে ঘণ্টায় ০.১০ ডলার লাগে। তাই ১০ বার পুনর্ব্যবহারের পর ক্যাশটি মোট প্রায় ২.৭ ঘণ্টা রাখা হলে শুধু এই খাতগুলোর হিসাব সমান হয়; তার বেশি সময় রাখলে সংরক্ষণ খরচ সম্ভাব্য সাশ্রয় ছাড়িয়ে যায়।

একই ক্যাশ ১০ ঘণ্টা রেখে মাত্র ১০ বার ব্যবহার করলে সংরক্ষণেই ১.০০ ডলার এবং cached token ব্যবহারে ০.০৩ ডলার, মোট ১.০৩ ডলার হবে। অনুরোধের সংখ্যা বাড়লে বেশি বার কম দামের টোকেন ব্যবহারের সুযোগ পাওয়া যায়; মেয়াদ বাড়লেও অনুরোধ না বাড়লে শুধু সংরক্ষণ খরচ বাড়ে। এই সম্পর্কই মেয়াদ নির্ধারণের প্রধান হিসাব।

কাজের প্রশ্নগুলো স্বল্প সময়ের মধ্যে এলে সেই সময়ের উপযোগী মেয়াদ দিন। কাজ চলার আগেই মেয়াদ ফুরোলে ক্যাশ আবার তৈরি করতে হবে; প্রয়োজন শেষ হওয়ার অনেক পর পর্যন্ত রাখলেও খরচ চলতে থাকে। সিদ্ধান্ত নিতে স্থির অংশের টোকেনসংখ্যা, সম্ভাব্য পুনর্ব্যবহারের সংখ্যা ও সংরক্ষণের ঘণ্টা পাশাপাশি রাখুন। Interactions API ব্যবহার করলে বাস্তব ক্যাশে হিট দেখুন; explicit cache ব্যবহার করলে নির্ধারিত মেয়াদসহ হিসাব করুন।

আরও পড়ুন:

• GitHub Actions cache-mode বসান—একটি ভুলে cache poisoning ফিরতে পারে
• Claude API-তে 429 এড়ান—token count আর cache-এর হিসাব আগে করুন
• Asure Luna এখন payroll-এ কাজও করে: ভুল হলে মানুষকেই শেষ সিদ্ধান্ত নিতে হবে