AnythingLLM Max Tokens: लंबे जवाब बीच में क्यों रुकते हैं

AnythingLLM का लंबा जवाब वाक्य के बीच में रुक जाए, तो पहले जाँचें कि Max Tokens ने उस जवाब की सीमा तो तय नहीं कर दी। संदर्भ विंडो या प्रॉक्सी का टाइमआउट बढ़ाना उसी समस्या का दूसरा समाधान नहीं है। सही जाँच के लिए वास्तव में भेजा गया आउटपुट बजट, API का finish_reason और केवल एक चीज बदलकर किया गया दोबारा परीक्षण चाहिए; पुरानी सेटिंग सुरक्षित रखें।

जवाब कैसे समाप्त हुआ, उसी आधार पर अगला कदम चुनें

स्क्रीन पर नया पाठ आना बंद होना लक्षण है, निदान नहीं। OpenAI Chat Completions के अनुसार length का अर्थ है कि अनुरोध में निर्धारित टोकन सीमा पूरी हो गई। stop स्वाभाविक समाप्ति या दी गई स्टॉप सीक्वेंस मिलने से आ सकता है। tool_calls का मतलब मॉडल ने किसी टूल को काम सौंपा है, अंतिम जवाब दे दिया है यह नहीं। किसी संगत API के लिए उसके वास्तविक सर्वर व्यवहार की भी जाँच करें।

उपलब्ध प्रमाण	पहले क्या जाँचें	अगला कदम
API ने finish_reason=length लौटाया और प्रभावी आउटपुट बजट पता है	आउटपुट की सीमा	इनपुट समान रखें और केवल समर्थित आउटपुट बजट बदलें
सर्वर स्पष्ट रूप से संदर्भ बहुत बड़ा बताता है; कम इतिहास या कम खोजे गए दस्तावेज़ों के साथ वही काम पूरा होता है	संदर्भ पर दबाव	इनपुट कम करें और मॉडल की वास्तविक विंडो जाँचें; केवल आउटपुट सीमा न बढ़ाएँ
टाइमआउट, कनेक्शन रीसेट या रद्द करने का रिकॉर्ड है, अथवा समाप्ति की वजह दिखे बिना स्ट्रीम रुकती है	कनेक्शन, रद्द किया गया अनुरोध या स्ट्रीमिंग संगतता	समय मिलाकर पता करें कि किस हिस्से में अनुरोध समाप्त हुआ; केवल फ़ील्ड न मिलने से नेटवर्क की खराबी साबित नहीं होती
stop मिला, लेकिन कोई अनुभाग या क्रमांक गायब है	निर्देश, स्टॉप सीक्वेंस और सामग्री की पूर्णता	छूटा हुआ हिस्सा जाँचें; सामान्य समाप्ति का अर्थ काम पूरा होना नहीं है

आउटपुट बजट तय करता है कि एक अनुरोध कितना पाठ उत्पन्न कर सकता है। संदर्भ विंडो उस संदर्भ की क्षमता से संबंधित है जिसे मॉडल संभाल सकता है। इतिहास, सिस्टम निर्देश और खोजे गए दस्तावेज़ों के अंश भी इनपुट में जा सकते हैं; AnythingLLM का Generic OpenAI अडैप्टर इन्हें जोड़ता है। इसलिए छोटा सवाल भी बड़ा अनुरोध बन सकता है, और इंटरफ़ेस में विंडो का बड़ा मान भरने से सर्वर पर मॉडल की क्षमता नहीं बढ़ती।

issue #6703 के एक उपयोगकर्ता ने बताया कि आउटपुट सीमा की वजह से कटे जवाब के लिए वे पहले रिवर्स प्रॉक्सी और WebSocket टाइमआउट जाँचते रहे। यह एक उपयोगकर्ता का अनुभव है, जिससे जाँच का क्रम समझ आता है; इससे आपके मामले की वजह तय नहीं होती।

पुरानी सेटिंग बचाएँ और वास्तविक मॉडल पहचानें

