Gemini Enterprise-এ খালি আসনের খরচ নেই: Google বদলাল AI বিলিং

Google Cloud ২৬ আগস্ট ২০২৬ Gemini Enterprise app-এর জন্য pay-as-you-go consumption edition এবং এআই এজেন্টের নতুন ব্যয় নিয়ন্ত্রণ চালুর ঘোষণা দিয়েছে। Google Cloud-এর ঘোষণায় বলা হয়েছে, এই সংস্করণে আগাম আর্থিক প্রতিশ্রুতি বা মূল subscription fee নেই; ব্যবহৃত compute ও token-এর জন্য standard model API rate-এ বিল হবে। সুবিধাটি এখন নির্বাচিত গ্রাহকের জন্য পাওয়া যাচ্ছে, আর বিস্তৃত সরবরাহ পর্যায়ক্রমে হওয়ার কথা।
Google আসনভিত্তিক subscription তুলে নেয়নি; প্রতিষ্ঠান এখন নির্দিষ্ট ব্যবহারকারীর আসন এবং প্রকৃত ব্যবহারের বিলিং পাশাপাশি নিতে পারবে। ২৬ আগস্টের Axios প্রতিবেদন pay-as-you-go বিকল্প, প্রকল্পের মাসিক ব্যয়সীমা এবং এক ও তিন বছরের প্রতিশ্রুতিতে যথাক্রমে ১০% ও ২০% ছাড়ের তথ্য নিশ্চিত করেছে। প্রতিবেদন অনুযায়ী, বড় আসন-প্রতিশ্রুতির আগে কম স্থির খরচে কর্মীদের ব্যবহার যাচাইয়ের সুযোগ দেওয়াও পরিবর্তনটির লক্ষ্য।
‘খালি আসনের খরচ নেই’—কোন শর্তে
কথাটি কেবল নতুন consumption edition-এর ক্ষেত্রে প্রযোজ্য। এ মডেলে কোনো কর্মীর জন্য আগে থেকে আসন কিনে রাখতে হয় না; প্রকল্পে ব্যবহার না হলে token বা compute consumption-এর বিলও তৈরি হয় না। চাহিদা কমলে খরচ সেই অনুপাতে কমতে পারে।
এটি সব Gemini Enterprise গ্রাহকের জন্য স্বয়ংক্রিয় মূল্যছাড় নয় এবং বিদ্যমান per-user subscription-এর শর্তও বদলায়নি। আসনভিত্তিক মডেলে প্রতি ব্যবহারকারীর নির্ধারিত মাসিক ফির সঙ্গে প্রকল্পজুড়ে ভাগ করা দৈনিক quota থাকে। নিয়মিত একই কর্মীদল পণ্যটি ব্যবহার করলে এই স্থির ভিত্তি বাজেট অনুমান সহজ করতে পারে; অনিয়মিত এজেন্ট বা স্বল্পমেয়াদি পরীক্ষায় consumption edition অব্যবহৃত আসনের স্থির খরচ এড়ায়।
Pay-as-you-go-তে সক্রিয় সময়ের বিল সরাসরি ব্যবহারের সঙ্গে বাড়বে। ফলে ‘খালি আসন নেই’ মানেই প্রতিটি workload-এ মোট খরচ কম হবে—এমন নিশ্চয়তা নেই। কোন SKU ব্যবহৃত হচ্ছে, token ও compute consumption কত এবং কেনা quota বাস্তবে কতটা কাজে লাগছে—এই তিনটি বিষয় তুলনায় রাখতে হবে।
তিন ব্যবহার-প্যাটার্নে তিন ধরনের হিসাব

