Gemini Enterprise-এ pay-as-you-go: খালি AI seat-এর খরচ এড়ানো যাবে

Google Cloud ২৬ আগস্ট ২০২৬ Gemini Enterprise app-এর জন্য pay-as-you-go consumption edition চালুর ঘোষণা দিয়েছে। Google Cloud-এর ঘোষিত কাঠামোতে upfront commitment বা base subscription fee নেই: যোগ্য গ্রাহক ব্যবহৃত compute ও token-এর জন্য standard model API rate অনুযায়ী অর্থ দেবেন। Editionটি নির্বাচিত গ্রাহকের জন্য পাওয়া যাচ্ছে এবং বিস্তৃত rollout এখনো চলছে।

এর ফলে অনিয়মিত agent workload-এর জন্য সম্ভাব্য প্রত্যেক ব্যবহারকারীর নামে মাসজুড়ে স্থির seat ধরে রাখার প্রয়োজন কমতে পারে। Axios-এর ২৬ আগস্টের প্রতিবেদন নতুন optionটিকে বিদ্যমান per-seat subscription-এর পাশাপাশি fixed spend commitment ছাড়া Gemini Enterprise ব্যবহারের পথ হিসেবে নিশ্চিত করেছে। তবে খালি seat-এর খরচ এড়ানো সম্ভব হওয়া আর মোট খরচ কমে যাওয়া এক বিষয় নয়—শেষ ফল নির্ভর করবে workload ও অন্যান্য metered charge-এর ওপর।

ব্যবহার অনুযায়ী charge যেভাবে তৈরি হবে

Pay-as-you-go edition-এ licenseভিত্তিক feature quota নেই; ব্যবহার বাড়লে bill বাড়বে, কমলে কমবে। Assistant, agent action, image ও video generation, Deep Research এবং AI developer tools-এর সংশ্লিষ্ট ব্যবহার Agent Platform-এর আলাদা rate অনুসরণ করে। ফলে procurement হিসাবের জন্য একটি অভিন্ন token price যথেষ্ট নয়: কোন model ব্যবহৃত হচ্ছে, input ও output token কত, agent কতবার action বা model call করছে—সবই প্রাসঙ্গিক।

Gemini Enterprise-এর quota ও pricing নথিতে storage ও data indexing-এর মূল্য মাসে প্রতি GiB ৫ মার্কিন ডলার নির্ধারিত আছে; অন্য প্রধান feature-এর charge Agent Platform pricing-এর সঙ্গে যুক্ত। USD ছাড়া অন্য মুদ্রায় payment হলে Cloud Platform SKU-তে প্রকাশিত স্থানীয় মূল্য প্রযোজ্য, আর নির্বাচিত support service অনুযায়ী পরিবর্তনশীল support fee যোগ হতে পারে।

তাই base subscription না থাকলেও ‘ব্যবহার নেই মানে কোনো bill নেই’—এমন নিশ্চয়তা দেওয়া যায় না। Indexed data রাখা হলে storage charge চলতে পারে, support fee আলাদা থাকতে পারে এবং একাধিক ধাপে চলা agent একই কাজ সম্পন্ন করতে বহু model call করতে পারে। বাংলাদেশের বা ভারতের finance team-এর পূর্ণ হিসাব তাই token ও compute-এর সঙ্গে storage-indexing, support, প্রযোজ্য কর এবং মুদ্রা রূপান্তর মিলিয়ে করতে হবে।

কারা এখন pay-as-you-go নিতে পারবেন

বর্তমান eligibility সাধারণ card-based self-service account-এর চেয়ে সংকীর্ণ। Google-এর নথি অনুযায়ী projectটি এমন invoiced Cloud Billing account-এর সঙ্গে যুক্ত থাকতে হবে, যা সক্রিয় মাসিক invoice পায়; accountটিকে ১৭ আগস্ট ২০২৬ চালু হওয়া নতুন overage billing controls-সংক্রান্ত নির্দিষ্ট email-ও পেতে হয়েছে। এই দুই শর্ত পূরণ না হলে console-এ optionটি দেখা বা subscription নেওয়া নিশ্চিত নয়।

অতএব বর্তমান status হলো: editionটি ঘোষিত এবং নির্দিষ্ট যোগ্য গ্রাহকের জন্য ব্যবহারযোগ্য, কিন্তু সবার জন্য নির্বিশেষে উন্মুক্ত নয়। Commercial quote বা migration পরিকল্পনার আগে billing-account type, account-specific email এবং project eligibility মিলিয়ে দেখা দরকার; শুধু প্রতিষ্ঠানের আগে থেকেই Google Cloud account আছে বলেই access নিশ্চিত ধরে নেওয়া যাবে না।

Seat, pooled quota ও consumption-এর নিরপেক্ষ তুলনা

স্থিতিশীল দৈনিক ব্যবহার: ধরা যাক, একটি নির্দিষ্ট দল প্রতিদিন Gemini Enterprise assistant ও developer tools ব্যবহার করে এবং ব্যবহারকারীর সংখ্যা খুব বেশি বদলায় না। এমন workload-এ per-user subscription-এর স্থির মাসিক baseline বাজেটকে পূর্বানুমানযোগ্য করে। একই edition, project ও location-এর ব্যবহারকারীরা quota pool ভাগ করে নেওয়ায় একজনের অব্যবহৃত allowance অন্য ভারী ব্যবহারকারীর কাজে লাগতে পারে।

