Gemini 3.8 Flash একই দামে বেশি ভাবছে—token খরচ কিন্তু বাড়তে পারে
Google-এর ২ সেপ্টেম্বরের ঘোষণায় Gemini 3.8 Flash সাধারণভাবে উন্মুক্ত করা হয়েছে। 3.7 Flash-এর সমান প্রারম্ভিক দামে প্রতি ১০ লাখ input token ০.৭৫ ডলার এবং প্রতি ১০ লাখ output token ৩.৭৫ ডলার; তবে জটিল কাজে অতিরিক্ত reasoning step ও ধারাবাহিক tool call-এর কারণে মডেলটি বেশি token ব্যবহার করতে পারে।
Google DeepMind-এর model information মডেলটির General Availability, ১০ লাখ input-token context, ৬৪ হাজার output-token সীমা এবং Gemini API ও Google AI Studio-তে প্রাপ্যতা নিশ্চিত করে। ফলে 3.7 থেকে production migration এখন সম্ভব, কিন্তু একই unit rate-কে একই workload bill ধরে নেওয়া যাবে না।
একই দামটি প্রারম্ভিক—স্থায়ী rate নয়
3.8 Flash ও 3.7 Flash-এর তুলনায় “একই দাম” বলতে বর্তমান standard API unit rate বোঝায়। এই প্রারম্ভিক rate ৩১ ডিসেম্বর ২০২৬ পর্যন্ত প্রযোজ্য; ১ জানুয়ারি ২০২৭ থেকে ঘোষিত standard rate প্রতি ১০ লাখ input token ১.৫০ ডলার এবং output token ৭.৫০ ডলার হবে। অর্থাৎ বর্তমান migration হিসাবের সঙ্গে ২০২৭ সালের নির্ধারিত মূল্যবৃদ্ধিও আলাদা scenario হিসেবে রাখা দরকার।
Unit rate অপরিবর্তিত থাকলেও একটি কাজ শেষ করতে কত input, output ও reasoning token লাগে, সেটিই প্রতি-task ব্যয় নির্ধারণ করে। Agentic workflow-তে প্রতিটি নতুন model turn-এ আগের কথোপকথন বা tool result input হিসেবে গেলে billable volume বাড়তে পারে। উন্নত reasoning যদি ব্যর্থতা ও retry কমায়, সফল কাজপ্রতি খরচ আবার কমতেও পারে—কোন ফলটি ঘটবে, তা workload না মেপে বলা যায় না।
GA, API access ও context limit-এর অর্থ
General Availability status মানে 3.8 Flash কেবল সীমিত preview নয়; production ব্যবহারের জন্য স্থিতিশীল model ID পাওয়া যাচ্ছে। ১০ লাখ input-token limit বড় document set, codebase-এর অংশ বা দীর্ঘ agent history একটি request-এ নেওয়ার জায়গা দেয়, কিন্তু এটি বিনা খরচের capacity নয়—প্রকৃতপক্ষে যত input পাঠানো হবে, তার ওপরই input charge নির্ভর করবে।
একইভাবে ৬৪ হাজার output token একটি সর্বোচ্চ সীমা, প্রত্যেক response-এর স্বাভাবিক দৈর্ঘ্য নয়। Maximum output কমিয়ে রাখা response-এর ঊর্ধ্বসীমা নিয়ন্ত্রণ করতে পারে, কিন্তু reasoning ও tool loop কত token নেবে তা task, prompt এবং নির্বাচিত effort level-এর ওপরও নির্ভর করবে। তাই context limit সামর্থ্যের মাপ; budget-এর নিশ্চয়তা নয়।
Ars Technica-র ২ সেপ্টেম্বরের প্রতিবেদন ও release, একই প্রারম্ভিক API rate এবং Google ecosystem-এ তাৎক্ষণিক প্রাপ্যতা নথিবদ্ধ করেছে। প্রতিবেদনটি একই সঙ্গে মনে করিয়ে দেয় যে প্রকাশিত performance ফল মূলত Google-এর benchmark; কোনো প্রতিষ্ঠানের নিজস্ব workload-এ সমান উন্নতি নিশ্চিত নয়।
প্রতি-token rate থেকে প্রতি-task bill
বর্তমান standard rate-এ প্রাথমিক হিসাবটি সরল: input token-কে ১০ লাখ দিয়ে ভাগ করে ০.৭৫ ডলারে গুণ করতে হবে, তারপর output token-কে ১০ লাখ দিয়ে ভাগ করে ৩.৭৫ ডলারে গুণ করে দুই ফল যোগ করতে হবে। Model charge-এর বাইরে কোনো paid tool, grounding service, cache storage বা অন্য অবকাঠামো থাকলে তার খরচ আলাদাভাবে যোগ হবে।
একটি শর্তসাপেক্ষ উদাহরণে, ১০ হাজার input ও ২ হাজার output token-এর task-এর model cost প্রায় ০.০১৫ ডলার: input-এর জন্য ০.০০৭৫ এবং output-এর জন্য ০.০০৭৫ ডলার। একই input রেখে output ৪ হাজার token হলে খরচ দাঁড়ায় ০.০২২৫ ডলার—unit rate না বদলালেও task bill ৫০ শতাংশ বেশি।
আরেকটি শর্তসাপেক্ষ agent run-এ tool result ও পরবর্তী turn মিলিয়ে input ২০ হাজার এবং output ৪ হাজার হলে model cost হবে ০.০৩০ ডলার। এটি 3.8 Flash-এর ঘোষিত বা স্বাভাবিক usage নয়; একই rate-এর অধীনে token volume বদলালে মোট ব্যয় কীভাবে বদলায়, শুধু তার arithmetic illustration। বাস্তব তুলনায় retry-সহ একটি সম্পূর্ণ task-এর সব call একত্র করতে হবে।
কোন effort level কোথায় মানানসই
3.8 Flash-এ low, medium ও high thinking level আছে; default হলো medium। কোনটি ব্যবহার করা হবে, তা শুধু task-এর জটিলতা দিয়ে নয়, ভুল ফলের মূল্য এবং অতিরিক্ত reasoning সফলতার হার কতটা বাড়ায়—এই দুই বিষয়ের ভিত্তিতে ঠিক করা উচিত।
- Low: classification, extraction, format conversion বা latency-sensitive কাজ, যেখানে 3.7 ইতিমধ্যে নির্ভরযোগ্য এবং token budget কঠোর।
- Medium: কয়েক ধাপের synthesis, code analysis বা সীমিত tool use; 3.7 ও 3.8-এর shadow comparison শুরু করার জন্য এটি যুক্তিসংগত baseline।
- High: দীর্ঘ coding task, autonomous agent loop বা কঠিন বহু-ধাপের বিশ্লেষণ, যেখানে ভালো first-pass result retry-এর চেয়ে বেশি মূল্যবান। এখানে token ও tool-call ceiling আলাদাভাবে রাখা দরকার।
- 3.7 বজায় রাখা: 3.8-এর quality বা success-rate gain অতিরিক্ত task cost পুষিয়ে না দিলে efficiency-first workload সরানোর প্রয়োজন নেই; 3.7 এখনও সমর্থিত।
এটি billing tier নয়, workload বাছাইয়ের কাঠামো। একই application-এর মধ্যেও ছোট extraction task low effort-এ এবং জটিল agent task high effort-এ চালানো যেতে পারে; সব traffic-এর জন্য একটি effort setting বাধ্যতামূলক করার প্রয়োজন নেই।
3.7 ও 3.8-এর shadow evaluation
Migration-এর নির্ভরযোগ্য unit হলো সফলভাবে শেষ হওয়া task, একক request নয়। একই production traffic-এর পরিচয়মুক্ত নমুনায় দুই model চালিয়ে prompt, tool permission, timeout, effort setting এবং maximum output যথাসম্ভব সমান না রাখলে খরচের পার্থক্য model-এর বদলে configuration থেকে আসতে পারে।
- সহজ, মাঝারি ও জটিল workload bucket তৈরি করে representative task এবং গ্রহণযোগ্য ফলের rubric আগে স্থির করুন।
- প্রতি run-এর input ও output token, tool-call সংখ্যা, latency, retry, final status এবং manual-review ফল সংরক্ষণ করুন।
- প্রতিটি bucket-এ মোট model bill-কে সফল task-এর সংখ্যা দিয়ে ভাগ করুন। Failure rate ও review time পাশাপাশি রাখুন, তবে token charge-এর সঙ্গে এক মেট্রিকে মিশিয়ে ফেলবেন না।
- Quality gain কত হলে বাড়তি task cost গ্রহণযোগ্য হবে, তা bucket অনুযায়ী নির্ধারণ করুন। একটি সামগ্রিক average ছোট কিন্তু ব্যয়বহুল agent workload-এর পরিবর্তন আড়াল করতে পারে।
এখন নিশ্চিত অবস্থা হলো: Gemini 3.8 Flash GA, Gemini API ও Google AI Studio-তে পাওয়া যাচ্ছে এবং ২০২৬ সালের শেষ পর্যন্ত 3.7-এর সমান প্রারম্ভিক standard token rate বহাল। অনিশ্চিত বিষয় কোনো universal cost increase নয়; আসল পরিবর্তন workloadভেদে reasoning, tool loop, retry ও সফলতার হারের ওপর নির্ভর করবে। তাই production cutover-এর সিদ্ধান্তে তালিকামূল্য নয়, bucketভিত্তিক সফল task cost-ই তুলনার উপযুক্ত মাপকাঠি।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।