Gemini Enterprise-এ খরচসীমা—বাজেট ফুরোলেই এজেন্ট থামবে

Google Cloud ২৬ আগস্ট ২০২৬ Gemini Enterprise-এর নির্বাচিত গ্রাহকদের জন্য ব্যবহারভিত্তিক সংস্করণ এবং প্রকল্প পর্যায়ে মাসিক ব্যয়সীমা ঘোষণা করেছে। Google Cloud-এর ঘোষণায় বলা হয়েছে, নতুন pay-as-you-go edition বিস্তৃতভাবে চালুর আগে সীমিত গ্রাহকের জন্য পাওয়া যাচ্ছে; আর Gemini Enterprise Flexible Savings Plans ইতিমধ্যে স্ব-পরিষেবা ও Enterprise Agreement গ্রাহকদের জন্য উপলভ্য।

প্রকল্পের নির্ধারিত বাজেট শেষ হলে সংশ্লিষ্ট এজেন্টের API কল সাময়িকভাবে থামবে। Axios-এর প্রতিবেদনে pay-as-you-go বিকল্প, মাসিক প্রকল্পসীমা এবং নির্দিষ্ট মাসিক ব্যয়ে এক ও তিন বছরের প্রতিশ্রুতির জন্য যথাক্রমে ১০% ও ২০% ছাড়ের তথ্যও রয়েছে। ফলে নতুন ব্যবস্থার মূল বিনিময়টি স্পষ্ট: কঠোর সীমা বিলকে আটকে রাখে, কিন্তু বহু ধাপের এজেন্ট-কাজ মাঝপথে থামাতে পারে।

আসনভিত্তিক বিলিংয়ের পাশে নতুন ব্যবহারভিত্তিক পথ

Gemini Enterprise-এর বিদ্যমান per-user seat subscription বাদ যাচ্ছে না। নিয়মিত ব্যবহারকারীর জন্য নির্দিষ্ট মাসিক ফি ও প্রকল্পজুড়ে ভাগ করা দৈনিক quota থাকছে; নতুন consumption edition-এ আগাম প্রতিশ্রুতি বা ভিত্তি subscription fee ছাড়া ব্যবহৃত compute ও token-এর জন্য standard model API rate প্রযোজ্য হবে। প্রতিষ্ঠান একই পরিবেশে এই পদ্ধতিগুলো মিলিয়েও ব্যবহার করতে পারবে।

স্থির আসন এমন দলের জন্য তুলনামূলকভাবে অনুমানযোগ্য, যারা প্রতিদিন Gemini Enterprise ব্যবহার করে। বিপরীতে pay-as-you-go পরীক্ষামূলক, বিরতিযুক্ত বা প্রকল্পনির্ভর agent workload-এর সঙ্গে বেশি মানানসই: কাজ না থাকলে খালি আসনের খরচ নেই, তবে ব্যবহার হঠাৎ বাড়লে বিলও সরাসরি বাড়বে। এটি ছাড়ের চুক্তি নয়; ব্যবহারের সঙ্গে ব্যয় ওঠানামা করার ব্যবস্থা।

Pay-as-you-go edition-এর প্রাপ্যতাও এখন সীমিত। Google-এর প্রকাশিত তথ্য অনুযায়ী এটি নির্বাচিত গ্রাহকদের দিয়ে শুরু হয়েছে এবং পরে বিস্তৃতভাবে চালু হবে। তাই বাংলাদেশ বা ভারতের কোনো Cloud Billing account-এ সুবিধাটি এখনই দেখা যাবে—এমন নিশ্চয়তা ঘোষণাটি দেয় না।

কঠোর সীমা খরচ থামায়, কাজ শেষ হওয়ার নিশ্চয়তা দেয় না

