लंबे अनुरोध पर सर्वर त्रुटि या टाइमआउट आए तो क्या करें?

लक्षण

• आप बहुत लंबा टेक्स्ट भेजते हैं, जैसे दसियों हज़ार से लाखों अक्षर, या बहुत लंबा जवाब माँगते हैं।
• कुछ मिनट बाद Server error, please try again later (openai_error), bad response status code 524, टाइमआउट या कनेक्शन बंद होने की त्रुटि आती है।
• उसी समय छोटे अनुरोध काम करते हैं, लेकिन नेटवर्क, VPN या कनेक्शन स्थान बदलने पर भी लंबे काम विफल होते हैं।

कारण

बिना स्ट्रीमिंग वाले आउटपुट में मॉडल पूरा जवाब तैयार करने के बाद ही क्लाइंट को परिणाम मिलता है। लंबे काम में परिणाम आने से पहले क्लाइंट या कनेक्शन के किसी चरण की समय-सीमा पार हो सकती है।

अगर छोटे अनुरोध सफल हैं और लंबे अनुरोध बार-बार विफल होते हैं, तो VPN बदलते रहने के बजाय पहले आउटपुट मोड और काम का आकार जाँचें। केवल त्रुटि संदेश से नेटवर्क की समस्या या सेवा पर अधिक भार की संभावना खारिज नहीं होती।

समाधान

1. स्ट्रीमिंग चालू करें

स्ट्रीमिंग जवाब को छोटे हिस्सों में लौटाती है, जिससे लंबे समय तक डेटा न आने के कारण होने वाले आइडल टाइमआउट कम होते हैं। पहला हिस्सा आने में देरी, क्लाइंट की कुल समय-सीमा या अधिक भार के कारण फिर भी विफलता हो सकती है।

Cherry Studio

यह रास्ता Cherry Studio 2.0.14 के अंग्रेज़ी इंटरफ़ेस में जाँचा गया है:

1. असिस्टेंट की चैट खोलें और ऊपर उसके नाम पर क्लिक करके Edit Assistant (असिस्टेंट संपादित करें) खोलें।
2. Model (मॉडल) चुनें।
3. पक्का करें कि Stream output (स्ट्रीमिंग आउटपुट) चालू है।

Cherry Studio के एक उपयोगकर्ता ने बताया कि स्ट्रीमिंग चालू करने से लंबे कामों में बार-बार होने वाले टाइमआउट ठीक हो गए।

सीधे API कॉल

अपनी BetterToken API Key को BETTERTOKEN_API_KEY पर्यावरण चर में सेट करें और ... की जगह अपना काम लिखें। अनुरोध बॉडी में "stream": true जोड़ें। --no-buffer curl की आउटपुट बफ़रिंग बंद करता है।

curl --no-buffer https://bettertoken.ai/v1/chat/completions \
  -H "Authorization: Bearer $BETTERTOKEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "stream": true,
    "messages": [{"role": "user", "content": "..."}]
  }'

जवाब एक पूरे JSON ऑब्जेक्ट के बजाय SSE इवेंट के रूप में आता है। SDK का इस्तेमाल करते समय हिस्सों को पढ़ने के लिए उसका स्ट्रीमिंग इंटरफ़ेस उपयोग करें।

2. स्ट्रीमिंग उपलब्ध न हो तो काम बाँटें

बड़े टेक्स्ट को हिस्सों में संसाधित करें या परिणाम चरणों में माँगें। स्ट्रीमिंग में भी टाइमआउट हो तो इनपुट या हर जवाब की लंबाई घटाएँ।

3. वही अनुरोध बिना बदलाव बार-बार न भेजें

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

अधिक भार वाले समय

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

समस्या अभी भी है?

सहायता टीम को यह जानकारी दें:

• त्रुटि का अनुमानित समय और समय क्षेत्र।
• Model ID।
• क्लाइंट का नाम और संस्करण।
• स्ट्रीमिंग चालू थी या नहीं और त्रुटि से पहले जवाब का कोई हिस्सा मिला था या नहीं।
• त्रुटि विवरण, अनुरोध ID यदि उपलब्ध हो, और इनपुट की अनुमानित लंबाई।

पूरी API Key या संवेदनशील मूल टेक्स्ट न भेजें।

संबंधित दस्तावेज़

• आउटपुट टोकन सीमा
• API त्रुटि प्रबंधन