बदलने से पहले मौजूदा स्थिति लिख लें। AnythingLLM का संस्करण, Desktop या स्वयं होस्ट किया हुआ इंस्टॉलेशन, वैश्विक प्रदाता, कार्यक्षेत्र और चैट में चुना गया प्रदाता व मॉडल, एजेंट का इस्तेमाल, संदर्भ विंडो और आउटपुट सेटिंग दर्ज करें। स्क्रीनशॉट में कुंजी छिपाएँ। प्रयोग के लिए पुराना कार्यक्षेत्र, बातचीत या अनुक्रमित दस्तावेज़ न मिटाएँ।

Settings में LLM प्रदाता का कॉन्फ़िगरेशन खोलकर सुनिश्चित करें कि परीक्षण वास्तव में Generic OpenAI से चल रहा है। इसकी आधिकारिक मार्गदर्शिका API के काम करने के तरीके और मॉडल के प्रतिक्रिया प्रारूप, दोनों में OpenAI संगतता माँगती है। किसी दूसरे प्रदाता से अनुरोध जा रहा हो, तो Generic OpenAI बदलने से वह दूसरा रास्ता कॉन्फ़िगर नहीं होगा।

2026-10-16 को पढ़े गए आधिकारिक इंटरफ़ेस कोड में ये फ़ील्ड हैं:

फ़ील्ड	क्या मिलाना है
Base URL, API Key, Selected Model	पहले काम कर चुका पता, उससे संबंधित कुंजी और सटीक मॉडल पहचानकर्ता; केवल दिखाई देने वाले नाम से पहचानकर्ता न बनाएँ
Model context window	कॉन्फ़िगर की गई संदर्भ क्षमता, जवाब का आउटपुट बजट नहीं
Max Tokens	उत्पन्न होने वाले आउटपुट का बजट; इसे संदर्भ सेटिंग से अलग जाँचें

सहेजने के बाद सेटिंग दोबारा खोलकर देखें कि मान बने हुए हैं। अनुरोध रिकॉर्ड देखने की अनुमति हो तो वास्तविक model और आउटपुट सीमा वाला फ़ील्ड भी जाँचें। स्क्रीनशॉट केवल इंटरफ़ेस का मान दिखाता है, सर्वर को मिला अनुरोध नहीं। सामान्य चैट और एजेंट को अलग जाँचें: Desktop v1.16.2 के बदलावों में Generic OpenAI के एजेंट स्ट्रीम में max tokens की अनदेखी होने का सुधार दर्ज है।

आप पहले से BetterToken इस्तेमाल कर रहे हों, तो इसी चरण पर उसके Chat Completions निर्देशों से मौजूदा पता, कुंजी और मॉडल कॉन्फ़िगरेशन मिलाएँ; यह कनेक्शन सेटिंग की संदर्भ सामग्री है, AnythingLLM की हर सुविधा चलने या आउटपुट सीमा हटने की गारंटी नहीं।

0, पैरामीटर का नाम और संस्करण अलग-अलग बातें हैं

0 का मतलब असीमित आउटपुट नहीं है। Desktop v1.17.0 के बदलावों के अनुसार Generic OpenAI में 0 सेट करने पर अनुरोध से max_tokens हटाया जा सकता है। उसके बाद सर्वर के डिफ़ॉल्ट और सीमाएँ लागू होती हैं। निदान के लिए मॉडल द्वारा समर्थित स्पष्ट सकारात्मक बजट बेहतर है, ताकि तुलना समझने योग्य हो।

2026-10-16 को पढ़े गए अडैप्टर कोड में आउटपुट का मान GENERIC_OPEN_AI_MAX_TOKENS से और संदर्भ का मान GENERIC_OPEN_AI_MODEL_TOKEN_LIMIT से आता है। आउटपुट फ़ील्ड डिफ़ॉल्ट रूप से max_tokens है; GENERIC_OPEN_AI_MODEL_MAX_TOKEN_KEY से दूसरा नाम चुना जा सकता है। यह उस कोड का व्यवहार है, हर स्थापित संस्करण में वही नियंत्रण मिलने का दावा नहीं।

