মডেল ও thinking/effort সঠিকভাবে বেছে নেওয়া

১ · সবচেয়ে বড় মডেল সবসময় সঠিক পছন্দ নয়

একটি সাধারণ প্রবণতা — যখনই সন্দেহ হয়, ডেভেলপাররা প্রোভাইডারের সবচেয়ে শক্তিশালী (ও সবচেয়ে দামি) মডেল বেছে নেন, "নিরাপদ" থাকার জন্য। OpenAI-এর নিজস্ব নির্দেশনা এই অভ্যাসকে স্পষ্টভাবে চ্যালেঞ্জ করে — বড় মডেল জটিল প্রম্পট বোঝায় এগিয়ে থাকে, কিন্তু ছোট মডেল দ্রুত ও সস্তা। সিদ্ধান্ত নেওয়া উচিত কাজের প্রকৃত জটিলতার ওপর ভিত্তি করে — অভ্যাসের বশে নয়।

বিপরীতে, বহু-ধাপের যুক্তি, অস্পষ্ট/জটিল প্রম্পট বোঝা, বা উচ্চ-ঝুঁকির সিদ্ধান্তের ক্ষেত্রে বড় মডেলের অতিরিক্ত ক্ষমতা সত্যিই মূল্য যোগ করে। প্রশ্নটি সবসময় হওয়া উচিত — "এই নির্দিষ্ট কাজের জন্য কোন মডেল যথেষ্ট?", "কোন মডেল সবচেয়ে শক্তিশালী?" নয়।

২ · Claude-এর effort প্যারামিটার ও অ্যাডাপ্টিভ থিংকিং

মডেল নির্বাচনের পাশাপাশি, একই মডেলের ভেতরেও একটি দ্বিতীয় নিয়ন্ত্রণ-স্তর আছে — কতটা "চিন্তা" করবে। Claude-এর সাম্প্রতিক মডেলগুলো অ্যাডাপ্টিভ থিংকিং (Adaptive Thinking)Adaptive Thinkingমডেল নিজেই স্থির করে কখন এবং কতটা "চিন্তা" (thinking tokens) প্রয়োজন — প্রশ্নের জটিলতা ও effort প্যারামিটার অনুযায়ী। ব্যবহার করে — অর্থাৎ মডেল নিজেই ঠিক করে কখন ও কতটা "থিংকিং" প্রয়োজন, প্রশ্নের জটিলতা এবং একটি effort প্যারামিটার দিয়ে ক্যালিব্রেট করে।

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

৩ · Gemini-এর thinking_level

Google-এর Gemini মডেলগুলোতে একই ধারণার নিজস্ব বাস্তবায়ন হলো thinking_level প্যারামিটার — যা থিংকিং-বাজেট কনফিগারেশনকে সরল কয়েকটি স্তরে ভাগ করে। ডিফল্টভাবে Gemini 3 মডেলগুলো ডায়নামিক থিংকিং (HIGH) ব্যবহার করে জটিল প্রম্পট যুক্তি সাজাতে।

কম-লেটেন্সি/কম-খরচের উত্তরের জন্য, যেখানে জটিল রিজনিং দরকার নেই, thinking_level কে LOW বা MINIMAL-এ সীমাবদ্ধ করা যায় — MINIMAL মডেলকে থিংকিং-এর জন্য যতটা সম্ভব কম টোকেন ব্যবহার করতে বাধ্য করে, যা সরল/কম-জটিল কাজে সবচেয়ে উপযুক্ত যা বিস্তৃত রিজনিং থেকে বাস্তবিক লাভবান হয় না। দ্রুততর উত্তরের জন্য thinking_level LOW-তে সেট করা এবং system instruction-এ "think silently"-এর মতো নির্দেশনা যোগ করাও একটি লেটেন্সি-কমানোর কৌশল।

৪ · ব্যাচ API — রিয়েল-টাইম নয় এমন কাজের জন্য

প্রতিটি অনুরোধের জবাব তাৎক্ষণিকভাবে প্রয়োজন না হলে (যেমন রাতারাতি ডেটা প্রসেসিং, বাল্ক ক্লাসিফিকেশন, বড় ডেটাসেট সামারাইজেশন), ব্যাচ API ব্যবহার করলে একই কাজের জন্য প্রায় ৫০% পর্যন্ত সাশ্রয় হতে পারে। ট্রেড-অফ হলো — উত্তর তাৎক্ষণিক আসে না, একটি নির্দিষ্ট উইন্ডোতে (সাধারণত ঘণ্টার মধ্যে) প্রসেস হয়ে ফিরে আসে।

৫ · সম্পূর্ণ খরচ-অপ্টিমাইজেশন অগ্রাধিকার তালিকা

এই মডিউলে (M4) আমরা টোকেন খরচের হিসাব (পাঠ ১৫), প্রম্পট ক্যাশিং (পাঠ ১৬), লিন প্রম্পটিং (পাঠ ১৭), এবং এখন মডেল/effort সাইজিং দেখেছি। প্রোডাকশনে খরচ কমানোর সময় এই কৌশলগুলো একটি নির্দিষ্ট অগ্রাধিকার-ক্রমে প্রয়োগ করা উচিত —

1. প্রম্পট ক্যাশিং — cached ইনপুটে ৯০% পর্যন্ত সাশ্রয়; সর্বোচ্চ লিভারেজ, সবচেয়ে কম ঝুঁকি (পাঠ ১৬)।
2. ব্যাচ API — রিয়েল-টাইম নয় এমন workload-এ প্রায় ৫০% সাশ্রয়।
3. মডেল সাইজিং — সরল কাজে ছোট/সস্তা মডেল, শুধু প্রয়োজনে বড় মডেল ব্যবহার করা।
4. Reasoning/thinking গভীরতা কমানো — সরল কাজে Claude-এর effort বা Gemini-এর thinking_level MINIMAL/LOW সেট করা, কারণ reasoning টোকেনও বিল হয়।