जर तुम्ही लार्ज लँग्वेज मॉडेल्सवर आधारित उत्पादन बाजारात आणत असाल, तर तुमचा मार्जिन तुमच्या पुरवठादाराच्या दरपत्रकावर (rate card) अवलंबून असतो. Novita आणि StreamLake या दोन्ही कंपन्यांनी अलीकडेच त्यांच्या मॉडेलच्या किमतींमध्ये बदल केले आहेत, आणि याचा अर्थ असा की तुमच्या युनिट इकॉनॉमिक्समध्ये (unit economics) बदल झाला आहे, मग तुम्हाला ते लक्षात आले असो वा नसो. हे नियमित देखभाल (maintenance) कालावधी नाहीत. जेव्हा इन्फरन्स प्रोव्हायडर्स (inference providers) त्यांच्या प्रति-टोकन (per-token) दरांमध्ये बदल करतात, तेव्हा सपोर्ट तिकीट वर्गीकृत करणे, दस्तऐवजाचा सारांश काढणे किंवा कोड सुचवणे यांसारख्या कामांचा खर्च रातोरात बदलतो. जे डेव्हलपर्स API च्या किमतींकडे स्थिर पार्श्वभूमीचा भाग समजतात, त्यांना सहसा समस्या तेव्हाच समजते जेव्हा त्यांचा मासिक बिल येतो.
शांतपणे झालेला किमतीतील बदल बजेट कोलमडून का टाकू शकतो
बहुतेक इंजिनिअरिंग टीम्स एक इन्फरन्स प्रोव्हायडर निवडतात, काही लेटन्सी बेंचमार्क (latency benchmarks) तपासतात आणि मग पुढे जातात. प्रॉम्प्ट टेम्पलेट्स (prompt templates) व्हर्जन कंट्रोलमध्ये समाविष्ट केले जातात, क्लायंट कोड प्रोडक्शनमध्ये जातो आणि फायनान्स टीमला महिन्याचा एक अंदाजित खर्च मिळतो. ही कार्यपद्धती तोपर्यंतच काम करते जोपर्यंत काही अनपेक्षित घडत नाही. टोकन्स हे वापरण्यायोग्य संसाधन (consumable resource) आहेत. वापरकर्त्यांची संख्या, कॉन्टेक्स्टची लांबी (context length) आणि रिट्राय बिहेव्हियर (retry behavior) नुसार तुमचे बिल वाढत जाते. स्प्रेडशीटवर किरकोळ वाटणारा दरवाढ एखाद्या हाय-व्हॉल्यूम फीचरचा मार्जिन संपवू शकतो.
याचा परिणाम पूर्णपणे तुमच्या वापराच्या स्वरूपावर अवलंबून असतो. कमी लांबीचे क्लासिफिकेशन प्रॉम्प्ट्स पाठवणारी टीम कोणतीही मोठी बदल न करता किमतीतील बदल सहन करू शकते. लांब कॉन्टेक्स्ट विंडोज (context windows) प्रोसेस करणारी किंवा हजारो पानांवर बॅच जॉब्स (batch jobs) चालवणारी टीम त्यांचा बर्न रेट (burn rate) वेगाने वाढताना पाहू शकते. तुमचे सरासरी कॉल दोनशे टोकन्सचे आहेत की वीस हजार, यावर अवलंबून तेच टक्केवारीतील बदल वेगवेगळ्या प्रकारे परिणाम करते. म्हणूनच Novita आणि StreamLake कडून आलेल्या अपडेट्सकडे गांभीर्याने पाहणे आवश्यक आहे. तुमच्या प्रति वापरकर्ता सरासरी खर्चाने तुमच्या अंदाजाबाहेर जाऊन काही बदल केले आहेत का, आणि आता ट्रॅफिक रिराईट (reroute) करण्याची वेळ आली आहे का, हे तुम्हाला माहित असणे आवश्यक आहे.
Novita चा किमतीतील अपडेट
Novita ने अलीकडेच त्यांच्या मॉडेलच्या किमतींमध्ये बदल केले आहेत. हे प्लॅटफॉर्म विविध लँग्वेज मॉडेल्स उपलब्ध करून देते, आणि तिथे होणारा कोणताही बदल त्याचा वापर प्राथमिक इन्फरन्स लेअर (inference layer) म्हणून करणाऱ्या टीम्सच्या ऑपरेटिंग खर्चावर थेट परिणाम करतो. Novita अनेक मॉडेल्स होस्ट करत असल्यामुळे, हा अपडेट संपूर्ण कॅटलॉगमध्ये सारखा नसू शकतो. मॉडेल्सचा एक गट स्थिर राहू शकतो तर दुसरा बदलू शकतो. केवळ एक सामान्य घोषणा करण्यापेक्षा ही बारकावे (granularity) समजून घेणे अधिक महत्त्वाचे आहे.
जर तुम्ही सर्व ट्रॅफिक एकाच मॉडेल आयडी (model ID) द्वारे वळवत असाल, तर तुमचा नवीन अंदाजित खर्च मोजणे सोपे आहे. जर तुम्ही Novita च्या कॅटलॉगचा डायनॅमिकली वापर करत असाल, म्हणजेच जटिल प्रॉम्प्ट्स मोठ्या मॉडेल्सकडे आणि साधे प्रॉम्प्ट्स लहान मॉडेल्सकडे वळवत असाल, तर तुमचा मिश्र सरासरी खर्च (blended average cost) अशा प्रकारे बदलला असू शकतो जो कोणताही एक अलर्ट स्पष्ट करू शकणार नाही. हे जाणून घेण्याचा एकमेव मार्ग म्हणजे तुमचे युसेज लॉग्स (usage logs) काढणे, ते मॉडेलनुसार गटबद्ध करणे आणि नवीन दरपत्रकानुसार प्रत्यक्ष टोकन संख्येने गुणणे. प्रति दशलक्ष टोकनची किंमत पूर्वी काय होती, यावर केवळ स्मृतीवर अवलंबून राहू नका. ते लिहून ठेवा. ऐतिहासिक रेकॉर्ड ठेवा. तुमच्या त्रैमासिक पुनरावलोकन चक्राचा (quarterly review cycle) हा भाग बनवा जेणेकरून पुढचा बदल तुम्हाला चकित करणार नाही.
StreamLake चा किमतीतील अपडेट
StreamLake ने देखील त्यांच्या मॉडेल्सवर किमतींचा अपडेट लागू केला आहे. त्यांच्या स्टॅकशी (stack) जोडलेल्या टीम्ससाठी, टोकन दरांमध्ये होणारा कोणताही बदल कंटेंट विश्लेषण (content analysis), ट्रान्सक्रिप्शन बॅक-एंड्स (transcription back-ends), जनरेटिव्ह फीचर्स (generative features) किंवा प्लॅटफॉर्मद्वारे चालणाऱ्या इतर कोणत्याही लँग्वेज वर्कलोडच्या गणितात बदल करतो. बदलाचा नेमका आकार किती आहे यापेक्षा त्याचा चक्रवाढ परिणाम (compounding effect) अधिक महत्त्वाचा आहे. जेव्हा तुम्ही विविध वातावरणात (environments) दररोज लाखो टोकन्स प्रोसेस करत असता, तेव्हा प्रति-टोकन झालेली थोडीशी वाढ देखील मोठी ठरते.
खरा प्रश्न नवीन किंमत काय आहे हा नसून, त्या नवीन किमतीमुळे तुमच्या प्रत्येक फीचरच्या ग्रॉस मार्जिनवर (gross margin) काय परिणाम होतो हा आहे. जर StreamLake एखाद्या ग्राहक-केंद्रित सारांश साधनाला (summarization tool) किंवा अंतर्गत मॉडरेशन लेयरला (moderation layer) पॉवर करत असेल, तर तुमचा 'कॉस्ट ऑफ गुड्स सोल्ड' (cost of goods sold) नुकताच बदलला आहे. तुम्ही तुमच्या ऑब्झर्व्हेबिलिटी टूलिंगमध्ये (observability tooling) तो खर्च स्पष्टपणे वेगळा केला पाहिजे. त्या API कॉल्सना प्रोव्हायडर आणि फीचरनुसार टॅग करा, जेणेकरून जेव्हा इनव्हॉइस येईल, तेव्हा तुम्ही त्याचे अचूक विभाजन करू शकाल. जर एखादा वापर (use case) तोट्याचा ठरला असेल, तर तो मर्यादित करायचा (throttle), लहान मॉडेलवर डाउनग्रेड करायचा की धोरणात्मक खर्च (strategic cost) म्हणून तो स्वीकारायचा, हे ठरवण्यासाठी तुमच्याकडे डेटा उपलब्ध असणे आवश्यक आहे.
तुमच्या इन्फरन्स खर्चाचे ऑडिट कसे करावे
स्वीकारणे