हर संगत API में पैरामीटर का नाम मनमाने ढंग से न बदलें। OpenAI के मौजूदा पैरामीटर संदर्भ में max_completion_tokens है, जिसके बजट में दिखाई देने वाला आउटपुट और रीजनिंग टोकन दोनों शामिल हैं। इसलिए छोटा दिखाई देने वाला जवाब भी बजट समाप्त कर सकता है। अपने सर्वर और मॉडल का समर्थित फ़ील्ड जाँचें और केवल समर्थित संस्करण में संबंधित सेटिंग बदलें।

Desktop में इंटरफ़ेस इस्तेमाल करें, किसी कॉपी किए गए उदाहरण से .env न बदलें: आधिकारिक कॉन्फ़िगरेशन दस्तावेज़ ये निर्देश स्वयं होस्ट किए गए या Docker इंस्टॉलेशन के लिए रखता है। v1.17.0 में कार्यक्षेत्र सेटिंग सहेजने का तरीका भी बदला है। हर संस्करण में एक ही बटन खोजने के बजाय सेटिंग दोबारा खोलकर सहेजे गए मान की पुष्टि करें।

finish_reason और वास्तविक उपयोग कहाँ मिलेगा

AnythingLLM को मॉडल सेवा से मिली प्रतिक्रिया को प्राथमिकता दें। बिना स्ट्रीम वाले Chat Completions में choices[0].finish_reason और लौटाया गया usage देखें। स्ट्रीम में समाप्ति की वजह वाला हिस्सा खोजें और जाँचें कि सर्वर की पूरी समाप्ति श्रृंखला आई या नहीं। पहले हिस्से का खाली मान अंतिम स्थिति नहीं होता। आधिकारिक प्रतिक्रिया परिभाषाएँ इसका आधार हैं।

वेब या स्वयं होस्ट किए गए वेब इंटरफ़ेस में ब्राउज़र के डेवलपर टूल्स का Network पैनल खोलें, लॉग सुरक्षित रखने का विकल्प चुनें और समस्या एक बार दोहराएँ। संबंधित चैट अनुरोध का समय, स्थिति और प्रतिक्रिया दर्ज करें। यह ब्राउज़र से AnythingLLM तक का संचार दिखाता है, ज़रूरी नहीं कि मॉडल सेवा का मूल जवाब हो।

2026-10-16 को पढ़े गए Generic OpenAI स्ट्रीम हैंडलर में सर्वर से गैर-खाली समाप्ति वजह मिलने पर उसे AnythingLLM के अपने close: true संदेश में बदला जाता है, मूल वजह उसी रूप में नहीं भेजी जाती। प्रदाता से उपयोग न मिलने पर कोड पाठ के हिस्सों की गिनती से अनुमान भी लगा सकता है। इसलिए इंटरफ़ेस में समाप्ति और टोकन की संख्या दिखना न तो पूर्ण जवाब का प्रमाण है, न बजट ठीक-ठीक समाप्त होने का।

जिन मॉडल-सेवा लॉग या अनुरोध विवरणों तक आपको अनुमति है, उनसे मूल वजह और उपयोग लें। पहुँच न हो तो अनुरोध का समय और पहचानकर्ता अपने इंस्टॉलेशन के व्यवस्थापक को दें। Desktop v1.16.2 में खिड़की के ऊपर संस्करण चिह्न से लॉग और स्टोरेज खोलने का रास्ता बताया गया है; लॉग फ़ोल्डर मिलना यह नहीं बताता कि हर संस्करण मूल समाप्ति फ़ील्ड दर्ज करता है।

