सारांश
- स्ट्रीमिंग प्रतिक्रियाओं को अपूर्ण चंक्स और अंतिम टोकन उपयोग डेटा को संभालने के लिए मजबूत SSE पार्सिंग की आवश्यकता होती है।
- JSON मोड की विफलताएं आमतौर पर मॉडल द्वारा कड़े JSON स्कीमा के बाहर ट्रेलिंग टेक्स्ट जनरेट करने से आती हैं।
- 100k कॉन्टेक्स्ट विंडो प्रॉम्प्ट और कंप्लीशन के बीच साझा किया जाता है, इसलिए लंबे आउटपुट उपलब्ध इनपुट स्थान को कम करते हैं।
- लागत का अनुमान लगाने में आउटपुट टोकन की उच्च कीमत को ध्यान में रखना आवश्यक है, जो इनपुट टोकन की तुलना में अधिक है।
आपका स्ट्रीमिंग रिस्पॉन्स क्यों हंग हो रहा है
स्ट्रीमिंग रिस्पॉन्स तब लटक जाते हैं जब क्लाइंट टोकन उपयोग डेटा वाले अंतिम Server-Sent Event (SSE) चंक को पढ़ने में विफल रहता है। हमारा API टोकन्स को जनरेट होते ही स्ट्रीम करता है, लेकिन कनेक्शन अंतिम चंक आने के बाद ही पूरी तरह से बंद होता है। यदि आपका क्लाइंट कोड जल्दी डिस्कनेक्ट हो जाता है या अंतिम चंक को अनदेखा करता है, तो आपको बिलिंग सत्यापन के लिए आवश्यक सटीक टोकन गणना खो जाती है।
स्ट्रीम समाप्त होने तक हर चंक पढ़ें। यह न मानें कि आखिरी चंक में केवल अंतिम टोकन होता है। हमारे SSE स्ट्रीम में आखिरी चंक में शामिल होता है usage इनपुट और आउटपुट टोकन के कुल योग के साथ फ़ील्ड। यदि आप इस डेटा को छोड़ देते हैं, तो आप अपने पूर्व-भुगतान क्रेडिट की खपत की सटीक निगरानी नहीं कर पाएंगे।
सामान्य बाधाएँ
- अंतिम SSE इवेंट को अनदेखा करना।
- लंबे पूर्ण होने के लिए बहुत कम सेट किए गए टाइमआउट।
- स्ट्रीमिंग मोड में आंशिक JSON हैंडल नहीं करना।
सर्वर को यह जानने के लिए कि क्लाइंट ने पूर्ण प्रतिक्रिया प्राप्त की है, स्ट्रीम को पूरी तरह से खपित करें। यह हमारी ओर से संसाधन लीक को रोकता है और यह सुनिश्चित करता है कि आपके पास अपने स्वयं के लॉग के लिए आवश्यक डेटा है।
प्रोडक्शन में JSON मोड त्रुटियाँ हैंडल करना
JSON मोड त्रुटियां इसलिए होती हैं क्योंकि मॉडल बंद ब्रेस के बाद टेक्स्ट जनरेट कर सकता है, जो कठोर JSON पार्सिंग नियमों का उल्लंघन करता है। जब आप सेट response_format को {"type": "json_object", मॉडल वैध JSON आउटपुट करने का प्रयास करता है, लेकिन अक्सर बंद ब्रैकेट के बाद 'यहाँ डेटा है:' जैसी बोलचाल की सामग्री जोड़ देता है। आपका पार्सर अतिरिक्त पाठ पर क्रैश हो जाता है।
अंतिम मान्य बंद ब्रेस के बाद आने वाले अंतिम पाठ को हटा दें। मॉडल पर यह भरोसा न करें कि वह JSON संरचना के अंत पर बिल्कुल रुक जाएगा। आपको अंतिम '}' या ']' खोजने और उसके बाद की हर चीज को छोड़ने के लिए एक पोस्ट-प्रोसेसिंग चरण लागू करना होगा। यह एरे या नेस्टेड ऑब्जेक्ट्स को पार्स करते समय महत्वपूर्ण है।
सर्वश्रेष्ठ प्रथाएँ
- अंतिम मान्य JSON ब्लॉक को निकालने के लिए एक रेगेक्स का उपयोग करें।
- एक JSON पार्सर के साथ निकाले गए स्ट्रिंग की जांच करें।
- यदि आउटपुट अराजक है तो कम तापमान के साथ पुनः प्रयास करें।
यह दृष्टिकोण सुनिश्चित करता है कि आपकी प्रोडक्शन पाइपलाइन स्थिर रहे, भले ही मॉडल बातूनी बनने का फैसला करे। अनसेंसर्ड मॉडल्स कम बाध्यकारी होते हैं, इसलिए वे अपने फॉर्मेटिंग के साथ अधिक 'रचनात्मक' लग सकते हैं।
संदर्भ विंडो सीमाओं को समझना
संयुक्त प्रॉम्प्ट और पूर्णता के लिए संदर्भ विंडो की सीमा 100,000 टोकन है। इसका मतलब है कि यदि आपका इनपुट 50,000 टोकन है, तो आप सीमा से टकराने से पहले केवल 50,000 टोकन ही उत्पन्न कर सकते हैं। सीमा केवल इनपुट के लिए नहीं है; यह पूरे अनुरोध के लिए एक साझा बजट है।
इनपुट टोकन गणना को 100,000 से घटाकर अपनी उपलब्ध आउटपुट स्पेस की गणना करें। यदि आप एक बड़ा सिस्टम प्रॉम्प्ट या संदेशों का एक लंबा इतिहास भेजते हैं, तो आपकी उपलब्ध आउटपुट स्पेस उसी अनुपात में कम हो जाती है। यह उन एप्लिकेशन के लिए महत्वपूर्ण है जो लंबी बातचीत के इतिहास को बनाए रखते हैं।
गणना उदाहरण
- कुल विंडो: 100,000 टोकन।
- इनपुट टोकन: 20,000 टोकन।
- अधिकतम आउटपुट: 80,000 टोकन।
यदि आप इस सीमा से अधिक हो जाते हैं, तो API एक त्रुटि लौटाता है। मॉडल की प्रतिक्रिया की अप्रत्याशित ट्रंकेशन से बचने के लिए अपने टोकन उपयोग की निकट निगरानी करें। मॉडल स्वचालित रूप से ट्रंकेट नहीं करता है; यह केवल तब अनुरोध को अस्वीकार कर देता है जब कुल विंडो से अधिक हो जाए।
टोकन गिनती और लागत अनुमान
लागत का अनुमान लगाने में इनपुट और आउटपुट टोकन के बीच कीमत के अंतर को ध्यान में रखना आवश्यक है। इनपुट टोकन की कीमत 1M टोकन प्रति $0.15 है, जबकि आउटपुट टोकन की कीमत 1M टोकन प्रति $0.50 है। आउटपुट टोकन काफी अधिक महंगे हैं, इसलिए लंबी प्रतिक्रियाएं उत्पन्न करने से आपके खर्च लंबे इनपुट भेजने की तुलना में तेजी से बढ़ेंगे।
अपनी लागत का अनुमान लगाने के लिए अपेक्षित टोकन गणना को संबंधित कीमत से गुणा करें। उदाहरण के लिए, 10,000 इनपुट टोकन और 5,000 आउटपुट टोकन की लागत होगी: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50)। इसका मतलब है $0.0015 + $0.0025 = $0.004 प्रति अनुरोध।
मूल्य निर्धारण तालिका
| टोकन प्रकार | प्रति 1M टोकन कीमत |
|---|---|
| इनपुट | $0.15 |
| आउटपुट | $0.50 |
अंतिम SSE चंक या API प्रतिक्रिया के माध्यम से अपने उपयोग को ट्रैक करें। यह सुनिश्चित करता है कि आप उच्च-वॉल्यूम एप्लिकेशन के लिए सटीक बजट बना सकें। प्रीपेड क्रेडिट कभी समाप्त नहीं होता है, इसलिए आप मासिक शुल्क के बिना समय के साथ अपने खर्च की योजना बना सकते हैं।
रेट लिमिटिंग: 300 RPM की व्याख्या
रेट लिमिटिंग प्रति API कुंजी आपके अनुरोधों को 300 प्रति मिनट तक सीमित करती है। यह सीमा सभी अनुरोधों पर लागू होती है, चाहे पेलोड साइज या टोकन संख्या कुछ भी हो। यदि आप इस सीमा से अधिक हो जाते हैं, तो API एक 429 त्रुटि लौटाता है। आपको इन त्रुटियों को सहजता से संभालने के लिए एक्सपोनेंशियल बैकऑफ लागू करना होगा।
अपने अनुरोध दर की निगरानी करें और समवर्णता को उसी अनुसार समायोजित करें। यदि आप कई थ्रेड्स या प्रक्रियाओं का उपयोग कर रहे हैं, तो सुनिश्चित करें कि वे एक ही API कुंजी साझा करते हैं और संयुक्त रूप से 300 RPM सीमा के भीतर रहते हैं। इस सीमा को पार करने से अस्थायी त्रुटियां होंगी जब तक कि दर रीसेट नहीं हो जाती।
429 त्रुटियाँ हैंडल करना
- एक्सपोनेंशियल बैकऑफ लागू करें।
- विश्लेषण के लिए विफल अनुरोध लॉग करें।
- यदि सीमाएं अक्सर होती हैं तो समानांतरता कम करें।
हमारा API उच्च-वॉल्यूम उपयोग के लिए है, लेकिन दर सीमा सभी क्लाइंट्स के बीच उचित उपयोग को सुनिश्चित करती है। यदि आपको उच्चतर सीमाओं की आवश्यकता है, तो आप एक नया API कुंजी उत्पन्न कर सकते हैं, लेकिन ध्यान दें कि प्रत्येक खाते में एक समय में केवल एक सक्रिय कुंजी की अनुमति है।
फंक्शन कॉलिंग विफलताओं का निवारण
फंक्शन कॉलिंग विफलताएं तब होती हैं जब मॉडल की टूल परिभाषा अपेक्षित स्कीमा से मेल नहीं खाती या जब मॉडल टूल तर्कों के लिए वैध JSON आउटपुट करने में विफल रहता है। सुनिश्चित करें कि आपके टूल डिफ़िनेशन सटीक हों और सभी आवश्यक पैरामीटर शामिल हों। अस्पष्ट स्कीमा खराब टूल कॉल का कारण बनते हैं।
फ़ंक्शन निष्पादित करने से पहले टूल तर्कों की जांच करें। मॉडल ऐसे तर्क उत्पन्न कर सकता है जिनमें आवश्यक फ़ील्ड गायब हैं या गलत प्रकार के हैं। आपका क्लाइंट कोड इन त्रुटियों को एक स्पष्ट प्रॉम्प्ट के साथ पुनः प्रयास करके या टूल परिभाषा को समायोजित करके संभालना चाहिए।
डिबगिंग चरण
- टूल परिभाषा सिंटैक्स की जाँच करें।
- तर्क प्रकारों और मानों की सत्यापन करें।
- मॉडल आउटपुट की समीक्षा करें कि क्या कोई फ़ील्ड छूट गई है।
फंक्शन कॉलिंग एक शक्तिशाली सुविधा है, लेकिन इसमें सावधानीपूर्वक स्कीमा डिज़ाइन की आवश्यकता होती है। अनकैप्ड मॉडल टूल परिभाषाओं के साथ अपने फ़िल्टर वाले समकक्षों की तुलना में कम स्थिर हो सकते हैं, इसलिए कठोर सत्यापन आवश्यक है।
'uncensored' पूरी तरह से अनलिमिटेड नहीं है
'uncensored' लेबल का अर्थ है कि मॉडल कानूनी वयस्क, काल्पनिक या विवादास्पद विषयों को अस्वीकार नहीं करता है, लेकिन उसके पास किशोरों से संबंधित यौन सामग्री के लिए एक कठोर सीमा है। यह एकमात्र कठोर सामग्री प्रतिबंध है जो हमेशा लागू होता है। ऐसी सामग्री वाले अनुरोध अस्वीकार कर दिए जाएंगे, भले ही प्रॉम्प्ट का बाकी हिस्सा पूरी तरह से वैध हो।
अन्य अस्वीकृतियां तकनीकी त्रुटियों या दर सीमाओं के कारण अभी भी हो सकती हैं। मॉडल जादू नहीं है; यह अभी भी एक प्रतिक्रिया उत्पन्न करने में विफल हो सकता है यदि इनपुट बहुत जटिल है या संदर्द्र विंडो को पार कर लिया गया है। समझें कि 'uncensored' सामग्री नीति को संदर्भित करता है, न कि तकनीकी विश्वसनीयता को।
सामग्री सीमाएँ
- किशोरों के साथ यौन सामग्री नहीं।
- कानूनी वयस्क सामग्री अनुमत है।
- तकनीकी त्रुटियां अभी भी अस्वीकृति का कारण बन सकती हैं।
यह अंतर उन एप्लिकेशन के लिए महत्वपूर्ण है जिन्हें विभिन्न विषयों को संभालने की आवश्यकता होती है। विशिष्ट सीमा को जानने से आपको अपने फ़िल्टरिंग लॉजिक को सही ढंग से डिज़ाइन करने में मदद मिलती है।
400 बनाम 429 त्रुटियों को डिबग करना
400 त्रुटियां अनुरोध में किसी समस्या को इंगित करती हैं, जैसे अमान्य JSON, आवश्यक फ़ील्ड्स की कमी, या 8 MB अनुरोध बॉडी सीमा से अधिक होना। 429 त्रुटियां इंगित करती हैं कि आप प्रति मिनट 300 अनुरोधों की रेट लिमिट से अधिक हो गए हैं। इन त्रुटियों में अंतर करना आपको सही समस्या को जल्दी ठीक करने में मदद करता है।
400 त्रुटियों के लिए, अपने अनुरोध पेलोड और स्कीमा की जांच करें। 429 त्रुटियों के लिए, बैकऑफ़ लागू करें और कन्करेंसी कम करें। यदि आपको अनुरोध बॉडी साइज के बारे में संदेश वाले 400 त्रुटि प्राप्त होते हैं, तो सुनिश्चित करें कि आप एकल अनुरोध में बहुत अधिक डेटा नहीं भेज रहे हैं। 8 MB की सीमा कठोर है।
त्रुटि कोड
| त्रुटि कोड | अर्थ |
|---|---|
| 400 | बैड रिक्वेस्ट |
| 429 | रेट लिमिट एक्ससीडेडेड |
इन त्रुटियों को उनके संदर्भ (पेलोड, टाइमस्टैम्प) के साथ लॉग करने से डिबगिंग बहुत आसान हो जाता है। अपने एकीकरण को अनुकूलित करने और बार-बार विफलताओं से बचने के लिए इस डेटा का उपयोग करें।
Heretic LLM अनुकूलन के लिए अगले कदम
अनुकूलन आपके टोकन उपयोग और त्रुटि दरों की निगरानी से शुरू होता है। अपने वास्तविक उपभोग को ट्रैक करने के लिए अंतिम SSE चंक से टोकन डेटा का उपयोग करें। सटीकता सुनिश्चित करने के लिए इसे अपने अनुमानित खर्चों से तुलना करें। अपने अवलोकित उपयोग पैटर्न के आधार पर अपनी समवर्तीता और दर सीमा रणनीतियों को समायोजित करें।
अधिक स्थिर JSON आउटपुट या फंक्शन कॉलिंग के लिए कम तापमान का उपयोग करने पर विचार करें। यदि आपको अधिक रचनात्मक प्रतिक्रियाओं की आवश्यकता है, तो तापमान बढ़ाएं लेकिन अधिक पार्सिंग त्रुटियों के लिए तैयार रहें। अपने उपयोग मामले के लिए सही संतुलन खोजने के लिए विभिन्न पैरामीटर के साथ प्रयोग करें।
अनुकूलन टिप्स
- टोकन उपयोग का निकट निरीक्षण करें।
- स्थिरता बनाम रचनात्मकता के लिए तापमान समायोजित करें।
- मजबूत त्रुटि हैंडलिंग लागू करें।
अपने इंटीग्रेशन का परीक्षण करने के लिए मुफ्त ट्रायल से शुरुआत करें। यह एक कम जोखिम वाला तरीका है जो सत्यापित करता है कि आपका क्लाइंट कोड स्ट्रीमिंग, JSON मोड और दर सीमाओं को सही ढंग से संभालता है, इससे पहले कि आप प्रीपेड क्रेडिट के लिए प्रतिबद्ध हों।
