Microsoft তাদের Azure API Management (APIM)-এ একটি ডেডিকেটেড AI Gateway tier যুক্ত করেছে। এই পদক্ষেপটি ইঙ্গিত দেয় যে LLM কলগুলোকে এখন কেবল একটি সাধারণ API endpoint হিসেবে নয়, বরং একটি আলাদা workload হিসেবে বিবেচনা করা হচ্ছে।
কেন LLM ট্রাফিক ক্লাসিক গেটওয়েগুলোকে অকার্যকর করে তোলে
একটি প্রম্পটের খরচ অন্যটির তুলনায় ১০০ গুণ বেশি হতে পারে, তবুও একটি স্ট্যান্ডার্ড API gateway উভয়কেই একটি একক রিকোয়েস্ট হিসেবে দেখে। গেটওয়েটি কল গণনা করে, মডেলটি কতগুলো টোকেন প্রসেস করছে তা নয়। একটি রিকোয়েস্ট যা মাত্র কয়েকশ টোকেন পাঠায় এবং অন্যটি যা হাজার হাজার টোকেন পাঠায়, উভয় ক্ষেত্রেই রিকোয়েস্ট-কাউন্ট মেট্রিক্স একই থাকে, যদিও পরেরটির খরচ বহুগুণ বেশি হতে পারে।
চারটি কারণ রিকোয়েস্ট-ভিত্তিক লিমিটকে AI-এর জন্য অকেজো করে তোলে:
- Cost ≠ request count. বিলিং টোকেনের সাথে যুক্ত, আপনি কতগুলো HTTP কল করছেন তার সাথে নয়।
- Token volume ব্যাপকভাবে পরিবর্তিত হয়। একটি কুয়েরি হতে পারে একটি ছোট প্রশ্ন; অন্যটি হতে পারে একটি দীর্ঘ ডকুমেন্ট।
- মডেল নির্বাচন দাম পরিবর্তন করে। বিভিন্ন LLM প্রতি টোকেনের জন্য ভিন্ন ভিন্ন রেট চার্জ করে।
- Streaming চূড়ান্ত বিল লুকিয়ে রাখে। যখন রেসপন্স স্ট্রিম হয়, তখন স্ট্রিম শেষ না হওয়া পর্যন্ত মোট টোকেন সংখ্যা জানা যায় না।
আপনি যদি কেবল রিকোয়েস্ট পরিমাপ করতে থাকেন, তবে আপনার মনিটরিং ডেটা থেকে প্রকৃত খরচের বিষয়ে কিছুই জানতে পারবেন না।
AI Gateway tier যা পরিবর্তন করে
টোকেন ব্যবহার নিয়ন্ত্রণের জন্য প্রয়োজনীয় বেশিরভাগ পলিসি ইতিমধ্যেই স্ট্যান্ডার্ড APIM tier-এ বিদ্যমান—যা XML রুল হিসেবে লেখা এবং কাস্টম ড্যাশবোর্ডে প্রদর্শিত হয়। AI tier সেই একই সক্ষমতাগুলোকে একটি বিশেষায়িত অভিজ্ঞতার (purpose-built experience) মধ্যে একত্রিত করে:
- AI ট্রাফিকের জন্য scaling-এর আইসোলেশন।
- সহজ কনফিগারেশন যা হাতে তৈরি XML পলিসির প্রয়োজনীয়তা দূর করে।
মূল পরিবর্তনটি হলো অপারেশনাল: টোকেন বাজেট প্রয়োগ করার জন্য আপনাকে আর জটিল কোড লিখতে হবে না বা আলাদা ড্যাশবোর্ড মেইনটেইন করতে হবে না। এই tier-টি সেই কন্ট্রোলগুলোর জন্য একটি রেডি-মেড ইন্টারফেস প্রদান করে।
কখন পরিবর্তন করবেন – ট্রাফিক-ভিত্তিক নির্দেশিকা
- AI আপনার ট্রাফিকের একটি সামান্য অংশ। আপনার বিদ্যমান APIM tier ব্যবহার চালিয়ে যান এবং সূক্ষ্ম নিয়ন্ত্রণের প্রয়োজন হলে টোকেন পলিসি যুক্ত করুন।
- AI আপনার কলের সিংহভাগ দখল করে আছে। স্কেলিং আইসোলেট করতে এবং খরচ নিয়ন্ত্রণ (cost governance) স্বচ্ছ রাখতে AI tier-এ চলে যান।
- আপনি ইঞ্জিনিয়ারিং ওভারহেড এড়াতে চান। এই tier-এর বিল্ট-ইন টুলগুলো কাস্টম পলিসি তৈরি এবং মেইনটেইন করার সময় বাঁচায়।
সবচেয়ে বড় খরচ সাবস্ক্রিপশন মূল্য নয়; বরং একটি সাধারণ গেটওয়েকে টোকেন ইকোনমিক্স বোঝানোর জন্য সেটির ত্রুটিগুলো সংশোধনে ব্যয় করা ইঞ্জিনিয়ারিং সময়।
প্রিভিউ-ফেজ প্লেবুক
Microsoft এখনও AI tier-টি প্রিভিউ হিসেবে অফার করছে। এটিকে একটি টেস্টবেড হিসেবে বিবেচনা করুন, প্রোডাকশন লঞ্চ হিসেবে নয়।
- একটি উচ্চ-ভলিউম অভ্যন্তরীণ AI workload নির্বাচন করুন। সেই সার্ভিসটি বেছে নিন যা সবচেয়ে বেশি টোকেন ট্রাফিক তৈরি করে।
- সেই workload-টি AI tier-এর মাধ্যমে রাউট করুন। প্রতিটি কনজিউমারের টোকেন ব্যবহার ক্যাপচার করতে নতুন কনফিগারেশন ব্যবহার করুন।
- কয়েক সপ্তাহ ধরে টোকেন-খরচের ডেটা সংগ্রহ করুন। আপনার বিদ্যমান মনিটরিংয়ের সাথে টোকেন সংখ্যা এবং সংশ্লিষ্ট খরচের তুলনা করুন।
- বাজেট নির্ধারণে বেসলাইন ব্যবহার করুন। এই tier-এর খরচ-নিয়ন্ত্রণ সুবিধাগুলো এর প্রিভিউ-ফেজের সীমাবদ্ধতার চেয়ে বেশি কি না তা সিদ্ধান্ত নিন।
এটি জেনারেল অ্যাভেইল্যাবিলিটি (general availability)-তে না আসা পর্যন্ত মিশন-ক্রিটিক্যাল প্রোডাকশন workload-গুলোকে প্রিভিউ সার্ভিসে স্থানান্তর করবেন না।
পাল্টা যুক্তি: সবার জন্য আলাদা tier প্রয়োজন নেই
যদি আপনার সংস্থা কেবল মাঝে মাঝে LLM-এ কল করে, তবে AI tier-এর অতিরিক্ত খরচ যুক্তিসঙ্গত নাও হতে পারে। আপনি বিদ্যমান পলিসি ফ্রেমওয়ার্কের মাধ্যমে টোকেন-লেভেল গভর্নেন্স অর্জন করতে পারেন, যদিও এতে ম্যানুয়াল প্রচেষ্টা বেশি লাগবে। যখন AI ট্রাফিক আপনার API সারফেসের একটি উল্লেখযোগ্য এবং ক্রমবর্ধমান অংশ হয়ে ওঠে, তখন এই tier-টি অত্যন্ত কার্যকর হয়।
সারসংক্ষেপ
AI Gateway tier স্বীকার করে যে LLM ট্রাফিক প্রথাগত API কলের থেকে মৌলিকভাবে ভিন্নভাবে আচরণ করে। রিকোয়েস্ট গণনার পরিবর্তে টোকেন-ভিত্তিক গভর্নেন্সের দিকে সরে আসার মাধ্যমে, এটি ডেভেলপারদের কাস্টম কোডের ঝামেলা ছাড়াই AI খরচ নিয়ন্ত্রণে রাখার একটি ব্যবহারিক উপায় প্রদান করে। যে দলগুলোর AI ব্যবহার ইতিমধ্যে উল্লেখযোগ্য—অথবা বাড়বে বলে আশা করা হচ্ছে—তাদের জন্য এখন প্রিভিউটি পরীক্ষা করা একটি টোকেন-খরচের বেসলাইন তৈরি করতে সাহায্য করতে পারে।
