আপনি যদি large language models-এ production workloads চালান, তবে আপনি ইতিমধ্যেই জানেন যে মডেলের পারফরম্যান্স যুদ্ধের মাত্র অর্ধেক। বাকি অর্ধেক হলো মাসের শেষে আসা বিল। তিনটি প্রোভাইডার—Mancer 2, Novita, এবং StreamLake—সম্প্রতি তাদের মডেলের দাম পরিবর্তন করেছে। আপনি যদি এই API গুলোর কোনোটির ওপর নির্ভর করেন, তবে আপনার পরবর্তী ইনভয়েসটি আগেরটির চেয়ে আলাদা হতে পারে।
এটি এখন আর অস্বাভাবিক কিছু নয়। LLM মার্কেট এখনও inference-এর জন্য কীভাবে চার্জ করা হবে তা নিয়ে পরীক্ষা-নিরীক্ষা করছে। কিছু প্রোভাইডার প্রতি হাজার টোকেনের জন্য বিল করে। অন্যরা রিকোয়েস্টগুলোকে বিভিন্ন টিয়ার বা স্তরে ভাগ করে অথবা sustained-use ডিসকাউন্ট প্রদান করে। যখন একটি প্ল্যাটফর্ম তার ইউনিট প্রাইস পরিবর্তন করে বা তার টিয়ারগুলো পুনর্গঠন করে, তখন আপনার বাজেটের ওপর এর প্রভাব সামান্য বিরক্তি থেকে শুরু করে মারাত্মক খরচ বৃদ্ধির কারণ হতে পারে। এই আপডেটগুলো ট্র্যাক করা কোনো ঐচ্ছিক বিষয় নয়; এটি কাজেরই একটি অংশ।
কেন API প্রাইসিং আপনার মনোযোগ দাবি করে
ডেভেলপাররা প্রায়শই API প্রাইসিংকে এমন একটি বিষয় হিসেবে দেখেন যা একবার সেট করলে আর দেখার প্রয়োজন নেই। আপনি একটি মডেলের বেঞ্চমার্ক করেন, একজন প্রোভাইডার বেছে নেন এবং ফিচার তৈরির দিকে এগিয়ে যান। এটি ততক্ষণই কাজ করে যতক্ষণ না কোনো সমস্যা দেখা দেয়। বর্তমান প্রেক্ষাপটে, খুব সামান্য প্রচার ছাড়াই প্রাইসিং পরিবর্তন হতে পারে। একজন প্রোভাইডার তার legacy মডেলের খরচ কমাতে পারে আবার তার নতুন এন্ডপয়েন্টের দাম বাড়িয়ে দিতে পারে। অন্য কেউ হয়তো আউটপুট-টোকেন সারচার্জ (surcharge) চালু করতে পারে যা গত কোয়ার্টারে ছিল না। আপনি যদি নজর না রাখেন, তবে আপনার ক্লাউড বিল আসার পরেই কেবল আপনি তা জানতে পারবেন।
LLM বিলিংয়ের সূক্ষ্মতা (granularity) বিষয়টিকে বিশেষভাবে জটিল করে তোলে। আপনি খুব কমই একটি নির্দিষ্ট মাসিক রেট প্রদান করেন। আপনি প্রতিটি প্রম্পট টোকেন এবং প্রতিটি কমপ্লিশন টোকেনের জন্য অর্থ প্রদান করেন। আউটপুট সাইডের দাম বৃদ্ধি ইনপুট সাইডের তুলনায় বেশি যন্ত্রণাদায়ক হতে পারে, কারণ কমপ্লিশনগুলো প্রায়শই প্রম্পটের চেয়ে দীর্ঘ হয়। আপনার অ্যাপ্লিকেশন যদি দীর্ঘ টেক্সট, কোড বা মাল্টি-স্টেপ রিজনিং চেইন তৈরি করে, তবে প্রতি টোকেনে সামান্য বৃদ্ধিও দ্রুত বড় আকার ধারণ করতে পারে।
এখানে 'drift'-এর সমস্যাটিও রয়েছে। সময়ের সাথে সাথে আপনার অ্যাপ্লিকেশনের টোকেন প্রোফাইল পরিবর্তিত হয়। আপনি হয়তো একটি নতুন সিস্টেম প্রম্পট যোগ করছেন যা আরও বেশি ইনপুট টোকেন খরচ করে। আপনি হয়তো chain-of-thought prompting-এ সুইচ করছেন যা দীর্ঘতর আউটপুট তৈরি করে। এমনকি প্রোভাইডারের দাম স্থির থাকলেও আপনার খরচ পরিবর্তিত হতো। যখন প্রোভাইডারের দামগুলো একই সাথে পরিবর্তিত হয়, তখন সেই সম্মিলিত প্রভাব একটি টিমকে অপ্রস্তুত করে দিতে পারে যাদের কাছে এই বিষয়ে স্বচ্ছ ধারণা বা ভিজিবিলিটি নেই।
কী পরিবর্তন হয়েছে
Mancer 2, Novita, এবং StreamLake—সবাই প্রাইসিং অ্যাডজাস্টমেন্ট করেছে। প্ল্যাটফর্ম ভেদে এর বিস্তারিত ভিন্ন হতে পারে, তবে মূল বিষয়টি একই: গত মাসে আপনি যে কস্ট স্ট্রাকচার ব্যবহার করেছিলেন, তা এখন কার্যকর নাও থাকতে পারে।
Mancer 2 তাদের মডেলের দাম আপডেট করেছে, যার মানে হলো এর এন্ডপয়েন্ট ব্যবহারকারী ডেভেলপারদের প্রতি-রিকোয়েস্ট খরচ পুনরায় মূল্যায়ন করতে হবে। আপনি যদি আপনার অভ্যন্তরীণ নথিতে (internal documentation) পুরনো প্রাইস শিট সংরক্ষণ করে রাখেন, তবে সেই সংখ্যাগুলো এখন আর সঠিক নয়।
Novita-ও তাদের অফারিংগুলোতে দামের সমন্বয় করেছে। যে দলগুলো একটি নির্দিষ্ট বাজেটের মধ্যে থাকার জন্য Novita বেছে নিয়েছিল, তাদের জন্য নতুন রেটগুলো চলমান প্রজেক্টগুলোর total cost of ownership পরিবর্তন করে দিতে পারে।
StreamLake-ও তাদের প্রাইসিং পরিবর্তন করেছে। পরবর্তী বিলিং সাইকেল শুরু হওয়ার আগে StreamLake-এর আগের রেট কার্ডের ওপর ভিত্তি করে তৈরি করা যেকোনো ইন্টিগ্রেশন পর্যালোচনা করা উচিত।
যেহেতু এগুলো তিনটি ভিন্ন প্ল্যাটফর্ম এবং তিনটি ভিন্ন প্রাইসিং মডেল, তাই আপনি বেশি বা কম দেবেন কি না সে সম্পর্কে কোনো সার্বজনীন নিয়ম নেই। একজন প্রোভাইডার হয়তো স্টার্টার-টিয়ার রেট কমিয়ে দিয়েছে কিন্তু প্রিমিয়াম থ্রুপুট প্রাইসিং বাড়িয়ে দিয়েছে। অন্য কেউ হয়তো context-window প্রিমিয়াম অ্যাডজাস্ট করেছে। একমাত্র নিরাপদ ধারণা হলো আপনার পুরনো স্প্রেডশিটটি এখন ভুল।
রেট পরিবর্তন উপেক্ষা করার লুকানো খরচ
চলুন দেখি বাস্তবে এর অর্থ কী। ধরুন, আপনি একটি কাস্টমার-সাপোর্ট অ্যাসিস্ট্যান্ট চালান যা প্রতিদিন দশ হাজার কথোপকথন পরিচালনা করে। প্রতিটি কথোপকথনে গড়ে দুই হাজার ইনপুট টোকেন এবং চারশ আউটপুট টোকেন ব্যবহৃত হয়। প্রতি মিলিয়ন টোকেনে মাত্র কয়েক সেন্টের পরিবর্তনও মাসে কয়েকশ ডলারের অতিরিক্ত খরচ বাড়িয়ে দিতে পারে। যদি দামের পরিবর্তনটি আউটপুট টোকেনকে প্রভাবিত করে এবং আপনি মডেলটি আপগ্রেড করার কারণে আপনার অ্যাসিস্ট্যান্ট দীর্ঘতর উত্তর দিতে শুরু করে, তবে আপনি দ্বিগুণ ক্ষতির সম্মুখীন হবেন।
এরপর রয়েছে মাল্টিপ্লায়ার ইফেক্ট (multiplier effect)। অনেক অ্যাপ্লিকেশন প্রতি ইউজার রিকোয়েস্টে একবার LLM কল করে না। তারা এটি একটি লুপে, অথবা রিট্রিভাল স্টেপসহ একটি পাইপলাইনে, অথবা সেকেন্ডারি মডেলগুলোতে ফলব্যাক (fallback) হিসেবে কল করে। ফলব্যাক মডেলের দাম পরিবর্তন খুব একটা জরুরি মনে নাও হতে পারে, যতক্ষণ না আপনার প্রাইমারি মডেলটি রেট লিমিটে পৌঁছায় এবং আপনি একটি বৃষ্টির বুধবারের মতো দিনটি ব্যয়বহুল ব্যাকআপ মডেল ব্যবহার করে শেষ করে ফেলেন।
বাজেট অতিরিক্ত হওয়া একমাত্র ঝুঁকি নয়। যদি দাম কমে যায় এবং আপনি তা খেয়াল না করেন, তবে আপনি অনর্থক ব্যবহার সীমিত (throttling) করে রাখতে পারেন। আপনি আরও বেশি ব্যবহারকারীকে সেবা দিতে পারতেন, বড় ডকুমেন্ট প্রসেস করতে পারতেন অথবা গ্রাহকদের জন্য আপনার নিজস্ব দাম কমাতে পারতেন। অজ্ঞতা উভয় দিক থেকেই ক্ষতিকর।
কীভাবে খরচ ট্র্যাকিং করার অভ্যাস গড়ে তুলবেন
এটি নিয়ন্ত্রণে রাখার জন্য আপনার কোনো বড় প্রতিষ্ঠানের ফিন্যান্স টিমের প্রয়োজন নেই। আপনার প্রয়োজন একটি রুটিন এবং পরিবর্তনগুলো নথিভুক্ত করার একটি জায়গা।
আপনার রেট কার্ডগুলো (rate cards) এক জায়গায় জড়ো করার মাধ্যমে শুরু করুন। একটি সাধারণ ডকুমেন্ট রাখুন—সেটি একটি শেয়ার্ড উইকি পেজ, Notion টেবিল বা আপনার ডেভ চ্যানেলে একটি পিন করা মেসেজ যাই হোক না কেন—যেখানে আপনি যে প্রতিটি মডেল ব্যবহার করেন তার বর্তমান per-token বা per-request দাম তালিকাভুক্ত থাকবে। যখন কোনো প্রোভাইডার পরিবর্তনের ঘোষণা দেবে, তখনই ডকুমেন্টটি আপডেট করুন। স্প্রিন্ট রিভিউ (sprint review) পর্যন্ত অপেক্ষা করবেন না।
এরপর, প্রোভাইডার এবং মডেল অনুযায়ী আপনার ব্যবহারের ট্যাগ (tag) করুন। বেশিরভাগ অবজারভেবিলিটি টুল (observability tools) আপনাকে API কলের সাথে কাস্টম মেটাডেটা যুক্ত করার সুযোগ দেয়। সাপ্তাহিক খরচের সারাংশ তৈরি করতে সেই ট্যাগগুলো ব্যবহার করুন। যদি খরচে হঠাৎ বৃদ্ধি দেখেন, তবে কয়েক দিন নয়, বরং কয়েক সেকেন্ডের মধ্যেই আপনি বুঝতে পারবেন এটি ব্যবহারের পরিমাণ বাড়ার কারণে নাকি রেট পরিবর্তনের কারণে।
একটি বার্ন-রেট অ্যালার্ট (burn-rate alert) তৈরি করুন। এটি খুব জটিল হওয়ার প্রয়োজন নেই। একটি শিডিউল করা স্ক্রিপ্ট যা প্রতিদিন সকালে আপনার ইউসেজ ড্যাশবোর্ড থেকে তথ্য নিয়ে Slack-এ একটি সংখ্যা পোস্ট করবে, সেটিই যথেষ্ট। যখন খরচ হঠাৎ বেড়ে যাবে, আপনি সেদিনই তা জানতে পারবেন; ফিন্যান্স টিম থেকে কোনো রাগান্বিত ইমেল পাওয়ার ৩০ দিন পর নয়।
প্রতি তিন মাস অন্তর আপনার মডেল নির্বাচনের বিষয়টি পর্যালোচনা করুন। জানুয়ারিতে আপনার ব্যবহারের জন্য সেরা মডেলটি জুন মাসে সেরা নাও হতে পারে; এর কারণ মডেলটি খারাপ হওয়া নয়, বরং প্রাইসিং বা দামের কাঠামো পরিবর্তিত হওয়া। যে প্রোভাইডার একসময় অনেক দামী ছিল, তারা হয়তো রেট কমিয়ে দিয়েছে। আবার আপনার পছন্দের কোনো সস্তা মডেল হয়তো দাম বাড়িয়ে দিয়েছে। আপনার বেঞ্চমার্কগুলো ঐতিহাসিক দামের পরিবর্তে লাইভ দামের ভিত্তিতে পুনরায় যাচাই করুন।
সবশেষে, আপনার আর্কিটেকচার সংক্রান্ত সিদ্ধান্তের ক্ষেত্রে প্রাইসিং বা দামের বিষয়টি মাথায় রাখুন। যদি আপনি জানেন যে কোনো প্রোভাইডার প্রায়ই রেট পরিবর্তন করে, তবে আপনার সিস্টেমটি এমনভাবে ডিজাইন করুন যাতে কোডবেসের অর্ধেক অংশ পুনরায় না লিখেই আপনি এন্ডপয়েন্ট (endpoint) পরিবর্তন করতে পারেন। ক্লায়েন্টকে একটি ইন্টারনাল ইন্টারফেসের (internal interface) আড়ালে রাখুন। মডেলের নাম একটি কনফিগারেশন ফাইলে রাখুন, প্রম্পট লেয়ারে (prompt layer) হার্ড-কোড করে রাখবেন না।
নির্ভরযোগ্য আপডেট কোথায় পাবেন
প্রোভাইডারদের ব্লগ এবং ডকুমেন্টেশন হলো অফিসিয়াল উৎস, কিন্তু ব্যস্ত সপ্তাহে এগুলো খেয়াল করা কঠিন হতে পারে। একটি বিকল্প হলো কিউরেটেড রাউন্ডআপ (curated roundups) অনুসরণ করা, যা পুরো ইকোসিস্টেমের এই ধরণের পরিবর্তনগুলো ট্র্যাক করে। সাম্প্রতিক Mancer 2, Novita এবং StreamLake-এর পরিবর্তনের বিস্তারিত জানতে এখানে দেখুন:
LLM প্রাইসিংয়ে পরিবর্তন: Mancer 2, Novita, এবং StreamLake
আপনি যদি সব খবরের সাথে আপডেট থাকতে চান এবং অন্যান্য বিল্ডারদের সাথে অভিজ্ঞতা বিনিময় করতে চান যারা তাদের AI ইনফ্রাস্ট্রাকচার বিল নিয়ন্ত্রণে রাখার চেষ্টা করছেন, তবে একটি কমিউনিটি রয়েছে যা আপনার জয়েন করা উচিত:
আকস্মিক বিলের বিরুদ্ধে সেরা প্রতিরক্ষা হলো এমন এক নেটওয়ার্ক, যারা পরিবর্তন ঘটার সাথে সাথেই তা জানিয়ে দেয়।
মূল কথা
প্রাইসিংয়ের অস্থিরতা বর্তমান LLM মার্কেটের একটি বৈশিষ্ট্য, কোনো ত্রুটি নয়। মডেল চালানো সস্তা হচ্ছে, প্রোভাইডাররা রেট স্ট্রাকচার নিয়ে পরীক্ষা-নিরীক্ষা করছে এবং প্রতিযোগিতা দামের ওঠানামা ঘটাচ্ছে। দীর্ঘমেয়াদে এটি ভালো খবর, তবে কেবল তখনই যখন আপনি সতর্ক থাকবেন। আপনার API খরচকে আপনার আপটাইম মেট্রিক্সের (uptime metrics) মতো বিবেচনা করুন: সেগুলো পরিমাপ করুন, অ্যালার্ট সেট করুন এবং নিয়মিত যাচাই করুন। Mancer 2, Novita এবং StreamLake-এর সাম্প্রতিক পরিবর্তনগুলো কেবল একটি নতুন অনুস্মারক যে, আপনার AI স্ট্যাকের দাম কখনোই পুরোপুরি স্থির নয়।