अपनी LLM उपयोग फ़ाइल का विश्लेषण कैसे करें
हर LLM बिल के पीछे एक फ़ाइल होती है: उपयोग निर्यात जो आपका प्रदाता आपको देगा, पंक्ति दर पंक्ति, मॉडल दर मॉडल, दिन दर दिन। अधिकांश लोग इसे कभी नहीं खोलते, क्योंकि कच्चा निर्यात बिना कुल और बिना निष्कर्ष के टोकन गणनाओं की दीवार होता है। यह मार्गदर्शिका दिखाती है कि वह फ़ाइल कहाँ से मिलेगी, उसमें वास्तव में क्या है, और एक बार जब आप इसे स्पष्ट रूप से देख सकें तो खोजने योग्य तीन पैटर्न — इस साइट के LLM उपयोग विश्लेषक का उपयोग करके, जो फ़ाइल को आपके ब्राउज़र में पढ़ता है और कहीं और नहीं।
अंतिम अपडेट:
उपयोग कहाँ से निर्यात करें
वहाँ से शुरू करें जहाँ प्रदाता संख्याएँ रखता है। OpenAI उपयोग को दो जगहों पर उपलब्ध कराता है: प्रदाता कंसोल का उपयोग पेज, जो वर्तमान बिलिंग अवधि के लिए दिन और मॉडल के अनुसार गतिविधि का सारांश देता है, और उपयोग API, जो वही डेटा JSON के रूप में लौटाता है — समय बकेट, जिनमें से हर एक में संदर्भ टोकन, उत्पन्न टोकन और अनुरोध गणनाओं के साथ मॉडल-वार परिणाम होते हैं। वह JSON आकार जानने योग्य है क्योंकि यह वह है जिसे आप स्क्रीनशॉट के बिना संग्रहीत कर सकते हैं, तुलना कर सकते हैं और उपकरणों को दे सकते हैं। आज से शुरू करने योग्य एक आदत: महीने में एक बार API प्रतिक्रिया खींचें और उसे रखें। प्रदाता कंसोल में केवल सीमित अवधि का इतिहास रखते हैं; आपका अपना संग्रह ही इस बात का एकमात्र पूर्ण रिकॉर्ड है कि आपने वास्तव में कितना खर्च किया, महीना दर महीना।
Anthropic अपनी कंसोल और अपनी रिपोर्टिंग API के माध्यम से उसी भावना में उपयोग और लागत रिपोर्टिंग उपलब्ध कराता है: दिन और मॉडल के अनुसार एकत्रित, सारणीबद्ध डेटा के रूप में निर्यात योग्य। अन्य प्रदाता परिष्करण में भिन्न होते हैं लेकिन प्रकार में नहीं — उपयोग या बिलिंग पेज से CSV डाउनलोड, या दिनांकित पंक्तियाँ लौटाने वाला API समापन बिंदु। सामान्य आकार ही किसी भी विश्लेषण के लिए आवश्यक सब कुछ है: एक तारीख़, एक मॉडल नाम, इनपुट टोकन, आउटपुट टोकन, और भाग्य अच्छा हो तो कैश टोकन, अनुरोध गणनाएँ और एक लागत कॉलम। यदि आपका प्रदाता कई निर्यात देता है, तो उसके द्वारा दिया जाने वाला सबसे सूक्ष्म वाला लें — दिन के अनुसार मॉडल-वार, महीने के अनुसार परियोजना-वार से बेहतर है, क्योंकि जो एकत्रीकरण आप स्वयं करते हैं उसे हमेशा पूर्ववत किया जा सकता है, और जो प्रदाता ने किया उसे नहीं।
फ़ाइल में वास्तव में क्या होता है
उपयोग पंक्ति एक छोटा, घना दावा है: इस तारीख़ को, इस मॉडल ने इतने अनुरोध पूरे किए, इतने इनपुट टोकन पढ़े — जिनमें से इतने कैश किए गए थे — और इतने आउटपुट टोकन लिखे। उन कॉलमों वाली फ़ाइल पढ़ें और आप कार्यभार के आकार के बारे में लगभग सब कुछ पुनर्निर्मित कर सकते हैं: प्रॉम्प्ट लंबे हैं या छोटे, उत्तर शब्दाडंबरपूर्ण हैं या नहीं, ट्रैफ़िक स्थिर है या फटने वाला, और कौन-से मॉडल असली काम करते हैं। फ़ाइल जानबूझकर जो नहीं रखती वह उतना ही महत्वपूर्ण है: कोई प्रॉम्प्ट पाठ नहीं, कोई पूर्णता नहीं, कोई उपयोगकर्ता सामग्री नहीं। यह गणनाएँ और नाम हैं, और इसीलिए इसे उस ट्रैफ़िक की तुलना में अधिक स्वतंत्र रूप से संभाला जा सकता है जिसका यह वर्णन करती है — हालाँकि, जैसा कि अंतिम खंड तर्क देता है, “अधिक स्वतंत्र रूप से” का अर्थ “कहीं भी” नहीं है।
किसी भी विश्लेषण से पहले दो कॉलम संदेह के योग्य हैं। पहला है लागत: कुछ निर्यात बिल की गई लागत रखते हैं, कुछ सूची-मूल्य अनुमान रखते हैं, और कुछ कुछ भी नहीं, और फ़ाइल शायद ही कभी यह बताती है कि कौन-सा है। लागत कॉलम को प्रदाता के आँकड़े के रूप में मानें, लेकिन कुल पर भरोसा करने से पहले तारीख़ सीमा और छोड़ी गई या आंशिक पंक्तियों को सत्यापित करें। दूसरा है कैश टोकन कॉलम, जिसे प्रदाता कम से कम पाँच अलग-अलग तरीकों से नाम देते हैं और कभी-कभी उसे अलग दिखाने के बजाय इनपुट गणना में मोड़ देते हैं। यदि इनपुट टोकन उस मॉडल के लिए अविश्वसनीय रूप से सस्ते या महंगे लगते हैं, तो हेडर देखने की पहली जगह हैं — और इसीलिए विश्लेषक आपको हेडरों से पहचानी गई अपनी कॉलम मैपिंग दिखाता है और कुछ भी गणना होने से पहले उसे सुधारने देता है।
क्या देखना है: तीन पैटर्न
पहला, कैश टोकन अनुपात। कैश किए गए इनपुट को कुल इनपुट से विभाजित करें, प्रति मॉडल। किसी भी दोहराई गई संरचना वाले कार्यभार — एक सिस्टम प्रॉम्प्ट, एक दस्तावेज़ उपसर्ग, एक निश्चित उपकरण स्कीमा — को अपने इनपुट का बड़ा हिस्सा कैश करना चाहिए, क्योंकि वह उपसर्ग हर कॉल पर समान होता है। ऐसे कार्यभार पर शून्य के निकट अनुपात का अर्थ है कि कैशिंग बंद है, कॉलों के बीच कैश समाप्त हो रहा है, या उपसर्ग में कुछ हर अनुरोध पर बदल रहा है — एक समय-चिह्न, एक यादृच्छिक id, एक पुनः क्रमबद्ध फ़ील्ड — और चुपचाप उसे हरा रहा है। उस एक संख्या को ठीक करना नियमित रूप से मॉडल पर फिर से बातचीत करने से अधिक मूल्यवान होता है, क्योंकि हर प्रमुख प्रदाता पर कैश किया गया इनपुट पूर्ण दर के एक अंश पर बिल किया जाता है।
दूसरा, मॉडल मिश्रण। मॉडलों को अनुरोधों से नहीं, लागत से क्रमबद्ध करें: मिश्रण तब स्वस्थ होता है जब महंगे स्तर का लागत हिस्सा उस कार्य के हिस्से से मोटे तौर पर मेल खाता है जिसे वास्तव में उसकी आवश्यकता है। जिस बहाव पर नज़र रखनी है वह है किसी फ़्लैगशिप मॉडल के लागत हिस्से का महीना दर महीना बढ़ना जबकि उसका अनुरोध हिस्सा स्थिर रहे — लंबे प्रॉम्प्ट, लंबे आउटपुट, या किसी ऐसी डिफ़ॉल्ट सेटिंग द्वारा चुपचाप बड़े मॉडल की ओर भेजा गया नया ट्रैफ़िक जिसे सेट करना किसी को याद नहीं। तीसरा, केंद्रण और उछाल: एक API कुंजी, परियोजना या मॉडल का फ़ाइल पर हावी होना लागत तथ्य जितना ही विस्फोट-त्रिज्या तथ्य है, और दिन-वार उछाल — विशेष रूप से सप्ताहांत या रात में, जब कोई काम नहीं कर रहा था — पुनः प्रयास लूप, अनियंत्रित एजेंट, या उपयोग की जा रही लीक हुई कुंजी का हस्ताक्षर है। दिन-वार तालिका उस उछाल को नज़रअंदाज़ करना असंभव बनाने के लिए मौजूद है।
बिना लागत वाली फ़ाइल की कीमत तय करना
कई निर्यातों में कोई लागत कॉलम बिल्कुल नहीं होता, और तब विश्लेषण को फ़ाइल की कीमत स्वयं तय करनी होती है। विश्लेषक यह पारदर्शी तरीके से करता है: हर पंक्ति की कीमत इस साइट की LLM कीमत तालिका से तय की जाती है — वही सत्यापित सूची दरें जो लागत कैलकुलेटर भी उपयोग करता है — प्रदाता के अपने सूत्र से: बिना कैश वाला इनपुट इनपुट दर पर, कैश वाला इनपुट जहाँ मौजूद हो वहाँ कैश दर पर, आउटपुट आउटपुट दर पर। मॉडल नाम सख्ती से मिलाए जाते हैं: ठीक-ठीक, प्रदाता उपसर्ग हटाने के बाद, या अंत की तारीख़ या “latest” प्रत्यय हटाने के बाद। वह सख्ती ही मुद्दा है। ढीला, अस्पष्ट मिलान अंततः किसी फ़ाइन-ट्यून को उसके आधार मॉडल के रूप में या किसी पूर्वावलोकन को रिलीज़ के रूप में कीमत देगा, और कुल वह आत्मविश्वास प्राप्त करेगा जो उसने अर्जित नहीं किया है।
इसीलिए जो मॉडल किसी से भी मेल नहीं खाते उन्हें सूचीबद्ध किया जाता है, अनुमान नहीं लगाया जाता। उनके टोकन और अनुरोध फिर भी गिने जाते हैं — आप उनका वॉल्यूम देख सकते हैं और निर्णय कर सकते हैं कि अंतर मायने रखता है या नहीं — लेकिन उनकी लागत खाली छोड़ दी जाती है, और परिणाम पर यह लेबल लगाया जाता है कि उसका पैसा कहाँ से आया: फ़ाइल स्वयं, तालिका से गणना किया गया, मिश्रण, या कोई नहीं। किसी भी गणना किए गए कुल को पढ़ते समय उस मानक पर रखें: यह आपकी छूट, क्रेडिट, बैच दरों या स्तरित लंबे संदर्भ मूल्य निर्धारण की जानकारी के बिना सूची-मूल्य अंकगणित है, इसलिए यह बिल के साथ पैसे तक मेल नहीं खाएगा। यह विश्वसनीय रूप से जो करता है वह है क्रम: कौन-से मॉडल, कौन-से दिन, कौन-से पैटर्न बिल पर हावी हैं। लागत कार्य में, क्रम आमतौर पर निर्णय से संबंधित हिस्सा होता है।
गोपनीयता, और एक मासिक दिनचर्या
उपयोग फ़ाइल में कोई प्रॉम्प्ट पाठ नहीं होता, लेकिन यह फिर भी परिचालन की दृष्टि से संवेदनशील होती है: यह हर उस मॉडल का नाम देती है जिसे आप चलाते हैं, दिन के अनुसार आपके वॉल्यूम, आपकी वृद्धि वक्र और आपका खर्च — इस बात का प्रतिस्पर्धी और सुरक्षा-संबंधी फ़िंगरप्रिंट कि कोई प्रणाली कैसे बनी है। इसीलिए LLM उपयोग विश्लेषक फ़ाइल को आपके ब्राउज़र में स्थानीय रूप से विश्लेषित करता है और उसे कभी अपलोड नहीं करता। सामान्य नियम इस एक उपकरण से कहीं आगे तक लागू होता है: कोई फ़ाइल आपकी अवसंरचना का जितना अधिक सारांश देती है, उसे होस्ट किए गए चैट या अज्ञात कनवर्टर में चिपकाना उतना ही बुरा विचार होता है, भले ही फ़ाइल में शाब्दिक अर्थ में कोई रहस्य न हो। समुच्चय भी लीक होते हैं, बस अधिक चुपचाप।
एक ऐसी दिनचर्या के साथ समाप्त करें जो वास्तव में घटित होने के लिए पर्याप्त छोटी हो। महीने में एक बार: फ़ाइल निर्यात करें, उसका विश्लेषण करें, और चार संख्याएँ लिखें — कुल लागत और उसका स्रोत, शीर्ष मॉडल का लागत हिस्सा, कैश टोकन अनुपात, और सबसे बड़ा एकल दिन। उनकी तुलना पिछले महीने की चार संख्याओं से करें। वह पाँच मिनट का अंतर बहाव, उछाल और हारे हुए कैश को तब पकड़ता है जब वे अभी भी सस्ते होते हैं, और एक वर्ष में वह संग्रह बनाता है जो कोई भी प्रदाता कंसोल आपके लिए नहीं रखेगा। बिल उन लोगों को आश्चर्यचकित करते हैं जो केवल बिल पढ़ते हैं। वे उन लोगों को शायद ही कभी आश्चर्यचकित करते हैं जो उपयोग पढ़ते हैं।
अक्सर पूछे जाने वाले प्रश्न
कौन-सा निर्यात उपयोग करूँ — कंसोल CSV या उपयोग API JSON?
कोई भी; वे एक ही गतिविधि का वर्णन करते हैं। कंसोल CSV प्राप्त करना सबसे तेज़ है और एक बार देखने के लिए पर्याप्त है। API JSON बेहतर आदत है: यह पूर्ण है, स्क्रिप्ट योग्य है, संग्रहीत करने योग्य है, और मॉडल-वार टोकन फ़ील्ड (संदर्भ, उत्पन्न, जहाँ मौजूद हो वहाँ कैश, और अनुरोध गणनाएँ) स्थिर आकार में रखता है। यदि दोनों असहमत हों, तो पहले तारीख़ सीमाएँ और समय क्षेत्र जाँचें — कंसोल दृश्य अक्सर स्थानीय समय में दिखाए जाते हैं जबकि API बकेट UTC होते हैं, जो दिन की सीमा को स्थानांतरित करता है और कुल को बदले बिना आसन्न दिनों के बीच खर्च को ले जाता है।
मेरा कैश टोकन अनुपात शून्य के निकट है। प्रॉम्प्ट कैशिंग को क्या तोड़ता है?
सामान्य कारण, क्रम में: ट्रैफ़िक जिस मार्ग से जाता है उस पर कैशिंग सक्षम नहीं है या दी नहीं जाती; कॉलों के बीच का अंतर कैश जीवनकाल से अधिक है, इसलिए हर प्रविष्टि पुनः उपयोग से पहले समाप्त हो जाती है; या प्रॉम्प्ट उपसर्ग कॉलों के बीच वास्तव में समान नहीं है — डाला गया समय-चिह्न, प्रति-अनुरोध id, फेंटी गई उपकरण सूची या उपयोगकर्ता-विशिष्ट पहला संदेश, सभी उपसर्ग को बदलते हैं और कैश से चूक जाते हैं। शुरुआत में दो कच्चे अनुरोधों की बाइट दर बाइट तुलना करें: जो सबसे पहले भिन्न होता है वही वह जगह है जहाँ कैश मेल खाना बंद करता है। सुधार यह है कि हर परिवर्तनशील चीज़ को एक स्थिर, साझा उपसर्ग के बाद ले जाएँ।
उपकरण मेरे कुछ मॉडलों के लिए कीमत का अनुमान क्यों नहीं लगाएगा?
क्योंकि उसकी तालिका में उस नाम के लिए कोई ईमानदार कीमत मौजूद नहीं है। फ़ाइन-ट्यून आधार मॉडल का इंजन विरासत में पाते हैं लेकिन आवश्यक रूप से उसकी कीमत नहीं, पूर्वावलोकन अक्सर रिलीज़ से अलग बिल किए जाते हैं, और तृतीय-पक्ष तैनातियाँ अपने अनुबंधों का पालन करती हैं — उनमें से किसी का भी अनुमान लगाना कुल को गलत बनाते हुए उसे पूर्ण दिखाएगा। इसके बजाय उपकरण उन मॉडलों को उनके वॉल्यूम के साथ सूचीबद्ध करता है, ताकि आप उस हिस्से की कीमत अपने अनुबंध या बिल से स्वयं तय कर सकें, और हर आँकड़े का स्रोत स्पष्ट रखते हुए उसे गणना किए गए कुल में जोड़ सकें।