অনিয়মিত, স্থিতিশীল ও দ্রুত বাড়তে থাকা ব্যবহারে একই ক্রয়নীতি কার্যকর নয়। সিদ্ধান্তের ভিত্তি শুধু অনুমোদিত ব্যবহারকারীর সংখ্যা নয়; সক্রিয় ব্যবহার, মাসিক খরচের ওঠানামা এবং কাজ বন্ধ হওয়ার প্রভাবও বিবেচ্য।
- অনিয়মিত বা পরীক্ষামূলক ব্যবহার: দীর্ঘ বিরতির পর অল্প সময়ের জন্য এজেন্ট চালানো হলে pay-as-you-go সরাসরি মানানসই। সম্ভাব্য বিল হবে ব্যবহৃত token ও compute-এর সঙ্গে প্রযোজ্য API rate-এর গুণফল; নিষ্ক্রিয় কর্মীর জন্য আলাদা consumption charge যোগ হবে না।
- স্থিতিশীল দৈনিক ব্যবহার: প্রায় একই কর্মীদল প্রতিদিন কাজ করলে per-user subscription পূর্বানুমানযোগ্য মাসিক ভিত্তি দেয়। এখানে মূল প্রশ্ন হলো কেনা quota নিয়মিত ব্যবহৃত হচ্ছে কি না। অব্যবহৃত আসন বা quota ধারাবাহিক হলে consumption edition-এর সম্ভাব্য বিলের সঙ্গে তুলনা দরকার।
- দ্রুত বাড়তে থাকা ব্যবহার: মাসিক খরচের একটি নির্ভরযোগ্য ন্যূনতম স্তর তৈরি হলে Flexible Savings Plan প্রাসঙ্গিক হতে পারে। স্থিতিশীল অংশের জন্য commitment রেখে অনিশ্চিত অতিরিক্ত ব্যবহার on-demand rate-এ নেওয়া যায়।
এক প্রতিষ্ঠানে মডেলগুলো পাশাপাশি চলতে পারে: নিয়মিত অফিস ব্যবহারের জন্য আসন, সাময়িক এজেন্ট প্রকল্পে consumption billing এবং অনুমানযোগ্য ব্যয়ের জন্য savings plan। তাই তালিকামূল্য পাশাপাশি রাখাই যথেষ্ট নয়; আসন ও shared quota-এর ব্যবহারহার এবং pay-as-you-go workload-এর প্রকৃত consumption একই সময়সীমায় মাপতে হবে।
১০–২০% সাশ্রয়ের বিনিময়ে দীর্ঘ দায়
Flexible Savings Plan শর্তহীন ছাড় নয়। Google Cloud-এর FSP নথি অনুযায়ী, ক্রেতা এক বা তিন বছরের জন্য একটি নির্দিষ্ট ন্যূনতম মাসিক ব্যয়ের প্রতিশ্রুতি দেয়। যোগ্য Gemini Enterprise SKU-তে এক বছরের পরিকল্পনায় ১০% এবং তিন বছরের পরিকল্পনায় ২০% ছাড় পাওয়া যায়; কেনা commitment বাতিল করা যায় না।
কোনো মাসে যোগ্য ব্যবহার commitment-এর নিচে থাকলেও সম্পূর্ণ প্রতিশ্রুত অর্থ দিতে হবে, আর অব্যবহৃত অংশ পরের মাসে যাবে না। ব্যবহার প্রতিশ্রুত সীমা ছাড়ালে অতিরিক্ত অংশ standard on-demand rate-এ বিল হয়। ‘কোনো সর্বনিম্ন বা সর্বোচ্চ নেই’ বলতে Google নির্ধারিত বাধ্যতামূলক commitment size নেই; ক্রেতা যে অঙ্ক বেছে নেবে, মেয়াদকালে সেটিই তার ন্যূনতম মাসিক দায়।
এই কারণে commitment নির্ধারণে সবচেয়ে ব্যস্ত মাসের খরচ দুর্বল ভিত্তি হতে পারে। মৌসুমি চাহিদার একটি শীর্ষ মাস ধরে অঙ্ক বাছলে কম ব্যবহারের মাসে অব্যবহৃত commitment ছাড়ের সুবিধা মুছে দিতে পারে। স্থিতিশীল বা ধারাবাহিকভাবে বাড়তে থাকা workload-এ নিয়মিত অতিক্রম করা ব্যয়ের অংশটি commitment-এর ভিত্তি হিসেবে তুলনামূলকভাবে হিসাবযোগ্য।
মাসিক সীমায় শুধু এজেন্টের API call থামবে

প্রকল্প পর্যায়ে firm monthly spend limit নির্ধারণ করা নতুন নিয়ন্ত্রণগুলোর সবচেয়ে প্রত্যক্ষ অংশ। সীমা পূর্ণ হলে সংশ্লিষ্ট এজেন্টের API call সাময়িকভাবে থামবে; প্রকল্পের বাকি production infrastructure চালু থাকবে। ব্যয়ের ৫০%, ৮০% ও ১০০% পর্যায়ে স্বয়ংক্রিয় email alert দেওয়ার ব্যবস্থাও রয়েছে।
প্রশাসক console থেকে কাজ আবার চালু করতে পারেন। নিরবচ্ছিন্ন পরিচালনা বেশি গুরুত্বপূর্ণ হলে overage চালু করা যায়; তখন সীমার অতিরিক্ত ব্যবহার consumption rate-এ যাবে এবং প্রযোজ্য ক্ষেত্রে FSP থেকে ব্যয় সমন্বয় হতে পারে। ফলে hard cap শুধু সতর্কবার্তা নয়—এটি এজেন্টের ব্যবহার বাস্তবে থামাতে পারে।
এই নিয়ন্ত্রণের কার্যগত ঝুঁকিও আছে। পরীক্ষামূলক প্রকল্পে কঠোর সীমা অনাকাঙ্ক্ষিত বিল আটকাতে পারে, কিন্তু গ্রাহকসেবা বা সময়-সংবেদনশীল production workload-এ হঠাৎ API call বন্ধ হওয়ার ব্যবসায়িক ক্ষতি বেশি হতে পারে। তাই সীমা ও overage policy workload-এর গুরুত্ব অনুযায়ী আলাদা করা দরকার।
কী এখন পাওয়া যাচ্ছে, কী এখনো সীমিত
ঘোষণার সময় Flexible Savings Plan self-service এবং enterprise agreement—দুই ধরনের গ্রাহকের জন্য উপলভ্য ছিল। বিপরীতে, Gemini Enterprise app-এর pay-as-you-go consumption edition নির্বাচিত গ্রাহকের মধ্যে সীমিত; বিস্তৃত rollout-এর নির্দিষ্ট অঞ্চলভিত্তিক সময়সূচি প্রকাশ করা হয়নি।
বাংলাদেশ বা ভারতের কোনো প্রতিষ্ঠানের billing account-এ বিকল্পটি দেখা যাবে কি না, তা account eligibility ও rollout অবস্থার ওপর নির্ভর করবে। আলাদা আঞ্চলিক মূল্যও ঘোষণাটিতে দেওয়া হয়নি। নিশ্চিত পরিবর্তন হলো, Gemini Enterprise app কেনার ক্ষেত্রে স্থির আসন এখন আর একমাত্র বিলিং পথ নয়; তবে সাশ্রয় নির্ভর করবে workload-এর ধরন, commitment ব্যবহারের হার এবং spend cap-এ কাজ থামার ঝুঁকির ওপর।
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।