यदि आप लार्ज लैंग्वेज मॉडल्स (LLMs) द्वारा संचालित कोई उत्पाद लॉन्च करते हैं, तो आपका मार्जिन उतना ही स्थिर है जितना आपके प्रदाता का रेट कार्ड। Novita और StreamLake दोनों ने हाल ही में अपनी मॉडल प्राइसिंग अपडेट की है, और इसका मतलब है कि आपकी यूनिट इकोनॉमिक्स (unit economics) बदल गई है, चाहे आपने इस पर ध्यान दिया हो या नहीं। ये कोई नियमित मेंटेनेंस विंडो नहीं हैं। जब इन्फरेंस प्रोवाइडर्स (inference providers) अपनी प्रति-टोकन दरें बदलते हैं, तो सपोर्ट टिकट को वर्गीकृत करने, दस्तावेज़ का सारांश तैयार करने या कोड सुझाव जेनरेट करने की लागत रातों-रात बदल जाती है। जो डेवलपर्स API प्राइसिंग को एक स्थिर बैकग्राउंड नॉइज़ की तरह मानते हैं, उन्हें समस्या का पता आमतौर पर तभी चलता है जब उनका मासिक बिल आता है।
क्यों एक शांत मूल्य परिवर्तन बजट बिगाड़ सकता है
अधिकांश इंजीनियरिंग टीमें एक इन्फरेंस प्रोवाइडर चुनती हैं, कुछ लेटेंसी बेंचमार्क चलाती हैं, और फिर आगे बढ़ जाती हैं। प्रॉम्प्ट टेम्पलेट्स को वर्जन कंट्रोल में कमिट कर दिया जाता है, क्लाइंट कोड प्रोडक्शन में चला जाता है, और फाइनेंस टीम को एक मोटा मासिक अनुमान मिल जाता है। यह वर्कफ़्लो तब तक काम करता है जब तक कि वह काम करना बंद न कर दे। टोकन एक उपभोग्य संसाधन (consumable resource) हैं। आपका बिल यूजर अडॉप्शन, कॉन्टेक्स्ट लेंथ और रिट्राय बिहेवियर के साथ बढ़ता है। स्प्रेडशीट पर मामूली दिखने वाली दर वृद्धि एक हाई-वॉल्यूम फीचर के मार्जिन को खत्म कर सकती है।
इसका प्रभाव पूरी तरह से आपके उपयोग के स्वरूप (usage shape) पर निर्भर करता है। छोटे क्लासिफिकेशन प्रॉम्प्ट भेजने वाली टीम बिना कुछ बदले मूल्य समायोजन को सहन कर सकती है। लंबे कॉन्टेक्स्ट विंडो को प्रोसेस करने वाली या हजारों पेजों पर बैच जॉब चलाने वाली टीम का बर्न रेट (burn rate) तेजी से बढ़ता देख सकती है। प्रतिशत में समान बदलाव का प्रभाव अलग-अलग होता है, यह इस बात पर निर्भर करता है कि आपका औसत कॉल दो सौ टोकन का है या बीस हजार का। यही कारण है कि Novita और StreamLake के अपडेट्स पर गंभीरता से ध्यान देने की आवश्यकता है। आपको यह जानने की जरूरत है कि क्या प्रति यूजर आपकी औसत लागत आपके अनुमानों से बाहर निकल गई है, और क्या अब ट्रैफिक को रीरूट (reroute) करने का समय आ गया है।
Novita का प्राइसिंग अपडेट
Novita ने हाल ही में अपनी मॉडल कीमतों में बदलाव किया है। यह प्लेटफॉर्म विभिन्न प्रकार के लैंग्वेज मॉडल्स तक पहुंच प्रदान करता है, और वहां होने वाला कोई भी बदलाव उन टीमों की परिचालन लागत (operating costs) में सीधे तौर पर झलकता है जो इसे प्राथमिक इन्फरेंस लेयर के रूप में उपयोग करती हैं। चूंकि Novita कई मॉडल्स को होस्ट करता है, इसलिए अपडेट पूरे कैटलॉग में एक समान नहीं हो सकता है। मॉडल्स का एक समूह स्थिर रह सकता है जबकि दूसरा बदल सकता है। यह सूक्ष्मता (granularity) एक सामान्य घोषणा की तुलना में कहीं अधिक महत्वपूर्ण है।
यदि आप सारा ट्रैफिक एक ही मॉडल आईडी के माध्यम से रूट करते हैं, तो आपके नए अनुमानित खर्च की गणना करना आसान है। यदि आप Novita के कैटलॉग का गतिशील रूप से उपयोग करते हैं, जैसे जटिल प्रॉम्प्ट्स को बड़े मॉडल्स पर और सरल प्रॉम्प्ट्स को छोटे मॉडल्स पर रूट करना, तो आपकी मिश्रित औसत लागत (blended average cost) उन तरीकों से बदल सकती है जिन्हें कोई भी एकल अलर्ट नहीं समझा सकता। जानने का एकमात्र तरीका अपने उपयोग लॉग (usage logs) निकालना, उन्हें मॉडल के आधार पर समूहित करना और नए रेट कार्ड के अनुसार वास्तविक टोकन गणना को गुणा करना है। प्रति मिलियन टोकन की कीमत क्या थी, इस पर अपनी याददाश्त पर भरोसा न करें। इसे लिख लें। एक ऐतिहासिक रिकॉर्ड रखें। इसे अपने त्रैमासिक समीक्षा चक्र (quarterly review cycle) का हिस्सा बनाएं ताकि अगला बदलाव आपको चौंका न दे।
StreamLake का प्राइसिंग अपडेट
StreamLake ने भी अपने मॉडल्स पर प्राइस अपडेट लागू किया है। इसके स्टैक के साथ एकीकृत टीमों के लिए, टोकन दरों में कोई भी समायोजन कंटेंट एनालिसिस, ट्रांसक्रिप्शन बैक-एंड, जेनरेटिव फीचर्स, या प्लेटफॉर्म के माध्यम से चलने वाले किसी भी अन्य लैंग्वेज वर्कलोड के गणित को बदल देता है। समायोजन का वास्तविक आकार कंपाउंडिंग प्रभाव (compounding effect) की तुलना में गौण है। जब आप कई वातावरणों (environments) में प्रतिदिन लाखों टोकन प्रोसेस कर रहे होते हैं, तो प्रति-टोकन में मामूली वृद्धि भी काफी बढ़ जाती है।
असली सवाल यह नहीं है कि नई कीमत क्या है, बल्कि यह है कि वह नई कीमत प्रति फीचर आपके ग्रॉस मार्जिन (gross margin) पर क्या प्रभाव डालती है। यदि StreamLake किसी ग्राहक-केंद्रित सारांश टूल (summarization tool) या आंतरिक मॉडरेशन लेयर को शक्ति प्रदान करता है, तो आपकी बेची गई वस्तुओं की लागत (cost of goods sold) अभी बदल गई है। आपको अपने ऑब्जर्वेबिलिटी टूलिंग (observability tooling) में उस खर्च को स्पष्ट रूप से अलग करना चाहिए। उन API कॉल्स को प्रदाता और फीचर के आधार पर टैग करें ताकि जब इनवॉइस आए, तो आप इसे सटीक रूप से विभाजित कर सकें। यदि कोई उपयोग मामला (use case) अलाभकारी हो गया है, तो आपको यह तय करने के लिए डेटा की आवश्यकता होगी कि क्या इसे थ्रॉटल (throttle) करना है, छोटे मॉडल पर डाउनग्रेड करना है, या इसे रणनीतिक लागत के रूप में स्वीकार करना है।
अपने इन्फरेंस खर्च का ऑडिट कैसे करें
स्वीकार करना