स्ट्रीम का अंतिम उपयोग गायब भी हो सकता है: OpenAI बताता है कि स्ट्रीम रुकने या रद्द होने पर अंतिम usage हिस्सा नहीं मिल सकता। ऐसे में “प्राप्त नहीं हुआ” लिखें, शून्य नहीं; ऐप के अनुमान को बिलिंग डेटा न मानें।

पुरानी सेटिंग के साथ छोटे और लंबे जवाब की तुलना करें

पहले अनुरोध का रास्ता समान रखें, फिर माँगी गई जवाब की लंबाई बदलें। ज्ञान-आधार के दस्तावेज़ जोड़े बिना एक परीक्षण कार्यक्षेत्र बनाएँ। वही प्रदाता और मॉडल चुनें तथा सिस्टम निर्देश, तापमान, आउटपुट बजट और बाकी सेटिंग स्थिर रखें। हर परीक्षण खाली चैट में करें, ताकि दूसरे में पहले का इतिहास न जुड़ जाए। पहले सामान्य चैट जाँचें, एजेंट या टूल नहीं।

छोटे जवाब का परीक्षण A:

परियोजना के दस्तावेज़ सँभालने के लिए 3 सुझाव दें। हर सुझाव पर 2–3 वाक्य लिखें। पूरा होने पर अलग पंक्ति में [END] लिखें।

लंबे जवाब का परीक्षण B:

परियोजना के दस्तावेज़ सँभालने के लिए 20 सुझाव दें। हर सुझाव पर 2–3 वाक्य लिखें। पूरा होने पर अलग पंक्ति में [END] लिखें।

अनुरोध भेजें और जनरेशन समाप्त होने दें; रोकने का बटन न दबाएँ और पृष्ठ रीफ़्रेश न करें। टाइमआउट या कनेक्शन टूटने पर बार-बार पुनः प्रयास करने के बजाय समय लिखें। पूरे दिखाई दिए जवाब स्थानीय A.txt और B.txt में कॉपी करें। अनुरोध का समय, वास्तविक मॉडल, प्रभावी बजट, समाप्ति वजह, usage प्रदाता ने दिया या नहीं, अंतिम क्रमांक और [END] की मौजूदगी भी दर्ज करें। यहाँ संख्याएँ परीक्षण की माँग हैं, मॉडल की सीमा या निश्चित जवाब की लंबाई नहीं।

A पूरा और B अधूरा होने से बस इतना पता चलता है कि लंबे आउटपुट में समस्या आती है; Max Tokens वजह है, यह अभी सिद्ध नहीं होता। B में length आए तो उसका वही प्रॉम्प्ट और बाकी सेटिंग रखें, केवल आउटपुट बजट को सर्वर द्वारा स्वीकार्य स्पष्ट बड़े मान पर करें और खाली चैट में C चलाएँ। परिणाम C.txt में बचाएँ। सभी 20 सुझाव, अंतिम चिह्न और length के बिना समाप्ति इस मामले में बजट बढ़ाने के लाभ का प्रमाण हैं।

B पहले ही पूरा हो जाए तो अनावश्यक रूप से बहुत बड़ा बजट न करें। उसी वास्तविक कार्य को पुरानी बातचीत और खाली चैट में समान आउटपुट सेटिंग के साथ तुलना करें। समस्या इतिहास या खोजे गए अंशों के साथ आए तो संदर्भ जाँचें। गैर-ज़रूरी अस्थायी सेटिंग वापस करें और पुराने रिकॉर्ड बचाए रखें। भुगतान वाले API पर इन परीक्षणों का सामान्य अनुरोध शुल्क लग सकता है।

प्रमाण के अनुसार सुधार करें, सारे विकल्प एक साथ नहीं

आउटपुट सीमा पुष्ट है: बजट बदलें और भेजे गए फ़ील्ड को जाँचें

