जर तुम्ही large language models वर आधारित ॲप्लिकेशन्स तयार करत असाल, तर तुमचा Inference बिल हा पगार (payroll) नंतरचा सर्वात वेगाने वाढणारा खर्च असू शकतो. यामुळे तुमच्या प्रदात्याकडून (provider) होणारा कोणताही किंमत बदल (pricing update) हा केवळ मार्केटिंगचा भाग नसून एक महत्त्वाचा कार्यात्मक बदल (operational event) ठरतो. डेव्हलपर्स सध्या LLM होस्टिंग आणि APIs साठी वापरत असलेले दोन प्लॅटफॉर्म्स, Novita आणि StreamLake, यांनी अलीकडेच त्यांच्या दरांमध्ये बदल केले आहेत. तुम्ही एखादा साईड-प्रोजेक्ट चॅटबॉट चालवत असाल किंवा एखादे प्रॉडक्शन SaaS उत्पादन, हे बदल तुमच्या युनिट इकॉनॉमिक्समध्ये (unit economics) बदल घडवून आणतात. तुम्हाला तपशीलांकडे लक्ष देणे, तुमचा खर्च (burn) पुन्हा मोजणे आणि तुमचे सध्याचे स्टॅक (stack) अजूनही फायदेशीर आहे की नाही हे ठरवणे आवश्यक आहे.
Inference Pricing कडे तुमचे लक्ष देणे का आवश्यक आहे
बहुतेक डेव्हलपर्स मॉडेल्समुळे AI इंजिनीअरिंगमध्ये येतात, किंमत तक्ते (pricing tables) वाचायला आवडते म्हणून नाही. ही एक चूक आहे. Inference हे वापराच्या आधारावर चालणारे (consumption-based) इन्फ्रास्ट्रक्चर आहे. तुम्ही कोणताही ठराविक मासिक शुल्क भरत नाही; तर सिस्टीममधून जाणारा प्रत्येक टोकनसाठी तुम्हाला पैसे द्यावे लागतात. जेव्हा एखादा प्रदाता (provider) त्याच्या दरपत्रकात (rate card) बदल करतो, तेव्हा त्याचा परिणाम त्वरित आणि थेट असतो. जर तुमचे ॲप्लिकेशन दिवसाला सरासरी एक लाख युजर क्वेरीज हाताळत असेल, तर प्रति-टोकन खर्चातील अगदी थोडासा बदल देखील तुमच्या मासिक बिलामध्ये लक्षणीय फरक निर्माण करू शकतो.
प्रदाते सहसा इनपुट (input) आणि आउटपुट (output) टोकन्सच्या आधारावर किंमत ठरवतात. इनपुट टोकन्समध्ये प्रॉम्ट (prompt), सिस्टम सूचना (system instructions) आणि तुम्ही विंडोमध्ये दिलेला कोणताही संदर्भ (context) समाविष्ट असतो. आउटपुट टोकन्समध्ये मॉडेलने तयार केलेल्या उत्तराचा समावेश असतो. काही प्रदाते दोन्हीसाठी समान दर आकारतात; तर काही प्रदाते आउटपुटसाठी लक्षणीयरीत्या जास्त शुल्क आकारतात कारण जनरेशनसाठी अधिक संगणकीय शक्ती (computationally harder) लागते. जेव्हा Novita किंवा StreamLake त्यांच्या किमती अपडेट करतात, तेव्हा महत्त्वाचा प्रश्न केवळ "ते स्वस्त झाले की महाग?" असा नसून, "समीकरणातील कोणता भाग बदलला आणि किती प्रमाणात बदलला?" असा असतो.
इतर काही कमी स्पष्ट असे खर्च वाढवणारे घटक देखील आहेत. लांब कॉन्टेक्स्ट विंडोमुळे (long context windows) ठराविक टोकन मर्यादेनंतर अनेकदा प्रीमियम टियर्स लागू होतात. काही प्रदाते किमान टोकन संख्येसह प्रति विनंती (per request) बिल आकारतात, याचा अर्थ असा की केवळ एक शब्दाची क्वेरी असली तरी तुम्हाला किमान शुल्क द्यावे लागते. रेट लिमिट्समुळे (Rate limits) तुम्हाला उच्च कॉनकरन्सी टियर्समध्ये (higher concurrency tiers) ढकलले जाऊ शकते, ज्यासाठी अतिरिक्त शुल्क (surcharges) द्यावे लागते. जर तुम्ही अटी आणि शर्ती (fine print) नीट वाचल्या नाहीत, तर तुम्हाला वाटू शकते की तुमचा खर्च स्थिर आहे, परंतु तुमचे बिल हळूहळू वाढत असू शकते.
Novita आणि StreamLake मध्ये काय बदलले
Novita हे एक सर्व्हरलेस इन्फरन्स प्लॅटफॉर्म (serverless inference platform) म्हणून काम करते, जे डेव्हलपर्सना GPU क्लस्टर्स व्यवस्थापित न करता ओपन-वेट मॉडेल्ससाठी API ॲक्सेस देते. StreamLake मोठ्या प्रमाणावर मॉडेल्स चालवण्यासाठी तत्सम इन्फ्रास्ट्रक्चर सेवा प्रदान करते. या दोन्ही कंपन्यांनी अलीकडेच त्यांच्या LLM किमतींमध्ये सुधारणा केली आहे, ज्याचा अर्थ असा की त्यांच्या एंडपॉइंट्सद्वारे (endpoints) विनंती पाठवण्याचा खर्च बदलला आहे.
हे प्लॅटफॉर्म अनेक मॉडेल फॅमिलीला सपोर्ट करतात आणि अनेकदा मॉडेलचा आकार आणि कॉन्टेक्स्ट लांबीनुसार किमतींमध्ये फरक करतात, त्यामुळे केवळ एक "किंमत बदल" घोषणा अनेक तपशील लपवून ठेवू शकते. एखादे मॉडेल स्वस्त होऊ शकते तर दुसरे महाग होऊ शकते. 4K टोकन्सपेक्षा कमी कॉन्टेक्स्ट विंडोच्या किमती स्थिर राहू शकतात, तर 128K कॉन्टेक्स्टसाठी प्रीमियम ॲडजस्टमेंट लागू होऊ शकते. बॅच प्रोसेसिंग किंवा ऑफ-पीक वापरासाठी मिळणारी सवलती (discounts) कमी किंवा जास्त होऊ शकतात. या सूक्ष्म फरकांमुळे तुम्ही केवळ हेडलाईनवर अवलंबून राहू शकत नाही. तुम्हाला प्रत्यक्ष दरपत्रक (rate card) पाहणे आवश्यक आहे.
नेमके फरक दर्शवणारा डेव्हलपर ब्रेकडाउन मूळ अपडेट पेजवर उपलब्ध आहे. पुढच्या आठवड्यात पुन्हा बदलू शकणाऱ्या आकड्यांचा अंदाज लावण्यापेक्षा, मूळ स्त्रोताकडून (source) सध्याचे आकडे घ्या आणि तुमच्या शेवटच्या इनव्हॉइसशी (invoice) त्यांची ओळ-दर-ओळ तुलना करा.
तुमच्या स्टॅकवर होणाऱ्या प्रभावाचे ऑडिट कसे करावे
जेव्हा तुम्हाला किंमत बदलाची माहिती मिळते, तेव्हा घाबरण्यापूर्वी किंवा आनंद साजरा करण्यापूर्वी तुमच्या स्वतःच्या वापराचे (usage) त्वरित निदान (diagnostic) करा.
१. तुमचा टोकन हिस्टोग्राम (token histogram) एक्सपोर्ट करा. बहुतेक प्रदाते वापराचे डॅशबोर्ड किंवा API लॉग प्रदान करतात जे इनपुट विरुद्ध आउटपुट वापराचे विश्लेषण करतात. त्यांचे गुणोत्तर (ratio) तपासा. जर तुमचे ॲप्लिकेशन सिस्टम प्रॉम्ट्स आणि RAG कॉन्टेक्स्टवर जास्त अवलंबून असेल, तर तुमचा वापर इनपुट-केंद्रित (input-biased) आहे. जर तुम्ही लांब लेख, कोड किंवा बहु-टप्प्यांची तर्क साखळी (multi-step reasoning chains) तयार करत असाल, तर तुमचा वापर आउटपुट-केंद्रित (output-biased) आहे. तुमच्या वापराचा प्रकार आणि किमतीतील बदल यांचा मेळ घाला. इनपुट-किमतीतील कपात RAG पाइपलाइनसाठी फायदेशीर ठरते; तर आउटपुट-किमतीतील वाढ रायटिंग असिस्टंटसाठी नुकसानकारक ठरते.
२. तुमच्या वापराच्या प्रमाणात (volume) टॉप पाच मॉडेल्स ओळखा. तुम्ही वर्गीकरणासाठी (classification) एखादे जलद आणि स्वस्त मॉडेल आणि सारांश काढण्यासाठी (summarization) एखादे मोठे मॉडेल वापरत असाल. किंमतीतील बदल सहसा संपूर्ण कॅटलॉगमध्ये सारख्याच पद्धतीने लागू होत नाहीत. जर Novita किंवा StreamLake ने लहान क्लासिफायरसाठी दर बदलले असतील पण मोठ्या मॉडेलमध्ये कोणताही बदल केला नसेल, तर प्रति विनंती तुमचा सरासरी खर्च (blended average cost) फारसा बदलणार नाही.
3. एकत्रित बदलांची (bundled changes) तपासणी करा. कधीकधी किंमत अपडेटसोबत context-window विस्तार, नवीन fine-tuning endpoint किंवा सुधारित rate limits येतात. जर प्रदात्याने (provider) उपलब्ध concurrency दुप्पट केली असेल आणि तुमच्या युजर एक्सपिरियन्सला बाधा आणणाऱ्या queueing delays मध्ये घट केली असेल, तर प्रति-token (per-token) अधिक खर्च सहन करण्याजोगा असू शकतो. खर्च हा केवळ एक घटक आहे; latency आणि reliability देखील महत्त्वाचे आहेत.
4. पुढील तीस दिवसांचे मॉडेलिंग करा. गेल्या आठवड्यातील token count घ्या, नवीन दर लागू करा आणि मासिक रन रेटचा (monthly run rate) अंदाज वर्तवा. जर फरक (delta) पाच टक्क्यांपेक्षा कमी असेल आणि तुम्हाला अजूनही चांगली latency मिळत असेल, तर API स्थलांतरित करण्याचा खर्च (switch cost) बहुधा बचतीपेक्षा जास्त असेल. जर फरक पंचवीस टक्के असेल, तर वाटाघाटी करण्याची, ऑप्टिमाइझ करण्याची किंवा इतर पर्याय शोधण्याची ही वेळ आहे.
Inference खर्च अंदाजित ठेवण्यासाठीची रणनीती
जरी Novita आणि StreamLake ने किमती स्थिर ठेवल्या असल्या, तरीही तुम्हाला token खर्चाबाबत सावधगिरी बाळगणे आवश्यक आहे. मॉडेल कोण होस्ट करते याचा विचार न करता तुमचे मार्जिन सुरक्षित ठेवण्यासाठी खालील काही व्यावहारिक सवयी उपयुक्त ठरतील.
तुमचे prompts कॉम्प्रेस करा. तुमच्या system prompt मधील प्रत्येक अनावश्यक वाक्य म्हणजे प्रत्येक विनंतीवर (request) एक प्रकारे कर (tax) आहे. Filler words काढून टाका, तुमच्या JSON schemas मध्ये संक्षिप्त लेबल्स वापरा आणि वारंवार येणाऱ्या सूचना काढून टाका. जर तुम्ही एखाद्या prompt वर काम करत असाल, तर तो तैनात (deploy) करण्यापूर्वी tokenizer वापरून token count मोजा. प्रत्येक विनंतीमध्ये वाचवलेले शंभर bytes मोठ्या प्रमाणावर प्रत्यक्ष पैशात रूपांतरित होतात.
Deterministic queries कॅश (Cache) करा. जर तुमचे युजर्स वारंवार तेच प्रश्न विचारत असतील किंवा जर तुमचे बॅकएंड ओव्हरलॅपिंग डेटावर समान classification tasks चालवत असेल, तर निकाल काही मिनिटे किंवा तासांसाठी साठवून ठेवा. तुमच्या LLM client च्या समोर एक पातळ (thin) caching layer लावल्याने मॉडेलची गुणवत्ता न बदलता व्हॉल्यूम अर्ध्यावर आणता येऊ शकतो.
कामाच्या स्वरूपानुसार मॉडेल्स बदला. प्रत्येक ऑपरेशनसाठी प्लॅटफॉर्मवरील सर्वात सक्षम आणि सर्वात महागडे मॉडेल आवश्यक नसते. साध्या कामांसाठी लहान, स्वस्त checkpoints वापरा आणि अवघड (edge cases) कामांसाठी heavyweight मॉडेल्स राखून ठेवा. जर StreamLake किंवा Novita ने त्यांचे mid-tier मॉडेल्स अधिक स्पर्धात्मक करण्यासाठी किंमतींमध्ये बदल केले असतील, तर ते तुमच्या routing rules मध्ये संतुलन राखण्याचा संकेत आहे.
Token ceilings लागू करा. तुमच्या generation calls मध्ये output length वर एक कडक मर्यादा (hard ceiling) सेट करा. जर युजरने सारांश (summary) विचारला असेल, तर मॉडेलला एक हजार टोकन्सपर्यंत बोलू देण्याऐवजी त्याला दोनशे टोकन्सवर मर्यादित करा. तुमचे युजर्स देखील अनेकदा संक्षिप्त उत्तरेच पसंत करतात.
Reserved capacity किंवा commitment discounts कडे लक्ष द्या. जर तुमचा व्हॉल्यूम स्थिर असेल, तर serverless per-token pricing ही compute खरेदी करण्याचा सर्वात महागडा मार्ग असू शकतो. काही प्रदाते reserved throughput किंवा enterprise commits देतात, जे लवचिकता कमी करून कमी युनिट रेट देतात. किंमत बदलण्याची घटना ही त्यांच्या सेल्स टीमला मार्केटिंग साइटवर नसलेल्या 'hidden tiers' बद्दल विचारण्यासाठी एक चांगली संधी आहे.
सविस्तर माहिती कोठे मिळेल
LLM इन्फ्रास्ट्रक्चर मार्केट वेगाने बदलत असल्यामुळे, स्थिर लेख लवकरच जुने होतात. नक्की कोणते Novita आणि StreamLake endpoints बदलले आहेत, किती प्रमाणात बदलले आहेत आणि कोणते मॉडेल्स प्रभावित झाले आहेत, याचा संपूर्ण तपशील लिंक केलेल्या developer update मध्ये दिला आहे.
जर तुम्हाला इतर बिल्डर्ससोबत (builders) सतत चर्चा करायची असेल जे प्रदातांच्या किमती, बिलिंग ट्रिक्स आणि मॉडेल परफॉर्मन्सवर लक्ष ठेवून आहेत, तर GyaanSetu Telegram कम्युनिटी खुली आहे. प्लॅटफॉर्म्स त्यांचे दर बदलतात तेव्हा तुमच्या स्टॅकचे रिफॅक्टरिंग (refactor) करायचे की वाढीव खर्च सहन करायचा, यावर दुसऱ्या मतासाठी ही एक उपयुक्त जागा आहे.
मुख्य निष्कर्ष
किमतींमधील बदल हे केवळ व्हेंडरच्या बातम्या नाहीत; ते संकेत आहेत की तुमच्या खर्चाच्या गृहितकांना वास्तवाशी जुळवून घेण्याची गरज आहे. Novita आणि StreamLake ने त्यांचे LLM दर अपडेट केले आहेत, याचा अर्थ असा की तुम्ही तीन महिन्यांपूर्वी तयार केलेली स्प्रेडशीट कदाचित चुकीची आहे. तुमचा वापर डेटा (usage data) काढा, नवीन दर लागू करा, तुमच्या routing logic ची चाचणी घ्या आणि ऑप्टिमाइझ करायचे, वाटाघाटी करायच्या की स्थलांतरित करायचे याचा निर्णय घ्या. Inference हा कोणताही निश्चित खर्च (fixed overhead) नाही; तो एक बदलता खर्च (variable cost) आहे जो तुमच्या यशासोबत वाढतो. त्याला तसाच वागवा.