অনিয়মিত agent workload: অন্য একটি শর্তসাপেক্ষ দৃশ্যে মাসের কয়েক দিন document processing বা research agent খুব ব্যস্ত, কিন্তু বাকি সময় প্রায় নিষ্ক্রিয়। সেখানে প্রতিটি সম্ভাব্য operator-এর জন্য পুরো মাস seat কেনার বদলে বাস্তব consumption মেটানো অর্থসাশ্রয়ী হতে পারে। কিন্তু burst-এর সময় agent যদি বারবার search, tool ও model call চালায়, অল্প কয়েকটি সক্রিয় দিনেও charge দ্রুত বাড়তে পারে।

• Seat subscription: ব্যবহারকারী স্থির, কাজ নিয়মিত এবং মাসিক খরচের পূর্বানুমানযোগ্যতা প্রধান বিবেচনা হলে শক্তিশালী বিকল্প।
• Pooled quota: একই project ও edition-এ ব্যবহারকারীদের চাহিদা অসম হলেও মোট কেনা allowance যথেষ্ট হলে অব্যবহৃত capacity কাজে লাগাতে পারে।
• Pay-as-you-go: workload বিরতিতে আসে, seat সংখ্যা অনিশ্চিত এবং নিষ্ক্রিয় সময়ে base subscription বহন না করাই অগ্রাধিকার হলে বেশি যুক্তিসঙ্গত।
• মিশ্র কাঠামো: নিয়মিত office productivity-এর জন্য seat রেখে অতিরিক্ত বা আকস্মিক agent demand consumption rate-এ চালানো সম্ভব।

Break-even-এর জন্য seat-এর মোট মাসিক খরচের সঙ্গে pay-as-you-go model consumption, agent action, storage-indexing ও support fee-এর যোগফল তুলনা করতে হবে। eWeek-এর স্বাধীন বিশ্লেষণও দেখিয়েছে যে শুধু token charge দিয়ে সম্পূর্ণ Gemini Enterprise bill বোঝা যায় না এবং ব্যবহার বাড়ার সঙ্গে consumption model-এর সুবিধা সংকুচিত হতে পারে। কোনো একক সর্বজনীন break-even সংখ্যা তাই প্রকাশিত rate থেকে বের করা সম্ভব নয়।

Spend cap খরচ থামাবে, কাজও থামতে পারে

নতুন billing option-এর সঙ্গে project-level hard monthly spend cap, anomaly detection এবং overage control এসেছে। Project নির্ধারিত সীমায় পৌঁছালে সংশ্লিষ্ট agent-এর API call সাময়িকভাবে থেমে যায়; administrator পরে console থেকে কাজ পুনরায় চালু করতে বা overage অনুমোদন করতে পারেন। ৫০%, ৮০% ও ১০০% budget threshold-এ automated email alert দেওয়ার ব্যবস্থাও রয়েছে।

এই controls invoice আসার আগেই আর্থিক সীমা কার্যকর করতে পারে, তবে production workflow থেমে যাওয়ার operational cost দূর করে না। গুরুত্বপূর্ণ agent মাঝপথে pause হলে অসমাপ্ত কাজ কীভাবে সামলানো হবে, সেটিও প্রতিষ্ঠানকে নিজস্ব workflow অনুযায়ী বিবেচনা করতে হবে। Spend cap তাই bill-এর ঊর্ধ্বসীমা রক্ষার ব্যবস্থা; uninterrupted service-এর নিশ্চয়তা নয়।

স্থিতিশীল বা বাড়তে থাকা workload-এর জন্য আলাদা Flexible Savings Plan-এ এক বছরের monthly-spend commitment দিলে eligible token cost-এ ১০% এবং তিন বছরের commitment-এ ২০% ছাড় রয়েছে। বিপরীতে select workload-এর deferred execution ব্যবহার করে off-peak সময়ে inference cost সর্বোচ্চ অর্ধেক করার সুবিধা এখনো ‘coming soon’; বর্তমান budget-এ এটিকে নিশ্চিত সাশ্রয় হিসেবে ধরা যাবে না।

এখনও যে হিসাব প্রতিষ্ঠানের নিজস্ব

এখন পর্যন্ত নিশ্চিত চিত্র হলো, Gemini Enterprise-এ seat subscription-এর পাশাপাশি এমন consumption edition এসেছে যেখানে base subscription fee নেই এবং প্রকৃত usage অনুযায়ী charge হয়। কিন্তু access invoiced account ও নির্দিষ্ট eligibility-এর ওপর নির্ভরশীল; আর storage, support ও agent-এর বহুধাপের ব্যবহার যোগ হলে খালি seat বাদ দেওয়ার দৃশ্যমান সাশ্রয় পুরোপুরি বা আংশিকভাবে হারিয়ে যেতে পারে।

পরবর্তী গুরুত্বপূর্ণ তথ্য হবে broad rollout-এর সময়সূচি, eligibility-এর বিস্তার এবং প্রতিটি account, region ও model-এর জন্য কার্যকর Cloud Platform SKU। তার আগে নিরপেক্ষ তুলনার ভিত্তি হলো একই প্রত্যাশিত workload-এর জন্য seat baseline, pooled quota utilization এবং token, compute, storage ও support-সহ পূর্ণ consumption bill পাশাপাশি মাপা।