মাসিক project spend cap সাধারণ বাজেট-সতর্কতা নয়। সীমা পূর্ণ হলে সীমাবদ্ধ প্রকল্পের agent API call সাময়িকভাবে থামে, যদিও বাকি production infrastructure সচল থাকার কথা। ব্যয়ের ৫০%, ৮০% ও ১০০% স্তরে স্বয়ংক্রিয় ই-মেইল সতর্কতা রাখা যায়, যাতে চূড়ান্ত সীমায় পৌঁছানোর আগে অস্বাভাবিক ব্যবহার শনাক্ত করা সম্ভব হয়।

এর কার্যকরী ঝুঁকি হলো অসমাপ্ত workflow। কোনো এজেন্ট নথি সংগ্রহ, বিশ্লেষণ, যাচাই ও প্রতিবেদন তৈরির ধারাবাহিক কাজ করলে সীমা ছোঁয়ার পরের API-নির্ভর ধাপ আর এগোবে না। Google সর্বজনীনভাবে বলেনি যে প্রতিটি থেমে যাওয়া workflow পরে ঠিক কোন ধাপ থেকে শুরু হবে বা অসমাপ্ত state কতক্ষণ সংরক্ষিত থাকবে; তাই “সাময়িক বিরতি”কে নিরাপদ সমাপ্তি ধরা যাবে না।

Hard cap এবং quota overage এক বিষয় নয়। আসনভিত্তিক edition-এ প্রকল্পের pooled quota শেষ হলে প্রশাসক overage অনুমোদন করতে পারেন, যা pay-as-you-go হারে অতিরিক্ত ব্যবহার চালায়; কিন্তু প্রকল্পের মাসিক spend cap পূর্ণ হলে সেই অতিরিক্ত ব্যবহারও বন্ধ হয়। আর নতুন pay-as-you-go edition-এ প্রতিটি যোগ্য ব্যবহার শুরু থেকেই consumption rate-এ হিসাব করা হয়।

তিন কাজের ধরনে সিদ্ধান্তের ছক

কোন পদ্ধতি বাস্তবে উপযোগী হবে, তা ব্যবহারকারীর সংখ্যা নয়—ব্যবহারের নিয়মিততা, ন্যূনতম মাসিক ব্যয় এবং কাজ থামার সহনশীলতার সমন্বয়ে নির্ধারিত হবে।

• নিয়মিত দৈনিক ব্যবহার: স্থায়ী দল প্রতিদিন productivity feature ব্যবহার করলে per-user seat subscription মাসিক হিসাবকে স্থিতিশীল রাখে। প্রকল্পের pooled quota হালকা ও ভারী ব্যবহারকারীদের মধ্যে সক্ষমতা ভাগ করতে পারে।
• পরীক্ষামূলক বা অনিয়মিত প্রকল্প: ব্যবহারকারী ও agent workload কতটা বাড়বে জানা না থাকলে pay-as-you-go স্থির আসনের দায় এড়ায়। সর্বোচ্চ মাসিক ঝুঁকি বেঁধে দিতে project spend cap যোগ করা যায়, তবে সীমা কম হলে কাজ থামার সম্ভাবনাও বাড়ে।
• আকস্মিক ভারী কাজ: একবারের বড় workload-এর জন্য দীর্ঘমেয়াদি প্রতিশ্রুতির চেয়ে pay-as-you-go সরাসরি বিকল্প। কাজ মাঝপথে থামানো অগ্রহণযোগ্য হলে hard cap-এর অঙ্কে সম্ভাব্য সম্পূর্ণ runtime-এর জায়গা রাখতে হবে।
• পুনরাবৃত্ত কিন্তু ওঠানামা করা ব্যবহার: প্রতি মাসে বিশ্বাসযোগ্য ন্যূনতম ব্যয় থাকলে Flexible Savings Plan unit cost কমাতে পারে। কোনো কোনো মাসে ব্যবহার প্রায় শূন্যে নেমে গেলে একই প্রতিশ্রুতি উল্টো অব্যবহৃত ব্যয় তৈরি করবে।

