जब सफल request भी असल में विफल हो
कल्पना कीजिए कि आप कई हफ़्तों से एक ही character से बात कर रहे हैं। उसकी आवाज़ परिचित है, भाषा लगातार एक जैसी रहती है और जवाब तेज़ व जीवंत लगते हैं।
फिर character या मॉडल बदले बिना अचानक कुछ गलत महसूस होने लगता है।
अगला जवाब शुरू होने में दस सेकंड लेता है। structured output पर निर्भर कोई feature अचानक काम करना बंद कर देता है। character बेमतलब बोलने लगता है, दूसरी भाषा के टुकड़े मिलाता है या ऐसे जवाब देता है जैसे उसे किसी बहुत कमज़ोर मॉडल से बदल दिया गया हो।
Server के नज़रिए से कुछ भी विफल नहीं हुआ। API ने 200 OK लौटाया, tokens आए और request का शुल्क भी लगा।
उपयोगकर्ता के नज़रिए से मॉडल अचानक खराब हो गया।
इसी अंतर के कारण हमने Reverie के लिए provider canary probe और routing quarantine system बनाया।
मॉडल का एक नाम, inference के कई वातावरण
OpenRouter हमारा मुख्य model gateway है। इसकी एक बड़ी ताकत यह है कि एक ही मॉडल को कई स्वतंत्र inference providers चला सकते हैं। यदि एक उपलब्ध न हो, तो दूसरा request संभाल सकता है। इससे हमें किसी एक endpoint पर निर्भर रहने की तुलना में अधिक क्षमता, बेहतर कीमत और अधिक resilience मिलती है।
लेकिन इससे एक छिपा हुआ variable भी जुड़ जाता है।
मॉडल का नाम वही रह सकता है, जबकि उसे चलाने वाला infrastructure हर request में बदल सकता है। हर provider अलग inference engine, hardware configuration, quantization level, parser, chat template, queue या अतिरिक्त policy layer इस्तेमाल कर सकता है।
OpenRouter के provider-routing documentation के अनुसार default routing हाल की availability और कीमत को ध्यान में रखती है तथा अन्य providers को fallback के रूप में रखती है। ये संकेत महत्वपूर्ण हैं, लेकिन कोई endpoint online और सस्ता होने के बावजूद किसी खास product के लिए अस्वीकार्य परिणाम दे सकता है।
OpenRouter ने सार्वजनिक रूप से एक ही मॉडल चलाने वाले providers के बीच मापे जा सकने वाले अंतर पर भी लिखा है। सिद्धांततः समान precision पर समान weights का व्यवहार समान होना चाहिए। लेकिन production में बड़े मॉडल को चलाना जटिल है और अंतर सामने आते हैं।
“मॉडल degradation” से हमारा क्या मतलब है
“मॉडल degradation” कोई एक मानकीकृत diagnosis नहीं है। इसका यह अर्थ भी नहीं कि provider ने जानबूझकर किसी छोटे मॉडल से अदला-बदली की है।
हम इसे operational रूप में परिभाषित करते हैं: जब कोई inference endpoint प्रतिनिधि prompts पर requested मॉडल से अपेक्षित व्यवहार, क्षमताएँ या interactive performance बनाए नहीं रख पाता, तब request तकनीकी रूप से सफल होने पर भी वह endpoint degraded है।
Reverie के लिए इसके सबसे स्पष्ट रूप हैं:
- Latency degradation: connection सफल होता है, लेकिन first token आने में इतना समय लगता है कि live conversation का अनुभव टूट जाता है।
- Capability degradation: structured output देने वाला endpoint malformed text लौटाता है या schema पूरा करना बंद कर देता है।
- Behavioral degradation: जवाब corrupt, असंगत या अनपेक्षित रूप से दोहराव वाले हो जाते हैं, अथवा साफ़ तौर पर किसी दूसरी भाषा में चले जाते हैं।
- Policy mismatch: upstream host अपनी filtering layer जोड़कर Reverie द्वारा समर्थित scene को refusal, empty response या अधूरे जवाब में बदल देता है।
इसके कई कारण हो सकते हैं। कम precision वाली quantization कठिन prompts पर प्रदर्शन घटा सकती है, जैसा OpenRouter documentation और प्रकाशित quantization research दोनों बताते हैं। लेकिन quantization हर समस्या की व्याख्या नहीं है। inference engine या tool parser bugs, tokenizer या chat-template की गलतियाँ, overloaded queues और provider middleware भी उतने ही महत्वपूर्ण हो सकते हैं। OpenRouter ने tool calls में पाया है कि parser implementations अक्सर precision से अधिक provider variance पैदा करते हैं।
महत्वपूर्ण सवाल यह नहीं है कि “कौन-सा कारण सबसे संदिग्ध लगता है?”, बल्कि यह है कि “क्या हम endpoint को अलग करके failure दोहरा सकते हैं?”।
दो मामले जिन्होंने समस्या को वास्तविक बना दिया
हमारे लिए यह सिर्फ़ एक सैद्धांतिक चिंता नहीं थी।
Provider पर pin किए गए एक comparison में एक provider ने 20 में से 19 जवाबों की शुरुआत को punctuation या किसी असंबंधित token fragment से खराब कर दिया। उसी मॉडल को चला रहे अन्य चौदह hosts पर यह समस्या 49 जवाबों में 0 बार आई। Roleplay में पहला character अक्सर Markdown emphasis marker होता है, इसलिए एक अनचाहा byte पूरे जवाब की formatting भी तोड़ सकता था।
एक अन्य test में एक endpoint ने 3 में से 3 generations में Portuguese और Spanish को गंभीर रूप से मिला दिया। वही prompt मॉडल के official host और उसी precision class वाले अन्य tested hosts पर Portuguese में ही रहा। “मॉडल बस inconsistent है” अब अच्छा कारण नहीं था; defect endpoint के साथ चल रहा था।
ऐसी failures सूक्ष्म होती हैं क्योंकि वे हमेशा exception नहीं फेंकतीं। Traditional uptime monitoring को स्वस्थ API दिखाई देती है। उपयोगकर्ता को ऐसा character दिखता है जो अचानक ठीक से बोल नहीं पा रहा।
हमारा जवाब: केवल मॉडल नहीं, हर route को test करना
हर तीस मिनट में हमारा canary Reverie के default chat model को चला रहे active providers खोजता है। फिर वह हर provider को छोटे synthetic requests भेजता है, जिन्हें केवल उसी provider पर pin किया जाता है और fallbacks बंद रहते हैं।
Pinning महत्वपूर्ण है। यदि probe fallback कर सकता है, तो दूसरा स्वस्थ provider पहले की failure छिपा सकता है। हमें ठीक-ठीक पता होना चाहिए कि परिणाम किस inference environment ने बनाया।
System चार सीमित contracts की जाँच करता है जिन्हें code से तय किया जा सकता है।
1. First token तक का समय
Streaming conversation में throughput अनुभव का केवल आधा हिस्सा है। पहला token तय करता है कि उपयोगकर्ता loading indicator कितनी देर देखेगा।
हम इसे सीधे stream से मापते हैं। जो provider दस सेकंड के भीतर text नहीं देता, वह latency probe में fail होता है। Threshold जानबूझकर उदार रखा गया है और एक धीमा round किसी host को हटाने के लिए पर्याप्त नहीं है; queue पर अस्थायी दबाव हो सकता है।
2. Filtering और silent refusals
हम एक fixed roleplay continuation भेजते हैं जो Reverie द्वारा समर्थित traffic का प्रतिनिधित्व करता है। Probe finish reason, high-confidence refusal patterns और empty output की जाँच करता है।
हम इसे known-filtering hosts पर positive controls के रूप में भी चलाते हैं। यदि कोई control अचानक pass हो जाए, तो हम बाकी providers को स्वस्थ घोषित नहीं करते; हम probe को ही कमज़ोर मानते हैं। जो test अपनी known failure नहीं पकड़ सकता, वह health का सबूत नहीं है।
3. Structured output
हम fixed schema वाला एक छोटा object माँगते हैं और परिणाम validate करते हैं। Transport error और malformed output को अलग तरह से माना जाता है: टूटा connection बताता है कि provider पहुँचा नहीं जा सका, जबकि सफल generation का schema पूरा न करना capability regression का प्रमाण है।
“Endpoint parameter support घोषित करता है” और “endpoint उसे भरोसेमंद ढंग से निभाता है” एक ही वादा नहीं हैं।
4. भाषा की अखंडता
Reverie 17 interface languages support करता है, इसलिए केवल English smoke test उन समस्याओं को छोड़ देगा जिनका हमारे users वास्तव में सामना करते हैं।
Canary synthetic roleplay prompts के साथ supported locales को बारी-बारी test करता है। एक local, deterministic language detector पूरे response के स्पष्ट language switch, लगातार code-mixing और साफ़ encoding corruption को खोजता है। वह वास्तविक conversations का उपयोग नहीं करता और किसी दूसरे मॉडल से subjective judgment नहीं माँगता।
Ambiguous या बहुत छोटा output failure नहीं, बल्कि inconclusive माना जाता है। Language failure मिलने पर canary तुरंत दो confirmation attempts चलाता है और majority की माँग करता है। अगली round में वही locale दोहराया जाता है, ताकि provider केवल rotation आगे बढ़ जाने से consecutive-round rule से न बच सके।
हमने system को अपने निष्कर्षों पर संदेह करना सिखाया
Inference capacity को अपने-आप हटाना उपयोगी है, लेकिन false positive मूल defect से बड़ा outage बना सकता है। इसलिए canary में कई safeguards हैं:
- Transport errors quality failures नहीं माने जाते। Timeouts, rate limits और 5xx responses suspension streak बढ़ाने के बजाय score को freeze करते हैं।
- एक खराब round पर्याप्त नहीं है। Provider को हर आधे घंटे चलने वाली लगातार दो rounds में fail होना चाहिए।
- Observation और enforcement अलग हैं। हम system को observe mode में चलाकर देख सकते हैं कि कौन-से hosts suspend होते, administrators को सूचित कर सकते हैं और automatic action से पहले false positives माप सकते हैं।
- Capacity की न्यूनतम सीमा है। यदि suspension के बाद दो से कम production hosts बचेंगे, तो canary provider को नहीं हटाता और administrator को alert करता है।
- Recovery भी test होती है। Suspended providers पर probes चलते रहते हैं। लगातार दो clean rounds host को समय से पहले वापस लाती हैं।
- बार-बार failure पर अवधि धीरे-धीरे बढ़ती है। पहली suspension एक दिन, अगली तीन दिन और उसके बाद सात दिन की होती है। बिना नई suspension के चौदह दिन बाद history fade हो जाती है और ladder फिर शुरू होती है।
उद्देश्य providers को दंडित करना नहीं है। उद्देश्य users के traffic को ऐसे route से हटाना है जिसकी खराबी दोहराई जा सकती है, और समस्या ठीक होने पर वापसी का स्पष्ट रास्ता खुला रखना है।
सुरक्षा की तीन परतें
अंतिम routing decision तीन प्रकार के exclusions मिलाता है:
- Reviewed built-in exclusions उन measured defects या policy mismatches के लिए जिन्हें हम गलती से वापस नहीं लाना चाहते।
- Runtime incident exclusions जिन्हें administrator बिना deployment की प्रतीक्षा किए तुरंत जोड़ सकता है।
- Timed canary suspensions उन providers के लिए जो automatic failure threshold पार करते हैं।
Reverie request बनाते समय इन lists को OpenRouter के provider.ignore preference में मिलाता है। उपयोगकर्ता को तब तक retry नहीं करना पड़ता जब तक संयोग से बेहतर provider न चुन लिया जाए; unhealthy route candidates से बाहर हो जाता है।
हर automatic decision audit log में दर्ज होता है, महत्वपूर्ण transitions पर administrators को notification मिलता है और ज़रूरत पड़ने पर suspension manually हटाई जा सकती है।
यह system क्या guarantee करता है — और क्या नहीं
Canary जानबूझकर सीमित है। Code latency, schema validity, high-confidence filtering, language integrity और encoding health को judge कर सकता है। वह यह score करने का दिखावा नहीं करता कि character पर्याप्त मज़ेदार, भावनात्मक रूप से संवेदनशील या जटिल personality के प्रति पूरी तरह वफ़ादार है।
इन व्यापक सवालों के लिए representative prompts पर evaluations, human review, production telemetry और सबसे महत्वपूर्ण, user reports की ज़रूरत बनी रहती है।
यह system यह भी नहीं कहता कि हर अजीब जवाब degradation का प्रमाण है। Generative models probabilistic होते हैं। लंबी conversation में conflicting context जमा हो सकता है और character definition में प्रतिस्पर्धी instructions हो सकती हैं। कभी-कभी अजीब जवाब सिर्फ़ एक अजीब जवाब होता है।
बदलाव यह है कि अब “मॉडल वही है” हमारी जाँच का अंत नहीं है। अब हम serving route को isolate कर सकते हैं, objective failures दोहरा सकते हैं और बाद का traffic उससे दूर रख सकते हैं।
विश्वसनीयता का अर्थ अनुभव को सुरक्षित रखना है
Multi-provider routing अब भी मूल्यवान है। यह Reverie को वह क्षमता और resilience देता है जिससे किसी एक endpoint के बंद होने पर भी conversations उपलब्ध रहें।
लेकिन resilience केवल HTTP response मिलना नहीं है। जो जवाब बहुत देर से शुरू हो, required structure खो दे, supported content को refuse करे या अचानक भाषा बदल दे, वह केवल invoice पर सफल लिखे होने से स्वस्थ नहीं हो जाता।
AI character product के लिए reliability का अर्थ कुछ अधिक मानवीय है: चाहे कोई भी machine उसकी ओर से बोले, character को वही character महसूस होना चाहिए।
हमारे नए routing safeguards इसी standard की रक्षा के लिए बने हैं।
यदि response quality या भाषा में अचानक बदलाव दिखे, तो model name और लगभग समय के साथ हमें report भेजें। इससे हमें आपके अनुभव को उस exact route से जोड़ने में मदद मिलती है जिसने उसे serve किया था।