केवल वास्तविक अनुरोध रास्ते में लागू बजट बढ़ाएँ, मॉडल की समर्थित सीमा में। इंटरफ़ेस का मान बढ़ा लेकिन अनुरोध नहीं बदला, तो प्रदाता चयन, सहेजी गई सेटिंग, संस्करण और सामान्य चैट बनाम एजेंट का व्यवहार जाँचें। सर्वर तक न पहुँची आउटपुट सेटिंग को संदर्भ विंडो बढ़ाने से ठीक नहीं किया जा सकता।

संदर्भ बहुत बड़ा है: कार्य और बजट रखते हुए इनपुट घटाएँ

पहले वही लंबा कार्य खाली चैट में दोहराएँ। फिर अलग से खोजे गए अंश या अनावश्यक इतिहास कम करें। सर्वर स्पष्ट संदर्भ त्रुटि दे तो वास्तविक मॉडल क्षमता के अनुसार विंडो रखें; बड़ा अंक भरने से क्षमता नहीं बढ़ती। स्पष्ट त्रुटि के बिना खाली चैट में सुधार हो तो संदर्भ अभी जाँचने योग्य अनुमान है, पुष्टि की गई वजह नहीं।

कनेक्शन या स्ट्रीम विफल है: पहले टूटने वाला हिस्सा पहचानें

ब्राउज़र, AnythingLLM और मॉडल सेवा के एक ही समय के रिकॉर्ड मिलाएँ। रद्द होने, टाइमआउट और कनेक्शन बंद होने के संकेत देखें। मॉडल सेवा ने पूरा किया लेकिन ब्राउज़र को हिस्सा मिला, तो बीच के संचार और प्रदर्शन को जाँचें। मॉडल सेवा ही विफल हुई हो तो उसकी त्रुटि पहले सुलझाएँ। किसी हिस्से का टाइमआउट तभी बदलें जब प्रमाण उसी ओर इशारा करें।

स्वयं होस्ट किए गए या Docker इंस्टॉलेशन के व्यवस्थापक स्ट्रीमिंग को अलग परीक्षण में बंद कर सकते हैं। आधिकारिक कॉन्फ़िगरेशन में GENERIC_OPENAI_STREAMING_DISABLED="true" केवल Generic OpenAI पर लागू होता है; बदलाव के बाद संबंधित सेवा या कंटेनर पुनः शुरू करें। बाकी सब समान रखते हुए वही लंबा प्रॉम्प्ट चलाएँ, फिर पुराना मान वापस करके पुनः शुरू करें। बिना स्ट्रीम के सफलता जाँच को स्ट्रीमिंग वाले हिस्सों तक सीमित करती है, लेकिन प्रॉक्सी को दोषी सिद्ध नहीं करती। Desktop पर यह .env प्रक्रिया न अपनाएँ।

सुधार की पुष्टि और समस्या बचने पर अगला कदम

जवाब लंबा हो जाना पर्याप्त नहीं है। सभी अपेक्षित अनुभाग या क्रमांक, पूरा अंतिम वाक्य और अंतिम चिह्न जाँचें। मूल समाप्ति वजह और कनेक्शन रिकॉर्ड से देखें कि दोबारा कटाव नहीं हुआ। stop और [END] में से कोई भी सामग्री जाँच का विकल्प नहीं। सरल परीक्षण के बाद वह वास्तविक काम भी दोहराएँ जो पहले विफल हुआ था।

समस्या बनी रहे तो व्यवस्थापक को संस्करण और इंस्टॉलेशन प्रकार, सामान्य चैट या एजेंट, प्रदाता व मॉडल पहचानकर्ता, गोपनीय जानकारी हटाई हुई सेटिंग, न्यूनतम प्रॉम्प्ट, A/B/C में अंतर, समय और उपलब्ध मूल समाप्ति वजह भेजें। API कुंजी, प्रमाणीकरण हेडर और निजी दस्तावेज़ का पाठ हटा दें। न मिले फ़ील्ड के लिए “प्राप्त नहीं हुआ” लिखें। इससे अगली जाँच किसी ठोस अनुरोध पर टिकेगी, प्रॉक्सी टाइमआउट की फिर से अटकल लगाने पर नहीं।