এই তিনটির ভূমিকা আলাদা। Seat subscription নির্দিষ্ট ব্যবহারকারীভিত্তিক সক্ষমতা কেনে, pay-as-you-go প্রকৃত ব্যবহারের সঙ্গে বিল মেলায়, আর Flexible Savings Plan দীর্ঘ মেয়াদে একটি মাসিক ব্যয়ের দায় নিয়ে যোগ্য ব্যবহারে ছাড় দেয়। Project spend cap হলো আলাদা নিয়ন্ত্রণ; এটি ছাড় সৃষ্টি করে না, কেবল নির্ধারিত সীমানায় ব্যবহার থামায়।

১০% ও ২০% ছাড়ের বিনিময়ে দীর্ঘমেয়াদি দায়

Gemini Enterprise Flexible Savings Plan-এ এক বছরের প্রতিশ্রুতিতে যোগ্য SKU-তে ১০% এবং তিন বছরের প্রতিশ্রুতিতে ২০% ছাড় প্রযোজ্য, যদিও তালিকাভুক্ত কিছু SKU অতিরিক্ত FSP ছাড় না দিয়েও commitment কমাতে পারে। Google Cloud-এর FSP নথি অনুযায়ী গ্রাহক একটি নির্দিষ্ট মাসিক অঙ্কে এক বা তিন বছরের জন্য প্রতিশ্রুতিবদ্ধ হন; কেনার পরে পরিকল্পনাটি সাধারণভাবে বাতিল বা পরিবর্তন করা যায় না।

“Minimum বা maximum spend requirement নেই” কথাটির অর্থ Google সবার জন্য একই বাধ্যতামূলক অঙ্ক নির্ধারণ করেনি; গ্রাহক নিজের commitment amount নির্বাচন করেন। কিন্তু কেনার পর নির্বাচিত অঙ্কটিই প্রতি মাসের দায়। যোগ্য ব্যবহার সেই অঙ্কের নিচে থাকলেও পুরো commitment fee দিতে হয়, আর অব্যবহৃত অংশ পরের মাসে জমা হয় না।

তাই ঘোষিত ছাড়ের হারকে মোট বিলের নিশ্চিত সাশ্রয় হিসেবে পড়া ঠিক হবে না। পরিকল্পনাটি তখনই কার্যকর, যখন ছাড়যোগ্য মাসিক ব্যবহার commitment-এর কাছাকাছি থাকে। মৌসুমি workload-এর জন্য খুব বেশি অঙ্ক নির্ধারণ করলে কম ব্যবহারের মাসে হারানো commitment ঘোষিত ১০% বা ২০% সুবিধাকে ছাপিয়ে যেতে পারে।

যা চালু হয়েছে, যা এখনও অপেক্ষায়

নিশ্চিত অবস্থা হলো Flexible Savings Plans এখন পাওয়া যাচ্ছে, আর নতুন billing package-এর অংশ হিসেবে project spend cap ও বাজেট-সতর্কতা প্রকাশ করা হয়েছে। Pay-as-you-go consumption edition নির্বাচিত গ্রাহকদের জন্য চালু হলেও বিস্তৃত rollout এখনও বাকি। Google ভবিষ্যতে কিছু কাজ off-peak সময়ে সরিয়ে token cost-এ সর্বোচ্চ ৫০% ছাড়ের deferred execution pricing আনার পরিকল্পনাও জানিয়েছে; সেটি বর্তমান সুবিধা নয়।

বাংলাদেশ ও ভারতের জন্য আলাদা rollout সূচি, স্থানীয় মুদ্রায় কার্যকর মূল্য, করসহ চূড়ান্ত ব্যয় কিংবা সব যোগ্য account-এ consumption edition পৌঁছানোর নির্দিষ্ট তারিখ প্রকাশিত হয়নি। ফলে এখন তুলনার নির্ভরযোগ্য ভিত্তি তিনটি: workload কত নিয়মিত, প্রতি মাসে কত ব্যবহার নিশ্চিত এবং spend cap পূর্ণ হলে চলমান এজেন্ট-কাজ থামা কতটা গ্রহণযোগ্য।