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

স্মার্ট মডেল রাউটিংয়ের মাধ্যমে, আমরা এই সমস্যার সমাধান করতে পারি। এই ধরনের রাউটিং পদ্ধতিতে, আমরা প্রতিটি অনুরোধের জন্য একটি নির্দিষ্ট মডেল নির্বাচন করি। অন্য কথায়, সহজ কাজটি একটি ছোট মডেলে পাঠানো হয় যা কম ব্যয়বহুল হতে পারে, এবং কঠিন কাজটি আরও সক্ষম মডেলে রাউট করা হয়। যদি বেশিরভাগ অনুরোধ সহজ হয়, এই পদ্ধতিটি মোট খরচ ব্যাপকভাবে কমাতে পারে, কখনও কখনও প্রায় ১০ গুণ পর্যন্ত। এছাড়াও, প্রতিক্রিয়ার মান লক্ষণীয়ভাবে কমে না।

তবে, খরচ কমানো নিশ্চিত নয়। এটি অ্যাপ্লিকেশনটি যে ধরনের অনুরোধ পায়, মডেলগুলির মধ্যে মূল্যের পার্থক্য এবং রাউটিং সিস্টেমটি কতটা ভালো কাজ করে তার উপরও নির্ভর করে। LLM API ব্যবহারের মোট খরচ সাধারণত প্রক্রিয়াকৃত টোকেনের সংখ্যার উপর নির্ভর করে। ইনপুট টোকেনগুলির মধ্যে ব্যবহারকারীর বার্তা, সিস্টেম নির্দেশাবলী, কথোপকথনের ইতিহাস এবং মডেলকে দেওয়া যেকোনো নথি অন্তর্ভুক্ত। আউটপুট টোকেন হল প্রতিক্রিয়ার মধ্যে উৎপন্ন টোকেন। বড় এবং আরও সক্ষম মডেল সাধারণত বেশি খরচ করে কারণ তাদের আরও কম্পিউটিং সংস্থান প্রয়োজন।

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